Guide contents
Your client asks for the final file to inspect the work, prepare a launch or share it with their team. First understand that need and the sequence set out in your agreement. An early request does not automatically mean a disagreement about payment.
This guide helps explain review versus handoff, check the payment expected and coordinate files without introducing surprise conditions. Our freelance delivery guide covers the wider process of preparation, approval and final handoff.
The priority is the actual agreed terms: if a file is already due, this guide does not recommend withholding it. Any proposed change needs to be considered within the framework applicable to the project.
- What does the client want to inspect or use now?
- Which files and handoff conditions have been accepted?
- What payment is expected, when and through which channel?
- Which step genuinely remains to be confirmed before handoff?
Check the agreed sequence before setting a boundary.
Read the scope, deliverables, payment dates and handoff arrangements. A project may provide for payment before production, a balance before particular files or payment after a defined delivery. Do not replace that sequence with a general rule discovered at the end of the work.
Clarify what the client is requesting
Ask whether they want to review, check a format or put the result into use immediately. A readable preview may answer the first need; a specific technical check may require suitable material. Identify anything already due before suggesting an alternative.
A message to find the common reference
Subject: handoff arrangements for [deliverable]
Hello [name],
You would like to [review or intended use]. Agreement [reference] provides for [payment date and handoff conditions]. To address the current need, I can offer [action consistent with that agreement].
Could you clarify [point] so we can follow the same sequence? If you would prefer a different arrangement, let us agree on its terms before treating it as confirmed.
[Name]
Under French law, a legally formed contract binds the parties. It may be modified by mutual consent or on grounds authorised by law. Sending a new condition in a message does not, by itself, replace the existing agreement. Seek an appropriate assessment where the particular position is disputed.
Separate the preview, decision, payment and final handoff.
A review lets the client assess a version. Approval expresses a decision against the relevant criteria. A due date identifies when money must be paid. Handoff provides access to the agreed material. These steps can be connected without becoming interchangeable or proving each other automatically.
Match the response to the situation
| Situation | What to check | Practical response |
|---|---|---|
| The client wants to inspect the work | What they genuinely need to assess. | Provide a sufficient preview and identify the decision requested. |
| Payment has been announced | Its status in the agreed channel. | Reconcile the amount and reference before confirming receipt. |
| Handoff conditions are met | The correct package and recipient. | Coordinate handoff and request confirmation of retrieval. |
| The file is already due under the agreement | The accepted obligation and arrangements. | Follow the agreed delivery instead of creating a new restriction. |
| External access is requested | Permissions with the provider. | Check the role and access actually granted separately. |
In Dealokr, fixed-price projects begin with a signed agreement and the client paying 100% of the price upfront through Stripe Connect. Review comes afterwards. You can organise inspection of the work within a project already funded by the client, with handoff conditions established before production.
This describes new projects organised that way. It does not retrospectively change an existing commission’s terms or turn an announced payment into a confirmed one. Keep the chosen arrangement and observed status distinct.
Choose a preview suited to the work being assessed.
The review material should show enough for a decision. A readable PDF may suit layout, a viewing export may suit video, and a demonstration or agreed test environment may suit a digital journey. Choose according to the need and agreement, rather than relying on a single technical trick.
Avoid material that cannot be assessed properly
An unreadable image, missing sound or overly limited demonstration can prevent the client from checking the agreed result. State the preview’s limits and address anything blocking review. A preview should not be used to demand approval without a real opportunity to examine the work.
Equally, review does not always require the complete editable or production-ready package. List what belongs to final handoff: exports, agreed working files, media, documentation or access. Explain the distinction with the applicable terms before it becomes a last-minute disagreement.
Check content and permissions before sending
Open the version being shared, check its reference and make sure it does not accidentally include additional material. A preview can be copied in part. Do not present compression or a watermark as absolute protection against every reuse of what the client can see or hear.
If a particular check requires a specific file, look for a solution consistent with the accepted commitments. The right review material supports the assessment required without confusing what is being handed over at that stage. Record any limitation the client still needs to understand.
Present the preview with clear criteria and a next step.
Identify the version, points to assess and answer needed. “Let me know if everything is fine” can mix conformity, preference and receipt. Ask instead for a decision on the agreed scope presented, with specific reservations where necessary. The client should know what their reply will help you prepare.
A message for sending the review version
Subject: review of [deliverable] — version [reference]
Hello [name],
Preview [reference] is available in [channel]. It lets you assess [agreed points]. Open items or limits of this material are [list or none].
Could you send your decision or specific feedback by [agreed date or date to confirm]? The planned final package is [inventory], with handoff under [previously accepted conditions].
If you need other material to assess the work, please identify it so we can clarify the requirement.
[Name]
In Dealokr, the client can review the preview and request agreed revisions. The history helps you find the version and associated exchanges. You can connect the next action with the actual response rather than infer approval from a simple acknowledgement of receipt.
If the client raises a reservation, address it before presenting review as complete. A positive reply to an intermediate stage does not automatically describe a decision on every final file. Keep the reference and scope of that answer visible.
Distinguish a payment announcement from a confirmed status.
Find the expected amount, reference, currency and due date. Then check the actual state in the agreed payment channel rather than relying only on a message from the client. A different amount or reference needs reconciliation before you treat the stage as complete.
A transfer instruction is not the same as receipt
A screenshot may show information the client supplied. It does not, by itself, confirm that the corresponding payment has been received or confirmed in your channel. Check the payment tool or relevant account transactions under your arrangement. Do not mark a payment as confirmed merely to make the conversation easier.
You can explain that reconciliation is in progress without accusing the client. Request the information needed if the payment cannot be identified, then confirm the status observed. Initiated, pending and confirmed are different reference points; use the one you can actually verify.
Respect the other handoff conditions
If the agreed handoff depends on other items, check those too. Conversely, where your agreement already provides for delivery before payment, this check does not create a new right to withhold the file. The process needs to remain consistent with accepted obligations rather than creating another condition afterwards.
Payment confirmation does not guarantee that no dispute or difficulty can arise later. Keep the reference and observed status to document the project without presenting them as insurance against every possible outcome. Clarify uncertainty before making a statement the client may rely on.
Confirm the package and the step actually available.
Prepare the inventory and final version matching the client’s decision. Check the formats, recipient and prerequisites. Completing payment reconciliation does not, by itself, explain where the files are or how the client can retrieve them. The handoff message should make that practical step clear.
A message after checking payment
Subject: handoff for [project] — package [reference]
Hello [name],
Payment [reference, amount and currency] is confirmed in [agreed channel]. The other handoff conditions in agreement [reference] are [status actually checked].
I can confirm [package availability or agreed next step]. The material concerned is [inventory and versions], in [handoff channel]. Prerequisites or points still open are [list or none].
Could you confirm retrieval and opening of the material when it is available?
[Name]
Use the template only with a genuinely confirmed status and adapt the next action to the project’s conditions. Any open step should stay explicit. Do not announce final access as already active if it is not, or describe an expected event as completed.
In Dealokr, you request the transfer under the project’s conditions following the required review. The client gains access to hosted final files after transfer confirmation. An approval or date does not automatically trigger that movement; arrival in your bank account remains a separate event.
Check external access and preserve the right reference.
A file hosted in a project and a link to another service are controlled in different places. For Figma, Drive, a repository or a hosting account, check who can view, download or edit with the provider. Recording a link in Dealokr does not change those permissions.
Keep protection claims within their actual scope
A link already public does not become private through the project workflow. Do not promise to withdraw access that you do not control. Agree on the roles and handoff arrangements, then apply the appropriate settings in the relevant service.
A first milestone transfer does not unlock every file. Check the materials and stages actually concerned before telling the client everything is available. Use a suitable channel for credentials or invitations rather than adding them to a general archive. An inventory can identify an access step without exposing secrets.
Keep a useful handoff record
Retain the inventory, version reviewed, decision, payment status observed and handoff message. Ask for retrieval confirmation where useful. A history helps reconstruct events without guaranteeing the outcome of a dispute by itself.
Finally, specify the agreed follow-up and availability period. The project ends more clearly when each person knows what was handed over and whether anything remains to be done. Keep that final reference accessible within your own project records.
Before answering an early final-file request, identify the need, accepted terms and stage actually reached. Offer a useful review, verify the statuses you describe and coordinate handoff with a clear inventory.
- French Civil Code — Article 1103: the binding force of a contract
- French Civil Code — Article 1193: modification of a contract
- Dealokr — Agreements, initial payment and previews
- Dealokr — Review, conditional transfers and hosted final files
- Dealokr — External-service permissions and project history
Adapt this coordination method to the accepted terms. The brief contractual reference concerns France; it does not establish a general right to withhold files, change a payment date or suspend an obligation.
Practical guidance for clearer freelance projects and payments.