Proving your hours when a client disputes an invoice
· 6 min read
An invoice comes back with a question. Sometimes politely: could you break down the forty hours? Sometimes not: this seems high. Either way the conversation you are now in is about evidence, and the evidence you have was decided weeks ago.
The thing that matters is when the record was made
A record kept as the work happened carries weight. A breakdown produced after the challenge does not, however accurate it is.
This is not about honesty; it is about what the other person can reasonably conclude. A schedule assembled in response to a dispute is, from their side, indistinguishable from a justification. They cannot tell whether you are reporting or reconstructing, and neither can you, entirely, because memory reorganises itself around the story you are telling.
So the useful work is done before there is a dispute, and it is the only kind that helps once there is.
What a contemporaneous record looks like
It does not have to be elaborate. What it needs is to have existed before the question was asked, and to be dated.
An automatic record of application usage is a good foundation because it is not self-reported. It shows how long the machine was in use and what kind of work it was doing, and it was generated at the time without you deciding anything. Add a short daily note allocating that time to the work, written the same day, and you have something with a date and a provenance.
That combination is more persuasive than a detailed timesheet compiled later, because its structure shows it was not made for this argument.
What to actually send
Restraint helps more than volume.
Send a summary at the level the invoice was written: dates, hours, and a phrase describing the work. Offer the detail rather than attaching it. A client asking a routine question wants reassurance, not a data dump, and a wall of evidence reads as defensiveness.
Keep the tone matter of fact. Here is the breakdown by day. I keep an automatic record of working time and allocate it daily; happy to go through any of it. That sentence does the work, because it explains where the numbers came from without arguing.
Never send a raw record with client-identifying material in it, particularly if you work for more than one client. This is a real risk with tools that capture window titles or take screenshots: a screenshot proving you were working may also show another client’s name. That is a worse problem than the invoice.
When the dispute is really about something else
Worth considering before you assemble anything.
A client who is surprised by a bill is usually not disputing the hours. They are disputing the expectation. Either the scope grew without a conversation, or an estimate was treated as a quote, or nobody told them when the budget was half spent.
If that is what happened, evidence of the hours will not resolve it, because the hours were never the disagreement. The answer is a conversation about scope, and probably an acknowledgement that the update should have come earlier.
The genuine version of the dispute, where someone thinks the work should have taken less time, is less common than it feels in the moment.
Preventing it
Most of these never happen if the client sees the number before the invoice does.
Send a figure mid-project. A single line saying eighteen of the estimated forty hours are used is enough. Nobody is ever surprised by an invoice they were warned about.
Flag scope changes when they occur. That addition is roughly six hours; shall I proceed? takes a minute and removes the entire argument later.
Invoice more often. A monthly bill for a long project produces a small correction early rather than a large one at the end.
How to show a client where the time went without a timesheet covers the mid-project update, and how to estimate hours for a quote covers setting expectations that do not need defending.
Where Punchcard fits
Punchcard sits in the menu bar and prints a receipt of the day at the closing time you set: one line per application, the day’s total, a date stamp. Those receipts accumulate as a dated record of working time that was generated automatically rather than written by you.
What it does not record is which client anything was for, or what was in any document. It sees application names only, never window titles or file names, so a receipt cannot expose one client’s material to another. For anyone working with several clients, that constraint is what makes the record safe to reference at all.
The allocation to clients is a daily step you do yourself, and doing it the same day is what turns a raw record into evidence. Turning receipts into a simple invoice line covers making that routine.
If it escalates
For most disputes, a calm breakdown and a conversation settles it. If it does not:
Go back to what was agreed in writing. A dispute about hours is often a dispute about scope, and the scope document decides it.
Consider whether the relationship is worth the difference. A long argument over a few hours costs more in unbilled time than the hours in question, and that arithmetic is worth doing explicitly.
Where a payment is genuinely being withheld, contemporaneous records are what any formal process will ask for. Which returns to the same point: the record has to have existed already.
Questions
Are automatic records accepted as proof? They are corroboration rather than proof, and they are considerably better than an assertion. What gives them weight is that they were generated continuously rather than compiled afterwards.
Should I offer the detail unprompted? No. Send the summary, offer the detail. Volunteering everything looks like anticipating an accusation.
The client says the work should have taken less time. That is a scope and expectation conversation, not an evidence one. Records show what happened; they do not settle what should have happened. Address the estimate directly.
What if my record has gaps? Say so plainly. A record with an acknowledged gap and a note explaining it is more credible than one that is suspiciously complete.