Happy Tracker

What a Client Actually Wants to See When They Query an Invoice

An invoice goes out. A day later the reply says some version of “can you break this down for us?” or, less politely, “this seems high.”

The instinct is to export everything and send it. That is almost always the wrong move, and it is worth understanding why before reaching for the export button.

What they are actually asking

Almost nobody querying an invoice is accusing you of inventing hours. What has usually happened is that somebody internally has to justify the number to somebody else, and they cannot, because the invoice says “Development – 42 hours” and that is not a sentence anyone can defend in a meeting.

So the question is not “prove these hours happened.” It is “give me something I can forward.”

That changes what you send.

Table of three things to send when a client queries an invoice
What settles a query, and in what order.

One: the work, grouped by what they recognise

Not by day, not by person — by the thing they asked for. “Checkout redesign, 14 hours. Payment gateway integration, 11 hours. Bug fixes from the 12th, 9 hours. Calls and review, 8 hours.”

Four lines. Each one is something the client remembers asking for or agreeing to. The total is the same number that was on the invoice, and now it is a number somebody can forward to their finance person without a covering explanation.

This alone resolves most queries. If your time is tracked against projects and tasks, it is a report you already have rather than something you assemble by hand on a Friday.

Two: dates and who

If the first answer is not enough, add when and by whom. “Checkout redesign: Priya, 3rd to 7th. Payment gateway: Suresh, 8th to 11th.”

Hours are abstract. A sequence of days with names attached reads like a project, because it was one. Clients who were unsure about 42 hours are usually fine with “two people, a week and a half, these four things.”

Three: screenshots, and only if they ask

Here is the part people get wrong.

If you track screenshots, you have evidence that work happened. It is tempting to attach it, and it almost always backfires when unprompted.

Sending screenshots nobody asked for says that you expected not to be believed. It changes the conversation from “help me understand this” to “prove it”, and once a relationship is in that mode it tends to stay there.

Keep them. If the client genuinely does not believe the hours — which is rare and sounds different — then two or three images from the relevant days, with the explanation, ends the conversation immediately. That is what the evidence is for: the case where it is needed, not every case.

Table of unhelpful responses to an invoice query
Four common replies and what the client reads into them.

The four replies that make it worse

A CSV of every entry. Four hundred rows of three-minute increments is not transparency, it is a wall. The client asked for clarity and received homework.

Unrequested screenshots. Covered above. It reads as defensive even when it is meant as helpful.

A long explanation of how you track time. Nobody asked about your process. Explaining the methodology implies the number needs methodology to be believed.

Two days of silence. This is the worst one and the most common. Whatever you are doing in those two days — assembling a perfect answer, usually — the client is reading it as you working out what to say. A same-day “looking at this now, full breakdown tomorrow” costs nothing and removes the suspicion entirely.

What makes this easy or hard

Everything above is trivial if the time was tracked against projects and tasks as it happened. It is painful if it was not, because then you are reconstructing a month from memory and a calendar, and the result will be round numbers that look reconstructed — which they are.

Three habits make the difference:

Tasks named the way the client names them. If they call it “the checkout thing”, the task should not be called “CHK-204 frontend refactor”. The whole point is that the breakdown should be recognisable to them.

Billable and non-billable separated as the work happens. An internal meeting about their project is real work and may not be chargeable. Sorting that out at invoice time is guesswork; marking it while it happens takes a second.

No catch-all project. Hours sitting in “General” cannot be explained to anybody. If a third of the month is in the catch-all, the invoice cannot be defended no matter how accurate it is.

When they are right

Occasionally the invoice is wrong. Somebody left a timer running overnight, or logged a day to the wrong client, or a session was closed by the system at the daily limit and recorded as full hours.

If that is what happened, say so plainly, credit it, and send the corrected invoice the same day. A client who sees an error acknowledged in one sentence trusts the next invoice more than one who has never had reason to check.

The alternative — defending a number you are not sure about — is how a billing query becomes a relationship problem.