Direct answer

A client refuses to pay. These are the records that decide it.

Payment refusals sound like arguments, but they are settled like audits. Every refusal is one of four claims: we never agreed this, it was never delivered, it was not what we asked for, or we never accepted it. One small file, kept as you go, answers all four. Here is exactly what belongs in it, why, and how to keep it without turning your work into paperwork.

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

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

The six records, and the claim each one answers

1. The written agreement. Scope, price, and delivery terms, written down before work starts. It answers "we never agreed to this." An agreement in a signed document, a proposal, or even a clear email thread all count, as long as both sides saw the same scope and the same price.

2. Every approved change. Scope changes are where files quietly fall apart. A client asks for extra work in a chat message, you do it, and at invoice time the agreement on paper does not cover it. Keep every change approval in writing, attached to the agreement, with the price effect stated, even if the price effect is zero.

3. The work record. What was actually done, step by step, with the time each step was saved. This answers "it was not what we asked for" and half of "it was never delivered." A record made while the work runs is the strong version. Notes you write about the work afterwards are the weak version, because they are your account of your own work.

4. The delivery evidence. When the work was handed over, and where the client opens it. An email attachment has your sent time and nothing about arrival. A delivery page has the work itself, saved at stated times, sitting in one place the client can open. Keep the delivery link with the invoice, not buried in a thread.

5. The acceptance state. Whether the client accepted the work, flagged a problem, or has not decided yet. This answers "we never accepted it," and it is the record most freelancers never have, because acceptance usually happens as a vague reply in a thread, or does not visibly happen at all. When acceptance lives inside the delivery record, the state is simply a fact you can point to.

6. The invoice trail. The invoice itself, the payment terms on it, and every reminder you sent, with dates. It answers the procedural claims: wrong amount, wrong terms, never received the invoice, was never reminded. Boring records, and they close exits.

When you keep them matters as much as what you keep

A record made at the moment of the work and a record assembled during the dispute are different objects, and anyone experienced can tell them apart. The assembled file is gathered by the person with the most reason to make it look complete. The live record was written down before there was anything to argue about, one step at a time, by the system the work ran through. That is why the habit that protects you is not filing. It is delivering in a form that writes the record as a byproduct: the agreement saved with the job, changes approved in writing as they happen, the work saved step by step, delivery as one link, acceptance as a state on that link.

What the strong version looks like

When work runs through Zambo, the work record, the delivery, and the acceptance state are one object: a handover. Two real ones, public right now:

Accepted: the complete file, closed

Scope: Retrieval, extraction, verification, and reporting pipeline producing an AI-adoption research packet for a law firm.

Still open: the record waits, and the waiting is recorded too

Scope: AI visibility audit of zambo.dev: homepage copy inventory, on-page citation audit, and evidence-based recommendations.

Together the two cards are the whole lesson. The records were not prepared for a dispute. They are simply what delivery looks like when the record is made during the work, and they are ready for a dispute, a tax question, or a client who lost their own copy, without you lifting a finger.

What these records do not settle

A delivery record proves the saved result was not changed since it was saved, and it shows the acceptance state. It does not prove the work was good, and it does not prove who produced the work. A client with no money is a credit problem, not a records problem. And none of this is legal advice: how long records must be kept, and what a court or a platform will ask for, varies by place and by agreement. What does not vary is the direction: the side with the record made during the work is the side that gets believed.

Frequently asked questions

What records should I keep in case a client refuses to pay?

Keep six things for every job. The written agreement, with the scope and price. Every approved change to that scope, in writing. The work record itself: what was done, step by step, with the time each step was saved. The delivery evidence: when the work was handed over and where the client can open it. The acceptance state: whether the client accepted the work, flagged it, or has not decided yet. And the invoice trail: the invoice, the terms on it, and the reminders you sent. That file answers every version of a refusal: we never agreed it, it was never delivered, it was not what we asked for, we never accepted it. Each claim dies against one record in the file.

What if I did not keep records for a job that is already finished?

Rebuild what you honestly can from things that carry their own times: sent email, file version history, chat exports, payment platform records. Present it as what it is, a reconstruction, and do not backdate or tidy it into something stronger than it is. A reconstruction is weaker than a record made while the work ran, because you gathered it yourself after the argument started, and the other side knows that. Use it to settle this job if you can, and treat the gap as the reason the next job gets delivered as a record from the first step.

Do screenshots count as delivery records?

Screenshots are the weakest record in the file. They show what a screen looked like when someone chose to capture it, they can be cropped, and they say nothing about the steps before or after. Keep them as supporting color if you have them, but never as the delivery record itself. The record that settles arguments shows the work step by step, in order, with the time each step was saved, in a place the client can open and check without taking your word for any of it.

How long should I keep client records?

Keep them at least as long as a payment claim could still be raised where you work, and longer if your agreement or local rules say so. The limits vary by place and by contract, and this page is general information, not legal advice. A practical floor most freelancers use is several years for the agreement, the delivery record, and the invoice trail, stored somewhere that survives a lost laptop. Storage is cheap. Rebuilding a file during a dispute is not.

How do I keep these records without extra admin work?

Deliver the work as a record instead of rebuilding one later. When the work runs through Zambo, every step is saved as it happens, and the client receives one handover link carrying the steps, the times, and the acceptance state, so the delivery record and the acceptance record exist before anyone argues. For $0.99, run one full day of client work so the record keeps itself: 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