Direct answer

Check first. Files second. That order protects both sides.

The usual delivery moment bundles two transfers into one act of faith: you send the usable files, the client sends the money, and whoever goes first carries the risk. Unbundle it. The client gets something better than the files to check first, a full record of the work, and the files move when the money does. Here is the sequence, stage by stage, with the reply for the client who insists on files first.

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

Updated October 18, 2026. The delivery records quoted below are real and public, with their client decision states read back from the live service on publication day.

The honest problem on both sides

Your side is simple: final files are the finished product, and once they move, an unpaid invoice is a request, not a transaction. The client's side is also honest: paying in full for work they cannot inspect means trusting a summary, and they have been burned by summaries before. Watermarked previews split the difference badly, protecting the files while insulting the inspection. The way out is to notice that inspection and possession are different things, and only possession needs to wait for payment.

The sequence: record, acceptance, payment, files

Deliver the finished work as a handover link. The client opens it and sees the job step by step: what ran, when each step was saved, which sources were checked and which were not, each step with its own verifiable receipt. They accept it or flag a specific step. That decision is recorded with its date, and the release state answers the payment question for both sides:

Accepted: ok_to_release, the payment stage is due

Still open: hold, the files stay with you

When the final payment lands, send the final files the same day, with the usage rights your agreement describes, and confirm the transfer in writing. Promptness at your stage is what makes the client's stage feel fair, and fairness is what makes the sequence repeatable job after job.

If you already sent the files on a past job

Do not retrofit threats onto a finished act of trust. Invoice normally, and if payment stalls, work the sequence on the unpaid-invoice page in the related links: the boring causes, the reminder that carries the record, the proof packet, the formal demand. Then change the default for the next job while the lesson is fresh, because the fix for files-first is prospective: it lives in the agreement and the delivery definition, not in chasing the last delivery.

What the record does not do

Zambo never holds your files and never holds the client's money. The record proves the saved result was not changed since it was saved, and it shows the acceptance state and its date. It does not move payments, transfer rights by itself, or prove the work was good: quality is judged by the client at inspection, which is precisely why the inspection stage exists before the money stage. Rights transfer, payment terms, and remedies live in your agreement, and this page is general information, not legal advice.

Write the sequence into the agreement

One short paragraph does it: work is delivered as a handover link the client can inspect in full; the client accepts or flags a specific step within an agreed number of days; final payment follows acceptance; final files and the agreed usage rights are sent on payment. Clients rarely resist a sequence that gives them a stronger inspection than files-first ever did. The ones who resist every staged version of it are telling you, cheaply and early, how the last stage would have gone.

Frequently asked questions

Should I send the final files before the client pays in full?

No, and the client should not have to pay blind either. Split delivery into two different things that are usually bundled into one risky moment. First send the checkable record: one handover link where the client inspects every step of the finished work, checks the sources and states, and accepts or flags it. That gives the client real inspection, stronger than a watermarked preview, without giving away the usable files. When the acceptance is recorded and the final payment lands, send the final files and transfer the usage rights your agreement describes. Files first spends your only leverage before the money moves. Record first, payment second, files third keeps the leverage and removes the client's honest objection, which is that they cannot verify what they are paying for.

Is a watermarked preview or a low resolution copy enough protection?

It protects the files and fails at everything else. A watermark stops casual reuse of that copy, but it does not let the client check the work itself: the steps behind it, the sources used, the parts not checked. Clients know the difference, which is why preview fights feel like distrust on both sides. A delivery record inverts it: the client can inspect the work in depth, in a form they cannot simply take and use, and their acceptance is recorded against it. Previews say trust me less. Records say check for yourself.

What if the client insists on the files before paying?

Treat the insistence as information and answer the legitimate half of it. The legitimate half is verification: offer the full checkable record, a live walkthrough of it, and a written sequence in the agreement, record, acceptance, payment, files, so the client risks nothing by paying after acceptance. The illegitimate half is leverage: a client who wants usable files, no acceptance recorded, and payment later is asking you to carry all of the risk in the transaction. Stage the release if the job is large: source files last, exports in parts against milestone payments, or a trusted platform holding the payment in between. If every staged option is refused, that refusal is the answer about how the final invoice would have gone.

What should move at each stage of the sequence?

At delivery: the handover link, the invoice, and a short note naming what acceptance means and how long the client has to check. At acceptance: nothing moves from you; the client's decision is recorded, and the release state flips to ok_to_release. At payment: the final files, any source files the agreement includes, and the usage rights, sent promptly and confirmed. Keeping the stages separate is what makes each one enforceable in practice: a missing payment has an accepted record in front of it, and a missing file delivery has a payment receipt in front of it, so either side can point at exactly the stage that stalled.

How do I make this sequence the default on every job?

Write it into the agreement as the delivery definition: work is delivered as a Zambo handover link, the client accepts or flags within an agreed window, final payment follows acceptance, and final files move on payment. Run the work through Zambo so the record builds itself as the work happens, per step, instead of being assembled at the end. For $0.99, run the current delivery in this sequence, record first and files on payment, instead of handing over the finished work and hoping the invoice behaves: get the Day Pass. A Day Pass covers 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