Acceptance and Completion Criteria

Short answer: acceptance criteria are subjective (“the customer decides if it is good enough”) and completion criteria are objective (“we delivered X, here is the proof”). As a vendor, you want completion criteria in every SOW, because that is what gets you paid.

As a SaaS attorney, I run into this distinction constantly. What is the difference between acceptance criteria and completion criteria in a statement of work, and why should you care? The short version: acceptance criteria give the customer control over whether you get paid; completion criteria give you control. The gap between those two positions is where scope creep, payment disputes, and revenue recognition problems live.

Here is the comparison I walk clients through. It lays out the three ways “done” gets defined in a SOW, from the most subjective customer acceptance (for any reason) to objective completion criteria that actually protect a vendor. Click the chart to enlarge it.

Acceptance Criteria.

Usually drafted by the customer with language like “subject to acceptance” or “customer shall accept or reject deliverables within [X] days.” This is a subjective standard. The customer gets to evaluate whether what you delivered meets its requirements. The risk is that “meets its requirements” is whatever the customer decides on the day your invoice is due — and customers who are over budget, having internal problems, or simply dissatisfied for reasons unrelated to your performance can use acceptance criteria to delay or refuse payment indefinitely. Acceptance criteria language also creates an open feedback loop: the customer reviews, provides comments, you revise, they review again. Each cycle is an opportunity for scope expansion with no corresponding increase in your payment obligation.

Completion Criteria.

An objective measurement of whether you delivered a defined output. Did you deliver the report in the agreed format by the agreed date? Did you hold the training session for the agreed number of attendees? Completion criteria is something you can prove independently of the customer’s opinion. Either the file was delivered in the specified format or it was not. That is a fact, not an editorial judgment. It is also far easier to rely on in a breach of contract claim if you ever need to go that route.

Why Acceptance Criteria Gets You in Trouble.

If you want to get paid — or you are worried about scope creep or revenue recognition — this distinction is not boilerplate, it is a core business risk. Acceptance criteria language shifts all economic leverage to the customer at the worst possible moment: when your invoice is due. A customer who does not want to pay can use acceptance criteria as cover, and the language itself makes it difficult to prove they are acting in bad faith rather than exercising a legitimate contractual right.

Rookie Mistake.

It is a rookie mistake to trust the customer who says “I just need to check that you did the work.” That acceptance process opens the door to scope creep, payment delays, changing requirements, and customers who simply go quiet. Negotiate upfront for objective measurements of completion, be specific about every deliverable, and try to get paid in advance or at milestone delivery, not on acceptance.

How to Write Objective Completion Criteria.

Make “done” a fact rather than an opinion. Tie each deliverable to something observable and demonstrable: a document delivered in a stated format by a stated date; a training session held for a defined number of attendees; a feature that passes a defined test script; a milestone that is deemed complete if the customer does not object in writing within a set number of business days. That last mechanism — a deemed-acceptance window — is the single most practical protection against a customer who goes quiet to avoid triggering a payment obligation. IBM SOWs are the gold standard here: clear, specific, and built on objective completion language rather than open-ended acceptance. Pairing each milestone with an escalation process (if there is a dispute about whether the milestone was met, here is the resolution procedure) closes the loop entirely.

Completion Criteria, Revenue Recognition, and Getting Paid.

This is not just a payment-timing issue, it is a revenue-recognition issue. When payment hinges on subjective acceptance, your finance team often cannot recognize the revenue until the customer signs off, which can push income into a later period or leave it stranded. Objective completion criteria let you point to a defined, demonstrable event: “training delivered on this date,” “report accepted by default after ten business days of non-objection.” That is cleaner for both collection and accounting. The SOW language your salesperson treats as boilerplate is actually driving when, and whether, you book the deal.

For the related problem of software developers who take matters into their own hands when customers do not pay, see The One Thing a Software Developer Should Never Do. For how payment milestones interact with your SaaS agreement structure overall, I hope this helps. Trust me on this one: make “done” a fact.

Resources:

• SaaS Indemnity vs. Breach of Contract
• The One Thing a Software Developer Should Never Do
• SaaS Agreement vs. Software EULA: Which Template Do You Need?
• Acceptance Criteria in Requirements Management (Project Management Institute)

Disclaimer:

This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.