What Is a Statement of Work? A Plain-Language Guide

A statement of work, usually shortened to SOW, is the part of a services contract that says exactly what will be delivered, by when, by whom and for how much. If you are asking what is a statement of work, think of it as the project-level document that sits underneath the legal terms. In practice, it is where most contract disputes about "that was not what we agreed" are won or lost.

What does a statement of work actually contain?

A SOW describes one piece of work. It does not try to cover the whole relationship between two companies. Most well-drafted ones contain the same core blocks.

• Scope of work: what the supplier will do, in plain verbs, and what it will not do.

• Deliverables: the concrete outputs, such as a migrated database, a brand guide or 40 hours of support.

• Timeline and milestones: dates or durations, tied to deliverables rather than to a vague "by end of quarter".

• Fees and payment schedule: fixed price, time and materials, or a mix, with invoice triggers.

• Acceptance criteria: how the customer decides that a deliverable is done.

• Roles and dependencies: who supplies access, data, approvals or test environments, and by when.

• Change process: how scope, price or dates get modified once work has started.

Here is what that structure really says: the SOW turns a handshake idea into something a third person could read and verify. That third person is often a judge, an auditor or a new colleague who inherits the project.

How is a SOW different from an MSA, a proposal or a purchase order?

The confusion usually comes from documents that look similar and sit close together in a deal.

A master services agreement (MSA) holds the standing legal terms: liability, intellectual property, confidentiality, data protection, termination and governing law. It is signed once. Each SOW then hangs off it and covers one project. One MSA can carry a dozen SOWs over several years.

A proposal is a sales document. It describes what the supplier hopes to do and why you should pick them. It is not usually binding, and it often gets reused as the first draft of the SOW, which is where trouble starts, because marketing language ends up in a contract.

A purchase order is a payment authorisation. It names a price and a quantity, rarely a scope. Relying on a purchase order alone for a services project leaves the work undefined.

For a one-off job, a single combined agreement with the SOW as a schedule can be perfectly fine. The split between MSA and SOW earns its keep when you will buy from the same supplier repeatedly.

Which clause wins when the MSA and the SOW disagree?

This is the question most people skip, and it is the one that costs money.

Most carefully drafted agreements follow a simple pattern. The MSA controls the legal terms. The SOW controls scope, schedule and fees. An order of precedence clause says so in one or two sentences, and it names which document prevails if they conflict.

Without that clause, you rely on how a court reads the documents together. Under English law, for example, contract documents are generally read as one agreement, so an inconsistency does not cancel itself out. It creates an argument, and arguments are billable.

Here is the kind of wording to look for, written as a drafting example rather than advice for your jurisdiction:

§ In the event of conflict, the terms of the MSA prevail over the SOW, except that the SOW prevails as to scope, deliverables, schedule and fees for the project it describes.

Watch for one trap. A SOW that quietly overrides the liability cap or the IP ownership clause "for this project only" is legitimate when both sides intend it. It is a problem when nobody noticed it. Whoever signs the SOW should read it as a contract, not as a project plan.

What makes scope language hold up under pressure?

Scope is where SOWs fail. A vague scope is not neutral: it favours whoever is more willing to argue later. In practice, that is usually the party with more leverage.

Three habits make scope hold up.

First, write exclusions. A list of what is out of scope is often more useful than the list of what is in scope. "Does not include integration with the customer's legacy billing system" settles a conversation that would otherwise take three meetings.

Second, tie deliverables to nouns, not adjectives. "A responsive website" is arguable. "Eight templates, tested on the two latest versions of four named browsers" is checkable.

Third, state assumptions. If the timeline depends on the customer returning feedback within five business days, say so, and say what happens to the schedule if they do not. Delay claims are far easier when the dependency was written down.

Skip the temptation to copy a template and fill the blanks. A template shows you the headings. It cannot tell you which assumptions are specific to your project.

How should acceptance and change requests be written?

Acceptance criteria answer one question: when is a deliverable finished enough to pay for? "High quality" and "to the customer's satisfaction" do not answer it. A testable criterion does. For a data migration, for instance, it could be "all records transferred and a reconciliation report shows no unexplained differences".

Add a deemed-acceptance mechanism. A common pattern is that a deliverable counts as accepted if the customer does not send written deficiencies within a set window, often around ten business days. Without it, a customer can stall sign-off, and with it the final invoice, indefinitely. If you are the customer, push for a clear remedy period for the supplier to fix what you reported, so the clock is fair on both sides.

Change requests deserve the same care. Scope creep rarely arrives as one large request. It arrives as ten small ones that each seem reasonable. A one-paragraph change process fixes this: any change to scope, price or dates needs a written change order signed by both sides before work begins. Many suppliers lose margin on projects simply because the SOW allowed verbal agreement.

Fixed price or time and materials: which fits a SOW?

The pricing section changes how risk is shared, so it is worth choosing deliberately.

A fixed price puts delivery risk on the supplier. It works when the scope is well understood and unlikely to move. It works badly when the scope is fuzzy, because the supplier will price in a cushion or fight every change.

Time and materials puts effort risk on the customer. It suits exploratory work, but it needs a cap or a not-to-exceed figure, otherwise the budget is an opinion.

A hybrid, with a fixed price per milestone, is often the most honest compromise. Each milestone has its own deliverable, acceptance test and invoice, which makes the SOW easy to audit and easy to stop if the project goes wrong.

Where do people go wrong when they sign one?

After reading a lot of these documents, the same failures come back.

• Signing the SOW before the MSA exists, so the project runs on no liability or IP terms at all.

• Leaving dates as "approximately" with no consequence for missing them.

• Describing deliverables by activity ("provide support") rather than by output ("respond to priority tickets within four business hours").

• Forgetting data protection when the supplier will handle personal data. In the EU and UK, that usually means a data processing agreement alongside the SOW, and the right details depend on the jurisdictions involved.

• Never updating the SOW after a verbal change, then relying on memory a year later.

This is not a theoretical risk: it is what lawyers see regularly. None of these requires legal genius to avoid. They require someone to read the document slowly before signing.

Which tools help you draft, sign and review a SOW?

Tooling will not write a good scope for you, but it can remove the repetitive work around it.

For drafting from reusable blocks, with approvals and e-signature in one flow, a document platform is practical.

For signature alone, with audit trail and widespread acceptance among counterparties, a dedicated e-signature service is enough.

For teams that handle many SOWs a year and need them tied to an MSA, a contract lifecycle platform keeps the link between master terms and each project document.

For a first pass on clause risk inside Word, an AI review add-in can flag missing exclusions or a conflicting liability clause before a human reads it.

None of these replaces a lawyer when the stakes are high. Use the software to catch the routine problems, then take anything unusual, large or cross-border to your counsel.

What to do before you sign your next SOW

Three actions cover most of the risk.

1. Check that an MSA exists and that the SOW states which document prevails on legal terms versus scope and fees.

2. Rewrite every deliverable so that a stranger could tell, yes or no, whether it was delivered, and add exclusions and assumptions.

3. Confirm the acceptance window, the remedy period and the written change-order rule, then keep every amendment attached to the SOW itself.

If the project is large, involves personal data or crosses borders, have your counsel read it. The answer will depend on the governing law, and a short review costs far less than a dispute.