Contract Says Work Is Done When the Client "Accepts" It. What Does That Mean for Me?

What does client acceptance usually trigger?

Before negotiating, check what depends on acceptance in your contract. Commonly:

If several of these hang on acceptance, an undefined acceptance process affects almost every part of your deal.

• Payment of the final invoice, or of each milestone.
• The start of the payment clock, as in "net 30 from acceptance."
• Transfer of ownership or licence rights.
• The start of any warranty or support period.
• The end of your revision obligations.

The three parts of a fair acceptance clause

A workable acceptance clause has three parts. First, acceptance criteria: what the work must do or contain, ideally linked to a specification or brief. Second, a review period: a set number of days for the client to test and respond. Third, a deemed acceptance rule: if the client does not reject the work with reasons within the review period, it is treated as accepted.

Without the third part, silence can last forever. With it, the client still has a real chance to review, but cannot stall payment by not responding.

Why use objective criteria instead of client satisfaction?

"To the client's satisfaction" gives the client a subjective veto. Courts in many states will imply a standard of good faith or reasonableness, especially where the work is functional rather than artistic, but that is a weak position to rely on. Better criteria are objective: the site loads the listed pages, the report covers the agreed sections, the video matches the approved storyboard and length. For creative work, tie acceptance to the approved brief and treat changes of direction as new work.

What rules apply when the contract does not define acceptance?

It depends on whether the deal is mainly a sale of goods or a contract for services. If goods predominate, Article 2 of the Uniform Commercial Code supplies default acceptance rules. Under UCC § 2-606, a buyer accepts goods if, after a reasonable opportunity to inspect, it signals they conform or that it will keep them anyway, fails to make an effective rejection, or does something inconsistent with the seller's ownership, such as putting them into use. Under § 2-602, a rejection must come within a reasonable time after delivery, with notice to the seller, and under § 2-605 a buyer who rejects without naming a defect the seller could have cured may lose the right to rely on it later.

Courts decide whether a mixed contract falls under Article 2 using a predominant purpose test, set out in cases such as Bonebrake v. Cox, 499 F.2d 951 (8th Cir. 1974). Packaged software is often treated as goods, while custom design or development is usually treated as services, so most freelance work falls under ordinary contract law instead.

For services, the key doctrine is substantial performance. In Jacob & Youngs, Inc. v. Kent, 230 N.Y. 239 (1921), a builder used pipe from a different manufacturer than the contract specified, of similar quality. The New York Court of Appeals held that a trivial and innocent deviation did not justify withholding the balance of the price; the owner's remedy was the difference in value, which was nominal. The doctrine is applied well beyond construction: a client who receives work that substantially meets the agreed specification usually cannot refuse to pay in full because of minor flaws. These defaults help, but a written acceptance clause with a review period and deemed acceptance gets you the same result without arguing about which law applies.

Rejection must come with reasons

A fair clause requires the client to explain in writing how the work fails the criteria. You then fix those specific issues and resubmit, and the client reviews only those fixes, often within a shorter period. Limit the number of rejection cycles, or treat rejections that raise new issues as change requests.

Use of the work counts as acceptance

Add a clause saying that if the client uses the work in production, publishes it or sends it to customers, it is accepted. A client should not be able to launch your website and still refuse to accept it.

Partial acceptance and milestones

For larger projects, break the work into milestones, each with its own acceptance and payment. This spreads risk and stops a dispute about a final detail from holding up payment for the whole project. If minor defects remain, the client can accept with a punch list of small fixes rather than rejecting everything.

A worked example

Daniel delivers a mobile app. His contract says final payment is due on acceptance, with no criteria or deadline. The client says they need more time to test, then a new product manager asks for design changes, and three months later nothing has been accepted and $12,000 remains unpaid. The app has been released to a test group of customers.

With a 10-business-day review period, deemed acceptance, a requirement for written reasons and a rule that use in production counts as acceptance, the app would have been accepted within two weeks, and the design changes would have been quoted as new work.

Sample wording you can propose

"Client will review each Deliverable within 10 business days of delivery. Client may reject a Deliverable only by written notice identifying how it fails to meet the specification in Schedule A. Contractor will correct the identified issues and resubmit. A Deliverable is deemed accepted if Client does not reject it within the review period or uses it in production or publicly."

Common mistakes

• Accepting "to the client's satisfaction" as the only standard.
• Having no deadline for review.
• Allowing rejections without written reasons.
• Letting new requests be treated as defects.
• Tying the whole project fee to one final acceptance.

Quick checklist

• What does acceptance trigger: payment, ownership, warranty?
• Are there objective acceptance criteria?
• How long does the client have to review?
• Is there deemed acceptance on silence?
• Does use in production count as acceptance?
• Is the work split into milestones?

Key terms explained

These terms shape when your work counts as finished.

• Acceptance: the client's confirmation that the work meets the agreed requirements.
• Acceptance criteria: the objective standards the work is tested against.
• Review period: the time the client has to test and respond.
• Deemed acceptance: automatic acceptance if the client does not reject in time.
• Punch list: a list of minor fixes to finish after acceptance.
• Change request: a request for new or different work, priced separately.

How does acceptance interact with warranties?

Once work is accepted, many contracts give the client a warranty period, such as 30 or 90 days, during which you fix defects that prevent the work from meeting the specification. That is fair, and it is also why acceptance should happen promptly: the client is not left without a remedy for hidden bugs, because the warranty covers them. What the warranty should not cover is new features, changed requirements or problems caused by the client's own changes or third-party systems. Say so, and keep the warranty period defined and short.

Some clients use acceptance testing as a way to delay while continuing to use the work. The combination of a review deadline, deemed acceptance and a warranty period protects both sides: the client gets real time to test and a remedy for defects, and you get a clear point at which the project is finished and payable.

Acceptance in agile and ongoing work

In iterative projects, acceptance works best per sprint or per feature, with a short review period for each. Waiting for a single final acceptance at the end of a long agile project gives the client a reason to withhold payment for everything if one late feature is disputed.

Sample email when a client is not responding

"I delivered the final build on 3 March. Under clause 6, the review period ended on 17 March and no issues were raised, so the deliverables are treated as accepted. I have attached the final invoice, due within 30 days. If you have found any defects, send me the details and I will fix them under the warranty."

Keep a delivery record

Send every deliverable by a method that records the date, such as email or a shared folder with timestamps, and state in the message that the review period has started. That record is what makes deemed acceptance work if a client later says it never received the files.

Build the finish line into the contract

An acceptance clause decides when you get paid. If yours is vague, fix it before the project starts, while the client is keen to begin. You can upload the contract to see how its acceptance, payment and ownership clauses work together.