Statement of Work vs Scope of Work: The Difference and When You Need Each
A client once sent me a scope of work and asked me to sign it. I did. Four weeks later we were arguing about whether two rounds of revisions were included, because the document listed what I was making and said nothing about how we would decide it was finished.
That is the whole difference, and it is worth about six weeks of goodwill.
The terms get used as if they are the same thing. They are not. The real difference in statement of work vs scope of work is that one is a section and the other is the agreement that contains it. Here is what each one is, what belongs in each, and which one you actually need before you start work.
The short answer
| Scope of work | Statement of work | |
|---|---|---|
| What it is | A description of the work itself | The full working agreement for the project |
| Answers | What is being done? | What, by when, for how much, judged how? |
| Length | A few paragraphs or a list | Several pages |
| Usually | A section inside something bigger | The document the scope sits inside |
| Signed? | Not on its own | Yes, by both sides |
In one line: the scope of work is what. The statement of work is what, plus everything that decides whether you get paid.
What a scope of work actually contains
A scope of work describes the work and nothing else. Done properly it covers four things.
- The deliverables. The actual things that will exist at the end, named individually.
- The tasks. What has to happen to produce them.
- The boundaries. What is included, and — more importantly — what is not.
- The assumptions. What you are taking as given. “Client provides final copy” is an assumption, and writing it down is what lets you charge when it doesn’t arrive.
That last pair does most of the work. A scope that only lists what is included invites every reasonable-sounding addition, because nothing in the document says no. A scope with an explicit “not included” section has already said no, politely, in writing, before anyone was annoyed.
What a statement of work adds
The statement of work wraps the scope in everything commercial.
- Timeline and milestones — dates, not durations.
- Acceptance criteria — how both sides will know a deliverable is finished.
- Price and payment schedule — amounts, triggers, terms.
- Responsibilities on both sides — what the client has to provide and by when.
- Change process — what happens when something new gets asked for.
- Termination — how either side ends it, and what is owed if they do.
Acceptance criteria is the one people skip, and it is the one that caused my revisions argument. Without it, “finished” is an opinion, and the person with the money has the louder opinion.
US federal procurement is unusually clear about what good work descriptions do. FAR 37.602 directs agencies to describe work “in terms of the required results rather than either ‘how’ the work is to be accomplished”, and to “enable assessment of work performance against measurable performance standards.”
Results, not methods. Measurable, not vibes. That is a good test for any statement of work, government or not.
Why statement of work vs scope of work confuses everyone
Three reasons this is such a reliable mess.
Both get shortened to SOW. Scope of work and statement of work share initials, so a client saying “send me the SOW” has given you no information at all. Ask which.
Small projects collapse them. On a two-week job, a one-page document might contain the scope, a date and a price, and people call it either name. That is fine, as long as the commercial parts are in there somewhere.
Industries use them differently. Construction and government use scope of work as a formal standalone document with its own conventions. Software and marketing agencies tend to treat it as a section. Neither is wrong; they are different traditions.
The practical move is not to win the terminology argument. It is to check whether the document in front of you contains acceptance criteria and a change process. If it doesn’t, it is a scope of work, whatever the header says, and you should not start work on it alone.
Side by side: what goes where
| Element | Scope of work | Statement of work |
|---|---|---|
| Deliverables list | Yes | Yes (as the scope section) |
| Tasks and approach | Yes | Yes |
| Out of scope | Yes | Yes |
| Assumptions | Yes | Yes |
| Dates and milestones | Sometimes | Always |
| Acceptance criteria | No | Always |
| Price and payment schedule | No | Always |
| Client responsibilities | Sometimes | Always |
| Change control | No | Always |
| Termination terms | No | Always |
Which one you need
A scope of work on its own is enough when it is going to sit inside something else that carries the commercial terms — a master services agreement, a signed contract, or a purchase order that already fixes price and dates. If the client issues purchase orders, the order often carries the price and delivery date and the scope describes what is being bought.
You need a full statement of work when there is no other agreement in place, the project runs longer than a couple of weeks, there are stages and part-payments, more than one person has to approve things, or the deliverable is subjective enough that “finished” needs defining.
Signs you are about to regret not having one: the price was agreed verbally, nobody has written down what the client owes you, there is no sentence anywhere about revisions, and the start date is this week.
How to write the scope so it cannot be argued with
Four rules that have saved me more arguments than any contract clause.
Name deliverables as countable objects. “Website refresh” is not a deliverable. “Six redesigned page templates, delivered as Figma files” is. If you cannot count it, you cannot prove you delivered it.
Write the “not included” list before the included one. It is faster, because you already know what you are worried about, and it forces the uncomfortable conversation to happen now rather than in week four.
Put a number on anything repeatable. Revisions, meetings, reports, calls. “Two rounds of revisions per deliverable” is a boundary. “Revisions as required” is an open invoice in the client’s favour.
State what you need and when. “Final copy by 20 October; each day of delay moves the delivery date by one day.” Without that sentence, their delay becomes your late delivery.
Acceptance criteria: the part that decides if you get paid
If you add only one thing to your documents after reading this, add this.
Acceptance criteria answer: what has to be true for this deliverable to count as done?
Weak: “Client is satisfied with the design.”
Strong: “Each template matches the approved wireframe, renders correctly at 375px, 768px and 1440px, and passes the agreed accessibility checklist. Client confirms acceptance in writing within five working days, or the deliverable is deemed accepted.”
That last clause is the one that matters. Silence has to mean something. Without a deemed-acceptance line, a client who simply stops replying can hold a project open indefinitely, and you cannot invoice for a milestone that was never signed off.
Pair it with a payment trigger: milestone accepted, invoice issued, payment due on your stated terms. If you have not decided what those terms are, net 30 and what it really costs you is worth reading before you agree to anything longer. Worth knowing too that in the UK, GOV.UK sets out that if no payment date is agreed at all, payment becomes late thirty days after the customer receives the invoice or after you deliver, whichever is later — so an unsigned, undated agreement does not leave you with nothing, just with less than you should have.
The same project, written both ways
Here is a small website project, described as a scope of work and then as a statement of work, so the gap is visible.
As a scope of work:
“Redesign of the company website. Includes new homepage, services page, about page and contact page. Includes responsive layouts and handover of source files. Does not include copywriting, photography, hosting or ongoing maintenance. Assumes client provides final text and brand assets.”
That is a competent scope. It names the deliverables, draws a boundary and states an assumption. It also tells you nothing about money, dates or what finished means.
As a statement of work, the same project adds:
| Section | What it says |
|---|---|
| Milestones | Wireframes by 24 October; designs by 7 November; build complete by 28 November |
| Acceptance | Each milestone accepted in writing within five working days, or deemed accepted |
| Price | £4,800, invoiced in three equal milestone payments |
| Payment terms | Payment due 14 days from each invoice date |
| Client provides | Final copy and brand assets by 20 October |
| Revisions | Two rounds per milestone; further rounds quoted separately |
| Delays | Each day of late client input moves subsequent dates by one day |
| Changes | Quoted in writing before starting; agreed work continues meanwhile |
| Termination | Either party, 14 days written notice; work completed to date is payable |
Same work. One of these two documents can be argued about for six weeks, and the other cannot.
Change control, in three sentences
Most scope creep is not a client trying it on. It is a series of small, individually reasonable requests that nobody priced.
You need three sentences in the document:
- Any work not described in the scope is a change.
- Changes are quoted in writing before they start, with their effect on the timeline.
- Work continues on the agreed scope while a change is being approved.
The third one is the quiet hero. Without it, every change request stops the project, and then the overrun is somehow yours.
Once that is in place, saying no stops being personal. You are not refusing, you are following the process both parties signed. If a client repeatedly tries to go around it, that is a relationship question rather than a paperwork one, and we covered that in our guide to ending a client relationship professionally.
Mistakes that cause disputes
- Starting work on a scope of work alone. No acceptance criteria, no change process, no payment schedule. You are exposed on all three.
- Listing tasks instead of deliverables. Tasks describe effort. Clients pay for outcomes, and disputes are always about outcomes.
- Durations instead of dates. “Four weeks from kickoff” invites an argument about when kickoff was.
- No “not included” section. Silence reads as inclusion.
- Unlimited revisions. The single most expensive two words in freelance work.
- Nothing about client delays. If they are two weeks late with assets and your date doesn’t move, you absorb it.
- No deemed acceptance. Silence stalls the invoice.
- Signed by someone who cannot approve spend. Check the signatory can actually authorise the budget.
Once the statement of work is signed, the rest is administration — raising the invoice against the agreed milestone, with the reference the client’s system expects. Our guide to how to write an invoice covers the fields that decide whether that gets paid or returned, and GOV.UK lists the ones that are legally required.
Frequently asked questions
Is a statement of work a contract?
It can be, if both parties sign it and it contains the commercial terms. More often it sits under a master services agreement, which holds the legal terms while the statement of work holds the project specifics.
Can a scope of work be legally binding?
On its own it usually isn’t, because it carries no price, dates or obligations. It becomes binding when it is incorporated into a signed agreement or a purchase order.
Which comes first?
The scope. You cannot price, schedule or define acceptance for work you have not described yet.
Who writes the statement of work?
Usually the supplier, because the supplier knows the work. The client may provide a brief or a statement of objectives first.
How long should it be?
As short as it can be while still containing deliverables, out-of-scope items, dates, acceptance criteria, price and change control. Two pages is normal for a small project.
Do I need one for a small job?
For a few hours, an email confirming deliverable, date and price is proportionate. Anything with stages, part-payments or subjective output needs the full document.
The short version
The whole of statement of work vs scope of work comes down to this: the scope of work describes the work, and the statement of work is the agreement that contains that scope plus dates, acceptance criteria, price, responsibilities, change control and termination.
If the document in front of you has no acceptance criteria and no change process, it is a scope of work, whatever it is called — and signing it is agreeing to do the work without agreeing how anyone decides it is finished.
