ZAMBO.

Direct answer

Every hour, they ask. Send the work, not the timer.

The invoice was fair and the hours were real, and now the client wants a detailed breakdown of every hour you billed. The instinct is to export the time tracker and send the log, start times, stop times, app names, maybe screenshots. That export proves a timer ran. It does not show what the hours produced, which is the only thing the client is actually doubting, and a wall of timestamps invites an argument about minutes instead of a decision about work. Send the opposite document: the work itself, step by step, each step tied to the output it produced, with the hours as a short summary on top. Here is how to build that breakdown, for this invoice and for every invoice after it.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated October 30, 2026. First published October 30, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service.

Step 1. Work out what the request is really asking

A detailed-breakdown request is rarely about arithmetic. It is one of three doubts wearing an admin costume: the client cannot connect the hours to anything they received, the total surprised them against a quote or a budget, or someone above them needs a document before they can release payment. Each doubt has a different cure, and none of them is a longer timestamp list. Output answers the first, a reconciliation against the quote answers the second, and a clean single document answers the third. Ask one short question if the reason is not obvious from the thread, then build the breakdown for the real doubt. Sending the wrong proof, however detailed, just restarts the conversation at a higher volume.

Step 2. Build the breakdown out of steps and outputs, not timestamps

Structure the breakdown as the job itself, in the order it ran: each stage or work session as one line carrying four things, the date, what was done in plain words, the output that step produced (the draft, the fix, the file, the decision), and the time that step accounts for. Group small fragments honestly into the stage they belonged to rather than inventing precision you do not have; a breakdown that admits a rounded block reads as more truthful than one claiming eleven exact minutes on a Tuesday. Close the table with the total, which should match the invoice to the hour and the cent. If it does not match, you have found a real error, and step 4 covers what to do with it. The test for every line is simple: could the client open the output named on that line and see the work the hours bought?

Step 3. Read the two states your steps can sit in when the client checks

A breakdown built from outputs is strong. A breakdown whose outputs sit on a record the client can open and check is stronger, because the client stops taking your word for the shape of the job. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the states a job's steps can carry:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted record, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, decided 2026-10-16T14:31:51.146Z in that example, is a job whose steps the client side already walked and decided on: a breakdown drawn from it is a summary of a decision, not a fresh claim. A pending record, 5 of 5 steps checked and release_hint hold, is checked work still waiting for its decision, and there the breakdown doubles as the review document: send it with the link, and the hours conversation and the acceptance happen on the same page. Know which state your job is in before you send either.

Step 4. Send it as one document, with the errors owned first

Send the breakdown once, as a single document or a single link, with a two-line cover note: here is what each block of time produced, the total matches the invoice, and anything that looks wrong, tell me the line and I will answer it line by line. If building the breakdown surfaced an error of yours, a double-counted block, time billed to the wrong job, say so in the cover note and credit it in the same message, before the client finds it. An error you surface costs you that block. An error the client surfaces costs you the whole document's credibility, including the ninety percent that was accurate. Then stop. Do not send the raw tracker data as a supplement unless it is asked for by name; volunteering surveillance-grade detail reframes skilled work as monitored labour and trains the client to audit minutes forever.

Step 5. If a line is still challenged, answer that line only

When a specific block is disputed, keep the dispute at that size: answer with that step's output, its date, and whatever surrounds it, the request that started it, the feedback that closed it. Offer the honest outcomes for a line you cannot support: it comes off. Lines you can support stand, with their outputs open. What never helps is relitigating the whole invoice because one afternoon is contested, or discounting the total to end the conversation, which reads as an admission that the total was soft. Most breakdown requests end after step 4, because most clients were not accusing you of inventing hours; they could not see the work inside the number, and now they can.

Step 6. Run the next job so the breakdown already exists

The lasting fix is to stop reconstructing breakdowns from a timer after the fact. Work in stages that close as records: each stage delivered as a handover with its steps and outputs saved as they happen, accepted or flagged by the client as the job runs. Then a breakdown request, from this client or their finance team or their auditor, is answered by forwarding a link that already exists, in minutes, instead of an evening of archaeology through a tracker. Agree the shape at the start of the next job, in one line in the agreement: billing is supported by the delivery record, steps and outputs, available on request. Clients who intend to pay sign that happily. Clients who plan to audit minutes will show it early, which is when you want to know.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the hours billed equal the hours worked, does not judge whether the time was well spent, and cannot make a client accept a line they dispute. The step-by-step outputs, the matching total, and the errors you owned yourself are what the conversation stands on. This page is general information, not legal advice.

Frequently asked questions

My client wants a detailed breakdown of every hour I billed. What should I send them?

Send the work, not the timer: a step-by-step breakdown where each block of time carries its date, a plain-words description, the output that step produced, and the time it accounts for, closing with a total that matches the invoice exactly. A raw tracker export proves a timer ran; it cannot show what the hours bought, which is the doubt underneath the request. Build the breakdown from outputs, group small fragments honestly into their stage instead of inventing minute precision, and if you find an error of yours while building it, credit that line in the same message before the client finds it. Send it once, as one document or one link, and answer any later challenge line by line, never by discounting the whole total.

Should I send screenshots or my time-tracker export as the breakdown?

Not as the main document. Screenshots show a screen at a moment, and a tracker export shows a timer's start and stop times; neither connects an hour to the thing it produced, so both invite the client to argue about minutes and activity instead of deciding about work. Send the output-based breakdown first. If the client or their finance process then asks for the tracker data by name, send it as a supplement behind the breakdown, where it supports a document that already makes sense on its own. The order matters: outputs answer the question, surveillance data only corroborates it.

The job was a fixed price, not hourly. Do I still owe a breakdown?

You owe an account of the work, not an hourly accounting you never agreed to keep. Send the same step-by-step document with the time column replaced by the stage price from the quote: each stage, its output, its acceptance state. Be plain in the cover note that the job was priced by stage, so the breakdown shows what each part of the price bought rather than hours nobody tracked. Inventing retroactive hours for a fixed-price job helps nobody; it fabricates precision and hands the client a per-hour rate argument you never signed up for. What you never withhold is the work record itself, which is theirs to check either way.

What if I did not track my time in detail and cannot reconstruct every hour?

Say so, and send what genuinely exists: the staged outputs with their real dates, from file history, messages, and the delivery record, grouped honestly at the level you can support, stage by stage rather than hour by hour. A truthful coarse breakdown beats a precise invented one every time, because one discovered fabrication discredits every true line around it. For the amount itself, the accepted stages carry the price; where a specific block cannot be supported at all, the fair move is to name it and, if it is material, credit it. Then fix the process on the next job so the record builds itself as the work runs.

How do I make the next breakdown send itself?

Run the job in stages that close on a record as they finish: each stage delivered as a handover, its steps and outputs saved with a receipt as the work happens, and the client accepting or flagging each stage on the same link. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, so the breakdown is the record itself, steps, outputs, dates, and decision states, ready to forward the moment anyone asks. New users get 20 calls and 1 wrap-up free every day, and picking up work in another AI is always free. For $0.99, run the next billed job that way and answer the next breakdown request with a link: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related