billable.devMilestone Billing for Developers: Setup and Invoicing
By Mark Fulton · 2026-08-17 · 13 min read
Milestone billing means you get paid when a defined, checkable thing exists, not when a date on a plan passes. On a software project that means tying each payment to an artifact the client can open without you in the room: the approved spec, the staging build, the production deploy, the signed handover. A $12,000 fixed-price build splits cleanly into four payments of 25%, 30%, 30% and 15%, sent as four sequentially numbered invoices instead of one at the end. The percentages matter far less than the triggers. A milestone whose completion is arguable is not a milestone, it is a future dispute with a dollar amount already attached to it.
Most advice on this stops at "break the project into stages and get paid at each one," which is the easy half. The hard half is deciding what counts as done, what the invoice says, and what happens in week five when the client goes quiet for eleven days and your milestone is sitting there finished but unapproved. That is the part I want to cover, with the actual invoices.
What counts as a milestone on a software project?
A milestone has to pass three tests. It is binary, so there is no partial credit and no "roughly there". It is observable by the client without you narrating it, which usually means it lives at a URL or in a repository. And it has a date attached, so both of you can tell whether it happened on time.
That rules out most of what people write into proposals. "Backend complete" fails the observable test, because the client cannot see a backend. "Design phase" fails all three. "50% complete" is not a milestone, it is an opinion with a percentage sign on it.
This is not a freelancing quirk. US federal contracting works the same way: FAR Subpart 32.1 defines performance based payments as payments made on "accomplishment of defined events" measured by "objective, quantifiable methods." Government buyers landed on the same rule for the same reason. Payment triggers that depend on judgement generate arguments.
Here is the translation into work a developer actually does:
| Weak trigger | What to use instead | How the client verifies it |
|---|---|---|
| "Discovery complete" | Spec document, estimate and risk list delivered | They read a PDF you sent |
| "Design signed off" | Clickable prototype at a shared URL, all agreed screens | They click through it |
| "Backend done" | Staging environment feature complete, acceptance list A1 to A9 passing | They log in to staging and try it |
| "Testing phase" | Production deploy live on their domain, smoke tests green | The real site loads |
| "Project wrap up" | Repo transferred, credentials handed over, docs delivered, 14 day defect window closed | They own the code |
Four or five of those become your payment schedule. The acceptance list is the piece people skip and then regret. Write out the specific checks that make each milestone true, number them, and put them in the statement of work. When milestone two is done you send a link plus nine ticked lines, not a paragraph explaining why it is done.
How do you split the money across milestones?
Two constraints decide the split, and they pull in opposite directions.
The first is exposure. At no point should the amount of delivered but unpaid work exceed one milestone. If milestone three is worth $3,600, then the worst case if everything goes wrong is that you are out roughly $3,600 of work, not $12,000. That argues for more, smaller milestones.
The second is friction. Every milestone is an invoice, an approval, and a payment run at the client's end. Six milestones on a six week project means you spend a meaningful slice of the project chasing paperwork, and finance teams start treating you as an administrative burden. That argues for fewer, larger ones.
For most fixed price dev work between $5,000 and $25,000, four lands in the right place. Here is the $12,000 build, split:
| # | Milestone | Trigger | % | Amount | Running total paid |
|---|---|---|---|---|---|
| 1 | Spec approved | Spec, estimate and risk list delivered and signed | 25% | $3,000 | $3,000 |
| 2 | Staging demo | Feature complete on staging, acceptance list passing | 30% | $3,600 | $6,600 |
| 3 | Production deploy | Live on production domain, DNS cut over, monitoring on | 30% | $3,600 | $10,200 |
| 4 | Handover | Repo and credentials transferred, docs delivered, defect window closed | 15% | $1,800 | $12,000 |
Three things about those numbers.
Milestone one doubles as the deposit. It is invoiced on signature and paid before the spec work starts, which is why it reads as "25% on signature, covering the specification phase" rather than "deposit". Framing it as paid work rather than as a trust tax removes almost all of the pushback. The full decision framework for the up front percentage is in how much deposit to charge for freelance dev work.
The tail is 15%, not 40%. A large final payment means you fund the last mile yourself, and the last mile is exactly where projects go slow and clients go quiet. But a tail of zero is worse, because nothing is holding their attention during handover. Somewhere between 10% and 20% is the range that keeps both sides engaged without putting real money at risk.
The middle is where the work is. Staging and production are the two phases with the most hours in them, so they carry the most money. Splitting evenly at 25% each looks tidier and matches the work worse.
The objection worth taking seriously
There is a real argument that milestone billing hands the client a lever: if payment depends on their approval, they can slow your cash flow by not approving. That happens, and it is the strongest case against milestones.
The fix is not to abandon milestones, it is to stop making approval the trigger. Write the trigger as delivery plus a review window:
Each milestone is invoiced on delivery. The client has five business days to raise written defects against the acceptance criteria for that milestone. Undisputed after five business days, the milestone is deemed accepted. Defects raised in that window are corrected before the next milestone begins.
Now silence completes the milestone instead of stalling it. Their review right is preserved, it just has an expiry. This one clause is the difference between milestone billing that works and milestone billing that turns into unpaid waiting.
What goes on each milestone invoice?
Each milestone is its own invoice with its own sequential number, its own dates, and enough description that someone in accounts payable who has never heard of the project can approve it. Sequential numbering matters more here than on a one off invoice, because four documents from the same vendor against the same purchase order is exactly the pattern that triggers a duplicate payment check.
Invoice one, sent the day the contract is countersigned:
INV-0051 Issued: 17 Aug 2026
Due: on receipt
Milestone 1 of 4 - Specification phase
Acme dashboard rebuild, per SOW dated 15 Aug 2026
Technical spec, build estimate, risk register
25% of $12,000.00 project fee $3,000.00
------------------
Total due $3,000.00
Terms: due on receipt. The scheduled start date is confirmed
on receipt of this payment.
Invoice two, sent the day staging goes up, not the day it is approved:
INV-0055 Issued: 11 Sep 2026
Due: 25 Sep 2026 (net 14)
Milestone 2 of 4 - Staging demo
Feature complete build on staging, acceptance
criteria A1 to A9 passing (staging URL supplied
11 Sep 2026)
30% of $12,000.00 project fee $3,600.00
------------------
Total due $3,600.00
Paid to date: $3,000.00 (INV-0051, 19 Aug 2026)
Remaining after this invoice: $5,400.00
Invoice three, on the production deploy:
INV-0059 Issued: 30 Sep 2026
Due: 14 Oct 2026 (net 14)
Milestone 3 of 4 - Production deploy
Live on app.acme.com, DNS cut over, TLS issued,
uptime and error monitoring configured, smoke
tests passing
30% of $12,000.00 project fee $3,600.00
Change order CO-01 - CSV export endpoint
(approved in writing 22 Sep 2026, 4h at $150.00) $ 600.00
------------------
Total due $4,200.00
Paid to date: $6,600.00
Remaining after this invoice: $1,800.00
Invoice four, at handover:
INV-0062 Issued: 20 Oct 2026
Due: 3 Nov 2026 (net 14)
Milestone 4 of 4 - Handover
Repository transferred to Acme GitHub org,
credentials handed over, runbook and deployment
docs delivered, 14 day defect window closed
15% of $12,000.00 project fee $1,800.00
------------------
Total due $1,800.00
Project reconciliation - for reference, no action required
Project fee per SOW $12,000.00
Change order CO-01 $ 600.00
INV-0051 milestone 1 paid 19 Aug 2026 -$3,000.00
INV-0055 milestone 2 paid 24 Sep 2026 -$3,600.00
INV-0059 milestone 3 paid 13 Oct 2026 -$4,200.00
This invoice $1,800.00
Four patterns are doing the work in those documents. Every invoice says which milestone of how many it is, so nobody has to guess whether more are coming. Every invoice names the evidence, so approval does not require a meeting. The running paid and remaining figures mean a finance reviewer can sanity check the total without opening the other three PDFs. And the reconciliation block on the final invoice heads off the single most common reason a last invoice sits in a queue: someone seeing $1,800 against a $12,000 statement of work and asking a question that takes a week to answer. The rest of the fields are the same as on any other invoice, and they are covered line by line in what belongs on a software development invoice.
One bookkeeping note. If you are on the cash method, each milestone payment is income in the tax year you receive it, regardless of when the project finishes. The IRS sets out the cash method and constructive receipt rules in Publication 334, Tax Guide for Small Business. A project that starts in November and delivers in February therefore lands across two tax years, split at whatever point the milestones happened to fall. The SBA's guide to managing your business finances covers the cash versus accrual choice that sits underneath this. General information only, not tax advice.
What happens when a milestone slips?
Every project slips. What matters is who caused it, because the answer determines whether you get paid.
The client caused it. They did not deliver the content, the API credentials, the staging DNS, or the feedback. Your work is done and blocked. This is what a standing time clause is for, and it should be in the contract before you need it:
If the client does not supply materials, access or written feedback within ten business days of a written request, the milestone in progress is invoiced at the greater of the work completed to date or 50% of the milestone value, and the remaining schedule shifts by the length of the delay.
Without that clause you are financing their delay. With it, the invoice goes out and the calendar moves, and neither of those is a negotiation.
You caused it. Do not send an invoice. Send a revised date the moment you know, before they ask, and do not attach a discount to it unless the contract has a penalty clause. Volunteering money for a two day slip trains the client to expect it for every one after.
Nobody caused it, the work turned out to be bigger. This is a change order, not a slip. The scope grew, so the price and the schedule grow, in writing, before you build it. The extra becomes its own line item on the next milestone invoice, the way CO-01 does on invoice three above.
The mistake to avoid in all three cases is renegotiating the split mid project. If milestone three grows, add a change order line to it. Do not reopen the percentages, because that turns one conversation into four.
How do milestones compare to deposits and retainers?
They solve overlapping but different problems, and plenty of engagements use two of them at once.
| Structure | Fits | Protects you from | Weak spot |
|---|---|---|---|
| Deposit only | Short projects under about $5,000 | A client who cannot move money at all | Everything after the deposit is unbilled until delivery |
| Milestone billing | Fixed price projects of 4 weeks or more | Carrying the whole project unpaid | Needs verifiable triggers and a review window, or it stalls |
| Retainer | Ongoing work with no defined end | Gaps between projects | Wrong shape for a one off build with a deliverable |
| Weekly or fortnightly arrears | Hourly work, and clients whose policy bars prepayment | Long exposure windows | Does not test whether they can pay before you start |
The practical default for a fixed price build is a deposit that is milestone one, then milestones behind it. The deposit tests whether the client's payment process works before you have written anything, and the milestones cap what you are carrying afterwards. If you are still deciding between fixed price and hourly in the first place, the trade offs are in hourly vs fixed price billing for developers, and milestone billing is really only available to you on the fixed price side of that choice.
FAQ
How many milestones should a project have?
Divide the project fee by the largest amount you are willing to have delivered and unpaid at once, and round to the nearest whole number between three and five. On a $12,000 project, if $4,000 of unpaid work is your ceiling, that is four milestones. Below three you are running a deposit and a final invoice with extra steps. Above five or six the administrative overhead starts to outweigh the protection, and the milestones get small enough that clients begin batching them anyway. Long engagements over roughly three months are usually better served by monthly billing than by eight milestones.
Do I invoice before or after the milestone is approved?
Invoice on delivery, with a review window running in parallel. Milestone one is the exception and is invoiced on signature, before the phase starts, because it doubles as the deposit. For the rest, waiting for approval before invoicing means your payment clock does not start until the client acts, which can add two or three weeks to every milestone with nothing to show for it. Send the invoice the day you deliver, state the acceptance criteria on it, and let the five day defect window and net terms run together. If a defect is raised, you fix it inside the window and the invoice stands.
What if the client disputes that a milestone is done?
Go straight to the acceptance criteria and ask which numbered item failed. Most disputes evaporate at that question, because the objection is usually about something that was never in the milestone: a feature from a later phase, a design preference, or general nerves. If a criterion genuinely failed, fix it and the milestone completes, no drama and no renegotiation. If they will not point at a criterion, that is not a completion dispute, it is a payment problem wearing a completion dispute's clothes, and the reply is your work stop clause rather than more building. This is exactly why the criteria get written and numbered at the start, when everyone is friendly, instead of at the point of disagreement.
Can hourly projects use milestones?
Partly. You can use milestone dates for billing on an hourly engagement, invoicing every two weeks or at the end of each phase against actual hours logged, and that is a good habit. What you cannot do is use milestones as fixed price checkpoints, because the amount is not known in advance, so the client has no ceiling and you have nothing definite to invoice against. The hybrid that does work is fixed price milestones for the defined scope plus a separate hourly line, at a stated rate and a stated cap, for support and out of scope requests. Keep the two on separate lines of the same invoice so the fixed portion stays legible.
Sources
- Federal Acquisition Regulation, Subpart 32.1, Non-Commercial Item Purchase Financing
- IRS, Publication 334, Tax Guide for Small Business
- US Small Business Administration, Manage your finances
Got a milestone schedule to bill? Build the first invoice free at billable.dev, then save it and hit duplicate for each milestone. The number increments on its own, so you keep a clean sequence across all four without tracking it in a spreadsheet. Nothing leaves your browser and there is no account to create. If you would rather start from a filled in layout, the free invoice template for developers shows the structure; Pro ($4 a month billed as $24 every 6 months, or $79 once) keeps the saved history so the final reconciliation block writes itself.
This post is general business practice guidance, not legal or tax advice. Contract terms and the tax treatment of staged payments vary by country and state. Check your own position with a professional in your jurisdiction before relying on any of it.