Every working freelancer knows the problem even if they have never named it precisely. A project is scoped. A fee is agreed. The client is ready to move. And then the payment workflow immediately splits the engagement into two separate administrative events — a deposit invoice, then a final invoice — each with its own link, its own follow-up, its own clearing time, and its own opportunity to stall. The work is one project. The money should feel like one project. For most freelancers, it rarely does.
This article is about closing that gap. It covers why the two-payment structure exists, what makes it break down in practice, how to think about the math at each stage, and how onchain routing through a tool like shaka.deal makes it possible to build the entire deposit-plus-final-payment arc into a single, pre-configured deal — so that each payment clears with finality the moment it lands, every party receives exactly what was agreed, and no one spends days chasing remittances.
Why the deposit-and-final structure is the right default
Payment terms are not a formality. They are the rules that govern when you get paid, how much arrives first, and what you do in the gap between delivering work and seeing money. Nowhere is that gap more consequential than on a fixed-fee project with a defined deliverable at the end.
The two-payment deposit-and-final structure exists for a reason that is symmetrical: it distributes financial risk between both parties rather than concentrating it on one. The most widely used payment structure in freelance work collects half before starting and the remainder when the project is delivered or approved. This works because it splits the financial risk between the freelancer and the client.
A deposit is not a sign of distrust. It is standard practice across every service industry: construction, photography, event planning, legal services. Clients who have worked with professionals before expect to be asked for one.
The specific percentage is a function of project size, trust level, and front-loaded cost. The standard range is 25% to 50% of the total project value. What pushes the number higher: a new client with no track record with you, a large project where front-loaded time investment is significant, or work that requires purchasing materials or tools.
Consider what a deposit is actually doing for both sides. For the freelancer, it converts a new client from a promise into a financially committed one. A 25–50% deposit before starting work is common practice and can help filter out clients who are hesitant to commit. For the client, it creates a contractual anchor — they have paid money into a relationship and have every incentive to see the project through to a result they can be happy with.
The strongest predictor of a fast, clean payment across every account is not the size of the invoice — it is whether the freelancer collected an upfront deposit before the work started. That finding is not intuitive but it is consistent. The deposit does not just protect cash flow; it pre-sorts clients by seriousness. The ones who resist it are disproportionately the ones who would have paid late anyway.
The structural problem: two payments, two everything
Here is where the deposit-and-final approach routinely breaks down in practice. The structure is sound in theory. The execution tools are fragmented.
If you have been freelancing for more than a few months, you know the pattern. You finish scoping a project, write up a statement of work, send it out, and then wait. The client signs two days later. You send the invoice. You wait again. By the time the deposit clears, nearly a week has passed and you have not started a single line of work.
This is not a client problem. It is a workflow problem. The contract and the first payment are two separate documents living in two separate tools, connected only by the hope that your client will act on both promptly. The gap between those two actions is where cash flow dies for solo operators and small agencies alike.
And then the same dysfunction repeats at the end of the project. The work is delivered. The freelancer generates a second invoice for the remaining balance — often a different tool, sometimes a different payment method — and the cycle begins again. The client has to re-enter payment details. Approval has to be routed through whoever handles invoices on their side. The wait begins.
63% of freelancers wait over 30 days from invoice submission to receiving funds, so the gap between expenses and revenue stretches well past the project timeline. When that delay falls on the final payment — after the work is already complete — the freelancer is in the weakest possible leverage position. The most stressful position a freelancer can be in is finishing a project before getting paid for it. The work is delivered, the file is sitting in the client's inbox, and now the only leverage is a polite reminder and the hope that the invoice gets approved.
There is also a data problem. FreshBooks includes a deposit request field on invoices, but the deposit and the remaining balance are handled as separate billing events without a unified payment schedule visible to the client. The client experiences the project as a series of disconnected payment requests rather than a coherent financial agreement they understood and accepted at the outset.
This is not a small usability complaint. When payments are opaque, disputes are more likely. When each payment feels like a fresh ask rather than a fulfilment of an agreed schedule, clients feel less committed to the timing. The structural problem compounds at the final payment stage, when both parties' urgency is asymmetric: the freelancer needs the money, and the client has already received the value.
What the numbers look like across common project sizes
To make this concrete, consider three realistic project scenarios. In each case, the deposit-and-final split has a specific function and a specific risk profile.
Scenario 1: A brand identity project — $5,000 / ~AUD 7,700
A designer takes a $5,000 brand identity project: logo, typography, colour system, usage guidelines. On a project like this, the freelancer might spend on fonts and stock photography, costs for a subcontractor for illustrations, and 60+ hours of their own time before sending a single invoice. If the client pays late or disputes the final deliverable, those costs sit unrecovered.
A 50% deposit structure is appropriate here. The front-loaded cost in time and tooling is high. A 50% deposit covers out-of-pocket costs and reserves a meaningful portion of the freelancer's time. The final payment is tied to the handover of final files.
Scenario 2: A development project — $12,000 / ~AUD 18,500
A developer builds a client portal over six to eight weeks. A 40% deposit on signing, and 60% on acceptance of the build in staging. The higher final payment reflects that the majority of deliverable value comes in a dense push toward the end. The deposit is enough to justify beginning, and covers any infrastructure or tooling costs. The final payment is substantial, which is why it needs to clear quickly and with certainty once the client approves.
Scenario 3: A strategy or consulting engagement — $3,000 / ~AUD 4,620
A brand strategist or content consultant takes a three-week research and recommendations project. A 50% deposit on kickoff, and 50% on delivery of the final report. The work is entirely time-based and intellectual; there are no raw materials. The risk is pure time exposure, so the 50/50 split is symmetrical and defensible on both sides.
| Project | Split | Deposit | Final payment |
|---|---|---|---|
| Brand identity | 50 / 50 | $2,500 / ~AUD 3,850 up front | $2,500 / ~AUD 3,850 on delivery |
| Development | 40 / 60 | $4,800 / ~AUD 7,400 on signing | $7,200 / ~AUD 11,100 on acceptance in staging |
| Strategy or consulting | 50 / 50 | $1,500 / ~AUD 2,310 on kickoff | $1,500 / ~AUD 2,310 on delivery of the final report |
In each scenario, the total fee and the split are agreed before work begins. The most effective strategy is requiring deposits before major work begins. Clients actually appreciate the transparency — they know exactly what they're paying for and when. That transparency is what makes a two-payment structure feel like a coherent agreement rather than two separate invoicing events.
Why the final payment is where the most risk concentrates
It is worth dwelling on this because most payment advice focuses on how to ask for a deposit, not on what happens when the second payment stalls.
According to analysis of 100,000+ freelancer invoices, invoices over $20,000 were three times more likely to be paid late than invoices under $100. A large invoice sitting unpaid for 60 days is a significant cash flow event. For a two-payment structure, the final invoice — always at least as large in absolute terms, often 50–60% of the total — is precisely the invoice most at risk.
The dynamic is well understood. Once a client has the deliverable, their urgency drops. The internal approval chain reasserts itself. The invoice sits with three people in succession. The freelancer sends a polite reminder. Then a firmer one. The relationship that began with enthusiasm and a prompt deposit ends with the most economically important payment being chased across multiple weeks.
The principle of good payment structure is that the work completed should be roughly equal to the money received at every point in the project. Getting paid late is not a rare misfortune you can plan around — analysis of three years of freelance invoicing data found that 29% of invoices were paid at least a day late.
The practical solution is to make the final payment as pre-committed as the deposit. Not in terms of coercion, but in terms of architecture. Both payments should be defined in the original agreement, triggered by clear milestones, and routed through a mechanism that does not introduce new friction at the moment of collection.
Why traditional payment rails introduce friction at the worst moments
Wire transfers. ACH. Stripe. PayPal. Bank transfers. Each of these channels carries its own clearing delay, its own fee, and its own opportunity for the payment to sit somewhere between the client's account and the freelancer's.
As of Q1 2025, ACH payment volume rose 4.2% to 8.5 billion transactions, with the value reaching $22.1 trillion. Payments made using ACH batch at different intervals throughout the day and are deposited within a matter of days if not same-day. "A matter of days" means the payment is received but not yet final — not yet usable with certainty. The freelancer can see it, but cannot act on it with confidence until it clears.
A wire that takes three days, a check that takes ten, and a platform hold that adds a five-to-ten-day withdrawal each add their own friction on top of the client's internal slowness. For a deposit, that friction is annoying. For a final payment that follows weeks of completed work, it is genuinely costly.
There is also the reconciliation problem. The most expensive mistake is using a standalone processor without connecting it to invoicing and project records. A month of unreconciled payments means lost time chasing which client paid for which project, and the longer the gap between payment receipt and reconciliation, the more likely a missed payment goes unnoticed.
Running two separate invoices through two separate payment events on a two-payment project doubles this exposure. The deposit clears through one channel. The final payment clears through another. The amounts need to be reconciled manually against the contract. This is not a systems problem that only large agencies face; it is exactly the friction that loses solo freelancers hours every month.
The onchain routing approach: one deal, two payments, preset shares
This is where the mechanics of onchain payment routing become directly relevant to freelancers who bill on a deposit-and-final structure.
Shaka.deal is a B2B onchain payment router built on Ethereum. The core mechanic is straightforward: one incoming payment, preset shares, simultaneous payout, final settlement. A deal is configured in advance with the total amount, the parties involved, and the share each party receives. When a payment lands, the contract routes it instantly according to those preset shares. It does not hold funds. It routes and settles in one transaction.
For a freelance engagement structured around a deposit and a final payment, this means both payment events can be built into a single project link. The deposit — say, $2,500 / ~AUD 3,850 — is the first payment event on that link, triggered on signing. The final payment — $2,500 / ~AUD 3,850 — is the second payment event, triggered on delivery. Each one settles with finality the moment it arrives. There is no waiting for a bank to process. There is no balance sitting on a platform awaiting a withdrawal window.
Settlement finality is the point at which a blockchain transaction becomes irreversible. After finality, the payment cannot be reorganized out of history, double-spent, or unwound. For treasury teams and payment parties, finality is the moment risk leaves the books and cash is truly cash. For a freelancer, finality on the deposit means the project starts with certainty. Finality on the final payment means delivery triggers clean settlement, not a waiting period.
This is the structural shift that makes a single project link viable for a two-payment engagement. The link is not just a URL — it is an onchain deal specification. It encodes the total fee, the payment schedule, and the routing rules in one place. Both parties can see exactly what has been agreed before the first dollar moves.
Structuring the deal: practical mechanics
Here is how this plays out in a concrete workflow.
- Define the deal parameters before anything is signedBefore presenting a project link to a client, the freelancer defines the total project fee (e.g. $8,000 / ~AUD 12,320); the deposit amount and trigger (e.g. 50% = $4,000 / ~AUD 6,160, due on signing); the final payment amount and trigger (e.g. 50% = $4,000 / ~AUD 6,160, due on delivery acceptance); and any co-recipients, if applicable — a collaborator, a subcontractor, an agency taking a referral share. All of these parameters are set once, in advance, in the shaka.deal interface. The routing logic is baked into the deal before the link is shared.
- Share one link that covers both payment eventsThe client receives a single project link. That link is the canonical home for the financial relationship. It shows the total fee, the schedule, and the terms. When the client is ready to proceed, they make the deposit payment directly from that link. No second tool. No separate invoice. No re-entering payment details.
- Deposit settles instantly and is routed to preset destinationsWhen the deposit payment lands on the deal, Shaka routes it simultaneously to the preset parties — the freelancer's wallet, the subcontractor's share if there is one, any pre-agreed split. The routing is not a pending transfer. It is a completed settlement. The freelancer does not need to wait for a withdrawal to clear. The money has moved. Settlement essentially means the payment is no longer just in progress onchain and can be recognized as final within the relevant business or financial process. Crypto settlement starts when a transaction is broadcast to the blockchain and ends when the receiving side considers the transfer final enough to credit, reconcile, or release funds.
- Work proceedsThe deposit clears with certainty. The project is underway. The client's financial commitment is onchain and settled. There is no ambiguity about whether it arrived, no waiting period, no bank confirmation required before starting.
- Final payment is collected from the same linkWhen the work is delivered and the client is ready to approve, they return to the same project link for the final payment. The parameters are already set. The routing is already specified. The client does not receive a new invoice with new bank details or a new payment processor. They complete the payment event that was always the second step of the deal they agreed to at the start.
- Final payment settles with finalityThe final payment routes instantly to the same preset destinations — the freelancer, the collaborator, wherever the deal specified. Delivery and settlement happen in the same moment. The freelancer does not follow up. There is no "payment is being processed" window. The project closes cleanly.
When the project involves multiple parties
The deposit-and-final structure becomes more complex — and the case for onchain routing becomes even stronger — when the project involves more than two parties. This is extremely common.
Consider a content production project where a freelance creative director brings in a copywriter and a videographer. The total fee is $15,000 / ~AUD 23,100.
| Party | Share | For | From each $7,500 payment |
|---|---|---|---|
| Creative director | 60% | Direction, project management, and client delivery | $4,500 |
| Copywriter | 25% | Scripted content | $1,875 |
| Videographer | 15% | Production assets | $1,125 |
Each of those parties should receive their share — both at the deposit stage and at the final payment stage — without the creative director acting as a clearing house.
In a traditional workflow, the creative director receives the full $15,000 / ~AUD 23,100, and manually transfers the subcontractors' shares. That introduces delay, human error, and a trust dynamic that is unnecessary. The subcontractors are waiting on the creative director's cash flow and on their speed of transfer, rather than on the client's payment itself.
With a shaka.deal routing configuration, the shares are preset. When the client pays the $7,500 / ~AUD 11,550 deposit, each party receives their proportion instantly — no manual step, no intermediary treasury function. When the final $7,500 / ~AUD 11,550 lands, the same simultaneous distribution occurs. Every party receives their share at the same moment, from the same settlement event.
Establishing milestones and deliverables ensures a fair payment structure. Breaking down the project into smaller tasks with clear expectations allows payments to be made based on completed milestones. When multiple parties are involved, that fairness extends to the timing of their payment — not just the amount. Onchain routing removes the queue.
What finality means for both sides of the deal
The word "finality" carries a specific meaning in onchain payment contexts that is worth understanding precisely, because it reframes the entire relationship between payment and trust.
In traditional banking, a payment that has "cleared" is still, in various jurisdictions and under various conditions, subject to reversal. Card payments can be disputed. Wire transfers can be recalled in certain windows. A payment received is not always a payment settled.
Onchain payments work differently. Once a transaction is confirmed and the block reaches finality, the settlement is permanent. It is written into the ledger and cannot be unwound unilaterally. For the freelancer, this means the deposit — once settled — is a real, irrevocable commitment. For the client, it means the final payment — once made — has fully discharged the financial obligation. No disputes. No reversals. No "we're looking into it." Both parties have complete certainty about the state of the financial relationship.
This is not a technicality. It changes the dynamic of the professional relationship in a meaningful way. When both parties know that payment is final the moment it settles, the project has clear, shared accounting points. The deposit stage is done. The final payment stage is done. The engagement is closed, and the record is onchain.
Handling sub-milestones within a two-payment structure
Not every project needs more than two payment events. For smaller or short projects, milestones can add needless complexity, so a simple deposit and final payment often serve better. But when a project is larger or longer, the two-payment arc can be supplemented with intermediate checkpoints without abandoning the single-link architecture.
A common structure for a longer engagement is 30% on signing to confirm the booking and cover early discovery, 30% on approval of the design mockups, 30% on a working build delivered to staging, and the final 10% on launch. A shaka.deal link can encode this as a multi-event schedule — each payment event configured with its amount and routing rules, all under the same project reference. The client interacts with one link across the entire project. The freelancer receives each payment with the same instant settlement.
The principle that makes this work is that all the parameters are set before the engagement begins. A good payment structure does not chase money faster after the fact. It arranges the project so less of your money is ever at risk in the first place. Building the full payment schedule into a single onchain deal link at the outset is the cleanest expression of that principle.
Contract clauses that support this structure
The payment architecture needs to be reflected in the contract. Strong mechanics deserve strong documentation. A deposit-and-final structure should be described with specificity: the amounts, the triggers, and what happens to project progress if either payment stalls.
A freelance contract should include a clear deposit clause. Something like: a deposit of X% of the total project fee is required before work commences. The deposit is non-refundable and will be credited toward the final invoice. Work will not be scheduled until the deposit is received.
For the final payment: the clause should specify that final deliverables — files, access credentials, published assets — are transferred only after the final payment is confirmed. Industry standard practice requires final payment before completed files are transferred or the site goes live on the server. When both parties understand this from the outset, the final payment is not a confrontational ask — it is a pre-agreed condition.
Keeping the next stage gated helps. If a milestone payment is overdue, the most natural and least confrontational leverage is simply not starting the next stage until the current one clears. Because the work is structured in stages, pausing is a normal contractual step rather than a standoff.
When the project link is onchain, this gating has a clean technical counterpart. The next payment event does not trigger until the client acts. There is no ambiguity about whether the deposit was received before work began. The transaction is on the ledger, timestamped, and final.
Common objections, addressed directly
"My clients don't use crypto."
A common assumption. But onchain payment rails are increasingly accessible through wallet interfaces that do not require clients to be sophisticated crypto users. The question is not whether the client is a crypto participant — it is whether they can send a stablecoin to a deal address. For B2B clients paying significant project fees, this is a one-time setup that pays dividends in settlement speed and certainty across every subsequent payment.
"Two separate invoices work fine for me."
They do work — until they don't. The most common failure points are vague agreements that create disputes at invoice stage; no deposit, which removes the client's financial commitment before work begins; incomplete invoices that get kicked back by finance teams; late invoice sending that pushes payment timelines unnecessarily; and no follow-up process, leaving late payments to resolve themselves. The two-invoice workflow is functional when everything goes well. Onchain routing through a single deal link removes the points of failure that activate when something goes sideways.
"What if the project scope changes?"
Scope changes are handled in the contract, not in the payment architecture. If scope expands, a new deal parameter is agreed. The payment link can be updated before the additional payment event triggers. What does not change is the certainty of settlement when payment is made.
The professional case for presenting a deal link instead of an invoice
There is a presentational advantage to the single-deal-link approach that goes beyond mechanics. When a freelancer sends a project link that shows the full payment schedule — deposit, final payment, amounts, routing — it signals something about how they work.
It signals that the freelancer has thought about the entire project lifecycle before the contract is signed. It signals that the financial terms are transparent and complete, not assembled invoice by invoice. It signals that payment on both ends will be handled with the same seriousness as the work itself.
The freelancers who get paid consistently and on time are not luckier than average. They are more systematic than average. A deal link is a system. It is the payment equivalent of a well-structured statement of work: it tells the client everything that is going to happen, in what order, for what amount, before any money moves.
Asking for 30–50% of the project fee before work begins helps protect the freelancer financially and signals that the client is serious. Most professional clients expect this. Those who push back may warrant additional caution. A well-configured project link, presented at the outset, normalises the deposit as part of a coherent financial agreement — not a separate ask that arrives after the contract is signed.
Putting it all together
The deposit-and-final-payment structure is not going away. It is the right default for most fixed-fee freelance work because it distributes risk symmetrically, creates commitment on both sides, and aligns payment with project progress. The problem has never been the structure. The problem has been the execution — two invoices, two tools, two clearing windows, two opportunities to stall.
The onchain routing approach collapses that fragmentation. One deal link, configured in advance, holds the full payment schedule. The deposit settles with finality when the client is ready to commit. The final payment settles with finality when delivery is accepted. Every party receives their preset share at the same moment, from the same settlement event, with no manual transfer step in between.
Shaka.deal routes the total amount of a deal and distributes it instantly to every party at preset shares, in one transaction, with finality. For freelancers billing on a deposit-and-final structure, that routing architecture is not a complicated upgrade — it is a direct replacement for the two-invoice workflow, with one link, two payments, and complete certainty at every stage.
Getting a slow payer to speed up is expensive. Stopping the slowness before the first milestone is free, and it is the highest-leverage habit in freelance finance. The deal link is how you stop it before it starts — for the deposit, and for the payment that matters just as much: the one that comes when the work is done.
