What a delivery manifest is
A delivery manifest is the itemised packing list for a VFX delivery: one line per shot you are handing over, recording exactly what that line contains - the shot ID, the version you delivered, the frame range and count, the file path, the task, and a date. It is not the media and it is not the invoice. It is the record of what shipped, and it exists so that weeks later, when someone asks "which version of SH040 did we get, and when," there is a single dated document that answers instead of a thread of half-remembered emails.
The manifest matters most for shots marked Final. In-progress shots move constantly and nobody expects a paper trail on them. A Final shot is a claim - "this is done, this is the one, put it in the show" - and claims need evidence. The manifest is where "Final" stops being a status in someone's head and becomes a documented, auditable fact.
Why Final shots need an auditable list
Three things go wrong on delivery, and all three are really the same problem - two sides holding different pictures of what was handed over:
- Version confusion. You delivered v006. The client is reviewing v004 because that is what was in their bin. Without a manifest naming the version, this is a fight about memory. With one, it is a two-second lookup.
- Scope confusion. "That shot was never in this delivery" versus "yes it was." A manifest is the list of what was in the delivery, so the question answers itself.
- Range confusion. The shot delivered at the cut length but the online needed handles, or vice versa. A manifest recording the exact frame range makes the spec you delivered to explicit and checkable.
None of these are exotic. They are the ordinary friction of every hand-off, and they cost real time - re-deliveries, re-reviews, "can you resend" emails - all of which evaporate when there is one document both sides trust.
What a good manifest contains
A manifest is only as useful as the fields it carries. The recipient has to be able to match every line to an actual file, and you have to be able to prove what you shipped. That means, per shot:
| Field | Why it is there |
|---|---|
| Shot ID | The stable name both sides key on - see shot naming. |
| Version | The delivered version. The single most disputed field; name it explicitly. |
| Frame range & count | What was actually delivered, so range and handle claims are checkable. |
| Frame rate | Removes the ambiguity an EDL leaves open; a count is meaningless without it. |
| File path / filename | Lets the recipient find the media the line refers to. |
| Task / department | Which discipline this delivery is - comp, roto, fx. |
| Delivered date | The timestamp that makes the manifest a dated record, not a live sheet. |
| Conformed against | The cut this was checked against, so the delivery is tied to a known edit. |
Where the manifest comes from
The best manifest is a by-product, not a chore. If your tracker already knows every shot, its in-cut version, its frame coverage from the renders folder and which shots are marked Final, then the manifest is just a filtered export of what it already holds - no retyping, no separate spreadsheet that can drift from reality. That is exactly how Cutlist Tracker produces it: mark the Final shots, and it exports a delivery manifest of just those - version, frame range and path per shot - alongside the conform report it was checked with, as CSV or a printable page. Because the numbers come from the actual cut and the actual folder rather than from someone's memory, the manifest describes what you really delivered, which is the entire point of having one.