The Acceptance Clause Explained, With Samples (2026)

An acceptance clause sets out how a customer confirms that delivered goods, software, or project work actually meet the agreed requirements, and what happens if they do not. It matters most in contracts where something is built or configured, such as software development, systems integration, construction, and equipment supply. Acceptance is a hinge point in the deal: it is often the trigger for payment, for the start of warranty periods, and for the transfer of risk. A clear acceptance clause tells both sides exactly when the work has passed, and a poorly drafted one can quietly force a customer to accept work that does not perform. ## What problem it solves Without an acceptance process, there is no agreed moment when delivered work is judged against what was promised. The supplier says it is done; the customer says it does not work; and payment, risk, and warranty timing all hang in the balance. An acceptance clause solves this by defining acceptance criteria, usually linked to a specification, a test the work must pass, and a window in which the customer must test and either accept or reject. This gives the supplier certainty that the goalposts will not keep moving, and gives the customer a fair chance to confirm the work really meets the specification before it is on the hook to pay. ## Why it is negotiated Acceptance is contested because it controls money and leverage. The supplier wants a short test window, acceptance to be deemed if the customer stays silent, minor defects not to block acceptance, and payment tied to delivery rather than acceptance. The customer wants clear criteria tied to the specification, a realistic test period, the right to reject for any failure to meet the criteria, and payment withheld until acceptance. The treatment of deemed acceptance and of minor versus material defects is usually the sharpest point, because those two mechanisms decide who bears the risk when something is almost, but not quite, right. ## Common variations ### Acceptance testing The work must pass defined acceptance tests, often run by the customer against agreed test scripts, within a stated period. If it passes, the customer issues an acceptance certificate. ### Deemed acceptance If the customer does not reject within the test window, or starts using the deliverable in live operation, it is treated as having accepted. This protects suppliers from an open-ended refusal but can trap an inattentive customer. ### Staged or milestone acceptance Large projects are accepted in stages, each with its own criteria and sign-off, so problems are caught early rather than at the very end. ## Sample wordings > Sample wording (illustrative, adapt to your contract and jurisdiction):

Within 15 business days of delivery of a Deliverable (the Acceptance Period), the Customer shall test it against the Acceptance Criteria set out in the Specification. If the Deliverable meets the Acceptance Criteria, the Customer shall issue an acceptance notice. If it does not, the Customer shall give the Supplier written notice of the failures, and the Supplier shall correct them and re-submit the Deliverable for a further Acceptance Period. Payment of the relevant milestone is due only on acceptance. > Sample wording (illustrative, adapt to your contract and jurisdiction): A Deliverable shall be deemed accepted if the Customer uses it in live operation for a purpose other than testing, or fails to give an acceptance or rejection notice within the Acceptance Period and does not cure that failure within 5 business days of a reminder from the Supplier. The Customer may not reject a Deliverable for minor defects that do not materially affect its use, but the Supplier shall still correct such defects within a reasonable time after acceptance. ## Key drafting pitfalls - No defined acceptance criteria, so the parties argue about whether the work is good enough with nothing objective to measure against.

• A deemed-acceptance trap: acceptance is deemed on silence with no reminder, so a busy customer accepts defective work by inaction.
• No limit on repeated re-testing, so a supplier can re-submit failing work indefinitely with no consequence.
• Treating every minor cosmetic defect as grounds to reject, which is unfair to the supplier; or the reverse, forcing the customer to accept material failures as minor.
• Not linking acceptance to payment and warranty start, so it is unclear when money is due and when the warranty clock begins.
• Allowing live use of the deliverable to count as acceptance when the customer only intended a pilot.
• No right to terminate or get a refund if the work repeatedly fails acceptance, leaving the customer stuck with non-performing work. ## Jurisdiction note Acceptance clauses are mostly a matter of contract drafting, but they interact with sale-of-goods and supply law. In the United Kingdom, the Sale of Goods Act 1979 contains rules on when a buyer is deemed to have accepted goods and loses the right to reject, which a contract can modify within limits, and consumer law gives extra protection to consumers. In India, the Sale of Goods Act 1930 similarly addresses acceptance and the buyer's right to reject non-conforming goods. In the United States, the Uniform Commercial Code sets out rules on acceptance, revocation of acceptance, and the right to reject. Because these statutory defaults and the limits on changing them vary, confirm the clause under the governing law. This page is general information, not legal advice. ## Where this fits in day-to-day contract work The quiet danger in an acceptance clause is the deemed-acceptance mechanism: a customer can accept non-performing software simply by being slow to respond, or by running a pilot the contract treats as live use. Checking that acceptance criteria are objective, that deemed acceptance has a fair reminder step, and that acceptance is linked to payment, warranty start, and a right to reject or terminate is a per-clause review Adira is built to surface in one AI workspace tuned to your company and built on Claude. The guidance above stands on its own. ## Bottom line An acceptance clause defines the moment delivered work is judged against what was promised, and it usually controls payment, risk, and warranty timing. Tie acceptance to objective criteria and a realistic test window, handle minor versus material defects fairly, make any deemed-acceptance mechanism fair with a reminder step, and give the customer a remedy if the work keeps failing. Read the deemed-acceptance wording closely, because that is where a customer most often ends up accepting work it did not mean to.