Contract clause
Acceptance testing clause: deciding when the work is done
An acceptance testing clause sets out how a customer tests a deliverable against agreed criteria, how long it has to do so, how it rejects a failed deliverable, and when it is treated as accepted. Acceptance usually triggers payment, starts a warranty period and shifts the burden of proving later defects, so it shapes cash flow as much as quality.
Suppliers fear a customer that never says yes, and customers fear being told a half working system was accepted. An acceptance clause gives each side a date, a test and a decision, with deemed acceptance usually doing the tie breaking.
Nuwan Madhusanka · Co-founder
4 min read · Published
Sample clause
a software development agreement between Tarragon Apps, a fictional mobile app studio in Adelaide, and Marri Community Transport, a not for profit commissioning a booking app for volunteer drivers and passengers
7. Acceptance Testing 7.1 When Tarragon Apps notifies Marri Community Transport that a Deliverable is ready, Marri Community Transport has 10 Business Days (Test Period) to test it against the Acceptance Criteria in the relevant Statement of Work. 7.2 Before the Test Period ends, Marri Community Transport must give written notice either accepting the Deliverable or rejecting it, identifying each failure to meet an Acceptance Criterion with enough detail to reproduce it. 7.3 After a rejection, Tarragon Apps must correct the listed failures and resubmit the Deliverable within 10 Business Days, and a new Test Period applies to the corrected items only. 7.4 A Deliverable is taken to be accepted if Marri Community Transport does not give notice under clause 7.2 within the Test Period, or uses the Deliverable in live operation other than for testing. 7.5 Acceptance does not affect the warranty in clause 9. 7.6 If a Deliverable is rejected three times, Marri Community Transport may terminate the relevant Statement of Work under clause 20.
Sample wording, not legal advice.
Variants
Deemed acceptance on silence
A small supplier that cannot carry unpaid work while a customer's team is distracted by other priorities.
If the Client does not notify the Developer in writing of any material failure of a Deliverable to meet its specification within 5 Business Days after delivery, the Deliverable is taken to be accepted on the last day of that period. The Developer may invoice for the Deliverable on acceptance. Minor defects that do not prevent the Deliverable being used for its intended purpose do not justify rejection but must be fixed within the warranty period.
No deemed acceptance
A customer buying a complex or regulated system that must formally sign off before relying on it.
A Deliverable is accepted only when the Customer's Project Sponsor signs an Acceptance Certificate in the form of Schedule 6. No other conduct, including use of the Deliverable, payment of any invoice or the passing of time, constitutes acceptance. The Customer must not unreasonably withhold or delay signing an Acceptance Certificate for a Deliverable that meets the Acceptance Criteria.
Staged acceptance
Projects where components are delivered separately and the final system must also work as a whole.
Each Module is subject to Module Acceptance under clause 7.1. When all Modules have achieved Module Acceptance, the Supplier must deliver the integrated System for Final Acceptance testing over 20 Business Days against the end to end test scripts in Schedule 4. Module Acceptance does not prevent the Customer rejecting the System at Final Acceptance for a failure caused by the interaction of Modules.
What to negotiate
Objective criteria
Acceptance against the customer's satisfaction gives the customer a veto. Suppliers insist on criteria written into the statement of work, ideally test scripts or measurable functions. Customers accept objective criteria but ask for a catch all that the deliverable is fit for the purposes described, which suppliers try to confine to documented purposes.
Deemed acceptance triggers
Silence and live use are the usual triggers. Customers resist silence where test resources are thin, and ask for longer periods or a reminder notice before deeming applies. Suppliers accept a reminder if the reminder period is short. Live use is harder to resist, since a customer running its business on the system is plainly accepting it.
Defects that do not block acceptance
Customers want to reject for any defect; suppliers want only material defects to count. A severity classification solves it: critical and major defects block acceptance, minor ones go on a list to be fixed within an agreed time. Linking the list to a holdback of part of the payment keeps the supplier motivated.
The risk of leaving it out
Without an acceptance clause, it is unclear when work is complete, when payment is due and when warranties start. A customer can hold payment by pointing to defects of any size, while a supplier can argue the customer accepted by starting to use the work. Both positions lead to disputes that turn on correspondence and conduct rather than on a defined test.
What acceptance changes
Acceptance is a legal turning point, not just a project milestone. Payment is often due on acceptance. The warranty or defects period usually starts on it. After acceptance, the customer generally has to prove a defect exists and is covered by the warranty, rather than the supplier having to prove the deliverable meets its criteria. For goods sold under United States law, Article 2 of the Uniform Commercial Code treats acceptance as occurring when the buyer signifies it, fails to reject after a reasonable opportunity to inspect, or acts inconsistently with the seller's ownership, an idea mirrored in deemed acceptance clauses.
Acceptance and non excludable guarantees
Accepting a deliverable under a contract does not remove rights that the law gives regardless. Where the Australian Consumer Law applies to a supply of services, guarantees of due care and skill and fitness for a disclosed purpose continue to apply after acceptance, and a term that purports to exclude them is void to that extent. In business to business software projects the practical effect is narrower, but the acceptance clause should still say that acceptance does not waive the warranty, as the sample does, so the two clauses work together.
Where it sits in a generated document
Acceptance testing sits after delivery and before payment in a development agreement, with the acceptance criteria themselves in a statement of work or schedule. A generated agreement numbers each clause, so the payment clause can make an invoice due on acceptance under a named sub clause. Test periods and rejection limits come from the description, and the draft cites no legislation.
Documents that carry this clause
Software development agreement with sprints and an acceptance testCustom software goes wrong in the space between delivered and accepted, where one side thinks a sprint is finished and the other is still writing a list. This agreement fixes a ten business day acceptance window against criteria written before the sprint started, and assigns the intellectual property sprint by sprint as each invoice is paid.
Statement of work template under a master agreementArdent Analytics migrates Coastline Insurance’s claims database to a cloud platform over 18 weeks under SOW-2026-041, governed by a master services agreement dated 3 March 2026. The work is time and materials with four roles priced by the day and a $412,000 estimate before GST, five dated deliverables, ten business days to accept each one, and five assumptions written down before anyone starts.Questions people ask
What is deemed acceptance?
It is acceptance that happens automatically when a stated event occurs, usually the customer failing to reject within the test period, or using the deliverable in live operation. It protects suppliers from indefinite delay. Customers protect themselves with a reasonable test period, objective criteria and, where resources are tight, a reminder notice before deeming applies.
Can a customer reject for minor defects?
Only if the clause allows it. Many clauses permit rejection only for failures to meet acceptance criteria that are critical or major, with minor defects listed and fixed within an agreed time. Without a severity rule, arguments about whether a defect is serious enough to justify rejection become common.
Does acceptance end the supplier's responsibility for defects?
No, if the contract includes a warranty or defects period, which usually starts on acceptance. Acceptance shifts the practical burden of showing a problem, but the supplier still must fix defects covered by the warranty. Statutory guarantees that apply to the supply also continue.
How long should the test period be?
Long enough to run the tests properly, which depends on the deliverable. Five to ten business days is common for a single feature or document, and twenty business days or more for an integrated system. Periods should restart only for corrected items, not the entire deliverable, unless the fix affects other parts.
Should acceptance trigger payment?
Often, particularly in milestone based projects. It gives the supplier an incentive to deliver working software and the customer leverage until it does. Suppliers limit the risk of withheld payment through deemed acceptance and objective criteria, and sometimes negotiate part payment on delivery with the balance on acceptance.
What happens if a deliverable keeps failing?
Clauses usually allow a set number of correction attempts, often two or three, after which the customer may accept with a price reduction, have the work completed by others at the supplier's cost, or terminate that part of the work. Without a limit, a failing project can cycle through tests indefinitely.
Put the clause in a finished document
The button opens the document generator with a starting description already filled in. Change it to match your own agreement before you run it.
Create a document with OneCraftRelated clauses
- Change control clause: requesting, pricing and approving a scope changeA change control clause sets how scope changes on a services or software project are requested, priced and approved. Sample procedure, form fields and variants.
- Milestone payment clause: paying by stageA milestone payment clause splits the price into stages released on acceptance. Sample wording for a four stage software build, variants and what to negotiate.
- Service level clause: turning good service into numbersA service level clause sets the measurable standards a service must meet. Sample uptime and response wording with a metrics table, and three variants.
- Warranty clause: promising a standard and backing itA warranty clause promises a fact is true or that work meets a standard. Australian sample wording for a ninety day defects warranty, variants and remedies.
For everything the document generator can do, see the document maker.
Step by step in the builder: Create a document with AI, then Document builder components.
Written and checked by the OneCraft team. Last checked .