What it means
Before accepting a delivery, the customer may need to see it work under agreed conditions, so acceptance tests translate requirements into observable checks. They differ from the supplier's internal quality tests.
A fictional retailer buying a new checkout system might test a sale, refund and daily report with sample data and compare the results with the agreed requirements. The parties should define criteria before testing, because a vague requirement such as "easy to use" is difficult to accept objectively and specific steps and outcomes reduce disagreement.
A fictional software team might agree that a refund must appear in the customer's account history within a stated process, and the acceptance test then verifies that behaviour. The test plan also identifies scope, environment, data, roles and timing, since an unrealistic setup can hide production risks and some scenarios need representative users and processes.
A fictional warehouse tests its inventory software with actual barcode workflows in a safe test environment, and does not rely on a vendor demo using unrelated sample items. Microsoft's implementation guidance describes user acceptance testing from the user's perspective alongside functional and process testing, and Atlassian advises clear pass/fail criteria and recorded results.
These are methods, not universal contract clauses, and testing should cover exceptions such as failed payments, missing data or emergency shutdowns, prioritised by risk, and not only a happy path. A failure should be logged with evidence, severity and owner, then fixed and retested.
A failure in a minor cosmetic detail may be treated differently from a core function, subject to the agreement. In a fictional test that finds a wrong tax total, the customer logs steps and screenshots, the vendor repairs the calculation and the affected scenario is retested before a decision.
An acceptance decision may be full, conditional, rejected or deferred under the contract, and a signed test sheet does not mean every defect is waived, so open items should be stated clearly. A fictional buyer might accept a system with one agreed minor report format issue to be corrected by a date, and its acceptance record names that exception.
Some contracts provide deemed acceptance if the customer does not respond by a deadline or uses the product, while others require a signed certificate, so a client starting live orders should first check whether use triggers acceptance. Acceptance tests can cover physical assets too, such as a machine that must meet specified throughput and safety checks, with measurement methods and tolerances defined in the plan.
Keep a trace from requirement to test case and result, and if a requirement has no test, note how it will be verified. Agree who can sign off, because a tester can report a pass but the contract may name an authorised representative, and a verbal "looks good" is not formal approval; a test result is also not a warranty, so warranty and defect-remedy periods remain separate contractual questions.
In practice
Real-world examples.
Example
A retailer checks checkout, refund and daily reporting workflows using sample data before accepting a new point-of-sale system. The results are compared with the written requirements, and a refund that fails to appear in the account history is logged as a defect.
Example
A manufacturer tests a newly delivered packing line over a sample production run against agreed speed and error thresholds. The report records the conditions and results, and final payment is released only once the thresholds are met.
Example
A booking app passes a normal reservation but fails when the customer also tests a cancellation and a duplicate payment attempt. The wrong tax total is fixed by the vendor, and the affected scenario is retested before the decision is recorded.
Formula
Calculation
Illustrative pass rate = test cases passed / executed test cases x 100. If a customer executes 50 test cases and 45 pass, the pass rate is 45 / 50 x 100 = 90%. The 5 failed cases are logged with severity and owner, and each is retested after the fix.
Contractual acceptance depends on required criteria and defect severity, not on the percentage alone. A 90% pass rate that includes a failed payment scenario may still block acceptance, while a 90% rate where all 5 failures are cosmetic report layouts might allow conditional acceptance if the contract says so.Case study
Seen in the real world.
In this fictional case, Silver Market, an invented grocery chain, receives a new ordering system. The first test run passes routine orders but fails refunds. The vendor fixes the defect, and customer staff rerun the scenario in the agreed environment. The authorised sponsor records acceptance with any remaining exceptions under the contract.
Before signing, the team checks that every agreed feature maps to a test identifier, and the check shows that the export function was never tested. They add the scenario, run it and attach the evidence to the acceptance record. Finance is told that final payment depends on the signed certificate, not on the go-live date. The team also notes the warranty start date so that later defects are handled under the correct remedy period rather than argued as part of acceptance.
Watch out
Common mistakes.
- Writing acceptance criteria only after a dispute.
- Testing a vendor demo instead of representative business workflows.
- Treating a tester's pass as automatic formal sign-off.
Questions
People also ask.
Who runs the test?
The agreed customer users or representatives, often with supplier support.
Must every issue be fixed first?
The contract and severity rules govern whether conditional acceptance is allowed.
Is acceptance the end of support?
No. Warranty and support obligations can continue separately.
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%