How much billable time do you lose reconstructing hours?

It’s the 28th. You’re making invoices. You’re looking at a client’s name and trying to remember that Thursday afternoon three weeks ago. Was it 2 hours? Two and a half? There was a long email thread that day — but was that before or after the main work block? You write “2h” and move on.

That’s not laziness. That’s the best you can do with the information available.

The problem is that “the best you can do from memory” isn’t very accurate. And the error systematically favors the client.

How memory degrades for time estimation

Research on retrospective time estimation is consistent: accuracy drops off fast.

The same day, you can reconstruct what you did with roughly 90% accuracy. You remember the session, the interruptions, the rough shape of the afternoon.

24 hours later, that drops to around 75%. You remember that the work happened. You lose the edges. A 90-minute block gets rounded to an hour. A meeting that ran 20 minutes over gets remembered as “about two hours.”

After a week, accuracy is somewhere around 30–40%. You remember the client, the topic, the general sense that it was a long day. But you’re estimating the hours — not recalling them. And estimates this far from the event are essentially guesses.

The dangerous part isn’t the sessions you forget entirely — those are visible. It’s the medium ones. The 90-minute call you misremember as an hour. The afternoon that felt full but was actually 4 hours. These errors go in both directions, but they tend to round down, because nobody wants to overbill.

What this costs in practice

Say you work 20 billable hours a week and invoice monthly. On the last week of the month, your recall is close to 90%. On the first week of the month — now 3–4 weeks ago — you’re down to 30–40%.

That means roughly half your invoiced hours are based on significantly degraded memory. If your effective error on those hours is 20% — not rounding to zero, just shaving 12 minutes off a session here, forgetting a short block there — the numbers compound fast.

At €80/h:

• 20 billable hours/week × 4 weeks = 80 hours
• 40 hours invoiced from degraded memory × 20% error = 8 hours lost
• 8h × €80 = €640/month
• Over 12 months: ~€7,600/year

At €120/h, that’s closer to €11,500/year.

None of this is intentional. You’re not trying to under-bill. You’re working with unreliable inputs.

Why this matters more than forgotten sessions

Most freelancers who think about unbilled time focus on sessions they forgot completely. A whole week they didn’t track. Entries missed during a busy stretch.

Memory inaccuracy is a different problem. The sessions are there — you invoiced for them. You just invoiced for less than you actually worked. And you’ll never know, because a “precise” invoice and an “imprecise” invoice look identical. They’re both a number you wrote down.

This is also why this problem is hard to fix with discipline alone. You’re not forgetting to track. You’re tracking from a degraded source.

What a calendar record actually is

A calendar event is created at the point of planning — not at the point of remembering.

When you block 2 hours for a client on Tuesday morning, that event exists before the work starts. It has a timestamp, a duration, a name. When Tuesday afternoon the session runs 30 minutes long, you adjust the end time. When you add the client prefix to the title — even just [ClientName] — the event becomes an unambiguous billing record.

At month-end, you’re not reconstructing. You’re reading. The naming convention takes a few seconds per event and captures the data at the moment it’s accurate.

Timescanner reads those tagged events and outputs billable hours by client, without any additional logging step. The accuracy isn’t 90% or 30% — it’s whatever precision you had when you put the block in your calendar. For most people, that’s close to 100%.

The error is invisible by design

Memory inaccuracy in billing is different from every other financial leak because there’s no signal. No error message. No missing entry. Just invoices that are slightly lower than they should be, month after month, in amounts too small to notice individually.

The cumulative number is large. The individual instances are invisible. That’s the pattern that’s hardest to fix without changing the data source entirely.