What Is Statement of Work?
A detailed addendum describing timeline, milestones, and acceptance for a deal.
Detailed Explanation
Often sits under an MSA. Payment triggers should match invoice schedules.
Example
SOW Phase 2 invoices on UAT sign-off per milestone table.
Why It Matters
Aligns legal obligations with what you bill.
Key facts
- A statement of work (SOW) is a formal document that defines project specifics: scope, deliverables, timeline, milestones, acceptance criteria, and pricing.
- Typically used alongside or in place of a contract for project-based engagements — common in consulting, software development, professional services, and construction.
- Standard SOW components: project objectives, scope (what's in AND what's out), deliverables, timeline/milestones, payment terms, acceptance criteria, change-order process, assumptions, and signatures.
- Master Service Agreement (MSA) + multiple SOWs is a common structure: the MSA covers legal terms once, individual SOWs cover specific projects.
- A well-written SOW is the primary defense against scope creep — vague scope language is the #1 cause of project disputes and unprofitable engagements.
How it shows up in practice
A boutique web agency signs an MSA with a client in January. For a homepage redesign in March, they sign SOW #003-2026: deliverables (3 design concepts, 1 final design, responsive HTML/CSS), milestones (concepts March 10, design March 25, build April 15), pricing ($14,500 with 50% deposit + 50% on launch), assumptions (client provides copy, 2 revision rounds included), and acceptance (client signs off within 7 days of delivery or auto-acceptance). When the client requests 4 additional revisions in April, the SOW makes the change-order conversation easy.
Common mistakes
- Vague scope language ('improve the website') instead of specific ('design and build a 5-page responsive marketing site with X, Y, Z features').
- Failing to define what's OUT of scope — explicit exclusions prevent assumptions.
- No change-order process — every small request becomes a free addition.
- Missing acceptance criteria — projects drag on because 'done' is ambiguous.
- Not requiring written signatures — verbal agreements are unenforceable in disputes.
Frequently asked questions
What's the difference between an SOW and a contract?
A contract typically covers the legal relationship (terms, IP, liability, dispute resolution). An SOW covers project specifics (scope, deliverables, timeline, price). Many engagements use an MSA (master contract) plus SOWs (per-project specifics).
Do I need an SOW if I have a proposal?
A proposal is typically pre-sale; an SOW is the formal post-sale agreement. The proposal can become an SOW with minor edits and signatures, or you can write a separate SOW after proposal acceptance.
What's the most important section of an SOW?
Scope and deliverables — they define what you're committing to deliver and what's out of bounds. Acceptance criteria comes second — it defines when 'done' is officially achieved (and final payment is triggered).
How do I handle scope changes mid-project?
Issue a change order: a brief amendment to the SOW that adds the new scope, new pricing, and new (if needed) timeline, signed by the client BEFORE doing the work. Don't fold extra scope into existing pricing.
Can a single SOW cover multiple projects?
Generally no — each distinct project should have its own SOW for clear scoping and acceptance. Multi-project arrangements use one MSA + multiple SOWs.
Related Resources
Last verified: May 2026
Related Business Terms
Get invoicing tips that actually help
Join 5,000+ freelancers and small business owners. One email per week with practical invoicing advice, tax tips, and product updates.
No spam, ever. Unsubscribe anytime.