A statement of work is the document that defines exactly what will be delivered on a project, on what schedule, for what price, and what counts as finished. It sits underneath a master services agreement, which supplies the legal terms, and it is where very nearly every project dispute is either prevented or quietly created. Most statement of work problems come from a single habit: describing activity instead of describing a finished thing. This guide covers what belongs in a SOW, how it differs from a scope of work, and how to write one that holds up months later when nobody remembers the conversation.
The short version
Check six things in any statement of work: the named deliverables, the dates, the price, what counts as done, what the client has to supply, and what is explicitly excluded. If a deliverable describes activity rather than a finished artefact, it can never be completed or disputed cleanly.
A statement of work (SOW) is a contract document that specifies the deliverables, timeline, price, and acceptance criteria for a single project or engagement.
What a Statement of Work Actually Contains
A workable SOW answers six questions. Whichever one it fails to answer is, reliably, where the argument will eventually happen.
- What is being delivered. Named, countable artefacts — not activities. “Five page designs in Figma” rather than “design work”.
- When. Dates, or elapsed time from a defined start, plus what happens if either side is late.
- What it costs. Fixed fee, time and materials with a cap, or milestone-based.
- What counts as done. The acceptance criteria, and how long the client has to object.
- Who does what. Client obligations belong here too — content, access, approvals, sample data.
- What is explicitly excluded. The single most under-used section in any statement of work.
That last one deserves its own moment. Writing down what you are not doing costs you one paragraph and removes most scope arguments before they have anywhere to start. Both sides come out ahead: the supplier gets a defensible boundary, and the client gets an accurate picture of what they are buying rather than a hopeful one.
Did You Get a Statement of Work or Just a Scope of Work?
Check the document for dates, a price and acceptance criteria: one that lists tasks alone is a scope of work, which describes the effort but is not the contract document that makes any of it enforceable.
The two terms get used interchangeably in conversation, and — with a flourish of professional cruelty — both abbreviate to SOW. The practical distinction is straightforward once you see it:
- A scope of work describes the work itself — the tasks, the approach, the boundaries of the effort.
- A statement of work is the broader contract document. It contains the scope of work, and adds schedule, pricing, acceptance criteria, assumptions, and responsibilities.
So the scope of work is usually a section living inside the statement of work. If somebody sends you a one-page “SOW” that describes tasks and nothing else — no dates, no price, no acceptance terms — you have been handed a scope of work, and the parts that would make it enforceable are still missing.
How a Statement of Work Fits With an MSA
The standard structure is one master services agreement holding the legal terms — liability, intellectual property, confidentiality, termination — with a separate SOW issued for each project. Sign the MSA once, and every engagement after it is a short document.
One detail here carries real consequences. The MSA almost always states that its terms control if a SOW conflicts with it, which means a favourable term you negotiated into a statement of work may simply be unenforceable when it contradicts the master agreement. If you genuinely need different terms for one project, either amend the MSA, or have the SOW say explicitly that it overrides the MSA on that specific point.
And then the caveat on that second option, which is the part most often missed: a statement of work can only override the master agreement if the master agreement lets it. Order-of-precedence clauses are frequently drafted to rule exactly that out — wording to the effect that the master terms control notwithstanding anything in any statement of work leaves no room for a project document to win, however emphatically the SOW tries. So read the precedence clause before you rely on an override. If it is absolute, the only route left is an amendment to the MSA itself, and that needs the other side to agree to something they have already written a clause to prevent.
This is also why warm assurances given on a kickoff call are worth so little. Under the parol evidence rule, prior or contemporaneous discussions generally cannot be used to contradict a written agreement the parties intended as their final expression. Everyone means it at the time. The document is what survives. If it matters and it is not in the SOW, assume it does not exist.
How to Write a Statement of Work
- Start from the deliverable, not the process. Write down the artefact the client will be holding at the end, then work backwards to the tasks that produce it.
- Make every deliverable countable. A number, a format, a location. “Twelve product photographs, retouched, delivered as JPEG and TIFF” leaves nothing to interpret and nothing to argue about.
- Define acceptance and give it a clock. State what the client checks against, and add deemed acceptance — deliverables are accepted automatically if no written objection arrives within five to ten business days.
- List client obligations with dates. If the project depends on content or approvals from them, say so, and note that the timeline moves if those slip.
- Write the exclusions. Three or four lines naming what is out of scope.
- Add a change process. No extra work starts until agreed in writing; our guide to change orders covers what goes in it.
Step three is where most money quietly disappears. A payment triggered by acceptance, with no defined acceptance window, is not really a payment term — the obligation does not start until the client decides to let it start. That mechanic is covered in more detail in our guide to contract payment terms.
Common Statement of Work Mistakes
- Describing effort instead of output. “Ongoing SEO optimisation” cannot be measured, which means it can never be finished, which means it can never be cleanly disputed either.
- No change control. Without a written change process, every request turns into a debate about whether it was always included — a debate with no evidence on either side.
- Silent on client delay. If the client is three weeks late supplying content, the SOW should already say what that does to the schedule and to the price.
- Copying the last SOW. Reused templates carry the previous project’s assumptions forward intact, and the one thing nobody ever does with a reused template is reread it.
- Treating it as paperwork. The SOW is the document that gets read in a dispute. The proposal deck that won the work is not.
The pattern underneath all five is the same, and it is worth naming plainly: a statement of work is written while everyone is optimistic and read only once somebody is unhappy. Those are very different frames of mind, and the document has to work in the second one. A SOW that would be clear to a stranger six months from now — someone with no memory of the kickoff call and no stake in what was meant — is one that will hold. The same principle drives the wider pre-signing checklist.
ContractClerk reviews statements of work alongside the master agreements that govern them, and flags deliverables described as activities, missing acceptance windows, and terms that conflict with the parent MSA.
A scope of work describes the tasks and boundaries of the effort. A statement of work is the wider contract document that contains the scope plus schedule, pricing, acceptance criteria, assumptions, and each side’s responsibilities. The scope is usually one section inside the statement of work.
Yes, when it is signed or issued under a master services agreement that makes it binding. The SOW defines the obligations for that project while the MSA supplies the general legal terms. Most MSAs state that the master terms control wherever a SOW conflicts with them.
Deliverables described as countable artefacts, a schedule, the price and payment triggers, acceptance criteria with a defined objection window, client obligations, explicit exclusions, and a written change-control process. Missing any one of these is where project disputes usually begin.
For repeat work with the same party, use both: the MSA once for legal terms, then a short SOW per project. For a single one-off engagement, one combined services agreement covering both the legal terms and the deliverables is simpler and faster to read.
Only by written agreement between both parties, which is why a change-control clause matters. It should state how a change is requested, who prices it, and that work on the change does not begin until both sides have agreed in writing.
Only if the statement of work said so before the delay happened. The clause that decides it is the one listing the client’s own obligations with dates attached: without it, their lateness is a fact about the project rather than a breach of anything, and the lost time lands on you. A workable version states that the schedule moves when a client dependency is late, and says whether standby time is chargeable.
The Bottom Line on a Statement of Work
A statement of work is where a project either becomes deliverable or becomes an argument. The MSA decides what happens if things go badly wrong; the SOW decides whether anybody can agree the work is finished at all. Write it so a stranger could tell, six months later, whether you delivered — and both sides will know exactly where they stand long before it ever matters.
This article is general information, not legal advice, and does not create an attorney-client relationship. Contract law varies by state and by situation. For high-stakes agreements, have a licensed attorney review the document.