What it means
Earlier stages of testing ask whether a system works as engineered. Acceptance testing asks whether it does the job the buyer is paying for, which is why it is normally run by the customer or by business users rather than by the team that built it, and why its criteria come from the contract or requirements document.
The common forms are user acceptance testing, where staff run real scenarios end to end, operational acceptance testing, which covers backups, recovery, monitoring and support handover, and factory or site acceptance testing for physical equipment. Contracts frequently make the final payment instalment conditional on passing.
Good acceptance criteria are written before development starts, are specific enough to be either met or not met, and are agreed with whoever has authority to sign off. A criterion such as "the system should be fast" produces arguments, whereas "a customer search returns results within two seconds with 500 concurrent users" produces a clear answer.
The financial argument is simple: defects are far cheaper to correct before go-live than afterwards, when they involve live data, real customers and emergency releases. Acceptance testing also protects the buyer's bargaining position, because once work is formally accepted the remedy usually shifts from withholding payment to making a warranty claim.
In practice
Real-world examples.
Example
A hospital trust runs user acceptance testing on a new appointment booking system with ward clerks rather than IT staff. They find that the shortest workflow takes eleven clicks, which passed every technical test but would never have survived a busy Monday morning.
Example
A drinks manufacturer sends two engineers to a supplier's plant for factory acceptance testing of a bottling line, verifying throughput and changeover time before the machine ships. A shortfall found on the supplier's floor is far cheaper to fix than one found after installation.
Example
A bank contracts a payments integration with 20% of the fee held back until acceptance. Two failed criteria on reconciliation reporting delay sign-off by three weeks, and the vendor fixes them at its own cost rather than lose the retention.
Formula
Calculation
Pass rate = (criteria passed / total criteria) x 100.
A retailer commissions a $1,500,000 warehouse management system with 240 documented acceptance criteria, of which 15 are classified as critical. The contract requires 100% of critical criteria and at least 95% of all criteria to pass before acceptance. On the first run, 228 criteria pass, giving a pass rate of (228 / 240) x 100 = 95%, but 3 of the 12 failures are critical, so acceptance is refused and the final 20% instalment of $1,500,000 x 0.20 = $300,000 stays unpaid. The retailer estimates that a defect corrected during acceptance testing costs about $1,200 to fix, against roughly $9,000 once the system is live, so catching all 12 defects now avoids 12 x ($9,000 - $1,200) = 12 x $7,800 = $93,600 of remedial cost.Case study
Seen in the real world.
Brindle Logistics is a fictional company used for this illustrative case. It buys a $900,000 transport planning system and, keen to move quickly, agrees acceptance criteria consisting of eleven bullet points written the week before go-live.
Testing is run by two IT analysts who confirm that each screen loads and each report generates. The system is accepted, the final instalment of $180,000 is released, and Brindle switches off its old planner. Within a month the transport office discovers that the route optimiser cannot handle multi-drop loads with mixed temperature requirements, which is roughly 30% of the business and was never written into any criterion.
The vendor is willing to help but charges the work as a change request at $140,000, because the system was formally accepted and met everything the criteria specified. In the illustrative post-mortem, Brindle's board concludes that the failure was not the software but the acceptance process: no operational user tested a real day's loads, the criteria were written too late to shape the build, and the retention was released before anyone had run the system in anger.
Watch out
Common mistakes.
- Writing acceptance criteria at the end of the project, by which point they describe what was built rather than what the business needed.
- Letting the development team run acceptance testing on the customer's behalf, which turns an independent check into a confirmation that the code does what its authors intended.
- Accepting under commercial pressure with a list of outstanding defects and a verbal promise to fix them, which surrenders the retention and the strongest remedy the buyer had.
Questions
People also ask.
Who should run acceptance testing?
The people who will use the system day to day, supported by whoever owns the budget, because they are the only ones who can judge whether it does the job in real conditions.
What is the difference between acceptance testing and user acceptance testing?
User acceptance testing is one form of acceptance testing focused on business users and workflows, alongside operational, contractual and regulatory acceptance activity.
What happens if acceptance testing fails?
The contract normally allows a defined remedy period and a retest, with the retention withheld until the criteria pass, and repeated failures may give the buyer a right to reject or terminate.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%Related