ZAMBO.

Direct answer

Do not resend a new file. Test the delivered one.

The moment you export a fresh copy and send it, you have destroyed the evidence and started a new argument. The delivered file either opens or it does not, and that is testable. Here is the calm sequence: gather their exact error, test the exact delivered copy, separate a broken file from broken software, and resend from the record if the delivery was sound.

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

Updated October 23, 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.

Step 1. Get the exact failure before you touch anything

Ask for four facts in one message: which file, by name; the exact error message or a screenshot of it; the app and device they opened it on; and whether every file fails or only one. Vague reports hide three completely different problems. A wrong app or an out-of-date app is their software. A download cut off halfway is the transfer. A file that fails everywhere, including for you, is a genuinely broken delivery, and that one is yours to fix free. You cannot sort the three without the facts, and a client who sends the screenshot has already done half your diagnosis for you.

Step 2. Test the exact delivered copy, not a fresh export

Open the copy that was actually delivered: the file in the delivery record, the sent folder, or the shared link, in that exact form. Do not open your working original and do not export a replacement yet, because a working original proves nothing about the copy that travelled. Test it the way the client would: download it fresh from the delivery link, open it in the standard app for that file type, and note the file size shown next to it. If the delivered copy opens for you at the size on the record, the delivery was sound and the problem lives on their side of the wire. If it fails for you too, skip to step 5 and own it.

Step 3. Separate the three culprits out loud

Name which culprit the test found, in writing, with the evidence attached. File: the delivered copy fails on a clean test, so you will replace it from the saved original. Transfer: the delivered copy opens and its size matches the record, but the copy on their machine is smaller or partial, so a re-download from the delivery link is the fix. Software: the file opens in the standard app at the recorded size, and their app, version, or device is the gap, so the fix is the app name and version to open it with, plus a widely readable fallback copy if one honestly exists, sent as a courtesy and labelled as an extra, not as a replacement for a broken file. Naming the culprit calmly, with the test result, ends the argumentative version of this conversation.

Step 4. Let the delivery record prove what was sent

The record is what turns your test into proof instead of your word against theirs. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the shape of a delivery record a client can open and check:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

For a file delivery, the record gives you the three facts this argument runs on: which steps were saved, when they were saved, and whether the client checked them, 4 of 4 checked and accepted on the first record, 5 of 5 checked and still pending on the second. A client who accepted a delivery on the record and later reports a file failure is reporting a specific, testable event, not reopening whether anything was delivered. And the receipt attached to the delivery step proves the saved result was not changed since it was saved, so the copy you test today is the copy that was delivered then, not a version quietly edited since.

Step 5. If the file really is broken, replace it from the saved original and say so

Sometimes the test convicts the file. Then the move is simple and credibility-building: say the delivered copy fails your own test, replace it from the saved original rather than re-exporting a changed version, deliver the replacement as a new step on the same record so both copies and both dates stay visible, and check the replacement opens before you send the link. Owning a real break quickly, with the record showing the original, the failure, and the replacement, costs you an afternoon. Arguing about a file that was actually broken costs you the client and, often, the invoice attached to the delivery.

Step 6. Deliver the next job so this test takes two minutes

Three habits make the next will-not-open report a two minute check instead of a week of suspicion. Deliver through one link on a record, never as scattered attachments across email and chat, so there is exactly one delivered copy to test. Name files plainly with the project and the date, so which file is unambiguous. And keep the working originals untouched after delivery, so the delivered copy can always be compared against what was saved. A client who knows the delivery lives on a checkable record also opens it sooner, which means real problems surface while the fix is still small.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the file was good, does not open the file on the client's machine, and cannot fix their software. The open test on the exact delivered copy settles whether the delivery was sound. This page is general information, not legal advice.

Frequently asked questions

My client says the files I delivered will not open. How do I prove the delivery was fine?

Test the exact delivered copy and show your working. First get their facts: which file, the exact error, and the app and device they used. Then download the delivered copy fresh from the delivery link yourself, open it in the standard app for that file type, and compare its size with the size on the delivery record. If it opens for you at the recorded size, the delivery was sound: send the client the test result, the re-download link, and the app name and version it opened in. If their copy is smaller, the transfer cut it off and a re-download fixes it. If the delivered copy fails your own test, the file was broken: own it, replace it from the saved original on the same record, and verify the replacement opens before you send it.

Should I just send a fresh copy straight away?

No, and the reason is evidence, not stinginess. A fresh export replaces the thing being argued about, so neither side can ever test what was actually delivered, and a client can fairly wonder whether the new copy was quietly fixed. Test first, then resend the same delivered copy from the delivery link if it passed, which also proves the link and the file together. The only fresh file you should ever send is a replacement for a delivered copy that failed your own test, and that one goes on the record as a new step, with the original and its date still visible beside it.

What if the file opens for me but still not for the client?

Then work their side of the wire, in order. Confirm they downloaded the whole file, because a partial download is the most common cause and its size gives it away. Confirm the app and its version, because files from current tools routinely fail in old versions of the same app. Offer the standard viewer for that file type, and if a widely readable fallback format exists, send it as a labelled courtesy copy while the original delivery stands as the record. If it opens on a second device of theirs, the first device is the answer. Document each test in one short message as you go, so the thread itself becomes the diagnosis instead of a loop of it does not work and it works here.

What if I test the delivered copy and it really is broken?

Own it in the same message you would have wanted: the delivered copy fails my own test, here is the replacement, it is taken from the saved original, and I have opened it myself before sending. Deliver the replacement as a new step on the same delivery record so the original file, the failure, and the fix all stay dated and visible, and do not charge for any of it, because delivering a working file was the original job. A fast, documented own-up usually strengthens the relationship. What damages it is a week of defending a file that was broken from the start, which the client will eventually prove with someone else's test.

How do I stop file delivery arguments on the next job?

Deliver one copy, in one place, on a record. When the work runs through Zambo, every step is saved as it happens, the client receives one handover link, and each step carries a verifiable receipt, so months later both sides can still test the exact saved copy instead of hunting through email attachments and chat uploads. Name files with the project and date, keep your working originals untouched after delivery, and ask the client to open the delivery when it lands, while a real problem is still a two minute fix. For $0.99, deliver the next job on a record where the exact files, their dates, and the client's acceptance are saved together: get the Day Pass. A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 for 30 days, one payment, or $290 for 365 days, and $19 for 30 days for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related