Acceptance Criteria for Custom Business Software

A demonstration is the beginning of acceptance

A convincing demonstration shows that a selected path can work. Acceptance asks whether the delivered version meets agreed requirements under defined conditions, including situations the presenter would rather avoid. For business owners purchasing custom software, this distinction matters more than the number of screens in the presentation.

Agree on acceptance evidence before the delivery checkpoint. Otherwise the buyer may expect a fully operated service while the supplier believes it owes only a working application. Separate functional acceptance, security verification, data reconciliation and operational handover. Different people may be responsible for approving each part.

Specify a complete business journey

Imagine a hypothetical service company implementing job scheduling and invoicing. A realistic journey starts with an authorized scheduler creating a job, continues through assignment and completion, and ends with an invoice linked to the correct customer. The acceptance evidence should demonstrate those transitions with representative, non-confidential test records.

A checklist saying “invoicing works” is too broad. State which inputs are used, which role performs the action, what the resulting invoice contains and which records remain unchanged. Include a cancellation after assignment, an incorrect tax configuration and an attempted duplicate completion. Financial treatment must follow the company's approved rules rather than assumptions embedded in the test.

Use explicit expected outcomes. If invoice delivery fails, does the job remain completed while delivery is retried? Does the user see pending delivery or a misleading success? Acceptance must distinguish a business transaction from a notification about that transaction.

Choose evidence according to risk

• Functional evidence: saved records, resulting state and permitted subsequent actions.
• Authorization evidence: the same operation succeeds for an allowed role and fails for a denied role through the server endpoint.
• Data evidence: imported totals, rejected records and correction decisions reconcile with the approved source.
• Recovery evidence: an authorized operator can recover the system using a tested procedure in an isolated environment.
• Usability evidence: representative users complete the journey without undocumented workarounds.

OWASP ASVS provides a structured reference for application-security verification. Select relevant controls and record the version and scope used; a checklist alone is not certification. Playwright's official testing guidance recommends independent, isolated tests, which helps make browser evidence reproducible rather than dependent on an earlier test's session or data.

Keep environment and release identity visible

Every acceptance run should identify the application version, database migration state, environment, test data and configuration assumptions. A pass on one build is not evidence for a later build with different dependencies. Avoid production credentials in test reports; record secret identifiers or approved configuration references instead of values.

Test integrations honestly. A simulated payment response can establish local handling, but cannot prove settlement with the real provider. Label simulated, sandbox and live evidence separately. Any real transaction or customer notification needs an approved operating procedure and an appropriate authorized tester.

Handle defects without changing the meaning of acceptance

Classify defects by business impact and recoverability. A misspelled label may be accepted with an owner and correction date. Unauthorized access to another customer's records is a release blocker. The project should define those boundaries before the final meeting, rather than negotiating them under schedule pressure.

Record a failed scenario with steps, expected result, actual result and release identity. After a fix, rerun the affected journey and relevant neighboring cases. Do not mark a defect closed solely because a developer says the code changed. Conversely, avoid rerunning every unrelated test when a focused correction has a clear, limited impact.

Make the sign-off decision explicit

A practical acceptance record identifies what passed, what remains excluded, who accepted the residual limitations and whether operation may begin. Conditional acceptance should name conditions and consequences. Silence in a meeting is not reliable approval.

For the hypothetical scheduling system, readiness means that the scheduler can create and amend a job, the technician sees only authorized assignments, completion cannot create duplicate invoices, and the operator can diagnose a failed notification. The business representative should verify the resulting records, not just follow a successful animation.

There is an alternative to one large final event: accept small, coherent journeys during delivery, then verify their combined behavior before launch. This exposes misunderstandings earlier while preserving a final release decision. A software delivery discussion should include the evidence the business needs to accept the system, alongside the features it wants to buy.