Statements of work sit in a documentation gap. They are legally significant — they define what is owed, when it is owed, and under what conditions it is considered complete. But they are typically drafted by project teams and business stakeholders with minimal legal involvement, reviewed briefly at the end of a procurement or contract process, and incorporated by reference into master service agreements that were negotiated with more care.
The acceptance criteria section of a SOW is where payment disputes are born. "Deliverables will be accepted upon customer's reasonable satisfaction" is a sentence that sounds fine to everyone in the room who is focused on getting the project started. It is a sentence that makes payment enforcement materially harder when the project is complete and the customer is unhappy.
Legal teams reviewing SOWs often focus on milestone dates, fees, and IP ownership — the high-value provisions in the master agreement that also appear or are referenced in the SOW. The acceptance criteria section, which may be two paragraphs near the end of the SOW's deliverable description, often does not receive the same attention. This is where the risk accumulates.
What Good Acceptance Criteria Look Like
Well-drafted acceptance criteria in a SOW have three properties: they are objective, they are measurable, and they include a defined process for evaluation and dispute resolution.
Objective: the criterion can be evaluated without reference to subjective judgment. "Deliverable will be accepted when it produces output matching the test cases specified in Exhibit B with a pass rate of 98% or higher" is objective. "Deliverable will be accepted when it meets client's quality standards" is not. The latter requires the client to have and apply quality standards that are not defined in the agreement, and it embeds a judgment call — "does this meet our standards" — into the acceptance decision that can be answered differently on different days by different people.
Measurable: even when subjective elements are unavoidable — design deliverables, written content, strategic advisory outputs — the acceptance criteria should include some measurable dimension. "Client will provide written feedback within 10 business days of delivery; deliverable will be deemed accepted if no written objection is received within that period" is not fully objective, but it is measurable. The acceptance decision has a defined clock and a defined procedure, which limits the client's ability to withhold acceptance indefinitely.
Process-defined: good acceptance criteria include a defined procedure for raising objections, a timeframe for vendor response and revision, and what happens if the parties disagree about whether acceptance criteria have been met. Without a dispute resolution pathway specific to acceptance, disagreements escalate directly to contract-level dispute resolution — which is slow, expensive, and typically unintended for the ordinary friction of a delivery process.
The Language Patterns That Create Risk
Specific language patterns in SOW acceptance criteria sections consistently generate disputes. When we flag acceptance criteria in contract review, these are the patterns that trigger review-level or high-risk flags:
"To client's reasonable satisfaction": the word "reasonable" does not help here as much as it seems. Reasonableness is a legal standard, and it requires a determination by someone — ultimately a court or arbitrator — that a party's satisfaction decision was objectively unreasonable. That determination is expensive to obtain. The practical effect of this language is that it gives the client broad discretion to withhold acceptance based on preferences that were never stated in the SOW, because arguing that a client's dissatisfaction was "unreasonable" is a high bar.
Silent acceptance periods: a SOW that defines deliverables and a delivery date but does not specify an acceptance period and a deemed-acceptance mechanism puts the vendor in a position where acceptance is potentially open-ended. If the client can withhold acceptance by simply not responding, the vendor's payment trigger never fires. Payment milestones that depend on acceptance are essentially uncollectable without a defined acceptance clock.
Acceptance criteria that reference external standards not defined in the agreement: "deliverable will comply with industry best practices" or "meet applicable regulatory requirements" without specification of which practices or which regulations creates a moving target. What constitutes best practice is debatable. What regulatory requirements apply depends on the client's specific circumstances, which the vendor may not fully understand at the time of delivery.
Scope conflation: acceptance criteria that include additional requirements beyond the deliverable specifications as conditions of acceptance. A software deliverable that must "meet all specifications in Section 2 and any additional requirements communicated by client during the development process" as conditions of acceptance creates acceptance criteria that are not fixed at SOW execution. "Requirements communicated during development" are typically informal — emails, Slack messages, meeting notes — and may significantly exceed what was scoped and priced in the SOW.
The Payment Trigger Problem
The financial significance of acceptance criteria depends directly on how payment triggers are structured. In fixed-fee SOW arrangements with milestone-based payments, acceptance is frequently the trigger for milestone payment. A deliverable that has been delivered but not formally accepted is a completed deliverable for which no payment has been received.
For vendors, this creates pressure to accept delivery and begin the payment clock. For customers, delayed or withheld acceptance is an informal cost control mechanism — not necessarily intentional, but operationally predictable when project stakeholders are busy and acceptance procedures are informal. The vendor is waiting for acceptance; the customer team that received the deliverable has moved on to the next project; the acceptance decision sits in a queue.
We're not saying that customer delay in acceptance is always bad faith. Projects are complex and teams are stretched. The point is that acceptance criteria written without a deemed-acceptance mechanism create a structural condition where delay is easy and recovery is hard. The deemed-acceptance provision — "deliverable will be deemed accepted if client does not provide written objection within [X] business days of delivery" — is the mechanism that converts the acceptance decision from open-ended to time-bounded.
Evaluating Acceptance Criteria During SOW Review
The review of acceptance criteria in SOWs is one of the areas where legal review adds the most value on a per-word basis. The section is usually short. The risk of not reviewing it carefully is specific and quantifiable. And the fix — adding an objective standard, a defined period, and a deemed-acceptance mechanism — is straightforward language that most counterparties will accept.
The playbook position should address:
- Acceptance criteria must be objective or include an objective element (measurable specifications, test criteria, or defined review procedures)
- Acceptance periods must be defined, with a maximum duration (typically 10 to 20 business days for most deliverable types)
- Deemed-acceptance mechanism required: delivery that is not objected to in writing within the acceptance period is accepted
- Objection procedure defined: written objections must specify the nature of the deficiency and the standard not met
- Revision cycle defined: vendor has a defined period to revise and resubmit; revised deliverable restarts the acceptance clock
In Repovyn's SOW review configuration, acceptance criteria are flagged as HIGH when deemed-acceptance language is absent and payment is milestone-triggered. They are flagged as REVIEW when acceptance criteria are present but rely on subjective standards without an objective fallback. The distinction matters because absent deemed-acceptance on a payment milestone is a structural problem — the payment trigger may never fire. Subjective acceptance criteria are a risk that depends on the relationship and the project context.
The Master Agreement Connection
SOW acceptance criteria interact with the master services agreement's dispute resolution provisions in ways that legal review of the SOW alone may miss. If the MSA provides for expedited dispute resolution on payment disputes but the SOW's acceptance process has no defined escalation path, the expedited process in the MSA is not accessible until acceptance has been clearly withheld — which requires a dispute that may not yet be formalized.
The most complete approach to SOW acceptance review confirms that the SOW's acceptance process connects to the MSA's dispute resolution provisions: that a dispute about whether acceptance criteria have been met constitutes a payment dispute triggerable under the MSA, and that the escalation path from informal acceptance objection to formal dispute is defined. This review requires reading the SOW acceptance provisions in context of the governing MSA terms, not in isolation.
SOWs are often treated as operational documents rather than legal ones, drafted by the people closest to the work and reviewed lightly by legal. The acceptance criteria section is where that treatment creates the most concentrated risk. A focused review of that section, applied systematically across all SOWs incorporated by reference into commercial agreements, is high-leverage work that prevents the payment disputes that are otherwise predictable from the language patterns described above.