[Blog]()Software acceptance # Accepting software: business tests and verifiable open issues “It works” needs a case, a result and someone who can approve it. Acceptance begins before the demonstration. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** Accept software through agreed tests of critical processes, run by business users with observed results recorded. Every failure needs a decision: block delivery, allow limited use or schedule a later improvement. A correction is accepted only after rerunning the case and checking related effects. ## Test worksheet: Software acceptance with verifiable business tests “It works” needs a case, a result and someone who can approve it. Acceptance begins before the demonstration. Record inputs, expected outcome, evidence, owner and observed result. [Download CSV worksheet]() In this guide - [Turn scope into results you can verify]() - [Fictional example: producing and partially delivering an order]() - [Check normal work, exceptions and retries]() - [Verify again after a correction]() - [Keep delivery and acceptance boundaries clear]() ## Turn scope into results you can verify “Production module complete” does not tell you whether you can reserve material, record waste and partially deliver an order. Write the starting point, data, steps and final state for each process. Name its tester and approval owner. If a requirement changes during testing, record the scope change before judging the supplier against a different rule. [ITI]() distinguishes functional testing from acceptance against business needs and processes. [Azure Test Plans]() can organize manual and acceptance tests with results. Tools can organize the work; criteria, representative data and the decision to use the system still need owners. ## Fictional example: producing and partially delivering an order A factory rehearses order P-310 for 100 units. Material is available for 80, a batch of 60 is produced and quality rejects five. The expected outcome is 55 released units, five rejected and 45 still owed on the order. This synthetic case is not a customer's result. Its value is connecting production, quality and a sales commitment in one check. The buyer should not approve it because each screen opens. They must find the same order, see material reservation, distinguish rejection from delivery and verify that a second click does not create another dispatch. Agree how the outstanding quantity will be handled. If the order can close without an explanation, decide whether that violates the defined process. | State |Meaning |Next decision | | --- | --- | --- | | Passed |Result and evidence match the agreed criterion |Close that case | | Failed and blocking |Prevents critical work or corrupts data |Correct and retest before release | | Limited use accepted |Specific workaround and owner-approved risk |Document limit, owner and date | | Not run |Access, data or dependency was missing |Still pending; never count as passed | ## Check normal work, exceptions and retries The matrix must identify the tested version, environment and input. Evidence should name a reference, export or screenshot that reconstructs the result without unnecessary sensitive data. A long demonstration recording does not replace an identifiable case. Fill observed results during execution rather than copying them from a proposal. | Test |Expected result |Business owner | | --- | --- | --- | | Reserve material for 80 |Visible reservation without authorizing impossible production |Production | | Release 55 and reject five |Separate quantities and recorded rejection reason |Quality | | Deliver the 55 released units |Order retains 45 outstanding |Sales and warehouse | | Attempt to deliver rejected units |Blocked with a useful explanation |Quality | | Retry confirmation after losing response |One dispatch; existing reference can be queried |Warehouse | | Unauthorized user attempts release |No state change; traceable attempt |Process owner | ## Verify again after a correction Ask for a new run of the failed case on the corrected version. Also check a neighboring case that could be affected: changing outstanding-quantity calculations may alter returns or cancellations. Keep old and new results; deleting initial evidence to make a matrix look perfect hides useful history. Closing a failure should explain what changed and who confirmed the result. Do not reduce the decision to a pass percentage. Nine passed tests and one duplicate dispatch may still prevent operation. Classify issues by their business effect and agree on each unresolved item. Performance, specialist security and recovery may need additional evaluation; functional acceptance alone does not demonstrate that those areas are resolved. ## Keep delivery and acceptance boundaries clear Use a controlled copy for rehearsal and agree which test data will remain. User preparation, connections, training and the cutover window can limit use even after code is delivered. Connect acceptance with the [cutover and rollback plan](), and review [questions before hiring a software company]() to document access and responsibilities. The downloadable worksheet contains examples to adapt to your process. Bring an anonymized order, a frequent exception and the stage scope to a [free consultation]() for [software consulting](). We can review whether the criteria support a concrete decision, without turning a successful demonstration into automatic approval. ## Define your software acceptance checks Use an order or service with a real exception to check the agreed scope. In a free consultation, define the expected outcome, who verifies it, and which unresolved issue prevents acceptance of that stage. - Stage scope and agreed acceptance criteria - An anonymized order or service with a real exception - Users who execute and authorize each result [Book a free consultation]()[Ask on WhatsApp]() Related - [Software consulting]() - [Custom software]() ## Frequently asked questions ### Can the supplier approve its own tests? It can execute and document technical checks, but business acceptance belongs to the agreed owner. That person needs sufficient data and criteria to decide. Signing a list without running the cases does not demonstrate the outcome. ### Must every test pass? Blockers must be resolved before the affected use begins. Other issues may be accepted with a documented limitation and workaround. The decision depends on risk and agreement; a pass percentage does not replace that review. ### What evidence is sufficient? Evidence should identify version, input, steps and result without replaying the entire conversation. It may be a reference with an export, an authorized screenshot or a system record. The process and data policy determine the appropriate form. ### Does a failed test mean canceling the project? Not necessarily. A well-described failure can be corrected and retested. Clarify ambiguous criteria; review the agreement when a critical capability is outside scope. Do not accept a different outcome solely because a stage was scheduled to finish. ## Sources 1. [Azure Test Plans overview]()Microsoft 2. [Pruebas de software]()ITI Last updated: October 8, 2026 ## Keep reading [System cutoverOct 8, 2026 ### Changing systems: rehearsal, cutover and rollback conditions]()[OperationsOct 2, 2026 ### How to document your processes without red tape (so your best employee isn’t the manual)]()[GuidesOct 2, 2026 ### Before you hire a custom software company: 10 questions to ask]() --- Canonical: https://nightlysoftware.com/en/blog/software-business-acceptance-tests Updated: 2026-10-08 Description: Define business tests, separate blockers from open issues and rerun corrected cases. Includes a downloadable software acceptance worksheet.