If you forgot to track time, do not start by guessing a neat number and moving on. Reconstruct the week from the things that actually happened, mark what is uncertain, and use idle detection as a review aid, not a hidden broom. The point is to keep the record honest, including the non-billable work that would otherwise disappear.
This matters more now because more work gets split between people, tools, and AI agents. If you want a cleaner approach to this, the Harvest alternative page explains how FlatHours handles tracking without metering every part of the account, and our billing for the work AI agents do page covers the part many teams are now trying to untangle by hand.
What to do when you forgot to track time
Start with the calendar, not the timesheet. Pull up meetings, calls, commits, files, messages, and anything else that pins work to a moment. Then write the day back in the order it happened, even if the gaps are awkward.
Do not try to make every missing block perfect. Put down the calls you remember, the task you were on, and the work that clearly took place between them. If a stretch cannot be defended from evidence, label it as uncertain rather than smuggling it in as fact.
Rebuild the week in layers
- First layer, fixed events: meetings, deadlines, hand-offs, client calls, releases.
- Second layer, visible work: tickets closed, documents edited, code merged, designs sent, invoices drafted.
- Third layer, supporting work: admin, review, internal notes, chasing answers, context gathering.
This is slower than filling in a blank timesheet from memory. That is the point. A good log is not a confession of productivity, it is a record you could defend if a client asked how the day went.
For teams that have already lost a month of detail, this also connects to broader billing hygiene. Our billing data CSV export guide goes deeper on what to do when the past exists, but not in a clean shape.
Why idle detection helps, when it is used honestly
Idle detection can save a lot of repair work. It can show where the log stopped while the person was still present, or where a timer kept running after attention moved elsewhere. That is useful because memory is bad at noticing drift.
The important part is what happens next. Idle detection should create a prompt for review. It should ask whether the timer was still valid. It should not decide in secret that those minutes do not count.
Silent deletion is the problem. If a system trims time without showing the user, the record stops being a record. It becomes an edit made by software, and nobody can tell whether the absence was real or convenient.
That is especially dangerous in a billing system. If time can disappear quietly, then the person who needs the audit trail has less of it, and the person doing the work has no clean way to explain the missing period. FlatHours never charges for invoices sent, projects created, clients added, tasks used, or a percentage of payments you collect, and that matters because tracking should not become a second bill hidden inside the tool.
What honest idle detection looks like
- It flags suspected idle time for review.
- It keeps the original entry visible until someone acts.
- It records the choice, whether the time stayed, changed, or was removed.
- It does not turn uncertainty into deletion.
There is a fair counter-argument. Some people want the cleanest possible timesheet and do not want to review pauses at all. If the work is simple and the team is small, that can feel faster. But speed is not the same as accuracy, and once the bill is tied to the log, hidden trimming becomes a trust problem, not just a usability choice.
Forgot to track time, and the non-billable work still counts
Many teams only remember to log the obvious billable bits. That leaves out support work, internal prep, admin, handovers, quality checks, and the small interruptions that make the paid work possible. Over time, that creates a false story about how the week was spent.
Non-billable work matters even when no client sees it. It tells you why utilisation looks lower than expected, why a project needed more coordination than the brief suggested, and why a week that felt full did not all turn into invoiceable time. If you never record that work, you end up blaming the wrong thing.
It also helps when scope drifts. A task that starts as a short fix can quietly become a series of questions, reviews, and internal passes. If only the final polish is logged, the numbers make the job look simpler than it was. That is how underpricing survives.
| Work type | Why it belongs in the log | What happens if it is skipped |
|---|---|---|
| Client calls | They explain interruptions and decision time. | The day looks shorter than it was. |
| Internal review | It shows how much effort quality actually takes. | Projects seem cheaper than they really are. |
| Admin and coordination | It reveals the hidden cost of keeping work moving. | The team appears less busy than it is. |
| AI-assisted work | It shows where human oversight and cleanup still happen. | Automation looks more complete than it was. |
That last row matters more every month. If an AI agent drafted the first pass, someone still checked it, corrected it, and decided whether it could ship. The human work did not vanish. It changed shape. If the log only records the final output, you will miss the supervision cost and treat a mixed workflow like a magic trick.
For teams sorting out that new split between human and machine effort, our page on billing the work AI agents do is the direct next step. It is the same principle as any other tracking problem: if it took time, record it in a way that can be explained later.
How to keep the record honest without making it painful
The best system is not the one with the most rules. It is the one that makes corrections easy and hidden changes hard. People will forget to track time. That part is normal. The software should help them recover the week without rewriting it.
A good workflow looks like this: track as you go when you can, review idle prompts at the end of the day, and fill in gaps from evidence rather than from a wish to look tidy. If a block remains uncertain, leave it visibly uncertain until you have enough context to defend it.
That approach is worth more than a perfect-looking timesheet. It produces numbers you can trust, invoice lines you can explain, and a cleaner view of where the week actually went. It also makes non-billable work visible instead of treating it as a leak.
The uncomfortable truth is that many teams do not have a tracking problem, they have a truth problem. They know roughly what happened, but not well enough to bill it cleanly or improve it later. That is why the answer to forgot to track time is not to guess harder. It is to rebuild the week honestly, keep idle detection visible, and log the work that would otherwise disappear.