Acceptance Clause Explained: Six Versions to Check Before You Sign
This page is general information, not legal advice.
An acceptance clause decides when finished work counts as finished. In freelance, agency, software and creative contracts, it sets out how the client reviews a deliverable, what standard it has to meet, how long the client has to respond and what happens if they reject it. It matters because payment, warranty periods and the end of your obligations often depend on acceptance. If the client can delay or refuse acceptance freely, it can delay or refuse payment too. If you're the client, the clause decides how much leverage you keep once work is handed over.
This page is about accepting deliverables under a services contract, not about how a contract is formed through "offer and acceptance." It covers six versions of the clause that tilt the risk. For each one you get an illustrative example, why it matters, and wording you can propose. How these clauses are read and enforced varies by jurisdiction, and they can often be negotiated.
The example clauses below are illustrative. They are not taken from any real company's contract.
1. Acceptance in the client's sole discretion
A typical clause might read: "Each Deliverable shall be subject to acceptance by Client in its sole discretion. Payment is due only for Deliverables accepted by Client."
Why it works against you
"Sole discretion" means the client doesn't have to explain a rejection, and the deliverable doesn't have to fail any particular test. Work that matches the brief exactly can still be rejected because someone changed their mind, and the payment goes with it. Satisfaction-based terms are especially risky in creative work, where taste is subjective. See creative services contract red flags.
What to ask for instead
Sample wording to propose: "Client will accept a Deliverable that materially conforms to the specifications in the Statement of Work. Any rejection must be in writing and identify the specific nonconformities."
2. No deadline for the client to review
A typical clause might read: "Client will review each Deliverable and notify Contractor of its acceptance or rejection."
Why it works against you
There's no time limit. If the client goes quiet, the deliverable sits in limbo: not accepted, not rejected and not paid for. Because your invoice may only be due after acceptance, payment terms like "net 30" may never start running. See payment terms net 30 explained.
What to ask for instead
Sample wording to propose: "Client will accept or reject each Deliverable within [5] business days of delivery. If Client does not provide a written rejection within that period, the Deliverable is deemed accepted."
3. Unlimited rejections and redo cycles
A typical clause might read: "If Client rejects a Deliverable, Contractor shall correct and resubmit it at no additional charge until it is accepted."
Why it works against you
There's no limit on how many times this can happen. Combined with vague criteria, it can mean months of extra work for the same fee. It also blurs the line between fixing a real defect and redoing work because the client wants something different, which should go through a change process instead.
What to ask for instead
Sample wording to propose: "Contractor will correct identified nonconformities and resubmit up to [two] times. Requests that go beyond the original specifications are handled as change orders. If a Deliverable still doesn't conform after the second resubmission, either party may end the affected Statement of Work, and Client will pay for work performed to date."
4. No acceptance criteria at all
A typical clause might read: "Deliverables shall be of high quality and suitable for Client's purposes."
Why it works against you
"High quality" and "suitable for Client's purposes" give you no objective target. If the client's purposes were never written down, you can't show you met them. Clear criteria protect both sides: you know what to build, and the client knows what it can reject. For software, criteria are often tied to tests; for creative work, to a brief and a set number of concepts.
What to ask for instead
Sample wording to propose: "Acceptance criteria for each Deliverable are set out in the Statement of Work. A Deliverable that meets those criteria will be accepted. Subjective preferences not stated in the criteria are not grounds for rejection."
5. Using the work without accepting it
A typical clause might read: "Client's use of any Deliverable shall not constitute acceptance."
Why it works against you
The client can launch your website, publish your article or run your code in production while still saying it hasn't been accepted, and so hasn't been paid for. Using a deliverable in live business is usually the clearest sign it works. Tying ownership and license rights to payment can help here too. See IP assignment clauses explained.
What to ask for instead
Sample wording to propose: "A Deliverable is deemed accepted when Client uses it in production or makes it available to the public, unless Client has already rejected it in writing."
6. Acceptance that waives all defects (when you're the client)
A typical clause might read: "Acceptance of a Deliverable, or payment of any invoice, constitutes Client's final acceptance and waiver of any claims relating to defects in that Deliverable."
Why it works against you
If you're the client, this version means that once you approve or pay, you may lose the right to complain about defects you find later. Bugs, accessibility problems or licensing issues often appear after launch. Check how this interacts with any warranty in the contract, and whether the provider has disclaimed warranties entirely. See warranty disclaimer clauses explained.
What to ask for instead
Sample wording to propose: "Acceptance does not waive Client's rights under the warranty in Section [X]. Provider will correct defects reported within [90] days after acceptance at no charge."
How acceptance connects to the rest of the contract
Acceptance is often a trigger for other clauses. Check whether it starts the warranty period, moves ownership of rights, releases a holdback or retention, or starts a support period. If the contract can be ended early, see whether unaccepted work in progress is paid for. See termination for convenience clauses explained and kill fee clauses explained.
Also worth a look
Look at the payment schedule for milestones tied to acceptance (see contractor payment terms red flags), late fees once an accepted invoice goes unpaid (see late payment fee clauses explained), and whether the client can claw back payments after acceptance (see clawback clauses explained). For a wider checklist, see freelance contract red flags, web design contract red flags and consulting agreement red flags.
Scan your own contract free
An acceptance clause can quietly control when, or whether, you get paid. Upload your contract to the ScanMyTerms freelance contract review as a PDF, DOCX, TXT or MD file, photograph it (up to 30 pages), or paste the terms. In about a minute you get a list of clauses that work against you, with the risk level, the exact wording, why it hurts and how to change it. The free preview shows the risk count and the first two findings. The full report is $5 per document.
This page is general information, not legal advice. Contract rules vary by jurisdiction, so for decisions about a specific contract, talk to a qualified lawyer where you live.
Sources
- All clause examples on this page are illustrative and written for this guide. They are not quoted from any real company's contract.