What Must You Deliver With a Finished Film?

The picture is locked. It plays from first frame to last with sound, at the right length, and it looks like a film. Then a distributor, a broadcaster, a festival or a sales agent asks whether you can deliver it, and the honest answer is: deliver what?

That is not evasion. A locked edit answers the question is the film finished? A delivery request answers a different question: which specific files and records, in which versions, can you put into a named recipient's hands by a named date? The two answers can sit miles apart. The gap between them is where promising pitches go wrong — not because anyone lied, but because "the film is done" got quietly promoted into "the package is done."

Film Independent's practitioner article Deliverables Demystified draws the line roughly where it belongs. Its useful observation is that supplying a completed film is not the same as supplying the additional materials a distributor requests, and that those materials are usually handled as an agreed schedule of items and dates. The piece was published in 2013 and republished in July 2017, which makes its technical formats historical reading, not instruction. The distinction is the part that still holds: delivery is an agreement about a list, not a property of the film. This article describes a method for turning your recipient's list into a bounded, inspectable package. It does not give you current specifications, prices or deadlines, because those belong to your recipient and your crew.

Everything below runs on one invented example, so the reasoning has something concrete to bite. The film, the recipient and the request are fictional. They are not typical of anything, and no current delivery schedule was inspected to build them.

The example. A 22-minute documentary short, locked in March at picture version 7. The only delivery-grade file on hand is an H.264 viewing master with a stereo mix, made for festival submissions: no head leaders, no textless elements exported. The recipient is a small distributor, Meridian Docs, whose requirements arrived on 2 May with a target delivery date of 30 June.

Meridian Docs — Delivery Requirements, 2 May. Target: 30 June.

1. Feature master, ProRes 422 HQ, 1920×1080, 23.976, with bars, tone and slate at the head. Master carries the 5.1 mix.
2. Textless elements: main title, lower thirds, end credits.
3. Stereo mix as a separate file. 5.1 mix.
4. M&E stem.
5. Closed captions matching the delivered picture.
6. Dialogue list with timecodes.
7. Key art and press stills suitable for marketing.
8. Synopsis: 50 words and 150 words.
9. Music cue sheet.
10. Credits list with roles.

Ten lines. Twelve deliverables, once you notice that lines 3 and 8 each carry two.

Start with the request, not someone else's checklist

The request has three properties your memory does not: it is written, it is dated, and it came from the recipient. Those three properties are what make it usable. A verbal version of the same list, relayed secondhand through a sales contact, cannot be argued with later.

Read the ten lines and sort them. Some are requirements in the recipient's own terms — "M&E stem," "textless elements," "closed captions matching the delivered picture." Some are specifications attached to an item, like the codec and frame rate in line 1. Some may turn out to be examples of a category rather than the whole category. And at least one is ambiguous, which is line 7: key art and press stills suitable for marketing. You can read that as "send us the poster file and some high-resolution frame grabs," or as "send us on-set production stills and we will build the layout ourselves." Those two readings describe different work, different owners and different costs. This film has no set photographer; the director took a handful of phone photos. If the second reading is correct, the item cannot be filled by exporting anything, and needs to be renegotiated rather than attempted.

The move here is to convert the ambiguity into a specific question, in writing, before anyone is commissioned: which of those two things does Meridian want, at what resolution, and does the poster file need to arrive layered or print-ready? That question takes four minutes to send. Guessing costs a designer's invoice and a week.

One more thing about checklists. Another filmmaker's accepted package is evidence about their film and their recipient. It can tell you what kinds of things distributors tend to ask for. It cannot tell you what Meridian asked for, and it cannot be used to answer a question Meridian has actually put in writing. The written request always outranks the internet version.

Group the work by what it enables

Twelve items sorted by file extension is a mess; twelve items sorted by what they enable is a plan. Four groups cover this request.

• Presenting the film: the feature master, the textless elements, the stereo mix, the 5.1 mix, the M&E stem.
• Translating and accessing it: the closed captions, the dialogue list.
• Promoting it: the key art and stills, the two synopses.
• Reviewing the supporting records: the music cue sheet, the credits list.

Grouping matters because it exposes the dependency the flat list hides. The viewing master is a perfectly good file — it is just built to do one job. It contains version 7 picture and a stereo mix. It does not contain a 5.1 mix, textless elements, or captions, because nothing about submitting to festivals required them. A file can be finished and still be missing from the package. Those are not contradictory statements; they are answers to two different questions.

Keep the recipient's vocabulary in view while you do this. "M&E" is not a synonym for "some audio stems." "Textless elements" names specific picture files — main title, lower thirds, end credits — without burned-in text, so a foreign-language version can be laid over them. Translating the request into assumed export presets before you understand it is how you end up exporting the right file for the wrong reason and missing an item entirely.

Replace "we have it" with an inspectable status

Here is the producer's optimistic list, written in the week the request arrived:

Picture locked. Stereo mix done. Subtitles done. Poster done. Two synopses done. We're basically there.

Every clause is defensible and the conclusion is wrong. "Subtitles done" describes a caption file that exists. It does not describe a caption file that matches the delivered picture, which is what line 5 actually asks for. The fix is not to become pessimistic. It is to make each line inspectable, one row per requested item, with the gap and its owner named.

None ready, ten needing work, one unknown, one blocked. Same film, same ten-line request, very different sentence to say out loud.

Notice how "unknown" behaves in that table. It is not a soft way of saying missing and it is not a soft way of saying fine. It means nobody has yet looked at the end-credit crawl to see whether it can produce the plain-text credits list Meridian wants. An unknown gets a name and a question: the assistant editor checks, and the status resolves one way or the other. Without that, unknowns drift, and drift is how a package that was "basically there" in May becomes a scramble in June.

Trace gaps to people, dates and cost bases

A gap is only useful once it is attached to whoever can close it. Three of these traces are worth walking through slowly, because they are the three shapes a gap usually takes.

The missing sound component goes back to its owner. The M&E stem does not exist because nobody needed one until now. The mix session, as far as anyone knows, lives at the re-recording mixer's studio; whether it still opens cleanly with the plug-ins used at the time is a question only the mixer can answer. So the questions are his: can you reopen the session, can you produce an M&E at the layout Meridian asks for, what does it cost, and when can you do it. Nobody else on the film can answer any of those, and no standard figure should be inserted in their place. If the session turns out to be unrecoverable, that is a finding, not a failure — and it changes the budget conversation rather than ending it.

The outdated caption file goes back to the picture version. The caption file was made against version 5. Version 6 shortened a scene; version 7 rebuilt the end credits. A shortened scene early in the film shifts everything after it, so the caption timings no longer line up — the file is not badly made, it is simply timed to a picture that no longer exists. And there is a second version question hiding behind it. The delivered master will carry bars, tone and slate at the head, so picture no longer starts at the file's first frame. The captioner and the finishing editor need to agree what the caption timecode refers to — picture start or the head of the delivered file — before re-timing begins. Get that wrong and the captions will be correct and useless, drifting by exactly the length of the leaders.

The ambiguous promotional request goes back to the recipient. Nobody internal can resolve line 7. Only Meridian can say whether they want existing art and frame grabs, or production stills that were never shot. This is the one gap in the table that no amount of work on your side can close, which is precisely why it should be asked first. It has the longest lead time of anything here, and it is the cheapest question to send.

Then sequence the rest so that later work is not invalidated by earlier work. The 5.1 mix has to exist before the master can be exported, because the request says the master carries it. Export the master first and you will export it twice. The captions should be re-timed against the delivered file rather than the edit. The textless elements, the transcript, the synopses and the cue sheet can all move in parallel, because none of them waits on the mix. And all of it is worth showing to a post supervisor or finishing house before you commit to a date — the order above is the method, not a substitute for someone who knows your specific project and your specific recipient.

Report readiness with the exceptions attached

The map becomes useful when you turn it into a short, bounded statement you can put beside a pitch. Something like this:

Readiness — 24 May. For Meridian Docs' 2 May request, target 30 June. Of twelve requested items: ten in progress with named owners, one awaiting a check, one blocked on Meridian. Open items that affect the offer: 5.1 mix cost and date (mixer), M&E export (mixer), caption re-timing (captioner), key art scope (Meridian). No item has been accepted by Meridian; acceptance is confirmed in writing by their delivery contact when the materials are in hand.

That statement does two jobs. It tells a buyer what is genuinely ready, and it prices the honesty in: the outstanding items are visible, owned and bounded, which is a better position than a clean-sounding "we're ready" that collapses in June. Note what it claims and what it refuses to claim. It does not say the film is distribution-ready, because there is no such state in the abstract — readiness is always readiness for a package. If Meridian later adds a French-language territory, the caption item changes, the dialogue list becomes a translation source, and the package is a different package. Nothing in the map is portable to a request you have not received.

Keep two sentences apart in your own mind, and in anything you write to a buyer. Files sent means an upload completed. Delivery accepted means the person named in the requirements has confirmed, in writing, item by item, that what arrived is what was asked for. A receipt from a portal is not acceptance. An email saying "got it, thanks" is not acceptance either. And when acceptance does come, it covers the items that person listed — not every version, territory or future use the film might eventually need.

The package you promise is the one in the written request, in the versions that request names, with the exceptions you have stated out loud. That is a much smaller promise than "the film is finished," and a far more useful one.

Frequently asked questions

What question does a delivery request answer that a locked edit does not?

A locked edit answers whether the film is finished. A delivery request asks which specific files and records, in which versions, can be put into a named recipient's hands by a named date. The two answers can sit far apart, which is how a finished film gets mistaken for a finished package.

Can a finished viewing master satisfy a delivery package?

No. In the example, the H.264 viewing master contains version 7 picture and a stereo mix, but it lacks a 5.1 mix, textless elements, and captions because festival submission never required them. A file can be finished and still be missing from the package; those are answers to different questions.

How should an ambiguous line such as key art and press stills suitable for marketing be handled?

Turn it into a specific written question to the recipient: which items they want, at what resolution, and whether the poster needs to arrive layered or print-ready. Those readings describe different work, owners, and costs. If production stills were never shot, the item may need renegotiation rather than an export attempt.

Why group deliverables by what they enable instead of by file type?

Grouping by function—presenting the film, translating and accessing it, promoting it, reviewing supporting records—exposes dependencies the flat list hides. The 5.1 mix must exist before the master is exported, captions should be re-timed against the delivered file, and several text items can move in parallel because none waits on the mix.

What is the difference between files sent and delivery accepted?

Files sent means an upload completed. Delivery accepted means the person named in the requirements has confirmed in writing, item by item, that what arrived is what was asked for. A portal receipt or a casual thanks is not acceptance, and acceptance covers the listed items, not every future version, territory, or use.