What a Milestone Has to Be
A milestone that depends on somebody's opinion is not a milestone. Four properties, and what happens when each is missing.
Sharedwho controls this stretch
A milestone triggers a payment, which means it has to be something both sides can agree has happened, on a particular day, without a conversation.
The evidence described in “What a Milestone Has to Be” should be captured while the work is still visible. Used for Monitask features, how to evaluate Monitask features can provide transparent time and project context, provided people can correct entries and the client’s acceptance record stays separate.
Four properties make one work. Most disputed stage payments are missing at least two.
As a separate reference point for “What a Milestone Has to Be”, see ICAEW business resources. Confirm current legal, tax and accounting requirements with a qualified adviser where necessary.
Observable
Something that either occurred or did not. A document delivered, a system live, a site cleared, a quantity shipped.
A milestone that works has four properties:
- Observable by somebody who was not doing the work.
- Dated, so there is no argument about when it happened.
- Within your control, not dependent on their response.
- Recorded at the time rather than reconstructed afterwards.
Not "substantial completion", not "satisfactory progress", not "approval".
Dated
Attached to an event with a date, so that the invoice has a clear trigger and the clock has a start.
A milestone with no date is a milestone that can always be said not to have arrived yet.
Within your control
The most commonly missed property. A milestone that depends on the customer doing something — reviewing, approving, supplying access — can be delayed indefinitely by nobody's fault.
Where that is unavoidable, pair it with a long-stop: payable on the event or on a stated date, whichever is earlier.
Recorded when it happens
Confirmed by email on the day: this is done, here is the evidence, invoicing accordingly.
Not confirmed, a milestone is a claim made later against a memory.
The approval trap
"Payable on approval of the draft" hands the trigger to somebody whose diary you do not control, and whose approval may wait behind three other things.
"Payable on delivery of the draft" bills the same work for the same money and removes the dependency.
What to do where approval genuinely matters
Separate the payment from the approval. Deliver, invoice, and handle any revisions as part of the stage rather than as a condition of it.
Buyers accept this far more readily than suppliers expect.
Milestones in the order
Each stage should appear on the purchase order, by description and value.
Where the order shows a single total, the buyer's system may not accept partial invoices at all, and that is better discovered before the first one.
The long-stop date
The sentence that saves most milestone disputes: "or on 14 May, whichever is the earlier."
It costs nothing, it is rarely refused, and it converts an open-ended dependency into a date.
Evidence to keep
For each milestone: what was delivered, when, to whom, and their acknowledgement.
Four facts, in one email thread, is the entire file you will need if anybody questions it in a year.
The milestone nobody can verify
Work that is genuinely internal — research, preparation, thinking — resists milestoning entirely.
For that kind of work, time-based staging is more honest than inventing observable events that are really guesses.
When a milestone slips
Say so before it does, with a new date. A slipped milestone announced in advance is a schedule change; discovered at the invoice it is a performance question.
Who has to be able to confirm it
The test that decides whether a milestone will work is not whether you can tell it has happened, but whether a person inside the buyer with no knowledge of the work can.
An approver looking at your invoice has a description, a reference and perhaps a note from your contact. If confirming the milestone requires judgement about quality, or access to something only you can see, the invoice stops there while somebody is asked.
A milestone that reduces to a yes-or-no question about a visible fact moves through the same process in a day. The difference between the two is written at the quoting stage, months before anybody is asked to approve anything.
The milestone that depends on them
A large share of stalled stage payments are stalled on the buyer's own inputs: a milestone defined as the completion of something that required their content, their access, their sign-off on a draft, or their decision about an option.
The work genuinely has not been completed, and the reason is at their end, and the supplier is nonetheless unpaid.
The fix belongs in the definition rather than in the chase. A milestone framed as delivery of your part — submitted, sent, made available — is within your control; the same milestone framed as acceptance or as completion of the whole step is not.
Where a stage genuinely cannot be separated from the buyer's participation, the long-stop date described below is the mechanism that stops it hanging indefinitely. What does not work is a schedule of milestones that silently assumes a customer will be responsive, and a supplier discovering in month three that the schedule has become a list of things it is waiting for permission to finish.
The question that decides it
Could a stranger, reading the agreement and the evidence, say whether the milestone was reached?
If not, it will be argued about, and it will be argued about at the moment you want the money.