What Is a Statement of Work (SOW)? Explained (2026)

What SOW means in business SOW stands for statement of work. In business, a statement of work is the document that describes exactly what work will be done on a specific project: the tasks, the deliverables, the timeline, the people, and how you will know it is finished. If a contract says the two sides will work together, the statement of work says what "the work" actually is. It matters because most project disputes are really disagreements about scope. The client thought the deliverable included one more thing; the supplier thought that was extra. A clear statement of work settles those arguments before they happen by writing down what is in, what is out, and what "done" looks like. This page is general information, not legal advice. Confirm your own position before relying on specific wording. ## What goes in a statement of work A good statement of work answers a short list of questions in plain terms: - Purpose and background. Why the project exists and what problem it solves.

• Scope. The specific tasks and activities included, and, just as important, what is explicitly out of scope.
• Deliverables. The concrete things that will be handed over, each described so both sides can recognise it.
• Timeline and milestones. The schedule, key dates, and the points at which progress is reviewed.
• Acceptance criteria. The test a deliverable must pass to be accepted, and how long the client has to review it.
• Roles and responsibilities. Who does what on each side, including what the client must provide, such as data, access, or approvals.
• Price and payment. The fee and how it links to milestones or time, with invoicing terms.
• Assumptions and dependencies. What the plan assumes is true, and what the work depends on from others.
• Change control. How a change to scope is requested, priced, and approved. ## A short statement of work template ``` STATEMENT OF WORK Project: [name] SOW date: [date] Under the agreement between [Client] and [Supplier] dated [date]. 1. BACKGROUND / PURPOSE [Two or three sentences on why this work is being done.] 2. SCOPE In scope: [list the tasks and activities]. Out of scope: [list what is explicitly excluded]. 3. DELIVERABLES
• [Deliverable 1, described]
• [Deliverable 2, described] 4. TIMELINE AND MILESTONES
• [Milestone 1] by [date]
• [Milestone 2] by [date] 5. ACCEPTANCE CRITERIA Each deliverable is accepted when [criteria]. The Client has [for example 10 business days] to accept or give written reasons for rejection. 6. ROLES Supplier provides: [roles]. Client provides: [access, data, approvals]. 7. PRICE AND PAYMENT [Fixed price / time and materials]. Invoiced [on milestone / monthly], due within [days]. 8. ASSUMPTIONS AND DEPENDENCIES [List.] 9. CHANGE CONTROL Changes to scope are requested in writing, assessed for cost and time, and take effect only when both parties sign a change note. SIGNED Client __________ Supplier __________

- **Level-of-effort or time-and-materials SOW.** Pays for time and resources rather than a fixed outcome. Suits open-ended or research work where the end is unclear.
- **Performance-based SOW.** Specifies the outcome and the standard, and leaves the method to the supplier. Often the best for results, because it ties payment to what the client actually wants. ## Common mistakes that cause scope creep - No out-of-scope list, so everything becomes arguable.
- Vague deliverables that cannot be objectively recognised as finished.
- No acceptance criteria or review window, so "done" is a matter of opinion.
- No change-control clause, so extra requests are absorbed for free or fought over.
- Forgetting client dependencies, then blaming the supplier for a delay the client caused. ## How context changes things Statements of work are a commercial tool rather than a creature of a specific statute, so the format is flexible worldwide. What changes is the surrounding legal framework in the MSA or contract, which follows local law on liability, intellectual property, and consumer or procurement rules. Government and regulated contracts often prescribe a particular statement-of-work format and stricter change control. If you are supplying to the public sector, check the required format before you draft. ## Keeping statements of work under control A busy supplier runs many statements of work at once, each under the same MSA, each with its own milestones, acceptance dates, and change notes. The work that outlasts signing is keeping every statement of work linked to the right master agreement, tracking milestone and acceptance deadlines, and making sure a change note is signed before extra work starts. Scattered across email and shared folders, milestones slip and changes go unbilled. That is the same problem businesses face across all their contracts, which is why drafting, understanding, editing, tracking, and governing a document like this can live in one AI workspace tuned to how your company contracts and built on Claude, with transparent per-seat pricing. [Adira](https://adiralaw.com) is built around that single-workspace idea for business contracts. For a single project, the template above is enough; the habit worth keeping is holding each statement of work, its master agreement, and its dates in one place.