Short answer: A statement of work (SOW) is the document that defines a specific piece of work: the scope, the deliverables, the schedule, the price, and the acceptance criteria that decide when the work is finished. It usually sits under a master service agreement, which carries the legal terms, so the SOW can stay focused on the project itself. A good SOW is short, specific, and testable. If two reasonable people can read it and disagree about whether a deliverable is done, it is not finished.
Last updated: July 2026.
Most disputes in services work are not about bad intentions. They are about a sentence that meant one thing to the person who wrote it and something else to the person who paid for it. "Redesign the website" is that sentence. The statement of work exists to replace it with something a stranger could audit.
What is a statement of work?
A statement of work is a binding project document that describes exactly what a vendor will deliver, how, when, and for how much. It converts a sales conversation into an operational contract. Where a proposal persuades, a SOW commits.
It answers five questions, and it is not finished until it answers all five without ambiguity:
- What is being delivered, in concrete nouns rather than activities.
- How the work will be performed, including standards, tools, and location.
- When each piece is due, and what depends on the customer.
- How much it costs, on what basis, and how it will be invoiced.
- How we know it is done, which is the acceptance criteria and the part most SOWs fumble.
Statement of work vs scope of work
People use these interchangeably, and in casual use it rarely causes harm. In a contract it does. The scope of work is a section. The statement of work is the document that contains it.
| Scope of work | Statement of work | |
|---|---|---|
| What it is | The description of the work itself | The full project document, including the scope |
| Covers | Tasks, deliverables, boundaries, exclusions | Scope plus schedule, price, payment, acceptance, assumptions, change control |
| Stands alone? | No, it is one section | Yes, it is signed |
| Typical length | One to three pages | Three to fifteen pages |
| Who writes it | The delivery lead who will do the work | The delivery lead, reviewed by whoever owns commercial terms |
Practical rule: when someone asks you for "the scope of work," they usually want the part that says what you will and will not do. When they ask for "the SOW," they want the whole signable document. Write the scope section first, because everything else in the SOW is a consequence of it.
What does a statement of work include?
These are the sections that carry weight. Anything else is usually padding that makes the document harder to enforce.
| Section | What it settles | The failure it prevents |
|---|---|---|
| Background and objectives | Why the work exists and what success looks like in business terms | Delivering exactly what was asked for and still missing the point |
| Scope of work | The tasks and boundaries of the engagement | Endless expansion of "while you are in there" requests |
| Out of scope | What is explicitly excluded | The most valuable paragraph in the document, and the one most often skipped |
| Deliverables | The artifacts handed over, each named, in a stated format | Arguments about whether advice counts as a deliverable |
| Schedule and milestones | Dates, sequence, and dependencies | Slippage with no agreed baseline to slip from |
| Acceptance criteria | The test each deliverable must pass, and who applies it | Work that is never formally done, so never fully paid |
| Customer responsibilities | Access, data, decisions, and review turnaround owed by the buyer | Being blamed for delays caused by a client who took three weeks to reply |
| Assumptions | The conditions the price depends on | Fixed-fee work priced on facts that turned out to be false |
| Fees and invoicing | Price, basis (fixed, time and materials, milestone), and invoice schedule | Cash collected months after the cost was incurred |
| Change control | How scope changes get priced and approved, in writing | Scope growth absorbed for free out of politeness |
| Key personnel | Who is actually doing the work | The senior team at the pitch, juniors on the project |
| Term and precedence | Start and end dates, and that the master agreement governs conflicts | A floating document with unclear legal terms |
Statement of work template
Use this as an outline and fill it with specifics. A SOW written from a template but stuffed with vague language is worse than no template, because it looks rigorous while committing to nothing.
- Header. SOW number, effective date, parties, and the sentence that ties it to the master service agreement: "This Statement of Work is entered into under the Master Service Agreement dated [date] between [parties] and is governed by its terms."
- Background and objectives. Two or three sentences on the business problem, then the measurable outcome the project targets.
- Scope of work. The tasks, grouped into phases, described in verbs and nouns a third party could follow.
- Out of scope. A bulleted list of the adjacent things people will assume are included and are not.
- Deliverables. A numbered table: deliverable, format, due date, and the acceptance test.
- Schedule and milestones. Dates or elapsed durations from a defined start trigger, such as "within 10 business days of kickoff."
- Acceptance criteria and process. Who reviews, in how many business days, on what standard, and what happens if they do not respond.
- Customer responsibilities. Named, with turnaround times attached.
- Assumptions. The facts the estimate rests on.
- Fees, expenses, and invoicing. Amounts, basis, milestone triggers, expense policy, and payment terms.
- Change control. The form a change request takes and who can approve it on each side.
- Key personnel. Names and roles, with a substitution clause if the customer cares.
- Signatures. Names, titles, and dates for both parties.
Keep the executed copy somewhere you can find it in ten seconds, which in practice means a searchable contract repository rather than the inbox of whoever signed it.
Statement of work example
Here is a compressed but realistic example: a design agency rebuilding a mid-market company's marketing site. Note how little of it is prose.
Objective. Replace the current marketing site so that the client's marketing team can publish new pages without engineering help, and reduce time to publish from two weeks to one day.
Scope. Discovery workshop; information architecture for up to 25 pages; visual design of 8 unique page templates; build in the client's existing CMS; migration of up to 25 existing pages; two rounds of revisions per template; training session for up to 6 marketing staff.
Out of scope. Copywriting; photography; SEO migration audit; changes to the client's e-commerce checkout; any page beyond 25; ongoing hosting or maintenance.
| Deliverable | Format | Due | Acceptance test |
|---|---|---|---|
| Information architecture | Sitemap document | Day 10 | Covers all 25 in-scope pages, approved in writing by the marketing director |
| Design templates | 8 templates, desktop and mobile | Day 35 | Each template renders correctly at 375px and 1440px and matches the approved IA |
| Built site on staging | Staging URL | Day 65 | All 25 pages published, zero critical bugs from the agreed defect list, Lighthouse performance score of 85 or higher on the homepage |
| CMS training | Recorded 90 minute session | Day 70 | Two named marketing staff independently create and publish a test page without assistance |
Customer responsibilities. Provide CMS admin access by Day 3; supply final copy for all 25 pages by Day 45; return consolidated feedback within 5 business days of each review request.
Assumptions. The existing CMS supports custom templates without a plan upgrade. Content is supplied in a single consolidated document. One stakeholder holds final approval.
Fees. Fixed fee of 60,000 USD, invoiced 30% at signature, 30% at design acceptance, 40% at site acceptance. Payment terms net 30. Delay caused by late customer deliverables beyond 10 business days entitles the vendor to re-baseline the schedule.
Notice that "Lighthouse performance score of 85 or higher" and "two named staff publish a test page unassisted" are testable by someone with no stake in the outcome. That is the standard to aim for. "Client satisfaction with the design" is not an acceptance criterion, it is a hostage note.
Acceptance criteria: the section that decides whether you get paid
Most late payment in professional services is not a collections problem, it is an acceptance problem. The invoice cannot be raised because the milestone was never formally accepted, and the milestone was never accepted because nobody defined what acceptance meant.
Three things fix it. Write criteria that are objectively testable. Give the reviewer a deadline, typically five business days. Add deemed acceptance: if the customer does not respond with specific written defects inside that window, the deliverable is accepted. Without deemed acceptance, silence becomes a free extension of your payment terms, and it goes straight into your days sales outstanding.
How the SOW works with a master service agreement
The two documents split the job. The master service agreement holds the durable legal terms: liability caps, intellectual property, confidentiality, insurance, governing law, payment terms. The SOW holds the project. Sign the MSA once, then add a SOW per engagement and start work in days instead of weeks.
The trap is order of precedence. Standard MSAs say the MSA wins any conflict with a SOW. That is sensible for legal terms, and it quietly destroys any commercial concession you negotiated into the SOW. If a SOW is meant to override something in the MSA, say so explicitly: "The parties agree that Section 7 of this SOW supersedes Section 12.3 of the MSA for this engagement only." Vague intent loses to a precedence clause every time.
Is a statement of work a legally binding contract?
Yes, once it is signed. A SOW executed under an MSA is binding, and it incorporates the MSA's terms by reference. A standalone SOW, signed without any master agreement above it, is also a contract, but it is a thin one: it carries no liability cap, no IP assignment, and no dispute mechanism unless you wrote those into the SOW itself. That is the usual argument for putting the MSA in place first, even for a small first project.
Who writes the statement of work?
The vendor usually drafts it, because the vendor knows what the work actually takes. The buyer should still redraft the acceptance criteria and the customer responsibilities, since those two sections are where a vendor's draft naturally protects the vendor. In larger organizations the buyer's procurement team writes a SOW template and issues it, particularly when the engagement came out of a request for proposal. Either way, the people who will do the work should write the scope, not the people who sold it.
What is the difference between a SOW and a contract?
A contract is the general term for a binding agreement. A SOW is a specific type of contract document that describes a project. In practice, when someone says "the contract," they usually mean the master agreement carrying the legal terms, and when they say "the SOW," they mean the project document describing this piece of work. Both are contracts. Only one of them tells you what gets built.
Five mistakes that turn a SOW into a dispute
- No out of scope section. Everything not mentioned becomes negotiable, and the customer's expectation of what was included expands quietly over the project.
- Deliverables described as activities. "Provide strategic guidance" cannot be delivered or accepted. "A 12 page written channel strategy" can.
- Fixed fee on unfixed assumptions. If the price depends on the customer supplying clean data on Day 5, that assumption belongs in the document, with a stated consequence if it fails.
- No change control. Every services business has absorbed thousands of dollars of unpriced extra work because saying no felt worse than doing it. A one page change order form, agreed in advance, makes the conversation routine instead of confrontational.
- Milestones that do not trigger invoices. Tie payment to acceptance events. Work that is delivered but not invoiced is a loan you did not agree to make, and it shows up later in your accounts receivable process.
Where the SOW sits in the wider engagement
The document chain in business-to-business services runs in a predictable order: a buyer runs a selection process, the parties sign a master agreement, a SOW defines the first project, and delivery generates the invoices. Each document has one job. Problems appear when one of them is asked to do another's, which is why an engagement paperworked entirely through email threads eventually needs a lawyer.
Getting this right is a customer experience decision as much as a legal one. The speed from "yes" to "started" is one of the first things a new customer measures you on, and it is set by how much of your client intake process is ready before the deal closes. Firms that already have a signed MSA and a SOW template can start on Monday. Firms that start drafting after the handshake take three weeks, and the customer notices.
This article is general information about commercial contracting practice, not legal advice. Have counsel review any agreement you intend to sign.