On this page
Payment milestones split a project's fee into instalments tied to defined points of progress, so you are paid across the work rather than waiting until the end. Setting them up takes five steps. One, take a deposit before any work starts. Two, break the project into stages that each produce something the client can see. Three, tie each payment to a deliverable rather than to a date or a percentage complete, because a deliverable is verifiable and an opinion is not. Four, front-load the schedule so you are never far out of pocket. Five, write the trigger, the amount, the due date, and what happens on late payment into the contract in plain language. A workable default for a small project is 40 percent up front, 30 percent at a defined midpoint, and 30 percent on delivery, with the final payment due before the files transfer rather than after. The schedule template and the checklist below cover the rest.
Getting paid at the end of a project sounds normal until you notice what it actually means: you are lending the client the full value of the work, interest free, for as long as the project runs, and then hoping they pay. On a six-week project that is six weeks of your costs carried by you.
Milestones fix that, but only if the triggers are written properly. A schedule with vague stage names is worse than no schedule at all, because it creates the appearance of agreement while leaving every payment open to interpretation. This guide covers how to build one that holds.
What a Payment Milestone Actually Is
A payment milestone is an agreed point in a project where a specific amount becomes due. Three things make it a milestone rather than a wish: a trigger that is objectively verifiable, an amount, and a due date measured from the trigger.
Miss any of the three and it stops working. A trigger like "on completion of the design phase" is not verifiable, because completion is a judgement and the client holds it. "On delivery of the three homepage concepts as PDF" is verifiable: either three PDFs exist or they do not.
The distinction that matters most is deliverable-based versus date-based. A date-based milestone pays on the 15th regardless of progress, which clients resist because it can pay for work not yet done. A deliverable-based milestone pays when a defined thing exists, which is defensible from both sides and is what almost every workable schedule uses.
Aziz's take: The single most useful change most freelancers can make is moving the final payment to before handover rather than after. Not thirty days after delivery, not on receipt of invoice following delivery. Before the files transfer. The moment your work is in the client's hands, your leverage is gone and you are an unsecured creditor chasing an invoice. It feels awkward to write into a contract exactly once, and then it quietly removes the entire category of problem.
How to Set Up a Milestone Schedule: Five Steps
Step 1: Take a deposit before anything starts
Not on day one of the work, before it. A deposit does two jobs: it covers your early costs, and it filters out clients who were never going to pay. A client who hesitates at a deposit is telling you something worth listening to. For small projects 30 to 50 percent is normal; below 25 percent you are carrying most of the risk yourself.
Step 2: Break the project into visible stages
Look for the natural points where you hand the client something. Research findings, a first concept, a draft, a staging link, a final file. Those handovers are your milestones, because they are moments when progress becomes visible to someone who was not doing the work.
Aim for three to five payments on a typical project. Two is barely a schedule. More than six and you spend your time invoicing rather than working, and each one becomes an opportunity for a delay.
Step 3: Tie each payment to a deliverable, never to a percentage
"50 percent complete" is an opinion, and in a dispute it is the client's opinion that counts. "On delivery of the approved wireframes" is a fact. Write the trigger so that a stranger reading the contract could tell whether it had happened.
Step 4: Front-load the schedule
Your costs land early and your risk peaks late, so the money should arrive ahead of the work rather than behind it. After each payment you want to be slightly ahead, never significantly behind. If a schedule leaves you having delivered 70 percent of the work for 40 percent of the fee, it has transferred the financing of the project onto you.
Step 5: Write the terms in plain language
Each milestone needs its trigger, its amount, its due date measured from the trigger, and the consequence of late payment. Add one line stating that work pauses on any overdue payment. That sentence is what turns a schedule into something with teeth, and it is far easier to invoke a clause you both signed than to invent a consequence mid-project. Writing the dates down also matters because silence has a default: in the UK, where no payment date is agreed the law treats payment as late 30 days after the customer receives the invoice or you deliver the work, and you can claim interest and debt recovery costs. An agreed schedule beats a statutory fallback every time. Our freelance contract template covers where this sits in the wider agreement.
The Schedule Template
Paste this into your contract or proposal and replace the bracketed parts. The structure is what matters: every row names a trigger you could verify, an amount, and a due date.
PAYMENT SCHEDULE
Total project fee: [AMOUNT]
M1 Deposit [40%] Due on signature,
before work begins
M2 On delivery of [DELIVERABLE] [30%] Due within 7 days
of delivery
M3 On delivery of final files [30%] Due before transfer
of final files
TERMS
- Each payment is due within 7 days of its trigger.
- Work pauses on any payment overdue by more than 7 days.
- Final files transfer on receipt of the final payment.
- Late payments accrue [RATE] per month from the due date.
- Approval is assumed if no written response within
[5] working days of a delivery.
Replace the bracketed values. The approval clause in the last line matters more than it looks, and the mistakes section explains why.
Three Splits That Work, and When to Use Each
50 / 50
Half up front, half before handover. Best for short projects of two to three weeks, and for first-time clients where you want minimal exposure. Simple enough that nobody argues about it.
40 / 30 / 30
The sensible default for most projects of four to eight weeks. The midpoint payment lands at a real deliverable, which also gives you an early signal about whether this client pays on time.
25 / 25 / 25 / 25
For longer engagements of three months or more, where four smaller payments keep cash arriving steadily. The risk is schedule drift, so each trigger needs to be tight or the later payments bunch up at the end.
Whatever the split, the test is the same: after each payment, are you ahead of the work or behind it? Our guide to managing cash flow covers why that ordering matters more than the total.
Writing a Trigger the Client Cannot Argue With
Most milestone disputes are not about money. They are about whether the trigger happened. Compare these:
Arguable
On completion of the design phase
When the client is happy with the draft
At the halfway point
On project sign-off
Following final approval
Verifiable
On delivery of three homepage concepts
On delivery of the first draft
On delivery of the staging link
On delivery of the final source files
Seven days after delivery of item 4
The pattern is that every workable trigger starts with on delivery of. That phrasing puts the trigger under your control: you can always deliver something, whereas you can never make someone feel finished.
Handle approval separately, and put a clock on it. A line stating that a deliverable is treated as approved if no written response arrives within five working days prevents the most common stall, which is a client who simply goes quiet and thereby freezes your payment indefinitely.
The Six Mistakes That Leave You Unpaid
- Starting work before the deposit clears. Not when it is promised, when it arrives. This is the most common way freelancers end up working for free, and it is entirely preventable.
- Tying a payment to client approval. It hands the trigger to the other party. Tie it to your delivery and put a time limit on their response.
- Releasing final files before final payment. Your leverage disappears the second the work is in their hands. Deliver on receipt, not before.
- No consequence for late payment. A due date with nothing behind it is a suggestion. Work pausing on overdue payment is the clause that matters, and it needs to be in writing before it is needed. Interest is worth stating too, and UK businesses have a statutory right to it: agreed payment terms must usually fall within 60 days for business transactions, and longer periods must be fair to both parties.
- Milestones that drift with scope. If the client adds work, the schedule needs a matching change. Otherwise you deliver more for the same money and the last payment arrives later than agreed.
- Too many small milestones. Eight payments on a two-month project means eight invoices, eight follow-ups, and eight chances for something to stall. Three to five is the working range.
The Pre-Signature Checklist
Run this before you sign anything. It takes two minutes and catches nearly everything above.
- A deposit is due before work starts, and work does not begin until it clears.
- Every trigger names a deliverable rather than a phase, a percentage, or an approval.
- Every trigger is something a stranger could confirm from the contract alone.
- Each payment has an amount and a due date measured from its trigger.
- After each payment you are ahead of the work, not behind it.
- Final payment falls due before final files transfer.
- There is a stated consequence for late payment, including work pausing.
- Approval is deemed given if no written response arrives within a set window.
- A scope change triggers a written change to the schedule.
- Three to five payments total, not two and not nine.
If you are also deciding how the fee itself is set, our guide to pricing your work covers that side, and scaling a service business covers what changes once several of these run at once. Payment terms are one piece of a wider question about what you take on yourself and what you hand off, which our guide to outsourcing tasks as a small business owner works through.