One Sentence Acceptance Criteria That Stop Unpaid Work for Freelancers

Acceptance criteria are the measurable, deliverable-level conditions that spell out what "done" actually looks like on a project. A usable one names the deliverable and its formats, the number of revision rounds included, and the approver plus a review window. Add explicit exclusions and you have closed off the most common source of unpaid extra work.

TL;DR:

• Clear acceptance criteria specify exact deliverables, formats, revisions, and approvers to prevent misunderstandings and unpaid extra work.
• Writing acceptance criteria during scope creation ensures both parties share a mutual finish line, especially listing dependencies and explicit exclusions.
• Handling out-of-scope requests involves promptly documenting, pricing, and obtaining signed approval before starting any additional work.
• Using standardized phrasing for scope and change orders helps freelancers enforce scope boundaries and reduces disputes with clients.
• Enforcing acceptance criteria with tools like Stria streamlines change requests, captures approvals, and protects income from scope creep.

Table of Contents

• 1. Discipline-specific acceptance criteria examples
• 2. How to write acceptance criteria that hold up
• 3. Change control: turning extra requests into paid work
• 4. Paste-ready wording for scopes and change orders
• 5. How Stria turns this process into a habit
• 6. What the research gets wrong about acceptance criteria
• Try Stria before your next fixed-price project
• Templates worth keeping on file
• Sources
• FAQ

1. Discipline-specific acceptance criteria examples

Generic language like "client approval required" invites arguments. Specific language ends them before they start. Here is what that looks like across the disciplines fixed-price creatives actually bill for.

For design work, name the exact variants, file formats, colorways, and revision count up front. A logo package might read: "Accepted when three lockup variants (horizontal, stacked, icon-only) are delivered in SVG, PNG, and EPS, in the two approved colorways, and two rounds of revisions are complete." That single sentence, adapted from the structure AIGA's standard form of agreement for design services recommends, removes the guesswork over what "the logo" even means.

For copywriting, tie acceptance to word count, page or post count, adherence to the brief, and final file format rather than vague quality language. "Accepted when 12 blog posts of 800 to 1,000 words each are delivered as Google Docs, matching the approved brief and tone guide" leaves no room for a client to reject clean copy just because they changed their mind about voice halfway through.

For website builds, list the page templates, responsive breakpoints, a QA checklist, and a staging approval step. "Accepted when the five listed page templates render correctly on desktop, tablet, and mobile, pass the QA checklist, and are approved on staging by the named approver" gives both sides a shared finish line instead of an open-ended "make it work everywhere."

For video, spell out duration, aspect ratios, captions, resolution, and export formats: "Accepted when the 60-second video is delivered in 16:9 and 9:16, with burned-in captions, at 1080p, in MP4 format."

One caution across every discipline: never tie acceptance to performance metrics like search rankings or conversion rates unless your contract actually gives you control over the variables that drive them. Those numbers depend on the client's audience, budget, and market, not your deliverable, and building them into your acceptance language just hands the client a permanent excuse to withhold payment.

• Design: variants, colorways, export formats, revision count.
• Copy: word count range, page or post count, tone and brief adherence, file format.
• Website: page templates, responsive states, QA checklist, staging sign-off.
• Video: duration, aspect ratios, captions, resolution, export format.

2. How to write acceptance criteria that hold up

Write acceptance criteria during scoping, not after the client has already seen a draft and started forming opinions. Follow these steps for each deliverable in your scope of work.

1. Write one acceptance entry per deliverable, describing exactly what it is, the formats it ships in, the quantity or variants included, and what "complete" means for that item.
2. Define a revision round as one consolidated, written feedback package from the approver, delivered within an agreed window, not an open channel for endless small notes.
3. Name the authorized approver by person or role and state the sign-off method, whether that's a reply email, a signed PDF, or a record in a project tool.
4. List client dependencies, like content, brand assets, or stakeholder availability, and state what happens if they arrive late: a schedule shift, a fee adjustment, or both.
5. Add explicit exclusions so "can you also" requests have an obvious answer: out of scope, or a paid addition.

3. Change control: turning extra requests into paid work

A request that falls outside the signed scope is not automatically a fight. It is a signal to run your change process. Acknowledge the request in writing right away, then compare it against the SOW line by line. If it is not covered, price it, show the schedule impact, and get signed approval before you touch it.

Contract language from established templates gives you a starting point for how much time to build into review periods. AIGA's design services agreement uses a 5 to 10 day notice window for objections, while the AICP digital SOW gives clients 30 days to review for material deviations before work is deemed accepted. Treat both as drafting examples, not legal requirements you must copy exactly.

• Acknowledge the request the same day it lands, in writing.
• Compare it against the signed scope before saying yes or no.
• Quote the added fee and any schedule impact if it's out of scope.
• Require a signature before starting the changed work.

Pro Tip: Never start extra work on a verbal "sure, go ahead." Get the change order signed first, even if that means a short pause in momentum.

4. Paste-ready wording for scopes and change orders

You don't need a lawyer to write solid acceptance language. You need consistent phrasing you can reuse across proposals. Here's a starter set.

• Design line: "Accepted when [X] variants are delivered in [formats] and [X] revision rounds are complete."
• Approver clause: "[Name/role] is the sole-authorized approver. Feedback is due within [X] business days of delivery; absent written objection within that window, the deliverable is deemed accepted." Flag this silent-acceptance language for your own contract review since enforceability can depend on your jurisdiction and the rest of your agreement.
• Revision definition: "One revision round means a single, consolidated written feedback package submitted within the review window."
• Change-order email: State the request, the affected deliverable, the added fee, the schedule impact, and a line for signature: "Please reply 'approved' or sign below to authorize this change before work begins."

5. How Stria turns this process into a habit

Writing good acceptance criteria solves half the problem. Enforcing them under deadline pressure, when a client emails "quick thing" at 6 p.m. on a Friday, is the harder half. That's the gap Stria was built to close.

Forward the client's email into Stria and it checks the request against your signed scope, the same comparison step described above, and flags anything that falls outside it. From there it prices the extra work against your rate card, generates a change order, and collects an email-verified signature before you're expected to start. Every approval lands in a tamper-evident record you can export as a PDF ledger if a dispute ever comes up.

Try this on your next project: add one deliverable-level acceptance criterion to your SOW using the template above, then run a single request through a real change-order workflow, whether that's a manual email exchange or a tool built for it. You'll notice the difference in how fast the conversation resolves.

6. What the research gets wrong about acceptance criteria

Most advice on this topic treats acceptance criteria like a legal problem, something you get right by hiring a lawyer to draft airtight clauses. That misses where these disputes actually happen: in the gap between what the contract says and what you just agreed to over a quick call.

The templates from AIGA and AICP are solid starting points, but they were written for agencies with legal departments, not a solo designer juggling four clients. The real skill freelancers need isn't legal precision, it's the discipline to write one sentence per deliverable before the project starts and to actually enforce the review window when a client goes quiet for three weeks and then objects.

If you take one thing from this, prioritize the approver clause over everything else. Vague scopes cause arguments, but an unnamed approver causes projects to stall indefinitely, with nobody able to say yes on the record. Fix that first.

— Team Stria

Try Stria before your next fixed-price project

Writing acceptance criteria is the easy part. Catching the moment a client's request drifts outside them, before you've already done the work for free, is what actually protects your income. This can be achieved by turning a forwarded email into a scope check, a priced change order, and a signed record, without having to reread your own contract every time.

• Start on the Free plan to see how scope checks and change orders work on your next deliverable.
• Compare plan tiers, including Freelancer Solo and Freelancer Studio, on the Stria pricing page.

Templates worth keeping on file

For a full-length design services contract with acceptance language you can adapt directly, use the AIGA standard form of agreement. For agency-scale digital work with formal review windows, the AICP digital SOW is the stronger model. For scope-writing fundamentals, including how to phrase exclusions and dependencies, see Spode Media's scope guidance and Kiolo's agency SOW template.

Sources

• AIGA standard form of agreement for design services
• AICP statement of work (digital SOW)
• The anatomy of a well-constructed scope document — Spode Media
• Agency scope of work template — Kiolo

FAQ

Who should be named as the approver in acceptance criteria?

Name a specific person or role, never "the client" as a general entity, and state the sign-off method they'll use, whether that's a reply email or a signed document. Practitioner guidance from Kiolo recommends preserving the approver's name, the version reviewed, and the date in your acceptance records.

Can silence count as client acceptance of a deliverable?

Yes, many contract templates build in a window, such as the 5 to 10 day period AIGA's design services agreement uses, after which a deliverable is deemed accepted if no written objection arrives. Whether this holds up depends on your specific contract language and jurisdiction, so review it with your own terms in mind.

What do I do if a client refuses to sign a change order?

Pause the extra work until it's signed, since starting unapproved work removes your leverage to get paid for it. If the client insists the request is within the original scope, point to the specific line in your SOW that defines the deliverable, since that comparison is usually where the disagreement actually resolves.

How is a revision round different from ongoing feedback?

A revision round is one consolidated, written feedback package delivered within an agreed window, not a running conversation. Defining it this way, as recommended in scope guidance from Spode Media, prevents drip-fed comments from turning one round into five.

Made with BabyLoveGrowth to bring in organic traffic