How to reconstruct a week you forgot to track

It is Friday afternoon, the invoice is due Monday, and the timer has been sitting at zero since Tuesday morning. You know you worked. You cannot say for how long, or on what, with the kind of precision you would be comfortable putting on a document that asks someone for money.

Most advice at this point is “track better next time”, which is true and useless. Here is the method for this week.

Start from evidence, not memory

Memory is the worst input available and it is the one everybody reaches for first. You will remember the two hours of deep work and forget the forty minutes of scattered follow-up either side of it. The reconstruction will come out low, which feels honest and is actually just inaccurate in the direction that costs you.

Your tools kept a record. Collect it before you write anything down:

Calendar. Meetings, with their real start and end if your calendar tracks that.
Sent mail and messages. Timestamps bracket when you were at the desk. The content tells you which client.
Version control. git log --author="you" --since="last monday" --date=iso gives you a timestamped list of what you shipped.
Editor and browser history. Not to reconstruct the work, but to establish presence: a run of activity from 09:12 to 11:40 is a boundary you can trust more than a recollection.
Documents and design files. Most of them keep revision history with times.

None of these tell you how long you worked. All of them tell you when you were working, which is the harder half.

Build the day as blocks, not as totals

Do not start by asking “how many hours did I put into Meridian this week”. Start by asking “what was I doing at 10am on Wednesday”. Blocks, in order, across the day.

The reason is that a total invites you to pick a comfortable number and defend it afterwards. A timeline forces you to account for the gaps, and the gaps are where the argument with yourself actually happens. When you find ninety minutes on Thursday you genuinely cannot place, you will be tempted to attach it to whichever client had the most work that day. Do not. Leave it unattached and decide about it deliberately at the end.

A workable block list for one day looks like this:

09:10 - 09:35   email, mixed clients, unbillable
09:35 - 11:20   Meridian, auth refactor       (git: 4 commits, 09:41-11:14)
11:20 - 11:45   gap, no evidence
11:45 - 12:30   Kestrel, call                 (calendar)
13:30 - 15:50   Meridian, auth refactor       (git: 3 commits)
15:50 - 16:20   review and PR comments        (github timestamps)

Rules for the gaps

You will have gaps. Three rules keep them honest.

A gap with no evidence on either side is not billable. If nothing happened before it and nothing happened after it, you were probably not working.

A short gap bracketed by the same client is billable. Twelve minutes between two commits on the same branch is thinking time, not a break. Twelve minutes is also roughly where this stops being obviously true. Past about twenty minutes, ask what you were actually doing.

A long gap bracketed by different clients is context switching, and it is real work that is usually unbillable. Note it anyway. Over a few weeks it tells you something useful about how fragmented your schedule is, which is a separate conversation worth having with yourself.

Round in the client’s favour, once

Every rounding decision in the reconstruction should go the same direction, and it should go against you. Not because you owe anyone the benefit of the doubt, but because a reconstructed invoice is one you may have to defend, and “I rounded down wherever I was unsure” is a complete answer to any challenge. “I rounded to the nearest half hour” is not, because the client can do arithmetic and will notice it always landed upward.

Round once, at the block level, and never again at the total. Rounding a total that is already made of rounded blocks compounds the error.

Write down what you assumed

Attach a short note to the entry, in whatever field your tracker gives you. Not for the client. For you, in five weeks, when the client queries it.

Reconstructed Friday 15 Aug from git log, calendar and sent mail. Wednesday afternoon has a 90 minute block placed on Meridian based on commit times either side. Lower confidence than the rest.

If the query ever comes, that note is the difference between a two-minute answer and an afternoon of archaeology. If it never comes, it cost you thirty seconds.

Decide about the unattached time deliberately

At the end you will have some hours you could not place. You have three honest options and one dishonest one.

The dishonest one is spreading it proportionally across clients so the numbers come out round. It looks reasonable and it is guessing with extra steps.

The honest options: write it off, bill it to whichever client the surrounding evidence actually points at and mark it low confidence, or bill it as a separate line the client can query. Which you pick depends on the relationship. Writing it off is not weakness, it is the price of not having tracked it, and it is a price you only pay once if you fix the underlying problem.

Then fix the underlying problem

Reconstruction is a skill worth having and a habit worth not needing. The reason the week went untracked is almost never that you forgot the concept of a timer. It is that starting one requires you to decide, in advance, what you are about to work on, at the exact moment you least want to think about it.

Any approach that removes the decision works. Some people keep a text file open and stamp a line whenever they switch. Some run a script on a cron that asks what they are doing. Some use software that watches which application has focus and builds the timeline without being asked, which is the approach Stunda takes, and which exists because the ritual described above used to happen monthly to the person who built it.

Whatever you choose, the test is the same: does it still produce a record on the day you are too busy to maintain it. Friday afternoon is when you find out.

The short version

Collect timestamps from calendar, mail, version control and file history before writing anything down.
Rebuild the day as ordered blocks, not as a total.
Leave unexplained gaps unattached until the end.
Round against yourself, once, at the block level.
Note what you assumed, on the entry.
Decide about the leftover time on purpose rather than by spreading it.

It takes about forty minutes for a week. It is worth doing properly, and it is worth arranging your setup so you do not have to do it again.