Deliverable Acceptance Criteria That Hold Up
The most expensive words in professional services are "we just need one more pass". Acceptance criteria exist to make that sentence answerable.
An engagement that cannot finish a deliverable cannot finish. Every additional review round consumes margin that was never priced, delays the milestone, holds the team, and moves the invoice. And the reason a deliverable will not close is almost never disagreement about quality. It is that nobody wrote down what finished looks like.
Acceptance criteria are the answer, and they are worth writing badly rather than not at all. A rough criterion that both parties read before work starts prevents more argument than a perfect one written afterwards.
What a usable criterion looks like
A criterion is usable when a third party who was not in the room could apply it and reach the same conclusion as both parties. That rules out most adjectives. "Comprehensive", "high quality" and "fit for purpose" are not criteria; they are hopes.
- Coverage: which entities, processes, systems, jurisdictions or periods are addressed. Countable wherever possible.
- Form: the format, the approximate length, the audience it is written for, and whether it must fit an existing template.
- Evidence: what supports the conclusions, and what standard of support is expected. A recommendation backed by interviews is a different deliverable from one backed by tested data.
- Review: how many rounds of client comment are included, over what elapsed period, and who consolidates the comments.
The distinction that ends most disputes
A comment is not a rejection. This sounds pedantic and it is the single most useful clause in a deliverables schedule. A client may return a document with fifty comments, none of which asserts that a criterion was unmet, and the deliverable is still acceptable. The comments are input to the next version, not evidence of failure.
A rejection must state which acceptance criterion has not been met. That requirement is not adversarial; it is what allows the firm to fix the actual problem rather than guess. It also prevents the pattern where a deliverable is rejected for a reason that amounts to a change in scope, which should be handled as a change and priced.
Deemed acceptance, and how to use it fairly
Deemed acceptance provides that if the client neither accepts nor rejects within a stated period, the deliverable is treated as accepted. Without it, a deliverable can sit unreviewed indefinitely while the engagement cannot progress and the invoice cannot be raised.
Used carelessly it damages relationships, so pair it with two things. First, an explicit reminder before the period expires, so nobody is caught by a clause they forgot. Second, a period that is realistic for the client's own governance: ten working days is reasonable for a document one person reviews and unreasonable for one that must go to a board.
Versioning and the current document
Much of what looks like an acceptance dispute is a version problem. Two people are reading different documents, one of them is commenting on a draft that was superseded a week ago, and the resulting conversation is unresolvable because both are right about what they read.
The remedy is that issued versions are identified, immutable and reachable from one place, and that comments are made against a stated version. Where the deliverable is shared through a client portal rather than by attachment, this becomes automatic, and the class of dispute disappears.
Recording acceptance
Acceptance should be an event with a record: who accepted, on what date, against which version. In many firms this is the trigger for revenue recognition and for the invoice, which makes an informal acceptance by email a finance problem as well as a commercial one.
The record does not have to be heavy. A named person, a date, a version and a status is enough, provided it is stored against the deliverable rather than in a mailbox belonging to whoever happened to receive it.