The Acceptance And Rejection Clause: What It Means and How to Negotiate It (2026)

What is an acceptance and rejection clause? An acceptance and rejection clause sets out how a customer checks a deliverable, and what happens depending on whether the customer accepts it, rejects it, or says nothing. It fixes the acceptance criteria, the review and cure periods, the form of notice, and, importantly, whether silence counts as a yes or a no. It is the bridge between delivery and payment: in most contracts, acceptance is the event that triggers the right to be paid and starts warranty and other clocks running. It is standard in contracts for software, hardware, professional services and construction, anywhere a customer receives deliverables and needs a fair way to confirm they do the job. Done well, it protects both sides. The customer gets a real chance to test the work before it is on the hook to pay; the supplier gets certainty that it cannot be strung along indefinitely. This article is general guidance, not legal advice. Acceptance rules interact with sale-of-goods and service law that varies by jurisdiction, so have a qualified lawyer review any clause before you rely on it. ## How the clause is usually structured Most acceptance and rejection clauses contain the same building blocks. - Acceptance criteria. What the deliverable must meet, usually the specification or the test criteria in the statement of work.

• Review period. How long the customer has to inspect or test the deliverable after delivery.
• Acceptance or rejection notice. A written notice accepting the deliverable, or rejecting it with reasons.
• Deemed acceptance. What happens if the customer does nothing. In commercial contracts, silence often counts as acceptance after the review period; in some public-sector contracts it runs the other way and silence means rejection.
• Rejection and cure. The supplier gets a chance to fix the defects and resubmit, usually within a cure period, often limited to material non-conformities.
• Failure to cure. If the supplier still cannot fix it, the customer may get a refund, a credit, or a right to terminate. Two refinements matter. Many clauses require the customer to accept a deliverable that substantially conforms, resolving minor issues through correction or credits, so trivial defects cannot block payment. And many state that testing, inspection or even payment is not acceptance, which must be confirmed in writing, so the customer keeps its remedies. ## Sample wording ``` ACCEPTANCE AND REJECTION 1. Within [20] Business Days after delivery of a Deliverable (the "Review Period"), the Customer shall test it against the Acceptance Criteria in the relevant Statement of Work and give the Supplier written notice of acceptance or of rejection setting out each non-conformity. 2. If the Customer gives no notice within the Review Period, the Deliverable is deemed accepted. 3. The Customer may reject a Deliverable only for a material failure to meet the Acceptance Criteria. If a Deliverable substantially conforms with only minor non-conformities, the Customer shall accept it and the parties shall resolve those issues by correction or credit. 4. On rejection, the Supplier shall correct and resubmit the Deliverable within [10] Business Days for a further Review Period. If the Supplier fails to achieve acceptance after [two] cycles, the Customer may [terminate the affected work and/or recover sums paid for it]. 5. Inspection, testing or payment does not of itself constitute acceptance.

- the right to reject for material failures, with a refund or termination right if the supplier cannot cure;
- no deemed acceptance, or at least a long window, and a clear statement that payment is not acceptance. **The supplier usually wants:** - a short review period with deemed acceptance if the customer stays silent;
- rejection limited to material non-conformities, with an obligation to accept substantial conformity;
- a capped number of cure cycles and protection against repeated rejection for moving or subjective reasons. The sharpest negotiation is usually over deemed acceptance and the test criteria. A supplier wants the clock to run and silence to mean yes; a customer wants enough time and objective criteria so it is not forced to accept work that does not perform. Pinning the acceptance criteria to a precise, testable specification protects both sides from arguments later. ## A note on jurisdiction Acceptance rules do not sit in a vacuum. In goods contracts they interact with sale-of-goods law, for example the concept of acceptance and the right to reject under the UK Sale of Goods Act, 1979 and, in India, the Sale of Goods Act, 1930, which address when a buyer is deemed to have accepted goods and loses the right to reject. Service and software deliverables are more often governed purely by the contract. Because the default rules, and how freely parties can change them, vary by jurisdiction, treat the contractual acceptance process as the main control and check it against the governing law rather than assume one approach fits everywhere. ## Where one contract workspace helps The risk in an acceptance clause is almost always a missed clock. A deemed-acceptance window passes while no one is testing, a cure period lapses, or a rejection notice goes out without the detail the clause requires. Across many deliverables and many contracts, keeping those dates and the required notices straight is real work. Drafting an acceptance and rejection clause, reviewing it and tracking its review periods, cure deadlines and payment triggers can all live in one AI workspace tuned to how your company contracts, so a deemed-acceptance window does not pass unnoticed. [Adira](https://adiralaw.com) is built for that kind of single workspace around acceptance terms. The explanation above is enough to negotiate the clause on its own.