← All articles

7-step Media Delivery Receipt Workflow for Creative Teams with C2PA

7-step Media Delivery Receipt Workflow for Creative Teams with C2PA

Coordinator verifying a digital delivery receipt

A media delivery receipt is a manifest-based proof of delivery that ties a named version and its components to a timestamped record the receiver can validate. The core verification signals are a manifest, a cryptographic hash, file length, and a persistent version identifier. Together they let a receiver prove they got the exact version and every component that was supposed to arrive.

TL;DR:

  • Using a cryptographic hash and file length for each file ensures accurate validation of both content integrity and transfer completeness.
  • Explicit version identifiers like UpdateNum or ExtraVersionReference are essential to distinguish new revisions from re-exported files with similar names.
  • Including a unique PackageID across deliveries prevents confusion between full package redeliveries and incremental updates months later.
  • Verification requires matching the manifest’s package and component details and recomputing hashes, not relying on file modification dates.
  • Managing manifest-driven workflows within a dedicated system like Posthive helps prevent rework and maintains clear audit trails across multiple projects.
Posthive
Keep Every Version Accountable
Posthive helps creative teams manage versions, track tasks, and collaborate across projects in one connected post-production workspace.
Visit Posthive

Table of Contents

What makes a media delivery receipt credible

A credible receipt is not a one-line confirmation email. It is a structured manifest that lists every file in a delivery and the technical details needed to verify each one. MovieLabs’ Media Manifest Core (MMC) is built around this idea: it links assets to technical metadata and supports inventory-only updates, so a receiver can confirm a version changed without re-downloading the full essence.

The MovieLabs manifest practices guidance gets specific about what each file entry needs:

  • A cryptographic hash (commonly SHA-256) for every file, used as the primary integrity check.
  • File length in bytes as a secondary check that catches partial transfers.
  • A persistent identifier (UUID or APID) that survives renaming or container changes.
  • An explicit version marker (UpdateNum or ExtraVersionReference) instead of file dates or names.

C2PA manifests add another layer: cryptographic claims and content bindings that tie assertions, such as who approved a cut, directly to the asset itself.

How to build and send a delivery receipt

Generating a receipt is a sender-side discipline, not an afterthought bolted on after the transfer finishes. Here is the sequence that production teams can follow for any outgoing drop.

  1. List every file and component going out in a single manifest, including proxies, captions, and audio stems.
  2. For each entry, record the filename, a stable container reference, the UUID or APID, the hash, and the byte length.
  3. Assign an UpdateNum or an explicit ExtraVersionReference, plus a PackageID that identifies the delivery as a whole.
  4. Decide deliberately between a single full package and an incremental update that only changes specific inventory entries.
  5. Log the DeliveryMethod (FTP, HTTP transfer, cloud share), a timestamp, and a progress code for the drop.
  6. Mark any component intentionally left out as “NotSupplied” rather than leaving it ambiguous.
  7. Send the manifest alongside the assets, or publish it at a stable URL, and include plain verification instructions for the recipient.

Pro Tip: Keep one PackageID convention across a project so incremental updates and full redeliveries never get confused with each other months later.

This sequence matters more on incremental deliveries, where only a few files change. Without an explicit UpdateNum, a receiver has no reliable way to know whether a new file is a real revision or a re-export of the same cut with a different filename.

Illustration distinguishing revisions from re-exports

How receivers verify a delivery receipt

Verification is where the receipt earns its purpose and becomes critical in live and broadcast workflows. A receiving team should run a consistent checklist rather than eyeballing filenames against an email.

  1. Open the manifest and match its PackageID or inventory entries against what the sender described in advance.
  2. For each file, recompute the hash and confirm it matches the manifest value, then check the byte length against the declared figure.
  3. Confirm version identity through the UpdateNum or ExtraVersionReference field, never through the file’s modification date.
  4. Check any QCError or delivery progress codes for flagged issues before accepting the package as complete.
  5. If the manifest includes a C2PA binding, validate the cryptographic signature to confirm the assertions were not altered after signing.
  6. Store the verification log and generate a signed receipt that records who checked it and when.

Including both hash and byte length catches issues a hash check alone can miss: a truncated or partially transferred file can still produce a hash mismatch, but pairing it with a length check gives a second, independent signal that something broke in transit, a practice the MovieLabs manifest guidance recommends for exactly this reason.

Best practices to reduce disputes and rework

A short set of habits, applied consistently, prevents most of the back-and-forth that happens when a delivery is questioned weeks later.

  • Always include hash, length, and a persistent ID in every manifest entry, and never rely on modification dates to identify a version.
  • Use explicit version fields like UpdateNum or ExtraVersionReference, and keep a consistent PackageID policy for incremental drops.
  • Provide a machine-readable manifest plus short validation instructions so recipients do not have to guess how to check it.
  • Record the delivery method, timestamp, and the identity of the sending system, and keep verification logs for later audits.
  • Attach QC reports with clear error descriptions so a flagged issue does not turn into a round of guesswork.

Pro Tip: Treat the manifest as the actual deliverable and the media files as its payload. A delivery without a manifest is a transfer, not a receipt.

How this fits into a creative team’s everyday workflow

Standards documents describe what a receipt needs. A post-production workspace is where that structure actually gets used day to day. In our own workspace at Posthive, version control and delivery ownership are built into the same place where teams track tasks and deadlines, so a manifest-driven handoff does not live in a separate spreadsheet.

  • We help keep track of deliverables and versions so teams can see which cut was approved.
  • Version tagging inside the workspace keeps a lineage attached to each file, separate from filenames or upload dates.
  • Delivery logs capture who sent what and when, providing a project record that supports traceability.

Our handoff checklist that prevents rework breaks down how manifest-driven receipts stop the same file from being re-sent three times because nobody could confirm which version was final.

Why verifiable receipts matter more than they seem

Why verifiable receipts matter more than they seem — overview diagram

Most disputes over a late payment or a missed deadline trace back to the same root cause: nobody can prove what was actually delivered and when. A manifest with a hash, a length, and an explicit version ID removes that ambiguity entirely, and it turns a delivery into something a client, a retailer, or a technical team downstream can check without asking a follow-up question.

Teams do not need to adopt every piece of the MovieLabs or C2PA specifications at once. Starting with one manifest per drop, a hash and length on every file, and an explicit version identifier gets most of the benefit. The same habits that work for a freelancer sending a single cut to a client scale cleanly up to studio or retailer deliveries with dozens of components.

— Lorenz

Turning this checklist into a daily habit with Posthive

Building a manifest by hand for every delivery is realistic for one project. It gets harder across a dozen active jobs with different clients and review cycles. That is the gap our workspace at Posthive is built to close: version control, attachable delivery manifests, and a running delivery log sit in the same place where a team already tracks tasks and approvals, so the receipt is a byproduct of normal work rather than a separate chore.

Posthive

All plans include unlimited seats, allowing clients and collaborators to review and confirm deliveries without paying per additional user. Our Pro and Enterprise plans add the storage and feature tiers larger teams need for frequent, high-volume handoffs. If a verifiable, auditable delivery process matters to your next project, take a look at how our workspace is structured and see where it fits your current pipeline.

FAQ

What is a media delivery receipt?

A media delivery receipt is a manifest that lists every file and component in a delivery along with verification data such as a hash, byte length, and a persistent version identifier. It lets a receiver confirm they got the exact version that was sent, rather than relying on a filename or an email confirming the transfer happened.

Why use a hash and file length instead of just a filename?

Filenames and modification dates can change during copying or re-exporting without the content actually changing, which makes them unreliable for proving a version’s identity. A hash paired with byte length, as recommended in MovieLabs manifest practices, gives two independent checks that catch both content changes and partial or corrupted transfers.

How does C2PA relate to delivery receipts?

C2PA manifests add a cryptographic layer that binds specific assertions, like who approved a cut or what transformations were applied, directly to an asset in a way that can be verified independently. This works alongside a delivery manifest rather than replacing it, giving a receipt both a bill-of-materials and a tamper-evident record of approvals.

What should a team do when a delivery is incomplete or flagged?

Check the delivery progress codes or QC errors in the manifest first, since these are designed to flag missing or problematic components before a receiver accepts the package. Any component intentionally left out of a delivery should be marked “NotSupplied” rather than left unexplained, which avoids confusion over whether something is missing or simply not part of that drop.

Can Posthive help manage delivery receipts for a team?

Our workspace at Posthive supports version control, delivery logs, and client ownership of deliverables, which gives teams a practical place to track manifest-driven handoffs without a separate spreadsheet. Plan details and pricing for teams that need this at scale are listed on our pricing page.

Sources

Standards and guidance worth reading next