What Each Payment Milestone Should Actually Trigger

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A VP-Engineering or COO at a mid-size Indian enterprise — 500+ crore revenue, regulated sector — who is about to sign a 1–3 crore custom software contract and has been handed a payment schedule by the vendor that ties every tranche to a date or a named module, not to a verified outcome

Every payment milestone in a custom software contract should trigger on one event and one event only: your written acceptance of a deliverable against criteria you signed off before the work began. Not the vendor's assertion of completion. Not the passage of a date. Not the appearance of a module in a staging environment. If your current schedule ties tranches to phrases like 'Phase 1 complete' or 'UAT environment delivered,' you are about to sign a contract where the vendor controls both the trigger and the evidence — and Indian courts will treat their assertion of delivery as the default.

This matters because the money is already large and getting larger. India's custom software development market is valued at $2.34 billion in 2024 and projected to reach $10.55 billion by 2030, which means more enterprises are signing more 1–3 crore contracts with governance frameworks that were designed for 20-lakh projects. And the base rate for things going wrong is not reassuring: 66% of enterprise software projects experience budget overruns, with 15% exceeding budgets by 200% or more. Your milestone clause is the main instrument you have for not being in that 15%.

What follows is a clause-by-clause rebuild of a payment schedule. It is written for the person who has to sign the contract and brief the lawyer, not for the lawyer. This is not legal advice. A qualified lawyer and, where applicable, your statutory auditor should review the final document against your sector's regulatory posture.

The core problem: delivery triggers vs. acceptance triggers

A delivery trigger pays the vendor when they say the thing is delivered. An acceptance trigger pays the vendor when you say it works. These sound similar. They are not.

Indian courts, following English contract authority, treat milestone payments as hard triggers. As Cyril Amarchand's dispute resolution team summarised in 2025, 'milestone payments will not become payable until the specified milestone is achieved — often evidenced by certificates or completion of testing,' and partial or 'substantial' performance does not suffice. The practical consequence: if your clause names the trigger as 'delivery of the KYC module,' then once the vendor delivers something they call the KYC module, the money is due. If you refuse to pay because it does not actually perform KYC checks against your bank's risk engine, you are now the party withholding payment, and the burden of proving the deliverable was defective sits with you.

This burden is not theoretical. In a 2025 Delhi High Court matter upholding an ₹18.22 lakh arbitral award against an infrastructure company, the court emphasised that 'correspondence, acceptance records, warranty-period communications and subsequent purchase orders may collectively undermine allegations of defective performance.' Translation: the enterprise that lacks contemporaneous written acceptance records loses the evidentiary battle, even when the software genuinely did not work.

The fix is a two-part structural change. First, every milestone must name a deliverable and the acceptance criteria that deliverable will be tested against. Second, the payment trigger is the signed acceptance certificate, not the deliverable itself.

What each milestone should actually trigger

Here is the milestone structure that holds up when things go wrong. The specific percentages vary by project and are not the point — the triggers are.

Milestone 1 — Kickoff / mobilisation

What it is for: Covering the vendor's team ramp-up cost and signalling you are a serious counterparty.

The wording that protects you: Payment is triggered on execution of the SOW and delivery of a named project team roster (with CVs, employment status, and committed allocation percentages), the written project plan with milestone dates, and the signed acceptance criteria for all subsequent milestones.

The wording that quietly does not: 'Payable on signing.' This gives the vendor cash before you have the acceptance criteria for milestones 2 through 7 locked down. Once they have your money, the leverage to negotiate tight criteria evaporates.

The question to put to the vendor: 'Can we attach the full set of acceptance criteria for every subsequent milestone as a schedule to the SOW, signed on day one?' If they resist, ask why.

Milestone 2 — Discovery and architecture sign-off

What it is for: Paying for the technical design document, data model, integration map, and non-functional requirements before any production code is written.

The wording that protects you: Trigger is your written sign-off on the architecture document, which must include: the API contract for every external integration, the data model with field-level definitions, the authentication and authorisation model, the deployment topology, the observability stack, and a written statement of what the system will not do.

The wording that quietly does not: 'Payable on submission of design document.' Submission is not acceptance. A design document can be submitted that omits half your compliance requirements.

The question to put to the vendor: 'If our architecture review surfaces a gap — say, we realise RBI's digital lending guidelines require an audit log we did not spec — is that a scope change or a correction to the design deliverable?' The honest answer is 'it depends on when the requirement was knowable,' and you want that nuance written into the SOW.

Milestones 3 to N minus 2 — Feature or module releases

This is where most schedules go wrong. The vendor proposes milestones named after modules — 'Loan Origination module,' 'Dashboard module,' 'Admin panel' — and ties payment to delivery of each. You should restructure these around verified capability, not module delivery.

The wording that protects you: Each milestone deliverable is accompanied by (a) a pre-written acceptance test suite that your team or an independent QA party will execute, (b) a definition of done that includes code coverage thresholds, security scan results, and performance benchmarks against named NFRs, and (c) a formal UAT window — typically 10 to 15 business days — within which your team runs the tests and either signs the acceptance certificate or issues a written defect report. Payment is triggered on the signed certificate.

The wording that quietly does not: 'Deemed acceptance after 7 days if no written objection.' Deemed acceptance clauses look innocuous and are the single most dangerous phrase in a software SOW. In a regulated enterprise, your QA, security, and compliance teams cannot credibly complete acceptance testing of a non-trivial module in 7 days, and the vendor knows this. The clause converts every milestone into a delivery trigger with extra steps.

If you cannot delete the deemed acceptance clause entirely — and some vendors genuinely need it to protect themselves from a buyer who disappears — negotiate the window to a defensible length (minimum 15 business days for modules, 20 for integrations touching regulated systems), require written notification to a named individual on your side when the clock starts, and carve out explicit exceptions for defects classified as severity 1 or 2, which pause the clock entirely until resolved.

UAT best practice from 2026 is unambiguous: acceptance criteria must be defined before development begins — writing them after code is done is 'writing a test you already know passes' — and exit criteria must include formal stakeholder sign-off before any milestone is considered complete.

The security and compliance gate milestone

In regulated sectors — BFSI, healthcare, insurance, listed-company IT — insert a dedicated milestone before go-live that pays only on completion of: a third-party penetration test with all critical and high findings remediated, a data protection impact assessment, sub-processor disclosure matched against your DPA, and sign-off from your CISO or equivalent.

The wording that protects you: Payment is triggered on receipt of the pen test report from a named independent vendor (not the development vendor's in-house team) and written confirmation from your security function that remediation is complete.

The wording that quietly does not: 'Vendor shall conduct security testing prior to go-live.' This lets them test themselves.

The go-live milestone

What it is for: Covering the cutover work, the first week of hypercare, and the moment the system actually serves real users.

The wording that protects you: Trigger is production stability for a defined period (typically 14 to 30 days) measured against named SLAs — uptime, error rate, p95 latency, incident resolution time — with the clock resetting on any severity 1 incident. The deliverable is not 'go-live.' It is 'stable production operation for N days.'

The wording that quietly does not: 'Payable on production deployment.' A system can be deployed and immediately fall over. If payment triggered on deployment, you have paid for a system that does not run.

The retention / warranty tranche

Hold back a meaningful percentage — the market convention sits in the 10 to 20 percent range, but this is a negotiation, not a rule — against a defined warranty period, typically 90 to 180 days post go-live. This tranche is the single biggest lever you have for ensuring the vendor responds to post-launch defects.

The wording that protects you: Retention is released at the end of the warranty period only if: (a) all defects raised during warranty are resolved to a defined severity threshold, (b) the transition-out package (source code, infrastructure-as-code, runbooks, credentials rotation plan, architectural decision records) has been delivered and verified, and (c) knowledge transfer sessions with your internal team have occurred and been signed off.

The wording that quietly does not: 'Retention payable 90 days after go-live.' Date-based release of retention defeats the purpose of retention.

The clauses that make the milestone structure actually work

A payment schedule is only as strong as the surrounding contract machinery. Four clauses matter disproportionately:

The acceptance criteria schedule. Attach as a numbered schedule to the SOW. Every milestone references its clause in this schedule. Changes to acceptance criteria follow the change control process. The vendor cannot unilaterally interpret what 'working' means.

The defect classification matrix. Define severity 1 through 4 with examples specific to your system. Severity 1 pauses the UAT clock and blocks milestone acceptance. Severity 3 and 4 can be deferred by agreement. Without this matrix, every disputed defect becomes a renegotiation.

The change control clause. Scope changes get priced and timed in writing before work starts. No scope change executes on a verbal instruction or a Slack message. This protects both sides, but it protects you more, because vendors are better at tracking undocumented scope than buyers are at remembering they asked for it.

The termination-for-convenience clause with milestone-pro-rata settlement. If you terminate mid-project, the settlement formula should pay the vendor for completed and accepted milestones plus work-in-progress on the current milestone, measured against evidenced effort — not a lump-sum early termination fee that effectively holds you to the full contract value. For context on how transition-out should look in practice when you are modernising a complex estate, our write-up on digital transformation engagements covers the artefacts a buyer should insist on at handover.

What this costs you to negotiate, and what it saves

Rebuilding a payment schedule along these lines adds roughly two to four weeks to contract negotiation and typically requires one or two rounds with the vendor's legal team. Some vendors will push back hard on removing deemed acceptance; a few will walk away. That is useful information.

The saving is harder to quantify in advance but easy to see in the base rates. PMI's 2025 Project Success Report found that 12% of total project investment is lost due to poor project performance — meaning $1 in every $8 spent on software produces no usable output. On a 2 crore contract, that is 24 lakh of exposure that a well-structured milestone schedule is specifically designed to compress, because the money does not move until the output is verified.

The specifics that would turn this general guidance into a schedule your lawyer can redline: the number and type of external integrations, your sector's regulatory acceptance requirements (RBI, IRDAI, SEBI, DPDP), whether you have an internal QA function or need to budget for independent UAT, and the vendor's standard contract template as a baseline to mark up. Those four variables determine the shape of the schedule more than any best-practice template. If you are scoping a contract of this size and want a second pair of eyes on the milestone and acceptance structure before you sign, that is a conversation worth having with a delivery team that has sat on both sides of the table.

Frequently Asked Questions

Can we tie milestone payments to calendar dates instead of deliverables?

You can, but it is strongly inadvisable for custom software. Date-based triggers pay the vendor regardless of whether the work is usable, and they punish you if your own team causes delays — in approvals, data provisioning, or dependency clearance — because the clock runs anyway. Deliverable- and acceptance-based triggers align incentives: the vendor is paid when something works, and delays caused by either side are visible rather than buried in a date.

What is a reasonable UAT window for a milestone in a regulated-sector project?

For a non-trivial module in a BFSI, healthcare, or insurance context, 15 to 20 business days is the floor, longer where the module touches core banking, patient records, or claims adjudication. The window should start on written notification to a named individual, pause on severity 1 or 2 defects, and reset if the vendor pushes material code changes mid-UAT. Vendors who insist on 7-day deemed acceptance for complex modules are optimising for cashflow, not quality.

How much should we hold back as retention against the warranty period?

Market practice sits in a wide band — commonly 10 to 20 percent of total contract value — released at the end of a 90 to 180 day warranty period. The exact figure is a function of how critical the system is, how much post-launch risk sits with the vendor's code versus your operations, and the vendor's financial profile (a smaller vendor cannot sustain a 20% hold without rate adjustment elsewhere). Discuss the number with your lawyer and your CFO; the structure matters more than the percentage.

What happens if the vendor refuses to accept acceptance-based triggers?

Treat it as a signal. A vendor confident in their delivery should welcome a clause that pays them for verified output, because it protects them from a buyer who moves goalposts. Vendors who insist on delivery-based triggers and deemed acceptance are either very large (and using scale to impose their template) or hiding delivery risk. If you cannot change the template, compensate elsewhere: deeper retention, shorter overall tranches, independent QA, and a tightly worded termination-for-convenience clause.

Does this structure work for fixed-price contracts, time-and-materials, or both?

Milestone-and-acceptance structure maps cleanly onto fixed-price work, where each milestone has a defined scope and price. On time-and-materials, the same logic applies to phase gates rather than payment tranches — you still want written acceptance of defined artefacts before authorising the next sprint block of spend, even though the billing cadence is different. Hybrid contracts (fixed-price build, T&M for post-launch enhancement) should carry acceptance mechanics across both halves.

Who should sign the acceptance certificate on our side?

A named individual with authority to bind the enterprise on the technical deliverable — typically a product owner or engineering lead for functional acceptance, with counter-sign from security or compliance for the pre-go-live gate. Avoid committee sign-off; it diffuses accountability and gives the vendor an opening to argue acceptance was constructively granted when one of three signatories did not respond. One name, one signature, one written record.