What Is a Statement of Work (SOW)? Definition, Contents and Example

What is a statement of work?

A statement of work (SOW) is the formal document that defines one specific piece of work a supplier will perform for a customer: what will be delivered, how each deliverable is accepted, when it will be delivered, and what it costs. SOW stands for statement of work, and people also call it a work order, project schedule, or project order, depending on the industry. In most business relationships the SOW sits under a master services agreement (MSA): the MSA holds the legal terms once, and each new project gets its own SOW.

Put simply, the MSA answers "on what legal terms do we work together?" and the SOW answers "what exactly are we doing this time, and how will we know it is done?"

This guide explains what belongs in a SOW, how it differs from an MSA, an order form and a purchase order, when to use a fixed-price or a time-and-materials SOW, and the mistakes that cause most SOW disputes. If you mainly want the relationship between the two documents, read our MSA vs SOW guide alongside this one.

What goes in a statement of work

A useful SOW answers seven questions. If any of them is missing, the gap tends to surface later as a scope argument, a stalled invoice, or a change request nobody agreed how to price.

1. Scope. What work is included, and just as importantly, what is out of scope. A short "exclusions" list prevents more disputes than any amount of detail in the inclusions, because it is the out-of-scope items that both sides later remember differently.

2. Deliverables. The concrete outputs: a report, a configured system, a set of designs, a number of training sessions. Each deliverable should be something you can point at and check.

3. Acceptance criteria. How the customer decides a deliverable is complete. Good criteria are objective (it passes these tests, it contains these sections, it meets this specification), and come with a review window, say ten business days, and a rule for what happens if the customer stays silent.

4. Timeline and milestones. Start date, key milestones, end date, and the dependencies on the customer (access, data, decisions) that the timeline assumes.

5. Fees and payment basis. Fixed price, time and materials, or a mix, with the rate card, any cap, the invoicing trigger (monthly, per milestone, on acceptance), and expenses policy. The payment mechanics usually point back to the MSA; see our guide to payment terms clauses for what is standard there.

6. Assumptions and dependencies. The conditions the price and timeline rely on. "Customer will provide test data by week 2" belongs here. When an assumption turns out false, it is the documented assumption that justifies a change request.

7. Change control. How either side proposes a change, how it is priced, who can approve it, and that no change is binding until it is signed as a change order.

A SOW also typically names the project contacts on each side and references the MSA it is issued under ("This SOW is entered into under the Master Services Agreement dated..."). What it should not do is quietly rewrite the MSA's legal terms. Liability caps, indemnities, IP ownership and confidentiality live in the MSA; if a particular project really needs different terms, say so explicitly and refer to the MSA's order of precedence clause. Our guides to limitation of liability and termination cover the MSA side.

SOW vs MSA vs order form vs purchase order

These four documents are often confused because they can all appear in the same deal. They do different jobs.

Statement of work vs scope of work

The two are easy to mix up because both abbreviate to "SOW". The scope of work is one section inside the statement of work: the list of what is included and excluded. The statement of work is the whole project document, which adds deliverables, acceptance criteria, timeline, fees, assumptions and change control around that scope. A scope without the rest tells you what the supplier will do but not when it is done or what it costs.

A practical rule: services that need defining get a SOW; standard products and subscriptions get an order form; and the PO is the buyer's finance paperwork that sits alongside either. The trap to watch is the PO with terms printed on the back. If the PO's terms conflict with the MSA and your MSA does not say it prevails over PO terms, you have a battle of the forms. Make the MSA's precedence clause cover POs explicitly.

Types of statement of work

Statements of work are usually grouped by how they describe the work. The labels come from US federal procurement, which lists performance-oriented documents ahead of detailed design-oriented ones when agencies choose how to state their requirements, but the same three styles appear in private contracts.

The federal rules describe the performance-based style as stating work "in terms of the required results" with "measurable performance standards" (FAR 37.602), and allow time and materials only when the work cannot be estimated with reasonable confidence (FAR 16.601). For most in-house teams buying services, a performance-based SOW with a fixed price is the default, and the other two are exceptions you choose deliberately.

How to write a statement of work

1. Agree the objective. One or two sentences on what the project is for and what the business will have at the end.
2. List scope and exclusions. Write both lists. The exclusions are what prevent later arguments.
3. Define deliverables and acceptance. For each deliverable, state the objective criteria, the review window, and what happens if the customer does not respond.
4. Set milestones and dependencies. Dates for each deliverable, plus what the customer must provide and by when.
5. Choose the pricing model. Fixed price, time and materials with a cap, or a mix, and tie invoices to accepted milestones where you can.
6. Record assumptions and change control. The conditions the price relies on, and how changes are requested, priced and signed.
7. Check it against the MSA. Confirm the SOW references the right MSA and does not quietly override its liability, IP, confidentiality or payment terms.
8. Sign before work starts. Have authorized people on both sides sign, then store the SOW where its dates and caps can be tracked.

Fixed price vs time and materials SOWs

The pricing model changes how the rest of the SOW has to be written.

US federal procurement rules put the T&M principle clearly: a time-and-materials contract may be used "only when it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work," and it must include a ceiling price that the contractor exceeds at its own risk (FAR 16.601). Private contracts are not bound by that rule, but the logic travels well: if you choose T&M, add a not-to-exceed amount and a notice obligation when spend reaches, say, 80 percent of it.

Public procurement also offers a useful drafting principle for fixed-price work. The FAR's guidance on performance work statements asks agencies to describe work "in terms of the required results rather than either 'how' the work is to be accomplished or the number of hours to be provided," and to enable assessment "against measurable performance standards" (FAR 37.602). Writing deliverables as results with measurable standards is exactly what makes acceptance criteria work.

Example: a statement of work outline

Here is a worked outline for a common in-house scenario: a company engaging an implementation partner to roll out a new HR system, under an MSA already in place.

SOW No. 3, HR system implementation Issued under the Master Services Agreement between Customer Ltd and Partner Ltd dated 15 January 2026.

1. Purpose. Configure and launch the customer's new HR system for 400 employees in two countries.
2. Scope. Configuration of core HR, absence and onboarding modules; migration of current employee records; two admin training sessions. Out of scope: payroll integration, custom reporting, migration of records older than 2020.
3. Deliverables.
   • D1: Configuration design document
   • D2: Configured test environment
   • D3: Migrated employee data, validated
   • D4: Two admin training sessions (remote, 2 hours each)
   • D5: Production go-live
4. Acceptance. Each deliverable is accepted when it meets the criteria in Annex A. Customer has ten business days from delivery to accept or give written reasons for rejection. If Customer does neither, the deliverable is deemed accepted. Rejected deliverables are corrected and resubmitted once at no extra cost.
5. Timeline. Start 1 October 2026; D1 by 16 October; D2 by 13 November; D3 by 4 December; D5 go-live 11 January 2027.
6. Customer dependencies. Access to the current HR system export by 9 October; a named project owner available four hours per week.
7. Fees. Fixed fee of 48,000 (currency per MSA), invoiced 25 percent on acceptance of D1, 25 percent on D2, 25 percent on D3 and 25 percent on D5. Travel expenses only with prior written approval.
8. Assumptions. Employee data is provided in the vendor's standard import format; no more than 40 custom fields.
9. Change control. Either party may request a change in writing. Partner provides an impact assessment (cost, timeline) within five business days. No change is binding until both parties sign a change order.
10. Contacts. Project owner and escalation contact for each party.

Notice what makes this outline workable: the exclusions list, deliverables you can point at, a deemed-acceptance rule so invoices do not stall, payment tied to accepted milestones rather than dates, and a change process that prices changes before anyone does them.

Sample acceptance wording (illustrative):

Customer shall, within ten (10) Business Days of receipt of each Deliverable, either accept the Deliverable in writing or notify Partner in writing of each respect in which the Deliverable fails to meet the Acceptance Criteria in Annex A. If Customer does not do either within that period, the Deliverable shall be deemed accepted.

Common SOW mistakes, and how to avoid them

Vague acceptance criteria. "Deliverable is complete when approved by the customer" gives the customer an open-ended veto and the supplier no invoice date. Replace it with objective criteria, a review window, and deemed acceptance.

No change-order process. Without one, every extra request becomes an argument about whether it was "in scope." A change clause that requires a written impact assessment and a signed change order before work starts protects both sides.

Conflicting order of precedence. A SOW that introduces its own liability cap, IP clause or payment terms creates a conflict with the MSA. If the MSA says the MSA prevails, the SOW's special terms may be void; if it says the SOW prevails, a project manager may have just renegotiated your liability position. Decide deliberately, and state in the SOW when a deviation is intended: "Notwithstanding clause 12 of the MSA, for this SOW only..."

Scope described as activities, not results. "Partner will provide consulting support" describes effort. "Partner will deliver a validated migration of all active employee records" describes a result you can accept.

Work starts before signature. Common under deadline pressure, and it leaves the work governed by nothing more than emails. If work must start early, sign a short letter of authorization with a cap until the SOW is executed.

The SOW gets lost after signature. SOWs outnumber MSAs many times over, and the milestones, caps and end dates inside them are what finance and project teams need later. If they live in inboxes, nobody sees the T&M cap approaching or the end date passing. This is where a searchable archive with key dates pulled out matters; see our overview of software for MSA and SOW management.

How to do this in Bind

Here is what drafting and tracking a SOW looks like in Bind, from the request to a signed document your team can find.

Step by step, with the names you will see in Bind:

Bind is used by in-house teams at companies including Atria, listed on Nasdaq Helsinki, and Slush, the global startup and tech event organizer.