Two refusals hide inside one sentence
"An AI did the work, so I am not paying" mixes a factual claim with a commercial one, and they need different answers:
- "It was not done." The client doubts the work happened, or happened as billed. This is settled by execution evidence: a record of what ran, step by step, fixed when it ran. A summary cannot settle it, because the summary is the thing being doubted.
- "An AI did it, so it is worth less, or I never agreed." This is settled by the agreement evidence: what was disclosed when the work was delivered, and whether the client accepted the delivery with that in front of them.
Arguing either half in prose loses, because prose is just your summary against theirs. The delivery record is not a summary. It was created when the work shipped, and the client can re-check every line of it without trusting you.
The packet: what to send
- The handover link for the job. One page holding every step of the delivery: the tool that ran, the timestamp, the saved output, and a verifiable receipt for each step. The client opens it with no account and presses Verify all to re-check every step in their own browser.
- The acceptance record. If the client accepted the delivery, that answer is in the record too: an event with its own receipt, pinned to the handover's original Merkle root. The machine-readable form at /handover/<id>/acceptance.json states the status, who the record says decided, and when.
- The disclosure from delivery time. The AI-use statement that shipped with the delivery, generated from the receipts' own labels, answers "you hid it" with a timestamped fact instead of a denial.
- The not_checked list. The parts of the job that were not checked, named on the record itself. Sending it voluntarily is what makes the rest of the packet credible: a record that admits its gaps is hard to dismiss as marketing.
The handover mechanics are documented at zambo.dev/docs/handover. The packet is not assembled for the dispute; it is the delivery itself, which is the whole point.
A real delivery, read as a dispute packet
Handover 45434a17: done, and accepted
Handover 45434a17 was created on October 16, 2026 at 14:31 UTC for a recipient named Acme. It carries four steps, each with a receipt a stranger can open: live prices for BTC ($82,212.68, receipt c7e596e9), ETH ($2,472.76, receipt 647bbf66), and SOL ($106.17, receipt 2b9a1121), plus a prompt_shield screen that returned safe (receipt 51dfbf1e). The set is closed by summary receipt da183db3 under the handover's Merkle root. Then the client accepted: the accept event in the JSON twin carries its own receipt (14cb8b21), recorded at 14:31:51 UTC and pinned to that same root, and the acceptance record reads status "accepted", decided_by "client", release_hint "ok_to_release", 4 steps checked and 0 unchecked. If this delivery were invoiced and refused with "prove it was done, and prove I accepted it," this page is the entire answer.
Handover 3ba7cb75: what "an AI did it" actually looked like
When the refusal is specifically about AI use, the packet answers with the per-step labels. Handover 3ba7cb75, a daily price check delivered to a receiving agent on October 16, 2026, shows a live_price step labeled Claude (BTC at $81,577.00, receipt 8f49dd82), a live_price step labeled Grok (ETH at $2,411.80, receipt 0fc0e687), and a prompt_shield step labeled Unspecified AI (receipt 81d7409c). The receiver accepted the delivery, acceptance receipt 1600adb6. The labels are the producer's own statement of which AI ran each step, fixed at delivery time. That fixed statement is exactly the fact the AI-use half of a refusal turns on, and the attribution page walks this same handover step by step.
Both handovers are public and live. Open them, run Verify all, and read the events yourself.
How these disputes actually settle
Platforms decide disputes on documented evidence, not on who argues better. Fiverr's guidelines make misrepresenting AI use the offence, punishable by cancellation, a full refund, and suspension, which means the freelancer who disclosed with a record is in a different case from the one who hid it. Upwork's dispute process likewise runs on documented evidence. A delivery record created at shipping time is the strongest form of the thing both platforms ask for.
What usually changes when the full packet lands: the factual argument ends. What remains is a commercial conversation about price and scope, and commercial conversations can be negotiated, split, or credited. A factual standoff cannot. And if part of the billed work genuinely was not done, the record shows that too, in a missing step or the not_checked list, and the honest move is to credit that part and bill the rest with evidence. The record cutting both ways is why it settles things.
What the record does not do
It does not prove the work was good. A verifiable receipt shows the saved result has not changed since it was recorded; it does not prove the result was right. Every handover prints that limit itself, in a not_proven list naming outside timestamp, issuer identity, and result correctness.
It does not prove who clicked Accept in the strong sense. The acceptance event on handover 45434a17 carries the notice verbatim: "Logged by Zambo on behalf of the visitor. Not identity-verified." The record proves a decision was recorded at that time on that delivery, and says plainly how far that proof goes.
It does not override a contract. If the client ordered human-only work, a receipt does not turn AI work into compliance with that order; it only proves what ran. And Zambo never holds the money, runs no dispute desk, and reverses nothing. The platform or the contract decides. The record decides what the argument is about.
Never have this fight again
Every item in the packet exists because it was created at delivery time. The prevention is one habit: deliver through a handover, with the AI use disclosed and the record attached, and let the client accept before the invoice goes out, the pattern on the proof before payment page. If you are on the buying side of this dispute instead, the dispute kit gives you the mirror image: the exact message to send when you are the one demanding receipts before you pay.
Questions, answered
My client refuses to pay the invoice because an AI did the work. What proof do I send?
Send the record, not an argument. The packet is the handover link for the job: every step of the work as its own verifiable receipt (the tool that ran, the time, the saved output), the list of anything that was not checked, and, if the client accepted the delivery, their own acceptance record. In the live example on this page, handover 45434a17 carries four receipted steps, and the client accept is itself a receipt (14cb8b21) pinned to the handover's Merkle root; its acceptance record reads accepted with release_hint ok_to_release. That packet answers the factual half of the refusal, what was done, when, and whether the client took delivery of it, in a form the client can re-check in a browser without trusting you.
Does it matter that an AI did the work, if the work is what was ordered?
That depends on the contract and the platform, not on the receipt. If AI help was allowed and the delivery matches the order, the record is your evidence: the steps, the outputs, and the acceptance. If the client ordered human-only work, no record fixes that; a receipt proves what ran, not that it was permitted. This is why disclosure at delivery time matters: the dispute that starts as you used AI is usually the one where the client found out late. The disclose-at-delivery pattern is covered on the AI-use disclosure page.
Can a verifiable receipt prove the AI work was good?
No, and the record says so itself. A verifiable receipt proves the saved result has not changed since it was recorded. It does not prove the result was correct or good; every handover prints a not_proven list that names result correctness. What the receipt settles is the factual dispute: whether the billed steps ran, what they returned, and when. Quality is judged on the outputs, which the packet also puts in front of the client, unchanged.
The client accepted the delivery and still refuses to pay. Does the acceptance help?
Yes, it is the strongest single item in the packet. An accept on a Zambo handover is recorded as its own event with its own receipt, pinned to the handover's original Merkle root, with the time. The acceptance record at /handover/<id>/acceptance.json reads status accepted, decided_by client, and release_hint ok_to_release. It carries an honest limit the record prints itself: the decision was logged by Zambo on behalf of the visitor and is not identity-verified. It is evidence of the recorded decision, created when it happened, not a claim assembled for the dispute.
Who decides whether I get paid?
The platform or the contract does, by its own rules. Zambo never holds the money, runs no dispute desk, and reverses nothing. What changes with the record is the shape of the argument: instead of two summaries against each other, the decision-maker gets a checkable delivery record, the disclosure made at delivery time, and the client's recorded answer. Platform disputes run on documented evidence; this packet is that evidence, created before the dispute existed.