Acceptance criteria, milestone payments, and holdbacks

Reference article · 6 min read

A payment schedule is a statement of what the agency believes it is buying. When milestones are tied to dates, signatures, or vendor activity, the agency is paying for elapsed time. When milestones are tied to functionality that has been demonstrated against written criteria in the agency's own environment, the agency is paying for results. The difference rarely matters in the first few months. It matters when a project slips and the agency discovers that most of the money is already out the door.

Acceptance criteria, milestone payments, and holdbacks are three parts of one mechanism. Acceptance criteria define what "done" means. Milestone payments attach money to those definitions. A holdback keeps a meaningful sum unpaid until the system has run in production long enough for real problems to surface. Each part is weak without the other two.

Define each deliverable so it can be tested

A deliverable is not a phase name. "Configuration complete" and "Phase 2" cannot be tested, so they cannot be accepted or rejected on any principled basis. Write each deliverable with a scope and a condition.

• Name the artifact or function. Converted case records, a working permit intake workflow, an interface that posts nightly to the financial system, a completed training curriculum delivered to a named group of staff.
• Name the environment. Functionality shown in a vendor sandbox is not the same as functionality running in the agency's test environment, with agency data, agency identity management, and agency network controls.
• Name the data. Acceptance on sample records invites rework later. Where privacy rules permit, test against production-representative volumes and edge cases, and handle masking obligations in the contract.
• Name the measurable condition. Response time at a stated concurrency, batch completion inside a stated window, conversion error rates within a stated tolerance.

Write acceptance tests before the work starts

Acceptance tests should exist in writing before the vendor begins the work they govern, not after delivery when both sides are arguing about what was promised. Attach them to the contract as an exhibit, or require them as an early deliverable that the agency approves in writing before the milestone opens.

Useful tests are procedural: preconditions, steps, expected result, pass or fail. They should be written or reviewed by the people who will actually use the system, not only by the project manager. Include negative cases and boundary cases, because that is where configuration gaps appear. Where accessibility, security, or records retention obligations apply, make them testable rather than aspirational, and confirm the current requirements with your own counsel and security office, since they vary by jurisdiction and change over time.

Set a review window and constrain "deemed accepted"

Vendors reasonably ask for protection against indefinite review. Agencies reasonably refuse language that turns silence into payment. The workable middle is a defined window with obligations on both sides.

• State the window in business days. Start the clock only when the vendor delivers written notice of readiness along with the test evidence the contract requires.
• Allow the clock to pause when the agency is blocked by a vendor defect, an unavailable environment, or missing documentation.
• If you accept a deemed-accepted clause, keep the window realistic for your actual staffing, require written notice before deeming takes effect, and exclude deliverables that depend on incomplete work.
• Preserve later rights. Acceptance of a deliverable should not waive warranty claims or claims for defects discovered afterward, and the contract should say so plainly.

Hold back through go-live and stabilization

Retainage is the portion of each milestone payment the agency withholds until the system is live and stable. It exists because integration problems, performance problems, and data problems tend to appear under real load, not during scripted testing.

Define release of the holdback by condition, not by calendar date alone. Typical conditions include a stated period of production operation without severity-one defects, closure of an agreed defect backlog, delivery of final documentation and source configuration exports, completion of knowledge transfer, and confirmation that the agency can administer the system without vendor assistance for routine tasks. Some states cap retainage or regulate its release for certain contract types, so confirm the rules that apply to your procurement before drafting the percentage.

Define rejection and what happens next

A rejection clause that only says the agency "may reject" leaves the project without a path forward. Specify the mechanics.

1. The agency issues written notice identifying the failed test cases and the observed behavior.
2. The vendor has a defined period to correct and resubmit, with the review window restarting on resubmission.
3. A limit applies on repeated failures, after which the agency may withhold the milestone, require a remediation plan, reduce scope, or terminate for cause.
4. Severity levels determine whether a defect blocks acceptance or moves to a punch list with a due date and a portion of payment attached.

Common failure modes

• Accepting on a demo. A demonstration is vendor-controlled. Acceptance should be agency-executed against written test cases.
• Paying at signature. Money released before any working functionality exists buys nothing testable. Where advance payment is unavoidable, tie it to a bond or an early verifiable deliverable.
• Milestones that measure effort. "Requirements workshops delivered" and "design document submitted" measure vendor activity. Pair document milestones with small amounts, and put the real money on working functionality.
• Vague final acceptance. If go-live is the only acceptance event, the agency has no leverage for two years and then has all of it at once.
• No one assigned to test. Agencies routinely sign strong acceptance language and then miss review windows. Staff the testing role before the contract is signed.

What to require and what to ask

Require in the contract: a deliverables table mapping each item to its acceptance criteria, payment amount, and review window; an acceptance test exhibit or an early approved test plan; a defined defect severity scale; retainage with condition-based release; and written rejection and cure mechanics. Ask vendors during evaluation how they define acceptance on comparable implementations, what evidence they submit with a deliverable, how they handle a rejected milestone, and which of their proposed milestones represent working functionality rather than documentation.

HQT builds and implements software for state and local agencies, and works within acceptance and milestone structures of this kind.

Frequently asked questions