Direct answer

Your client says they never got your files. Here is how to prove they downloaded them.

Delivery proof has three separate layers, and a dispute is won by showing all three together: the files were sent through a recorded delivery, the delivery link was opened and the files were retrieved, and the copy the client holds matches the exact bytes you sent. One layer on its own invites an argument. All three together leave very little to argue about.

Deliver the next job as a recorded handover instead of loose attachments: zambo.dev/handover. See the record layer first in the live demo, and check any receipt free at zambo.dev/verify.

Updated October 24, 2026.

The three layers of delivery proof

Most freelancers and sellers try to prove delivery with a single screenshot: a sent email, a chat message, a file sitting in a shared folder. Each one proves less than it looks like. A sent email proves you pressed send. It does not prove the file arrived intact, was opened, or is the same file the client is now looking at. Split the claim into three layers and each layer gets its own record.

Layer 1: Sent. A timestamped record of the delivery itself. The strongest version is a handover link created for this job, shared with the client, with the exact file set listed in the record: file names, sizes, and the date and time the delivery was made. HANDOVER is the flagship product on Zambo, the verifiable work layer for AI, because this record is created at delivery time, not reconstructed later when a dispute starts. A sent email with attachments is a weaker version of the same layer: it shows an attempt and a timestamp, but the file list lives in an inbox you do not control.

Layer 2: Retrieved. A record of the access event: the delivery link was opened, and the file was fetched, at a recorded time. Be honest about the weak version of this layer. Read signals from ordinary email and chat are unreliable: some clients block them, some mail apps fetch images automatically, and most chat apps show nothing at all for a file tap. A delivery page whose access is itself recorded is stronger, because opening the page and fetching the file are the events the page exists to log. That record is what answers the sentence clients actually say: I never got it.

Layer 3: Identical. The bytes the client holds match the bytes you sent. Every file has a fingerprint computed from its exact contents. If the copy on the client side produces the same fingerprint as the file listed in your delivery record, it is the same file, byte for byte. The client, or anyone the client trusts, can run that check again at any time. This layer kills the fallback claims that appear once retrieval is shown: the file was corrupted, it was an old version, it was not the file we agreed on.

The practical protocol: set it up before there is a dispute

Proof built after a dispute starts is always weaker than a record made at delivery time. Run every delivery the same way and the proof builds itself:

1. Deliver through one recorded link from the start. One link for the whole job, never loose attachments spread across three chats, two email threads, and a drive folder. Scattered delivery means scattered records, and in a dispute you will be stitching screenshots together while the client simply repeats that they never saw it.

2. List the exact file set in the delivery. Name each file and its size in the delivery note. Final logo, print version, source file, invoice: the listing is what later lets you say precisely which files the retrieval record covers.

3. Keep the fingerprint where the client can check it. Put the fingerprint for each file on the delivery page or in the delivery message itself, not buried in your own notes. A fingerprint the client can check without asking you is worth more than one you produce during an argument, because it was published before there was anything to argue about.

4. Ask for a short confirmation on the record. A one line reply on the delivery thread, got it, or a formal sign off where the job calls for it, adds a human layer on top of the machine record. It is helpful, but treat it as a bonus: the three layers above stand even when a busy client never replies.

5. Keep your originals untouched. Archive the exact files you delivered, in a folder you do not edit afterwards. If you keep working in the same files, your copy changes, its fingerprint changes, and layer 3 falls apart through your own doing.

When the dispute starts: assemble the three layers into one reply

Do not drip the evidence out across five messages. Send one calm reply that lays out the three layers in order, with links, and stops there:

Hi, here is the delivery record for this job. The files were delivered on [date] at [time] through this link: [link]. The delivery lists these files: [file names and sizes]. The record shows the link was opened and the files were retrieved on [date] at [time]. The fingerprint of the main file as delivered is [value]: you can check the copy you hold against it here, and it will match if the file is the delivered copy. If any file on your side does not match, tell me which one and I will send that file again today.

That reply works because it is specific, checkable, and generous at the end. It answers the claim that was made, offers a real fix for the one case that could still be genuine, and creates a clean written record if the dispute later moves to a platform, a payment provider, or a mediator.

Honest limits

A download record shows retrieval by someone with the link, not the identity of the person who retrieved it. Links get forwarded to assistants, partners, and IT staff, and the record cannot tell them apart. A verifiable receipt proves the saved record was not changed since it was saved. It does not prove the client read the work, understood it, or liked it, and it does not prove a file is good, only that the record of its delivery is intact and the delivered bytes can be rechecked. Present the proof as exactly that, no more, and it holds up. Overclaim what a layer proves and the whole reply loses credibility.

Run delivery on a record instead

Work and delivery run through the Zambo MCP endpoint at zambo.dev/mcp (153 tools) save a verifiable receipt for every call, and a handover packages the job, the files, and the record into one link the client can open and check. Start free: 20 free calls per day, then they upgrade. The Day Pass is $0.99 for 24 hours. The Zambo Pass is $29 for 30 days, one payment. Checking any receipt is always free at zambo.dev/verify.

Questions, answered

What if I already sent the files by email, can I still build the proof?

Partly. Layer 1 is partial: your sent folder, the email timestamp, and the attachment list show what you sent and when, even if they are weaker than a recorded delivery page. Layer 3 still works in full if you kept the original files: compute the fingerprint of the files you sent, send the client that fingerprint, and ask them to check the copy they hold against it, or check it together on a call. Layer 2 is the one you cannot rebuild after the fact: if the email or chat did not record an access event, there is no honest way to create one later. Say so plainly, use the two layers you have for this dispute, and deliver the next job through one recorded link from the start so all three layers exist.

What about very large files?

The same three layers apply, and large files are where the fingerprint matters most, because big transfers are the ones that get cut off, resumed, or copied between drives. Deliver large files through the recorded link instead of splitting them across chats, list each file with its size in the delivery record, and keep the fingerprint for each file next to the listing. If the client says the file arrived broken, compare fingerprints file by file: the files that match are settled, and only the file that does not match needs to be sent again.

What if the client claims the link never worked?

Check the access record first. If it shows the link was opened and files were fetched, reply with that record and the timestamps. If it shows no access at all, do not argue: test the link yourself from a private browser window, fix anything you find, and send a fresh recorded link with a short note that the new link replaces the old one. The record helps you in both cases, because it tells you whether you are dealing with a delivery that was retrieved or a link that genuinely failed.

Does a download record prove the client personally downloaded the files?

No, and you should not claim it does. A download record shows that someone with the link retrieved the files at a recorded time. It does not identify the person, and it does not prove the client read, opened, or understood the work. That limit is fine in most disputes, because the claim being answered is usually that the files never arrived. Retrieval from the client link at a recorded time answers that claim without overstating who held the mouse.

How does the fingerprint check work?

A fingerprint is a short value computed from the exact bytes of a file. Change one byte and the fingerprint changes. When you deliver, the fingerprint of each file is saved with the delivery record. Later, anyone can compute the fingerprint of the copy in front of them and compare it. If the values match, the copy is byte for byte the file that was delivered. If they differ, the copy was changed, damaged, or is a different version, and the delivery record tells you which version was sent.