Photo and video delivery to a client, sealed before sending

Delivery dispute

How to prove which version you delivered, and when

When the client says files were missing or that it was a different version, your word is worth the same as theirs. The exact package, sealed before you sent it, is not.

Private. Only the file fingerprint is registered.

Word against word “You never delivered it.” “The cocktail-hour photos were missing.” “That wasn’t the approved version.” And the invoice, unpaid until it is sorted out.
The dated proof wins The exact package you sent, sealed before you sent it. Which files, which version and which day. No longer your word: a date and a list.
Cents against an invoice One invoice disputed over “this isn’t it” is worth more than sealing every delivery you make all year. And today, sealing costs nothing.

The scene

“That’s not the version we approved.”

You delivered the finals on a Friday: the folder with the edited photos, the video in two formats, the PDF with the final design. The client replied “received, thanks”. Three weeks later, the invoice is still unpaid and an email arrives. “Half the material from the second day was missing. And the video you sent us isn’t the version we approved in the meeting.” You know it isn’t true. But the WeTransfer link has expired, you have kept touching the Drive folder, and all you have is your word and a “received, thanks”.

The ritual: before every delivery

  • Close the delivery into a single package: a ZIP with exactly what you are going to send. Photos, video, design, code, approval PDF. If you deliver in several batches, one ZIP per batch.
  • Add an index inside: a text or PDF listing the files, the version and the date. It is what turns “I sent you stuff” into “I sent you these 214 files, final version 3”.
  • Seal the ZIP before you send it. Right before: the date on the seal is the delivery date you will be able to prove. With the free account, the fingerprint is computed on your computer and the large package is not uploaded.
  • Send it the way you always do: WeTransfer, Drive, Dropbox, a hard drive. The channel doesn’t matter. What matters is that what you send is that exact ZIP and no other.
  • Keep the exact ZIP and the certificate with the rest of the project. If the client complains, verify their copy against your seal: if it matches, it is what you delivered; if it doesn’t, it isn’t.

What Sellat proves in this dispute

Sellat does not decide whether the delivery meets the brief, whether the client approved that version or whether they have to pay the invoice. That is for the contract, an agreement or a judge. Sellat proves one concrete thing: that the exact package, with those files and that index, existed on the date you sealed it, and that nobody has modified it since. It is technical evidence about an exact version of a file. With it, “I delivered this, on this day” stops being just your word.

What you keep after sealing

When you seal, you receive a PDF certificate and a verification ZIP by email. That ZIP is what you forward when the complaint arrives: it contains the fingerprint of the exact package, the date and the instructions for the client to check it on their own, without trusting you or Sellat. Sellat does not keep your delivery or see it: only its fingerprint.

Registered post proves what you sent and when. Sellat proves which files you delivered, and when.

A “received, thanks” proves that something arrived. It doesn’t prove what. Links expire, shared folders change, and the version history lives on someone else’s server. Sealing the package does for your delivery what registered post does for a letter: it fixes an exact date and exact contents that depend on neither your word nor the client’s. It works for 3 files or for 3,000: you seal the package, not each photo.

Inside the package

This is exactly what you open two years later.

Not a promise and not a screenshot: the real list of files Sellat puts in your ZIP. What you see here is generated by the same module that builds the package.

Open the package Close the package
  • original/<archivo> If the original is kept

    Your file, byte for byte

    The exact photo you sealed, in a folder of its own so no other file in the package can be mistaken for it. It travels inside when the original is available: the upload that created the proof, or custody.

  • certificado-<id>.pdf Always

    The readable certificate

    The PDF you show a person or attach to a filing. It is an informative document: what actually gets checked is the file, not the PDF. If the file carried Content Credentials (C2PA), the certificate records them too — who signed, with which tool and whether they declare AI use — exactly as your browser read them when you protected it.

  • proof.json Once the batch is anchored

    The portable proof

    Your file fingerprint, its Merkle leaf and inclusion path, the batch root and the public transaction that records it. This is the piece that lets anyone check everything without Sellat.

  • sello-cualificado-<id>.tsr With a qualified seal

    The qualified seal

    The RFC 3161 response from the qualified timestamping authority, exactly as it was issued. This is the file that fixes the date under eIDAS.

  • autoridad-sellado.pem With a qualified seal

    Who signed the seal

    That authority signing certificate, with its SHA-256 written into the README. It travels inside so the check works offline and nobody has to go looking for it.

  • anclaje-bitcoin.ots Once the batch is anchored

    The Bitcoin anchor

    The OpenTimestamps proof of the batch root. It may still be waiting for a block: it is a valid file and whoever receives it can upgrade it themselves.

  • LEEME.txt / README.txt Always

    The instructions, in two languages

    What each file is, what it proves and what it does not, and the exact commands to check it. In Spanish and English, so an expert or a lawyer never has to ask you anything.

The seal is signed by FNMT-RCM, not by Sellat.

Sellat is not the party attesting the time. The qualified seal is issued by a qualified timestamping authority of the FNMT-RCM, and its signing certificate travels inside your package. We are the intermediary that joins your fingerprint to that seal and hands it to you in a tidy folder.

It checks out without us and without the internet.

With the seal and the authority certificate inside the ZIP, the date is verified with standard tools on the machine of whoever receives it. If Sellat disappeared tomorrow, your package would still check out.

The package proves that this exact file existed on that date and has not been modified. It does not prove who created it, who took the photo, or what happened in front of the camera.

Seal the package before you send it. On every delivery.

One invoice disputed over “this isn’t it” is worth more than sealing every delivery you make all year. Today, sealing costs nothing. Upload the exact ZIP you are about to send and keep the certificate with the project.

Seal the delivery

Frequently asked questions

Before you ask.

What if I send via WeTransfer, Drive or Dropbox?

The channel doesn’t matter. You seal the exact ZIP before uploading it and send it however you like. What the proof shows is the contents and the date of the package, not the link. When the link expires, the proof will still be there.

Does it work for large batches? Do I have to seal every photo?

No: you seal the package, not each file. A ZIP with 3,000 photos is a single proof. Without an account the limit is 20 MB per file; with the free account, Sellat Local computes the fingerprint on your computer and you can seal large packages without uploading the original. For studios that deliver daily, there is an API.

How does the client verify it?

Without an account, on Sellat’s public verification page: they drag in their copy of the file and check that it matches the proof. They can also do it with the open-source verifier, without going through Sellat. All you need to do is forward them the certificate and the verification ZIP.

Will this hold up in court if the client doesn’t pay?

Sellat does not promise that a proof will hold up in court, and it cannot: the judge or arbitrator in each case is the one who weighs the evidence. What you can bring is technical evidence, verifiable by anyone, that that package and those files existed on that date and have not been modified since. On the legal page we explain precisely what Sellat proves and what it does not.

What if I am asked for certified photos?

If a client or an insurer asks you for certified photos of a shoot, a claim or a condition report, the ritual is the same: seal the package of exact photos straight out of the camera, before editing or sending them, and deliver the certificate together with the photos. It doesn’t turn anyone into an expert witness, but it fixes which photos existed, and since when.

Can anyone see my file?

It depends on the mode. In the normal flow the file is uploaded to Sellat only to calculate its SHA-256 fingerprint and prepare the proof; afterwards it is not retained. With a free account, Sellat Local calculates the fingerprint on your own device and the original is never uploaded. And if you turn on custody — optional, and only with an account — Sellat does keep the original, checked against its fingerprint, until you remove it. In all three cases the only thing in the public record is the hash, a code that cannot be used to read or rebuild the content.

Proof of delivery for digital files: showing which version the client received

Proving the delivery of files to a client has two parts: what exactly was delivered, and when. An email proves that something was sent; a sealed package proves what was inside. For freelancers and studios in photo, video, design or development, that is the difference between getting an invoice paid and arguing about it. Technical detail, in case you need it: Sellat computes the SHA-256 fingerprint of the exact ZIP (on your computer with Sellat Local, if you have an account), records it in a public reference on Polygon and on Bitcoin via OpenTimestamps, and sends you a PDF certificate and a verification ZIP. In the normal flow the original package is not kept after the proof is created: only its fingerprint. With an account you can calculate it on your computer (Sellat Local) or turn on custody so Sellat keeps it too. The client can check the proof with their exact copy, without an account and without trusting Sellat. For daily deliveries, there is an API.