Direct answer

Proof of Work for Clients

Proof of work for a client is a packet, not a promise: the goal, the steps in order, the output each step produced, a verifiable receipt for each recorded step, and the client acceptance on the same record. Send that packet with the invoice, or before it, and a client who wants to check the work can check it in minutes instead of taking your word for it. This page shows what proof looks like in each trade, how to attach it, and what to do when a client disputes the bill.

See the packet shape first: the worked example at zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 is waiting on its client, and this accepted example shows the closed state. Check any receipt free at the public verifier.

Updated October 20, 2026.

What counts as proof of work

A screenshot proves you can take a screenshot. A summary email proves you can write a summary. Real proof of work is a record the client can check without trusting you: what was asked, what ran, in what order, what each step produced, and when. On Zambo, the verifiable work layer for AI, work run through connected tools in an AI such as ChatGPT, Claude, Claude Code, Cursor, Gemini, Grok, Codex, or Copilot produces a verifiable receipt for each recorded step. A receipt proves the saved result was not changed after the fact, and anyone can check it free at zambo.dev/verify with no signup. It does not prove the work was good. The client still judges quality. The record settles what the work was.

The packet built from those receipts is called a handover: one link carrying the goal, the steps, the outputs, any open items, and the receipts, ending with two controls that belong to the client alone, Accept and Flag. Accept writes the client decision into the record with its own receipt. Flag attaches an objection to one named step. You cannot accept your own handover, and neither can the agent that did the work. That refusal is what makes the acceptance worth attaching to an invoice later.

People search this problem in many forms: freelancer proof of work for client, contractor proof of work for client, attach proof to invoice, prove work done before payment, client disputes invoice proof, client refuses to pay proof of work, and freelance invoice dispute evidence. The answer is the same packet in every form. Only the outputs inside it change by trade, which is the next section.

What proof looks like in each trade

Freelancer proof of work for client: for a general freelancer, the packet is the brief as agreed, the steps in order, the deliverable each step produced, and the acceptance on the final version. It ends the oldest freelance argument, which version was approved, because the accepted version is the one on the record.

Contractor proof of work for client: for a contractor, proof is staged: each completed stage in order, the record for that stage, photos or outputs attached to the step that produced them, and sign off per stage. A final invoice then points at stages the client already accepted, instead of asking for one large act of trust at the end.

Designer proof of work for client: for a designer, proof is the rounds: the brief, each round of files, the feedback each round answers, and the acceptance on the exact final files. When a change request arrives months later, both sides start from the approved version on the record, not from memory.

Developer proof of work for client: for a developer, proof is the build record: the tasks in order, the tests and checks with their receipts, the deploy step, and any open items the client still owes, like content or access. A bug report later can be checked against what the record shows was tested and shipped.

Writer proof of work for client: for a writer, proof is the brief, the research and draft steps, the submitted draft, and the acceptance on that draft. It separates two disputes that are often mixed together: whether the piece was delivered, which the record settles, and whether the client likes it, which stays a conversation.

Editor proof of work for client: for an editor, proof is the manuscript in, the passes in order, the queries raised, and the edited file out, with a receipt for each recorded step. The client sees the work between the two files, which is the part editing clients otherwise have to imagine.

Marketer proof of work for client: for a marketer, proof is the campaign record: the research, the assets produced, the launches in order, and the reports as outputs, each with its receipt. It keeps reporting honest in both directions: the client can check what ran, and the marketer can show exactly what ran when results are questioned.

Consultant proof of work for client: for a consultant, proof is the findings with the work under them: the interviews, analysis, and checks as steps, the recommendations as open items the client accepts or flags one by one. The invoice then bills for a process the client can inspect, not for hours they have to imagine.

In every trade the shape holds: goal, steps, outputs, receipts, decision. If a step was done entirely outside connected tools, an honest packet lists it as open or unchecked instead of dressing it up. A packet with one honestly unchecked step is worth more in a dispute than a packet that claims everything and proves half of it.

The packet: receipts plus the acceptance record

Build the packet while the work runs, not after the invoice is questioned. The routine is short. Run the work through your connected AI tools so each step leaves a receipt. Keep the goal in the words the client agreed to. Redact anything sensitive before you publish the packet: the record should be complete about the work and silent about everything else, including other clients, private addresses, and keys or codes that passed through a transcript. Then send the handover link and let the client decide.

The two worked examples show both honest states. The open example is a complete packet waiting on its client. The accepted example carries the client decision on the record, with who decided and when. For billing, the accepted state is the one you want next to the invoice, because it answers the two questions every payer asks: was this the work we agreed, and did we say yes to it. The receipts answer the first. The acceptance answers the second. Together they are the packet.

Public handovers are free to send and free for the client to open, with no account on the client side. That matters for proof: a client who needs a login, a tutorial, or your help to open the evidence will not open it, and unopened evidence settles nothing.

Attach proof to invoice: the exact steps

To attach proof to invoice in a way a client will actually use, keep it to four steps. First, finish the packet and get the client decision on it, or send it for decision with a clear note that the invoice follows acceptance. Second, put the handover link on the invoice itself, on the line it pays for, not buried in a footer: the words proof of work, followed by the link, next to the amount. Third, repeat the same link in the email or message that carries the invoice, with one sentence saying what the client can check there. Fourth, keep your own copy of the packet link with the invoice number in your records, so months later you can find the evidence by the bill it belongs to.

What not to do matters as much. Do not attach a folder of loose screenshots with names nobody can decode. Do not send proof only after a dispute starts, when it reads as defense instead of routine. Do not send a summary you wrote about the work in place of the record of the work. The habit to build is boring and powerful: every invoice leaves with its packet link, on good jobs and bad, so the one job that turns into an argument is already covered by your normal process.

Prove work done before payment: the before payment routine

The strongest position is proof before payment, not proof after an argument. The routine: deliver the work as a handover, ask the client to open it and accept or flag a step, and make the invoice due on acceptance under the terms you already agreed. A client who accepts on the record has said, in a form you can show later, that the work in the packet is the work they asked for. A client who flags a step has told you exactly what to fix, attached to that step, while the job is still warm.

This routine also protects honest clients, which is why good clients rarely resist it. They get to check the receipts free, see open items listed as open, and approve the exact version they are paying for. If a client refuses to open the packet, refuses to accept or flag anything, and also asks you to send final files and wait, that pattern is information. Pause and use your normal contract protections, deposits, and staged delivery, because the packet was never the problem.

For staged work, repeat the routine per stage: packet, acceptance, invoice for that stage. It is slower to argue with five small accepted stages than with one large unaccepted job, and both sides learn after stage one whether the working relationship is sound, while the money at risk is still small.

Prove hours worked with AI

To prove hours worked with AI, separate two claims that clients often merge. The record can show the work: the tool calls in order, their timestamps, and their outputs, each with a receipt. That is strong evidence of what was done and when it ran. It is not, by itself, a timesheet of your attention: a long running step is not proof you watched it, and a fast step is not proof the work was trivial. Bill honestly on that basis. Where your agreement is hourly, keep your normal time log and attach the packet as the work record under the hours, so the client can match billed time to recorded steps. Where your agreement is fixed price, the packet matters more than the hours: it shows the deliverable and the process, which is what a fixed price buys.

Used this way, the record ends the worst version of the hours argument, in which a client claims nothing happened because they saw nothing. Something did happen, it is on the record, and the client can check it without asking you for anything.

When a client disputes the invoice or refuses to pay

When a client disputes invoice proof is the whole game: the side with the record sets the terms of the conversation. Work the dispute path in order. First, resend the packet link and name the acceptance on the record, with its date. Many disputes are memory disputes, and the record refreshes memory without accusing anyone. Second, if the client flags a specific step, fix or answer that step and keep the exchange on the record, so the resolution is recorded too. Third, if the client refuses to pay proof of work you already delivered and they accepted, send the packet, the acceptance, and the invoice together as one evidence bundle to whoever decides next: a platform, a mediator, your lawyer, or a court, in that order of cost.

That bundle is freelance invoice dispute evidence in its cleanest form: the agreement goal, the steps, the outputs, the receipts a third party can check free, and the client own acceptance. It does not win every dispute, and this page does not claim it does. A client can still argue quality, scope, or contract terms, and those arguments are decided on their merits. What the bundle removes is the factual fog: nobody has to argue about whether work happened, what was delivered, or whether the client approved it.

For payment specific angles, see the related pages below on refusal to pay, chargeback evidence, and proof of delivery. Keep the packet habit regardless of outcome: evidence built as routine, on every job, is calmer and more complete than evidence assembled in anger after one job goes wrong.

What it costs

Public handovers are free to send and free for the client to open. For the recorded work itself, a Day Pass is $0.99, one payment for 24 hours of full access, which covers a full day of recorded delivery work whose receipts fill your packets. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal. Agents pay USDC on Base through x402. Framed against this page problem, the Day Pass is the cost of making one day of client work provable, attached to the invoice it will be billed on.

Honest limits

Three edges, stated plainly. First, a verifiable receipt proves the saved result was not changed after the fact. It never proves the work was correct, well made, or worth the price, and it is not legal advice or a collection service. Second, the packet covers only steps that ran through connected tools: work done entirely outside the record has no receipt, and an honest packet lists it as unchecked. Third, an acceptance on the record is a decision record, not a contract or a payment. Pair it with your normal agreement, deposit terms, and invoice, and let each document do its own job. AER-1, the receipt format underneath, is an IETF Internet-Draft (draft-zambo-aer1-24), not a finalized standard.

Frequently asked questions

What is proof of work for a client?

Proof of work for a client is a checkable packet, not a summary you wrote: the goal as agreed, the steps in order, the output each step produced, a verifiable receipt for each recorded step, and the client acceptance on the same record. The client opens one handover link with no account, checks any receipt free at https://zambo.dev/verify/, and accepts the job or flags one named step. It works for a freelancer, contractor, designer, developer, writer, editor, marketer, or consultant, because only the outputs inside the packet change by trade.

How do I attach proof to an invoice?

Finish the packet first and get the client decision on it where you can. Then put the handover link on the invoice itself, on the line it pays for, with the words proof of work next to the amount. Repeat the same link in the message that carries the invoice, with one sentence saying what the client can check there. Keep the link with the invoice number in your own records. Do not send a folder of loose screenshots, and do not wait for a dispute: every invoice leaves with its packet, as routine.

How do I prove work done before payment?

Deliver the work as a handover before the invoice is due, and ask the client to open it and accept or flag a step under the terms you already agreed. Acceptance writes the client decision into the record with its own receipt, including who decided and when, and you cannot accept your own handover. A client who accepted on the record has confirmed the packet is the work they asked for. A client who flags a step has told you exactly what to fix while the job is still warm.

What if a client disputes my invoice or refuses to pay?

Resend the packet link and name the acceptance on the record, with its date, because many disputes are memory disputes. If the client flags a specific step, answer that step and keep the exchange on the record. If they still refuse to pay for accepted, delivered work, send the packet, the acceptance, and the invoice together as one evidence bundle to a platform, a mediator, your lawyer, or a court, in that order of cost. The bundle settles what was delivered and approved. Quality and contract arguments are still decided on their merits.

Does a receipt prove my hours or that the work was good?

No, and the packet is more useful for being honest about it. A receipt proves the saved result of a recorded step was not changed after the fact, and the record shows tool calls in order with timestamps and outputs, which is strong evidence of what ran and when. It is not a timesheet of your attention, and it never proves the work was correct or worth the price. Pair it with your normal time log on hourly work and your normal agreement on every job.