How to write a time report your client actually reads

A time report has one job: to let your client see what their money bought without having to ask. When it does that job, the invoice that follows is a formality. When it doesn’t, the questions arrive anyway, usually by email, usually on the day the invoice does.

A report can fail without being wrong. The hours are right and the work was done, but it was written for the person who did the work rather than the person who pays for it. A client reading a report wants answers to three questions: how much, on what, and is the work moving. Everything below is about answering those three, in that order, before the reader gives up.

Start with the total

The first thing a client looks for is the number they will be billed for. Put it at the top, with the period it covers, so nobody has to add up a column to find it. “40:00 for the week of 5 October” answers the first question before a single row has been read.

If the work runs against something, put that beside the total: an agreed budget for the month, an estimate for the project, or the hours left on a prepaid block. A total on its own tells the client what happened. A total beside the number it is measured against tells them whether that was expected.

Write hours the same way every time. If you bill in hours and minutes, show hours and minutes, and do not switch to decimals halfway down the page. A reader who has to convert 13:05 into 13.08 is no longer reading about the work.

Group the hours by the work

A list of work sessions is how your week looked to you. It is not how it looks to your client. They think in pieces of work: the checkout, the new pages, the migration, the review calls. Group the hours that way and the second question answers itself.

Four lines like these say more than forty sessions:

• Mobile navigation: 11:40
• Checkout and validation: 13:05
• Performance: 8:25
• Calls and feedback: 6:50

Name each area the way the client names the work. If the brief says “checkout”, don’t call it “payment flow refactor” in the report. Their words make the report easy to match against what they asked for, and easy to forward to whoever approves the spend.

Keep the number of areas small enough to scan. If a week genuinely went into a dozen things, group the small ones under a heading that is still honest, such as “Fixes and small changes”, rather than giving each its own line.

Calls and meetings belong in the report too. Leaving them out makes the rest look padded, because the total no longer matches the visible work. Name them for what they were for, not for the fact that they happened.

Write a summary of a few lines

Under the hours, say what changed. A summary of three or four short lines is usually enough:

• what was finished,
• what is in progress,
• what is next,
• and anything you need from the client.

Write each line as a plain statement of the result: “Fixed the checkout validation issue” rather than “Worked on checkout validation”. The first tells the client something is done. The second only tells them time went somewhere.

The line that is easiest to skip is the one about what you need. If you are waiting on content, access or a decision, say so in the report, plainly, with what it is blocking. A request in a report has a date on it and a reason beside it, and it reaches the person who reads the hours.

Leave out what the client cannot use

A report is not the record. Start and end times for every session, the tools you had open, the order you did things in and your session notes all belong in your own record, where they are there when you need them. In the report they are noise, and noise makes a reader suspicious of the parts that matter.

Leave out apologies and justifications too. If a piece of work took longer than expected, say what it was and why in one line of the summary. A paragraph of explanation draws more attention to the overrun than the overrun itself.

The detail you leave out is not gone. If the client asks what went into “Performance”, you can answer from the record for those days, quickly and precisely, because it was made while you worked rather than rebuilt afterwards.

Send it on a rhythm

A report that arrives on the same day each week becomes something the client expects, reads and stops worrying about. One that arrives when you remember becomes a surprise, and surprises get questions.

A weekly report suits work that changes from week to week. Work that moves slowly can take a longer gap, as long as nothing in it would have been better said sooner. Whatever the rhythm, send the report before the invoice, not with it. The invoice should hold no news: a client who has already seen the hours by area of work reads it as a total they know.

Check it before it goes

Read the report once as the client would, before it goes out. Does the total match what you will bill? Would the client recognize every area by its name? Is there anything in a note or a summary that you would not want them to see? A minute here saves an email thread later.

A report is a habit, not a document

The first report takes thought. The tenth should take minutes, because the structure is settled: the total, the areas, a few lines of summary, and anything you need. Clients notice that consistency more than any single report. After a few weeks they stop asking what the hours went into, because the answer has been arriving on schedule all along.