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 nearly every project dispute is either prevented or created. Most statement of work problems come from one place: describing activity instead of describing a finished deliverable. This guide covers what belongs in a SOW, how it differs from a scope of work, and how to write one that holds up.
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. If any one is missing, that is 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 point deserves emphasis. Listing what you are not doing costs one paragraph and removes most scope arguments before they start. Supplier and client both benefit: one gets a defensible boundary, the other gets an accurate picture of what they are buying.
Statement of Work vs Scope of Work
The terms are used interchangeably in conversation, and both are abbreviated SOW, which does not help. The practical distinction:
- 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.
In other words, the scope of work is usually a section inside the statement of work. If someone sends you a one-page “SOW” that only describes tasks with no dates, price, or acceptance terms, you have received a scope of work and are still missing the parts that make it enforceable.
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, then each new engagement is a short document.
One detail carries real consequences: the MSA almost always states that its terms control if a SOW conflicts with it. So a favourable term negotiated into a statement of work may simply be unenforceable if it contradicts the master agreement. If you genuinely need different terms for one project, either amend the MSA or have the SOW state explicitly that it overrides the MSA on that specific point.
This is also why verbal assurances during 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 that the parties intended as their final expression. 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 hold 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.
- 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 timelines shift if those slip.
- Write the exclusions. Three or four lines naming what is out of scope.
- Add a change process. How a change is requested, who prices it, and that work does not start until it is agreed in writing.
Step three is where most money is lost. A payment triggered by acceptance, with no defined acceptance window, is not a payment term at all — the obligation never starts until the client chooses to let it. 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” is unmeasurable, so it can never be completed or disputed cleanly.
- No change control. Without a written change process, every request becomes a negotiation about whether it was always included.
- Silent on client delay. If the client is three weeks late supplying content, the SOW should say what happens to the schedule and the price.
- Copying the last SOW. Reused templates carry the previous project’s assumptions, and nobody rereads them.
- Treating it as paperwork. The SOW is the document a court reads, not the proposal deck that won the work.
The pattern underneath all five is the same as with any agreement: the SOW is written while everyone is optimistic, and read only once someone is unhappy. A statement of work that would be clear to a stranger six months from now — with no memory of the kickoff call — 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, 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.
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 anyone can agree the work is finished. Write it so a stranger could tell, six months later, whether you delivered — and both sides will know where they stand long before it 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.