What Is "Acceptance Testing" in System Development? What to Check at Delivery

Acceptance testing (often called "kenshu" in Japanese business practice) is the process by which a client inspects a delivered system or piece of software and formally accepts it after confirming that it matches what was agreed in the contract and specifications. In common industry practice, once acceptance is complete, the delivery is generally treated as "finished," and any defects found afterward are usually handled separately as a matter of contractual non-conformity, with different implications than issues raised before acceptance. For this reason, acceptance testing is not merely a formality — it is a key step that determines what the client does and does not confirm before taking ownership of the system. For the bigger picture of ordering a system, see our guide to ordering system development; this article focuses specifically on the acceptance process itself.

Acceptance testing matters because software development deals in an intangible deliverable. Unlike a building or a piece of machinery, whose condition can often be checked visually at delivery, software cannot be judged as correct simply by how it looks. A screen may display correctly while a calculation is subtly wrong under certain conditions, or the system may stop processing entirely once real data is loaded — both are common occurrences. Acceptance is also closely tied to payment timing. Under many contracts, completing acceptance triggers the obligation to pay the remaining balance, or is a precondition for invoicing, so rushing through acceptance can weaken your position for negotiating fixes to issues discovered later. Conversely, if acceptance criteria are left vague when the contract is drawn up, both the client and the development company can end up with different understandings of "how much needs to be checked before it counts as complete," which becomes a seed for disputes.

Acceptance-related problems generally fall into three structural patterns. The first is an unclear scope of review — the contract or specification does not spell out acceptance criteria, so pass/fail ends up being judged subjectively by whoever handles it on the client side. The second is an imbalanced review process — acceptance is completed solely by the IT department or the project lead, without input from the frontline staff who will actually use the system day to day. The third is time pressure — the acceptance period is set too short, or business demands push the review to the last minute, causing the contractual acceptance window to lapse and triggering a "deemed acceptance" clause (a provision under which acceptance is considered complete if no objection is raised within a set period). In each case, the client fails to make full use of acceptance as a right that belongs to them. Many additional-cost disputes also originate from insufficient checks at the acceptance stage — see how to prevent additional-cost disputes for a fuller picture of that risk.

The exact items to check during acceptance vary by contract and specification, but small and mid-sized businesses ordering a system commonly need to cover the following.

- Core functionality: Confirm that the features listed in the specification/requirements document work as described, through the described steps and conditions
- Real-data verification: Test with actual business data (or data close to it in volume and format), not just sample data, to check processing speed and error behavior
- Permissions and security: Confirm that access rights for each user work as specified, and that no user can perform operations they shouldn't be able to
- Error handling: Confirm that incorrect input or unexpected operations produce appropriate error messages and do not crash the system
- Full set of deliverables: Confirm that source code, design documents, manuals, and various accounts (server, domain, admin access to external services, etc.) are handed over as agreed in the contract
- Operations and maintenance terms: Confirm that post-acceptance maintenance scope and conditions align with the contract and with how maintenance costs are typically structured

Acceptance periods vary by contract, but one to two weeks is a common range. This is only a guideline, though — it can be adjusted by mutual agreement depending on the scale of the system and its impact on operations. What matters most is not letting acceptance be completed solely by the IT department or a single point of contact, but building in an opportunity for the frontline staff who will actually use the system day to day to try it out. Usability issues and mismatches with real workflows are the kind of thing that only shows up when the people who'll use the system get their hands on it — a purely technical review tends to miss them. Planning frontline testing into the acceptance schedule, and setting up a way to consolidate feedback and relay it to the development company, works best when it's thought through before the contract is even signed.

If you find a defect or a mismatch with the specification during acceptance testing, describe it in terms of a reproducible sequence rather than a vague impression. Lay out when it happened, on which screen, what operation was performed, and what happened as a result (including how it differs from the expected result), and share screenshots or a screen recording where possible — this speeds up the fix considerably. It also helps to keep the exchange in a written, trackable form — email or a ticketing tool — rather than verbal conversation alone. Keeping a running list of what was flagged during the acceptance period and how each item was resolved is useful both for deciding when acceptance is truly complete and for settling any disagreements that come up later.

Acceptance testing marks the formal delivery point of a system development project, and it is also the client's last real opportunity to confirm the quality of what they're receiving. Preparing a checklist in advance, and building in verification with real data and participation from frontline staff, makes it far less likely you'll be caught off guard after the fact. How acceptance criteria and post-acceptance handling actually work depends on the wording of your specific contract, so if anything is unclear, review the contract itself and consult the development company or a qualified professional as needed.