Acceptance testing regime: documents to prepare
An acceptance testing regime confirms that delivered software meets agreed criteria before payment or go-live is triggered. Preparing for it means fixing the test plan, the acceptance criteria and the sign-off procedure before testing starts, not after delivery lands. Missing documents at this stage routinely turn a technical delay into a payment dispute.
What changes once testing starts
Once the acceptance clock starts, silence stops being neutral. In most technology contracts, a fixed number of business days is set for the customer to respond to a test result. If nobody signs, rejects or raises a defect list inside that window, the contract usually treats the deliverable as accepted by default.
This default matters more than any single test script. A vendor that delivers on time and hears nothing back is entitled to invoice as if acceptance happened. A customer that wanted more time should have said so in writing, inside the window, not after it closed.
The point of no return is therefore not a technical milestone. It is a calendar date tied to a document that either exists or does not.
Documents to have ready before testing begins
Four documents carry the whole regime. Each should exist before the first test run, not be drafted while the clock is already running.
| Document | Purpose | Owner |
|---|---|---|
| Test plan | Defines scope, environment, data set and pass criteria | Agreed jointly, drafted by vendor |
| Acceptance criteria list | Sets measurable conditions a deliverable must meet | Customer defines, vendor confirms feasibility |
| Test log | Records each run, result, date and tester identity | Vendor maintains, customer can inspect |
| Sign-off form | Records acceptance, rejection or conditional acceptance with a deadline | Customer signs, vendor countersigns |
A test plan without pass criteria is not a test plan; it is a description of activity. If the criteria are vague, disagreement at sign-off is close to guaranteed, and the dispute will centre on interpretation rather than on the software itself.
What to do, in order
- Confirm the acceptance window in the contract before drafting anything else — the number of days sets every other deadline.
- Draft the test plan jointly; do not let one side write criteria the other has not seen.
- Agree the test environment and the data set in writing, since results depend on both.
- Run tests and log each result with date, tester and outcome.
- Issue the sign-off form within the window, marking acceptance, rejection, or conditional acceptance with a cure deadline.
- Keep every version of the test plan; a later dispute usually turns on which version was current.
Who decides, and how fast
Under most technology contracts, the customer's project lead decides acceptance or rejection, not the technical team running the tests. The decision is recorded on the sign-off form, inside the contractual window, which is typically measured in business days from delivery.
If the parties disagree on whether criteria were met, the contract usually points to an escalation step first — a joint review meeting or a named senior contact — before any dispute mechanism applies. Skipping that step tends to weaken a party's later position, because it suggests the disagreement was never properly tested internally.
Common forks
If the acceptance criteria were never fixed in writing, testing has no fixed target, and any sign-off is open to later challenge. Fix the criteria before running another test cycle, even if this delays the schedule.
If the other side has gone quiet inside the window, check the contract's default rule first. Silence often equals acceptance, and a customer who wanted to reject needed to say so before the deadline, not after.
If a defect is found after sign-off, check whether the contract separates acceptance from warranty. Many technology contracts hold acceptance and warranty as distinct regimes, so a post-acceptance defect follows a different clock and a different remedy path.
What this page does not cover
This page describes the procedural mechanics of acceptance testing: documents, timing and decision points. It does not set out remedies for a failed test, does not value a claim arising from rejected software, and does not address open-source components found inside a delivery, which follows a separate procedure. It also does not cover change requests raised mid-testing, which belong to change control rather than acceptance.
Sources and limit
This procedure reflects standard drafting and market practice in technology contracts and does not rely on a single statutory reference, because acceptance testing is typically a contractual mechanism rather than a statutory one. Where a dispute over acceptance escalates into a counterparty check, the relevant registry data is set out separately: Counterparty in Italy and what to prepare.
Where the underlying deliverable includes documentation held outside the immediate jurisdiction, a parallel registry question can arise: Document in Luxembourg explained.
Details of firm scope and how this material is checked sit on a separate page: About the firm and its scope in detail.
Related publications
A closely related procedure covers the documents needed once a delivered system is changed rather than newly tested: Change control procedure: documents to prepare.
FAQ
How long does acceptance testing regime take in practice?
The duration is set by the contract, not by the complexity of the software. Most acceptance windows run for a fixed number of business days from delivery, with a shorter secondary window for re-testing after a rejection. The total procedure, including one re-test cycle, commonly runs several weeks from first delivery to final sign-off.
Which documents are needed to start?
Testing should not start without a written test plan, agreed pass criteria and a defined environment and data set. Without these three, any result produced is difficult to rely on later, because there is no fixed baseline to measure it against.
What happens if the other side does not respond?
Check the contract's default rule first. Many technology contracts treat silence inside the acceptance window as acceptance by default. If the contract is silent on this point, the safer course is to issue a written notice recording the delivery date and the deadline for response, so the record does not depend on memory later.
Next step
If a delivery has already run into a dispute over on-chain or off-chain recording rather than a testing sign-off, the first practical steps differ: What to do first in this situation in practice. If the concern is an open-source component surfacing inside a delivery, the cost of an unclear position is set out here: When open source is found in the delivery and.