Payment Milestones for an AI Project That Work

Payment milestones for an AI project should be tied to verifiable deliverables, never to calendar dates, and there should be four of them rather than two. The reason is structural: the traditional 50 percent upfront and 50 percent on delivery split was designed for work where the build phase lasted months. When the build phase lasts four days, that schedule hands you all your money before anyone has agreed what the thing does, and then leaves half of it hostage to a client who has stopped replying.

Below is the schedule that survives contact with a fast build, a worked example at 12,000 in whatever currency you invoice in, and the one milestone almost everyone leaves out.

Why the 50/50 split breaks on AI work

On a three-month custom build, the 50/50 split works because time does the enforcing. The client cannot disappear for the middle six weeks without noticing, and you cannot coast, because there is visibly a lot left to do.

Compress the build to days and three things go wrong at once.

• The deposit arrives before the scope is real. You are paid to build something nobody has written down precisely, which is how the next argument starts.

• The gap between deposit and delivery is too short to notice a problem. A client who is unavailable for a week has been unavailable for the entire project.

• The final 50 percent becomes the whole negotiation. Everything the client wants to change is now leverage against a payment you have already earned.

Fast delivery does not reduce your payment risk. It concentrates it into the one week the client is least prepared to pay attention.

The four payment milestones for an AI project

The percentages matter less than the count. Four payment points mean that if a project dies, it dies having paid you for the part you finished. Two payment points mean it dies owing you half of everything.

Milestone 1 is paid discovery, and it should be

Charging for the spec is the single highest-leverage change on this list. It filters out clients who were never going to buy, it gets the requirements written while someone is paying attention, and it means the thing you build in four days is the thing that was asked for. If you are not comfortable charging for it separately, running it as a small paid pilot achieves the same thing with an easier name on the invoice.

Milestone 2 is where AI speed actually helps you

A working slice used to be expensive to produce, which is why the industry settled for showing mockups instead. It is now cheap. Build one real path, from the actual input to the actual output, on the client's real data, and demo it live rather than sending a recording. A client who has watched their own data come out the other side stops asking whether the project will work and starts asking when it ships.

The milestone everybody forgets: acceptance

Milestone 4 is the one missing from most contracts, and it is the one that decides whether you get paid in full or spend two months answering emails for free.

Write an acceptance window into the contract: a fixed number of business days, usually seven or ten, that begins the moment you hand over. During the window the client tests against the signed spec and reports anything that does not match. You fix those things. When the window expires with no report, acceptance is automatic and the final payment falls due.

Three rules make the window hold:

1. Only defects against the spec restart anything. A request for something the spec does not mention is new work, quoted separately.

2. The window runs on business days and starts on handover, not on the day the client eventually opens the email.

3. Silence is acceptance. Say it in exactly those words in the contract, because the alternative default is that silence is indefinite.

This clause does most of the work of keeping a project from turning into unpaid maintenance, which is the other half of handling scope creep on an AI project.

A worked example at 12,000

A two-week automation project for a mid-sized client: document intake, extraction, routing into their existing system, with a review queue for anything low confidence.

Note what the shape of this does. By day four you have collected half the project value and the client has seen their own documents processed. By day nine you have collected 85 percent. The remaining 1,800 is small enough that no client fights over it and large enough that you care about closing the acceptance window properly.

Compare that to 6,000 upfront and 6,000 on delivery, where on day nine you are owed half the project and the only leverage you hold is a piece of software already running in their account.

Payment terms, late payment, and the stall

Attach payment terms to each milestone, not to the project. Seven or fourteen days net per invoice is normal for work at this size, and shorter terms are easier to defend when the invoice follows a visible deliverable. If you invoice within the EU, the Late Payment Directive gives you an automatic entitlement to interest plus a minimum 40 euro recovery cost, with statutory interest set at a floor of 8 percent above the European Central Bank reference rate and a default 60-day ceiling on business-to-business terms. Most freelancers never invoke any of it, which is fine, but knowing it exists changes the tone of the second reminder email.

Put the milestone on the invoice

A small formatting habit prevents a surprising amount of argument. Each invoice should name the milestone it covers, quote the line from the signed spec that the milestone satisfies, and state the running total against the project value. Three lines.

The reason is that invoices get forwarded. The person who approves payment is often not the person who watched the demo, and an invoice reading "AI project, stage 2" gives them nothing to approve against. An invoice reading "Milestone 2 of 4, working slice, invoice extraction running end to end on live data, demoed 8 September, 6,000 of 12,000 to date" answers the only question they were going to ask.

For the stall itself, the rule is to stop work rather than escalate tone. Work stops at the unpaid milestone, the client is told plainly and once, and nothing further is built until it clears. This is far easier to do at milestone 2 of 4 than at the halfway point of a two-payment contract, which is the practical argument for the whole structure.

If the project dies at this point rather than recovering, the milestone structure has already done its job, and what happens when a client cancels an AI project becomes a much shorter conversation.

Frequently asked questions

Should the deposit be bigger than 20 percent?

Only if the spec phase is genuinely large. The deposit exists to cover discovery and to confirm the client is real, not to de-risk the whole project. A very large deposit makes the later milestones too small to enforce anything.

Does this work for fixed-scope and hourly alike?

Milestones assume fixed scope. If you bill hourly there is nothing to hang them on, which is one of several reasons fixed scope tends to beat hourly on AI projects once delivery speeds up.

What if the client wants to pay everything at the end?

Then the spec milestone is the test. A client who will not pay 20 percent for a written scope is telling you something useful about the remaining 80 percent, and it costs you four pages of work to find out rather than two weeks.

How does this affect what I charge overall?

It should not change the total. Milestones govern when money moves, not how much. Setting the number itself is a separate exercise, covered in how much to charge for an AI automation project.

If milestones are not the right fit and the client wants you paid from what the product earns instead, see how to structure a revenue share deal for an AI project.