Acceptance Testing Clause

TL;DR: An acceptance testing clause governs the procedure by which a customer evaluates a delivered software system, custom deliverable, or integrated solution to determine whether the vendor has satisfied the acceptance criteria. The clause is distinct from an acceptance criteria clause, which defines the pass/fail standard; the acceptance testing clause defines the process - who runs the tests, how long the testing window lasts, how defects are reported, how many cure-and-retest cycles are allowed, and when the deliverable is deemed accepted by operation of silence. The single most negotiated provision is the deemed acceptance trigger, because a short, unforgiving deemed acceptance clock can strip the customer of its rejection rights before it has meaningfully evaluated the deliverable.

‍

What Is an Acceptance Testing Clause?

An acceptance testing clause sets out the sequence of events that moves a deliverable from tendered to formally accepted. In a typical software implementation, the vendor notifies the customer that the deliverable is ready for testing, the customer executes a defined test plan within a fixed testing window (often 15 to 30 business days), and the customer either issues a written acceptance notice or a written notice of nonconformity identifying each defect. If defects are reported, the vendor has a cure period to fix them, redelivers, and the process repeats for a limited number of cycles. If no notice is issued within the testing window, the deliverable is deemed accepted.

Acceptance testing is usually called user acceptance testing or UAT when the customer's end users drive the evaluation. It differs from factory acceptance testing (FAT), which occurs at the vendor's facility before shipment, and from site acceptance testing (SAT), which occurs after installation at the customer's site. Many complex systems integration contracts use a three-stage model: FAT, then SAT, then operational acceptance testing once the system has run in production for a burn-in period.

The clause operates as the gate between two commercial regimes. Before acceptance, the vendor bears performance risk and the customer is not obligated to pay the acceptance-linked milestone. After acceptance, the warranty period typically starts, the liability cap engages, the customer owes the milestone payment, and the customer's remedies shift from rejection and rescission to the narrower contractual warranty remedies. Because so many downstream obligations hinge on this gate, the sequencing mechanics deserve careful drafting.

Acceptance testing clauses are most consequential in custom software development, systems integration, SaaS implementation statements of work, industrial equipment procurement, and design-build construction. They are less common in off-the-shelf software licenses (where acceptance is usually immediate on install) and in commodity supply contracts (where inspection and rejection under the UCC often suffices).

‍

Why It Matters

• Payment trigger: Acceptance is the contractual event that triggers the acceptance-linked milestone payment, often 20 to 40 percent of total deliverable value. A poorly drafted testing clause that lets the customer delay acceptance indefinitely converts a fixed-fee project into an open-ended credit extension to the customer. ACC Contract Benchmarks (2024) reports that over 30 percent of technology vendor revenue disputes trace back to acceptance testing mechanics.
• Warranty start date: The warranty period typically begins on acceptance. If acceptance is delayed by testing disputes, the vendor ends up carrying warranty liability later in the calendar than it priced, and a short testing window favors the vendor. Customers should align the warranty start with substantive use of the system, not administrative acceptance.
• Deemed acceptance trap: A deemed acceptance provision with a 10 or 15 business day silence trigger can convert an unacknowledged but defective deliverable into a formally accepted one, eliminating the customer's right to reject. Thomson Reuters Practical Law notes that deemed acceptance is the most litigated feature of UAT clauses in commercial software disputes.
• Exit leverage: Repeated failure of acceptance testing is the vendor-side event that most reliably supports termination for cause by the customer. A clause that limits the customer to two or three cure cycles gives the customer a clean exit ramp if the vendor cannot deliver. Without a cycle cap, the customer is trapped in cure-and-retest until it accepts a degraded deliverable.
• Risk transfer: For physical deliverables, acceptance usually marks the transition of risk of loss from vendor to customer. For software and cloud systems, it marks the point at which the vendor stops owning production incidents and the customer's internal support obligations engage.
• Change order interaction: Acceptance testing is the point where scope creep arguments surface. A customer that insists on testing against requirements never documented in the Statement of Work is effectively invoking an undocumented change order. The testing clause should reference only the acceptance criteria exhibit and the current, approved specifications.

‍

Key Elements of a Well-Drafted Acceptance Testing Clause

1. Test plan ownership and approval: State who drafts the test plan (usually the customer or a joint team), who approves it, and when. Tie test plan approval to a project milestone before the testing window begins. Reference the test plan as an exhibit or require that it be delivered and approved a specified number of days before the vendor's notice of readiness.
2. Notice of readiness for testing: Require the vendor to deliver a written notice of readiness that certifies the deliverable has passed internal vendor testing and is ready for customer UAT. Tie the start of the testing window to receipt of this notice plus the vendor's delivery of agreed prerequisites (test data, installation, training).
3. Testing window duration: Specify the testing window in business days (typically 15 to 30 for software, 30 to 60 for complex systems integration, 90 or more for industrial equipment). Tie duration to the severity and complexity of the deliverable, not to a one-size-fits-all default.
4. Notice of nonconformity mechanics: Require the customer to issue a written notice identifying each defect by reference to the specific acceptance criterion it fails, a reproducible test case, and a severity classification (for example, Critical, Major, Minor). Vague notices that simply assert the deliverable does not work should be contractually insufficient.
5. Severity-based rejection rights: Limit the customer's right to reject a deliverable to cases involving Critical or Major defects. Minor defects should not block acceptance but should be tracked on a punch list for post-acceptance correction within a defined period.
6. Cure period and redelivery: Specify the vendor's cure period (typically 15 to 30 days for software, longer for hardware) and the vendor's obligation to redeliver with documentation of the corrections made. Specify whether cure extends or resets the testing window.
7. Retest scope and cycle cap: Define whether retesting covers only the cured defects or the full deliverable. Cap the number of cure-and-retest cycles (market standard is two cycles). If the deliverable still fails after the cap, give the customer escalation remedies: extended cure, liquidated damages, termination for cause with refund of paid milestones, or engagement of a third party at the vendor's cost.
8. Deemed acceptance trigger: State the specific conditions that trigger deemed acceptance. Common triggers include: failure to issue a notice of nonconformity within the testing window; use of the deliverable in a live production environment for a defined period; and completion of a specified business process with the deliverable. Avoid open-ended or ambiguous triggers.
9. Partial acceptance: Address whether the customer may accept some modules or phases while rejecting others. For multi-module software or phased systems integration, partial acceptance with partial milestone payment is market standard.
10. Interaction with warranty and payment: Expressly state that acceptance starts the warranty period, triggers the acceptance-linked milestone payment, and marks the point at which the limitation of liability cap engages. Cross-reference the payment terms and warranty clauses.

‍

Market Position & Benchmarks

Where Does Your Clause Fall?

• Customer-Favorable: 30 business day testing window, unlimited cure cycles, deemed acceptance only on express written notice, any defect (regardless of severity) justifies rejection, warranty period starts only on production go-live rather than on acceptance, customer may unilaterally extend testing window on written notice, customer retains right to engage third-party testers at vendor's cost.
• Market Standard: 15 to 20 business day testing window, two cure cycles before termination rights engage, deemed acceptance if customer fails to issue a conforming notice of nonconformity within the testing window, rejection limited to Critical and Major defects, warranty period begins on acceptance or deemed acceptance, punch list for Minor defects closed out within 30 days post-acceptance.
• Vendor-Favorable: 10 business day testing window, one cure cycle before deemed acceptance, deemed acceptance on any production use, rejection permitted only for material non-conformance with functional requirements, warranty period begins on delivery notice rather than acceptance, customer bears cost of extended testing, vendor self-certification of test completion sufficient absent timely written objection.

Market Data

• Acceptance testing clauses appear in approximately 82 percent of custom software development agreements and 91 percent of systems integration contracts (ACC Contract Benchmarks, 2024).
• The median testing window in enterprise software implementations is 20 business days, with 15 business days being most common in mid-market SaaS implementation SOWs (Gartner Software Acceptance Practices, 2023).
• Deemed acceptance clauses appear in roughly 74 percent of vendor-drafted technology agreements and 48 percent of customer-drafted agreements, with silence-based triggers dominating over production-use triggers (Thomson Reuters Practical Law, 2024).
• Two cure cycles before termination is the most common cap, appearing in about 58 percent of negotiated agreements; 22 percent allow three cycles, and 14 percent allow only one cycle (PLI Technology Transactions Survey, 2023).
• In disputes reaching arbitration, roughly 38 percent of software implementation claims involve disputes about whether acceptance testing was passed, with deemed acceptance triggers cited in 41 percent of those disputes (AAA Commercial Arbitration Review, 2023).
• Warranty start dates tied to acceptance (rather than to delivery) appear in about 68 percent of negotiated software agreements; the remainder either use delivery or a fixed calendar date (ACC Contract Benchmarks, 2024).

Sample Language by Position

Customer-Favorable: "Customer shall have thirty (30) business days from receipt of Vendor's Notice of Readiness to conduct Acceptance Testing. Customer may reject the Deliverable for any failure to conform to the Acceptance Criteria or the Specifications, regardless of severity. Vendor shall cure all identified deficiencies within fifteen (15) days and resubmit for retesting. There shall be no limit on the number of cure-and-retest cycles. The Deliverable shall be deemed accepted only upon Customer's issuance of a written Acceptance Notice. Use of the Deliverable for any testing, evaluation, or pilot purpose shall not constitute acceptance."

Market Standard: "Customer shall conduct Acceptance Testing within twenty (20) business days of receipt of Vendor's Notice of Readiness, using the Test Plan set forth in Exhibit E. On or before the end of the testing window, Customer shall deliver either (a) a written Acceptance Notice or (b) a written Notice of Nonconformity identifying each Critical or Major defect by reference to the Acceptance Criterion it fails and the reproduction steps. Vendor shall cure identified Critical and Major defects within twenty (20) days and resubmit the Deliverable for retesting of the cured defects. If the Deliverable fails Acceptance Testing after two (2) cure-and-retest cycles, Customer may (i) accept the Deliverable with an agreed reduction in the associated milestone payment, (ii) terminate the applicable SOW for cause and receive a refund of amounts paid for the rejected Deliverable, or (iii) extend the cure period on mutually agreed terms. If Customer fails to deliver either notice within the testing window, the Deliverable shall be deemed accepted."

Vendor-Favorable: "Customer shall complete Acceptance Testing within ten (10) business days of delivery. Customer may reject the Deliverable only for material non-conformance with the functional requirements set forth in Exhibit D. Vendor shall have one (1) opportunity to cure any material non-conformance within thirty (30) days. The Deliverable shall be deemed accepted upon the earliest of: (a) Customer's written Acceptance Notice; (b) expiration of the testing window without a conforming Notice of Nonconformity; or (c) Customer's use of the Deliverable in a live production environment for any purpose. Customer's failure to make the test environment, test data, or test personnel available on the agreed schedule shall extend the testing window only on the vendor's written consent."

‍

Example Clause Language

These drop-in examples show acceptance testing mechanics for three common transaction types.

Enterprise SaaS Implementation SOW - UAT window and deemed acceptance: "The UAT Period for each Deliverable shall be fifteen (15) business days, commencing on the later of (i) Vendor's written Notice of Readiness for UAT and (ii) Vendor's completion of the UAT prerequisites listed in Section 4.2. During the UAT Period, Customer shall execute the Test Scripts attached as Exhibit F in the designated UAT tenant. On or before the last day of the UAT Period, Customer shall deliver to Vendor either an Acceptance Notice or a Defect Report classifying each defect as Critical, Major, or Minor. Critical defects are those that prevent completion of a Test Script. Major defects are those that materially degrade system performance or require a workaround to complete a Test Script. Minor defects are cosmetic or documentation issues that do not impair functionality. A Deliverable shall pass UAT if it contains no Critical defects and no more than five (5) Major defects. Minor defects and remaining Major defects shall be tracked on a Punch List and resolved within thirty (30) days post-acceptance. If Customer fails to deliver an Acceptance Notice or a Defect Report within the UAT Period, the Deliverable shall be deemed accepted and Vendor shall be entitled to invoice the Acceptance Milestone."

Custom Software Development Agreement - notice of nonconformity and cycle cap: "A Notice of Nonconformity shall be in writing and shall, for each asserted defect, identify (i) the specific Acceptance Criterion or Specification the Deliverable fails to meet, (ii) the steps necessary to reproduce the defect, (iii) the severity classification of the defect, and (iv) any supporting test logs or screenshots. Vendor shall not be obligated to cure defects that are not documented in a conforming Notice of Nonconformity. Following delivery of a Notice of Nonconformity, Vendor shall have twenty (20) business days to correct the identified defects and redeliver the Deliverable, together with a written Cure Report describing the corrections made. Customer shall then have ten (10) business days to retest. If the Deliverable fails Acceptance Testing after two (2) cure-and-retest cycles, Customer may, at its option, terminate the applicable Statement of Work for cause and receive a refund of all amounts paid for the rejected Deliverable, engage a third party to complete the work at Vendor's reasonable cost, or accept the Deliverable with a milestone payment reduction reflecting the remaining defects."

Systems Integration Contract - FAT, SAT, and Operational Acceptance: "The System shall undergo three stages of acceptance testing: (a) Factory Acceptance Testing at Vendor's facility, conducted jointly by the Parties against the FAT Test Protocol (Exhibit G), which on successful completion triggers shipment and the FAT Milestone payment; (b) Site Acceptance Testing at Customer's site following installation, conducted against the SAT Test Protocol (Exhibit H) within thirty (30) business days, which on successful completion triggers the SAT Milestone payment and the start of the Operational Burn-In Period; and (c) Operational Acceptance, which shall occur upon the System's continuous operation in production without a Critical Incident for sixty (60) consecutive calendar days, at which point Final Acceptance shall be deemed to have occurred, the Warranty Period shall commence, and Vendor shall be entitled to invoice the Final Acceptance Milestone. If the System fails to achieve Operational Acceptance within one hundred twenty (120) days after SAT, Customer may elect the remedies set forth in Section 8.4."

‍

Common Contract Types

• Custom software development agreements: Detailed UAT windows, defect severity classifications, and cure-and-retest cycles tied to milestone payments for each build or sprint deliverable.
• Systems integration contracts: Three-stage FAT, SAT, and operational acceptance frameworks, with burn-in periods and multi-tier acceptance milestones.
• Enterprise SaaS implementation Statements of Work: Test script-driven UAT in a non-production tenant, with deemed acceptance triggers tied to the UAT window or production go-live.
• Industrial equipment procurement: FAT at the vendor's manufacturing site followed by SAT at the buyer's site, with performance guarantees tested during a production run.
• Design-build construction contracts: Substantial completion testing, punch list procedures, and commissioning protocols for mechanical and electrical systems.
• Professional services and consulting deliverables: Review and comment periods for written deliverables, typically with a shorter window (10 to 15 business days) and a reasonable-satisfaction standard for advisory outputs.
• Hardware supply agreements with integration: Incoming inspection combined with post-installation acceptance testing, especially for networking, storage, and data center equipment.
• Outsourcing transition agreements: Transition milestones tested against defined runbooks and steady-state operational metrics before full service commencement.

‍

Negotiation Playbook

Key Drafting Notes

• Tie the testing window to vendor readiness, not calendar date. Starting the testing window on a fixed calendar date penalizes the customer if the vendor delivers late. Starting it on the vendor's Notice of Readiness plus completion of listed prerequisites (test data, installation, training) aligns the clock with the customer's actual ability to test.
• Match window length to deliverable complexity. A 10 business day window is fine for a reporting module but too short for a full ERP implementation. Calibrate the window to the number of test scripts, the complexity of integrations, and the availability of customer test personnel.
• Use severity tiers to prevent rejection for trivial defects. Without severity tiers, a customer can reject a nearly complete deliverable for a misspelled label. Define Critical, Major, and Minor tiers, limit rejection rights to Critical and Major, and track Minor defects on a punch list.
• Require specificity in notices of nonconformity. A defect list that simply says "does not work" gives the vendor nothing to cure and prolongs the testing phase. Require reproduction steps, screenshots or logs, and a cross-reference to the specific acceptance criterion.
• Negotiate the deemed acceptance trigger carefully. From the customer side, resist deemed acceptance tied to any production use or a short silence window. Push for deemed acceptance only after expiration of the testing window plus a short notice-and-cure grace period. From the vendor side, push for a clear silence trigger and a production-use backstop.
• Align warranty start with acceptance. If the warranty begins at delivery but acceptance is delayed by testing, the vendor's warranty period may expire before meaningful production use. Align the warranty start date with acceptance or deemed acceptance to avoid this mismatch.

Common Pitfalls

• Open-ended testing with no deemed acceptance. Without deemed acceptance, a customer can hold the vendor in acceptance limbo indefinitely, delaying the milestone payment and extending the vendor's performance risk. This is the single most common drafting error in customer-drafted SOWs.
• Deemed acceptance with a silence trigger that is too short. A 5 or 10 business day silence trigger in an ERP implementation can deem acceptance before the customer has executed a single end-to-end test. Match the silence trigger to a realistic testing timeline.
• Failing to cap cure-and-retest cycles. Without a cap, the customer is trapped in cure-and-retest with no clean exit. A cycle cap paired with termination rights gives the customer leverage without forcing premature termination.
• Ignoring customer-side dependencies. Many implementations fail testing because the customer did not provide test data, test personnel, or a ready test environment on the agreed schedule. Include vendor-side relief (testing window extension, reasonable costs) when customer-caused delays block testing.
• Using a scope-ambiguous acceptance criterion. Testing against vague criteria like "shall be suitable for Customer's business" invites disputes. Test only against the specific, documented acceptance criteria in the exhibit, and require change orders for any new criteria added mid-project.
• Confusing acceptance testing failure with warranty breach. Pre-acceptance failure gives the customer rejection rights and potentially termination rights. Post-acceptance failure gives the customer warranty remedies only, subject to the liability cap. Conflating the two erodes the vendor's warranty protections and the customer's rejection rights.

‍

Jurisdiction Notes

• U.S.: Acceptance of goods is governed by UCC Article 2, principally sections 2-606 (what constitutes acceptance), 2-607 (effect of acceptance, notice of breach, burden of proof), and 2-608 (revocation of acceptance for substantial impairment). Under UCC section 2-606, acceptance occurs when the buyer signifies acceptance after a reasonable opportunity to inspect, fails to make an effective rejection after a reasonable opportunity to inspect, or does any act inconsistent with the seller's ownership. Section 2-607(3)(a) requires the buyer to notify the seller of any breach within a reasonable time after discovery or loss of remedy. Custom software and systems integration services often fall outside Article 2 because they are predominantly services or hybrid goods-services (the "predominant purpose" test under cases like Advent Systems v. Unisys, 925 F.2d 670). In Maryland and Virginia, UCITA (Uniform Computer Information Transactions Act) provides analogous acceptance and revocation rules for computer information transactions. The statute of frauds under UCC section 2-201 and its services-law analog may require the acceptance testing provisions to be in a signed writing if the contract value exceeds the threshold.
• U.K.: Under the Sale of Goods Act 1979, sections 34 and 35 govern the buyer's right of examination and deemed acceptance of goods; acceptance occurs when the buyer intimates acceptance, does an act inconsistent with the seller's ownership, or retains the goods beyond a reasonable time without rejection. For services, the Supply of Goods and Services Act 1982 implies a term that the supplier will perform with reasonable care and skill, but acceptance mechanics are governed by the contract itself. For B2C transactions, the Consumer Rights Act 2015 adds short-term rejection rights (30 days for goods) and specific remedies for digital content. English courts enforce negotiated acceptance testing clauses as written provided they are not unconscionable or contrary to the reasonableness test under the Unfair Contract Terms Act 1977 where applicable.
• Other: The UN Convention on Contracts for the International Sale of Goods (CISG) governs international B2B sales of goods between parties in contracting states, with articles 38 and 39 requiring examination within as short a period as practicable and notice of non-conformity within a reasonable time (and not later than two years after handover). Incoterms 2020 do not govern acceptance testing directly but affect when risk passes for physical deliverables. The EU Digital Content and Digital Services Directive (2019/770) sets minimum acceptance and conformity rules for consumer digital contracts across member states. In civil law jurisdictions such as Germany (BGB section 640 for works contracts) and France (Code civil article 1792 for construction), statutory acceptance (reception) concepts can override or supplement contractual testing procedures.

‍

Related Clauses

• Acceptance Criteria - Defines the pass/fail standards that the acceptance testing procedure measures against; the two clauses operate together as criteria plus procedure.
• Milestone Clause - Milestone payments are typically gated by successful completion of acceptance testing, tying testing outcomes directly to cash flow.
• Scope of Work - The Statement of Work and its Specifications define what is being tested; ambiguity in the SOW translates into acceptance testing disputes.
• Warranty Clause - The warranty period typically begins on acceptance, making the acceptance testing outcome the trigger for the vendor's warranty exposure.
• Payment Terms - Acceptance-linked milestone payments and holdbacks are defined here; payment obligations are suspended pending acceptance.
• Termination with Cause - Repeated failure of acceptance testing after the cycle cap is a common trigger for termination for cause with refund of paid milestones.
• Change Order Clause - New or modified acceptance criteria introduced during the project must flow through the change order process rather than being asserted during testing.

‍

This glossary entry is provided for informational and educational purposes only. It does not constitute legal advice, and no attorney-client relationship is formed by reading this content. Consult qualified legal counsel for advice on specific contract matters.