I structure milestone payments around things the client can click, and never around calendar dates alone. When a payment falls due because "month two ended", the invoice becomes a negotiation about how finished the work is. When it falls due because "vendor onboarding works end to end on staging and your tester has run the scenarios", the invoice is a receipt. Same money, completely different conversation.
Why do date-based milestones go wrong?
Because both sides end up arguing about a percentage. A date-based milestone falls due whether or not anything is demonstrable, so the only evidence available at invoice time is an opinion about progress. Dates also remove the pressure to have something working by the first of the month.
| Property | Date-based milestone | Acceptance-based milestone |
|---|---|---|
| Falls due when | Month two ends | Vendor onboarding works end to end on staging |
| Evidence | A percentage-complete figure | The eight UAT scenarios, ticked by their tester |
| The invoice is | A negotiation | A receipt |
| It rewards | Being on the calendar | Having something to show |
"We're at sixty percent" is a sentence that means something different to an engineer and a finance manager, and I have watched a discussion about whether a project was at sixty or seventy percent complete last longer than the sprint it was describing. Nobody wins that conversation. The vendor sounds defensive and the client feels sold to.
What does a good milestone look like?
A good milestone has four properties. It is demonstrable, so the client sees it work rather than reads that it works. It carries a short written acceptance list. Payment follows sign-off within a fixed number of days. And it is small enough to land every three to five weeks.
I check every proposed milestone against those before it goes near a contract:
- Can the client click it? If the only proof is a status update, it is not a milestone.
- Is the acceptance list written down, short, and specific enough to argue about now instead of later?
- Does payment follow sign-off inside a fixed window, so acceptance and payment are one event rather than two?
- Does it land inside five weeks? A milestone that takes a quarter is a project with one payment at the end.
A real one reads like this: "Milestone 2: vendor onboarding, from invitation to first product listed, complete on staging with email verification. Acceptance: the eight onboarding scenarios in the UAT list pass. Payment: 25 percent, within ten business days of sign-off." Nothing in there is open to interpretation, which is exactly the point.
What do buyers expect now?
Proof before promises. Buyers increasingly want to see software working before they commit money to the next stage, and they walk away from vendors who can only offer slides. Milestone structure applies that instinct to a contract, so every payment becomes a small request to show the work.
The way buyers shop for AI agents in 2026 is a good picture of it, and a vendor confident in their delivery should welcome the scrutiny, because it makes the invoice conversation short.
On AI work I go one step further. The first paid milestone is often the boring one: the evaluation set agreed, the data access working, the failure cases listed, a baseline number measured on real examples. Clients sometimes push back on paying for a milestone with no feature in it. My answer is that it is the milestone that decides whether the features are worth building, and I would rather they pay for that answer early than for a beautiful feature that turns out to be measuring the wrong thing.
What if the client's finance team needs dates anyway?
Then each milestone carries both. A target date for cash-flow planning, and an acceptance list for payment. If acceptance slips for the vendor's reasons, the vendor carries the delay and says so. If it slips because client testing has not happened, a deemed-acceptance clause takes over after an agreed window.
Ten business days after delivery is the number I usually write, so a payment cannot be held hostage by an unopened staging link. Both sides know the rules before the first invoice, which is the only time anyone reads them calmly.
At Shanti Infosoft I would rather spend an extra hour on the milestone wording during contracting than an extra week arguing about percentages in month four, and it is the hour I defend hardest in any IT consulting agreement we sign. The hour is cheaper, and the client remembers the week.
When did your last invoice conversation take longer than it should have, and what would the milestone have needed to say to make it a receipt?
Sonal Jain leads delivery at Shanti Infosoft, a CMMI Level 5 software team that has shipped for 700+ companies.
Top comments (0)