Direct answer

Your finals are the delivery. Your raw files are your workshop. Do not hand over the workshop for free.

The client paid for finished work, and the finished work is ready. The raw files underneath it are a second product, the means to edit, extend, and reuse everything without you. Here is how to separate the two, the three doors for handing sources over, and the record that makes exactly what changed hands checkable later.

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

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

Finals and working files are two different products

Your agreement almost certainly bought an outcome: the finished design, the edited video, the final document, the built page, in the formats the client can use. Those finals are the deliverable, and delivering them in full is the job. Working files are everything underneath them: layered source files, drafts and unused directions, notes, prompts, project files, and the pieces you licensed for your own use along the way. They are your means of production, the workshop the finals came out of. Handing them over is not completing the delivery. It is selling a second product, the ability to make more of the first one without you, and second products get their own price and their own terms.

Why the ask matters more than it sounds

With the finals, the client can use the work. With the raw files, the client can change the work, extend it, rebrand it, and hand it to whoever comes next, and every future edit you would have been paid for can now happen somewhere else. That may be exactly what a good client needs, and there is nothing wrong with selling it to them. What is wrong is the framing that usually carries the request: it arrives at delivery, dressed as tidiness, as though a complete delivery obviously includes the workshop. It does not. A restaurant meal is complete without the kitchen. Price the files as what they are, a transfer of future work, and the conversation gets honest very quickly: clients who truly need the sources pay for them, and clients who were only tidying up discover the finals were enough.

The three doors

Door one: finals only, as agreed. You deliver the finished outputs in the agreed formats, the client reviews and accepts them, and the working files stay with you, where they also serve as your archive if a question comes up later. This is the default in most freelance agreements, and it needs no apology. Door two: raw files as a priced add-on with written terms. The files go on their own line, with the price set before release, a written note of exactly what is included, and terms that say what rights come with them and what does not, including your time walking anyone through old files. Door three: raw files released after full payment under a written handover. When the client genuinely needs the sources as part of the deal itself, sequence them last: finals accepted, balance paid, then the sources released against a written list. That list is not bureaucracy. It is the thing that settles every later argument about what changed hands.

Make the handover itself checkable

Whichever door you choose, run the handover on a record that lists the delivery item by item: the finals as one step, and each group of working files as its own step if they are released at all. Then the record, not your memory or the client's inbox search, answers the question that starts most delivery disputes: you never sent the sources. Either the sources are on the record, saved at a stated time, or they are not, and if they are not, it is because the door for them was never opened or never paid for. The two records below are real AER-1 records (IETF Internet-Draft draft-zambo-aer1-24) and show the two states a handover sits in.

Accepted: a decision is on the record, with a name and a time

Still open: delivered, checked, and waiting on a decision

The accepted record is a delivery whose decision is made, dated, and marked ok_to_release: what it lists is settled. The pending record is work that sits at hold, with no decision recorded yet. A raw-files release that hangs off a record like these inherits that clarity. The files move when the record says the stage is accepted and the payment state says the line is paid, and both facts stay readable long after the email thread is cold.

If the client pushes, or you already sent everything

If the client pushes, hold the line with an offer, not an argument: the finals are ready now, and the sources are available as an add-on at a stated price, released on payment. A client negotiating in good faith negotiates the price. A client who insists the files should simply be free is telling you what the files are worth to them, which is exactly why they should not be free. If you already sent everything on a past job, do not chase it with claims you cannot support. Note what was sent and when, keep your own copies, and run the next job through the three doors instead. The lesson is cheap exactly once.

What this page does not settle

What counts as a working file, and who owns what, depends on your agreement and on the rules where you work. If your agreement already promises the source files, that promise controls, and this page does not override it. Some material in your files may also sit under licences from third parties that were never yours to pass on. This page is general information, not legal advice. A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the files were complete, that the work was correct, or who owns the rights in it. Zambo never holds your money or the client's.

Frequently asked questions

My client wants all my raw working files included in the delivery. What should I hand over?

Hand over the finals: the finished outputs the client paid for, in the formats your agreement names. Treat the raw working files as a separate item, because they are one. Layered sources, drafts, prompts, and project files are how you make the work, and with them the client can make every future edit without you. If the client wants them, that is a fair purchase, priced on its own line, with written terms, and released under a written handover after payment, not a courtesy added at delivery. If your agreement already promises the sources, that promise controls. If it is silent, silence is not a promise: offer the three doors on this page and let the client pick with prices attached.

Why do clients ask for raw files, and what changes if I hand them over?

Some clients ask for tidy archiving, some because their next supplier wants them, and some because the files end the relationship cleanly in their favour. What changes is the future. With finals only, changes come back to you. With the working files, changes happen wherever the files sit, and your role in the life of the work ends at delivery. The files also carry things that were never part of the sale: early drafts, unused directions, your methods, and sometimes third-party material you licensed for your own use only. Handing everything over can hand over more than you ever priced.

How do I price raw files as an add-on?

Price the thing the client is actually buying: every future edit they will no longer need you for. A useful way to set the number is to ask what the files are worth across the life of the work, not what they cost you to copy, because copying is free and the value is not in the copying. Put the price on its own line, name exactly what is included (which files, which formats, which final version), state what rights come with them, and state that walkthroughs and fixes to old files are separate work unless you include them. Release the files after that line is paid, under a written handover, the same as any other delivery.

What should a written handover for raw files say?

Four things, in plain words. The list: every file or folder handed over, by name, so the delivery has edges. The state: which version each file is, and the date it was handed over. The terms: what the client may do with the files, and what stays yours, including unused drafts and your general methods. And the payment state the release hangs on, for example released on payment in full of the project and the raw-files line. Keep the handover with the job record, so that a later claim about what was sent can be answered from the record instead of from memory.

How do I keep a checkable record of exactly what I handed over?

List the delivery as steps on one record, finals as one step and each group of working files as its own step, so the record shows exactly what changed hands and when each item was saved. When the job runs through Zambo, the client accepts or flags the record itself, and a later claim that you never sent the sources is settled by opening it. For $0.99, run the next handover that way and let the record be the delivery manifest: https://zambo.dev/day-pass/ A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related