Acceptance Criteria in Software Contracts: How to Define 'Done'
Half of all large IT projects massively overrun their budgets, and a large share of that overrun is not spent writing code. It is spent arguing about whether code that was already written counts as finished.
That argument almost always traces to one missing paragraph. The statement of work described features. The payment schedule described money. Nothing described the evidence required to move a deliverable from “submitted” to “accepted.” The vendor believes the milestone is complete, the client believes it is 80% complete, and no neutral standard exists to settle it. Weeks of senior engineering and legal time disappear into a dispute that a competent acceptance criteria software contract section or even a basic software development contract checklist would have closed in an afternoon.
McKinsey and the BT Centre for Major Programme Management at the University of Oxford analyzed more than 5,400 IT projects with budgets above $15 million. On average those projects ran 45% over budget and 7% over schedule while delivering 56% less value than predicted and software projects carried the highest risk of cost and schedule overruns of any category.
The pattern is scale-invariant. A $40,000 agency engagement fails the same way a $40 million enterprise program does: the definition of completion lives in someone’s head instead of in a schedule to the agreement.
What follows is the anatomy of an enforceable acceptance criteria software contract clause: objective versus subjective standards, a worked checkout example, the acceptance window, milestone tie-ins and adaptable clause language.
What Is an Acceptance Criteria Software Contract Clause?
Acceptance criteria in a software contract are the objective, testable conditions a deliverable must satisfy before the client is contractually obligated to accept it and release payment. They convert “done” into pass/fail evidence named test cases, performance thresholds, defect severity limits and target environments instead of leaving approval to subjective judgment.
The distinction that matters is evidentiary. A criterion belongs in an acceptance criteria software contract only if two parties who disagree can run the same test and reach the same answer, which is why the criteria are usually attached to the statement of work rather than described loosely inside it.
“To Client Satisfaction” Is Not a Testable Standard
Most disputes begin with language that sounds reasonable at signing. Phrases such as “to the reasonable satisfaction of the Client,” “industry standard quality” and “substantially complete” appear across most mid-market development agreements, and each hands the definition of completion to whichever party is angrier later.
The practical difference is stark. Under a satisfaction standard, an agency delivers a working checkout and the client’s VP of Marketing rejects it because a button color feels off-brand. Under an acceptance testing clause software teams can actually operate, the button color is either in the design spec or it is a change order with the same clarity that makes comparing development quotes meaningful in the first place.
Subjective language creates three compounding costs.
Schedule drift comes first. Acceptance rounds that should take 10 business days stretch to 30 or 45 because no bounded list of checks exists; every review invites fresh opinions.
Cash-flow damage lands on the vendor. When 30–40% of a fixed fee sits behind a final gate with no defined test, an agency can carry six figures of unpaid work for a quarter.
Relationship erosion completes the set. Once the client’s leverage is “we won’t sign” and the vendor’s is “we won’t fix,” both sides are negotiating rather than delivering. A proper acceptance criteria software contract provision removes that game because the answer is already documented.
How to Write Criteria That Survive a Dispute
Drafting enforceable criteria is a delivery discipline, not a legal formality. It needs the technical lead and the contract owner in the same room before signature, which is why the acceptance criteria software contract conversation belongs in the proposal stage rather than the kickoff meeting.
QA, UAT and Formal Acceptance Are Three Different Events
Quality assurance is the vendor’s internal verification that the build matches the specification. It runs continuously, at the vendor’s cost, and produces the evidence submitted with each deliverable; teams without that capability in-house often scope it as a dedicated QA project.
User acceptance testing is the client’s verification that the software supports real business workflows, run by client-side testers in a defined environment against a defined script.
Formal acceptance is the contractual event, a written determination, or deemed acceptance triggered by silence, that payment is now due.
Collapsing the three produces a predictable failure: a client rejects a deliverable for defects UAT should have caught two sprints earlier, and the vendor has no basis to refuse the rework. Any acceptance criteria software contract should state that acceptance testing is limited to the documented criteria and is not a re-review of previously accepted work, a separation that verified testing and QA agencies will normally insist on themselves.
The UAT Sign Off Process Needs a Named Human and a Bounded Script
A functional UAT sign off process specifies four things the agreement should name outright: who holds sign-off authority, which environment testing occurs in, which test script is executed, and what format the response takes. The strongest agreements carry these forward from the software development RFP rather than inventing them at contract stage.
Sign-off authority should be one named role, never a committee. An acceptance criteria software contract requiring “Client approval” without naming an approver reliably stalls, because three stakeholders each assume someone else is responsible and the window expires undecided.
Environment matters more than clients expect. Criteria verified on staging with seeded data will not reproduce on infrastructure carrying real load, real integrations and real data quality. Name the environment, name the dataset, state who provisions it.
A Worked Example: Measurable Criteria for a Checkout Flow
Subjective version: “Vendor shall deliver a fully functional checkout experience meeting Client’s requirements.”
Objective version: under an acceptance criteria software contract schedule the kind experienced e-commerce development partners will propose without being asked the deliverable is accepted when all of the following are demonstrated in the environment specified in Schedule C:
- All 27 test cases in Schedule B execute successfully, covering guest checkout, registered checkout, saved-card checkout and abandoned-cart recovery.
- Payment paths pass the provider’s test suite: successful authorization, 3-D Secure challenge, declined card, expired card, network timeout with retry, and partial refund.
- Tax and shipping calculations match Schedule B-2 to the cent across the 12 named jurisdictions.
- Confirmed orders write to the ERP within 60 seconds, with 500 consecutive test orders processed with zero data loss or duplication.
- The checkout path completes on the two most recent versions of Chrome, Safari, Edge and Firefox, plus iOS 16+ and Android 12+.
- The p95 load time for each checkout step is 2.0 seconds or less on a simulated 4G connection.
- Under 250 concurrent checkout sessions, the transaction error rate stays below 0.5%.
- The checkout path meets WCAG 2.2 Level AA, verified by an automated scan returning zero critical violations plus manual keyboard-navigation testing.
- Zero open Severity 1 or 2 defects; no more than five open Severity 3 defects; Severity 4 items recorded on a punch list for the warranty period.
Item nine carries the most weight, and works only if the defect severity levels are defined inside the acceptance criteria software contract itself. A workable set: Severity 1 means checkout is unusable or transactions fail with no workaround; Severity 2 means a core function fails with an impractical workaround; Severity 3 means a non-core function fails or has a practical workaround; Severity 4 is cosmetic with no functional impact. Without those definitions, every bug becomes a negotiation about its own severity.
The Acceptance Period and What Silence Triggers
Your acceptance period contract language is where most agreements are quietly one-sided, and it deserves more redline attention than it usually gets.
Typical windows run 5 to 15 business days from the delivery notice; complex integrations spanning several stakeholder groups the norm on enterprise software budgets justify 20 to 30. Too short, and clients reject reflexively to protect their position; too long, and the vendor finances the project indefinitely.
Silence is the harder question. Most vendor-drafted agreements include a deemed acceptance clause: absent written rejection inside the window, the deliverable is automatically accepted and payment falls due. Clients who strike this wholesale usually regret it, because an open-ended acceptance right is exactly what makes agencies price defensively.
Three further triggers are worth negotiating into any acceptance criteria software contract:
- Production use as acceptance. Putting the deliverable into live commercial use accepts it regardless of the window. This stops the pattern where a client runs revenue through a system while withholding sign-off.
- Partial acceptance. Deliverables passing in part should be acceptable in part, with the disputed portion carved out otherwise one failing test case blocks an entire milestone payment.
- Clock suspension. The window pauses when the client fails to supply the environment, test data or named testers, and resumes when they do.
Rejection Rights, Cure Periods and the Second Failure
Sound rejection rights software delivery terms are specific about the form of a rejection, not just the right to issue one. A rejection notice should be written, delivered inside the window, and identify each non-conformity by reference to the numbered criterion it fails. “This isn’t what we wanted” should be contractually invalid.
The escalation ladder that works:
- First rejection opens a cure period commonly 10 to 15 business days during which the vendor remediates at its own cost.
- Re-submission restarts a shortened window, typically 5 business days, limited strictly to the items named in the rejection notice.
- Second failure on the same criteria opens client remedies: a defined fee reduction, third-party completion at the vendor’s cost up to a cap, or extension with liquidated damages.
- Third failure permits termination for cause, with refund of amounts paid for that milestone and delivery of work product, source code and documentation as they exist.
Cap the cycle. An acceptance criteria software contract with no limit on rejection rounds creates an infinite-loop obligation no agency should accept and no client genuinely benefits from and the termination remedy is only worth anything if code ownership when you outsource is already settled in your favour.
Tying Acceptance to the Milestone Payment Schedule
Payment structure is where acceptance stops being theoretical. A workable fixed-price split: 20% at kickoff, 30% on acceptance of a defined build phase, 30% on acceptance of the integrated release, 20% on final acceptance.
Two drafting choices matter more than the percentages. Avoid tying 100% of a milestone to a single all-or-nothing event; partial acceptance with a proportional holdback keeps cash moving. And keep the final holdback modest: 10–15% is defensible, while 40% turns an acceptance criteria software contract into a financing arrangement disguised as a quality gate, and changes which agencies will quote against your custom development budget at all.
What This Looks Like on Real Engagements
A Series-B logistics company hired an offshore agency for a driver-facing mobile app at a fixed price near $185,000, a figure that tracked the offshore rate differences for that region. Its acceptance criteria software contract language relied on “reasonable satisfaction,” and milestone two sat unpaid for 11 weeks while both sides argued whether GPS accuracy was a defect or an unspecified requirement. After rewriting the remaining milestones around 41 numbered test cases and a four-level severity matrix, the final two milestones cleared in 9 and 6 business days.
A mid-market retailer replatforming checkout caught the opposite problem during vendor vetting. The proposed contract carried a 5-business-day window with deemed acceptance and no clock suspension, so a delivery submitted before a two-week holiday freeze would auto-accept untested. Extending the window to 15 days and adding a suspension trigger cost nothing at negotiation and protected roughly $54,000 of final-milestone leverage.
A Framework for Choosing Your Acceptance Model
Not every engagement needs identical rigor. Match the acceptance criteria software contract model to the contract structure and the cost of being wrong, the same way a buyer framework for comparing agencies weights capability against risk.
| Acceptance model | What “done” means | Best fit | Primary failure mode |
| Satisfaction-based | Client approves subjectively | Small design or advisory work under $15,000 | Unbounded review cycles, unpaid vendor work |
| Test-case based | A numbered suite passes in a named environment | Fixed-price contract acceptance criteria for defined scope | Heavy upfront drafting, brittle if scope shifts |
| Sprint / incremental | Each sprint’s stories meet a shared definition of done | Time-and-materials and agile retainers | No single gate, so integration issues surface late |
| Service-level based | The running system meets uptime and performance thresholds | SaaS, managed services, ongoing platforms | Measures operation, not delivery correctness |
Most substantial engagements need a hybrid: incremental acceptance during delivery to surface problems early, plus a formal gate at each payment milestone to make the criteria enforceable.
What Most Teams Get Wrong
The criteria get written after the SOW is signed. This failure is structural: acceptance language feels like a legal detail during a commercial negotiation, so it gets deferred to “we’ll define the test plan at kickoff.” By kickoff the price is fixed and the leverage is gone, and any acceptance criteria software contract drafted after signature favors whoever is more willing to escalate.
Second, teams let the agency both write the test cases and run them. Vendors should propose criteria; they know the technical surface better than the client does. But accepting a vendor-authored suite without review lets the vendor grade its own work, which is why criteria review belongs in the same stage of a step-by-step hiring guide as reference checks. Budget 4 to 8 hours of a technical stakeholder’s time to review and add cases.
Third, clients underestimate their own obligations. UAT needs client-side people, test data, environment access and decisions. A meaningful share of blown windows trace to the client’s team rather than the vendor’s build, and vendors who omit clock-suspension language absorb that cost silently.
Fourth, and most consequential during selection: teams evaluate agencies on portfolio and price while ignoring how they draft acceptance terms. An agency that proposes specific, testable criteria before you ask is telling you something real about how it runs projects. One that resists any objective standard is showing you one of the clearer red flags in a development company and verified delivery history predicts a clean acceptance criteria software contract far better than a polished pitch deck.
Before You Sign the SOW
Acceptance language is not a legal afterthought. It decides whether a fixed-price engagement ends in a working product or a settlement conversation. If your acceptance criteria software contract defines completion in terms a reasonable person could read two ways, that clause is the highest-leverage thing you can fix this week.
If you are scoping a new build and want to compare verified IT agencies on how they handle scoping, acceptance and delivery terms without bidding wars, listing fees or a 10–20% commission out of your budget GetProjects lets you post a project in under two minutes and connect directly with vetted agencies at no cost. Review how each one proposes to define “done” in writing, and choose on substance rather than sales pressure.
Start at getprojects.ai, and bring your draft acceptance criteria software contract terms to the first call the agencies worth hiring will engage with them immediately.
Frequently Asked Questions
What counts as delivered software under a contract?
Determining what counts as delivered software depends on the agreement’s own definition. Absent one, delivery means the vendor’s submission of the build plus written notice. Delivery and acceptance are separate events: delivery starts the clock, acceptance triggers payment. Every acceptance criteria software contract should define delivery to include what testing requires the build, deployment instructions and test evidence.
How long should a software acceptance period be?
Five to fifteen business days is standard for discrete deliverables. Complex integrations touching multiple systems justify 20 to 30. Set the window against real testing effort: if the full suite takes six days of a tester’s time, a five-day window is not an acceptance right, it is a formality.
What is the deemed acceptance clause meaning in practice?
The deemed acceptance clause meaning is straightforward if the client does not respond inside the window, the deliverable is treated as accepted and payment falls due. It protects vendors from indefinite non-payment. Clients should accept the principle but negotiate the conditions: a realistic window, a clock that pauses when testing is blocked, and no deemed acceptance for defects not reasonably detectable.
What is the difference between QA and UAT in a contract?
QA is the vendor’s internal testing against the technical specification, included in the fee. UAT is the client’s business-workflow testing against documented criteria, run by client-side testers. Your acceptance criteria software contract should limit acceptance testing to those criteria otherwise UAT expands into a general product review and the gate never closes.
Do acceptance criteria work in agile or time-and-materials contracts?
Yes, with a different structure. Time-and-materials agreements apply a shared definition of done per sprint, with a lighter formal gate at release boundaries. An acceptance criteria software contract in an agile engagement governs release increments rather than one monolithic deliverable, and payment tracks time worked rather than acceptance events.
What should a SaaS acceptance testing clause cover?
A SaaS acceptance testing clause should separate implementation acceptance from ongoing service levels. Test the implementation first data migrated with verified record counts, integrations authenticating and syncing, configured workflows executing then hand off to SLA terms covering uptime, response times and support for the subscription term.
Who should write the acceptance criteria: the client or the agency?
Both, in sequence. The agency drafts the technical criteria because it knows the implementation surface; the client reviews, adds business-workflow cases and confirms they reflect production reality. If you are still selecting a partner, comparing how several agencies answer that question is the cheapest diligence available before any acceptance criteria software contract gets signed.