What is a Statement of Work and why does it matter?

A Statement of Work (SOW) is the document that pins down the specific work to be done in one engagement under a broader services contract, usually a Master Services Agreement (MSA). If the MSA is the umbrella that governs the whole relationship, the SOW is the page that says what actually gets built, delivered and paid for this time. This article explains what a SOW is for, what it should contain, how it becomes legally binding, and the traps that follow when it is drafted badly.

We will cover the difference between an MSA and a SOW, the essential contents of a well-drafted SOW, how a SOW becomes part of the contract, a worked example of the stack in action, the common misconceptions that cause scope disputes, and when it is worth having a lawyer review the documents.

The MSA sets the rules; the SOW describes the work

A Master Services Agreement governs the whole relationship between the parties. It contains the machinery that does not change from project to project: how the provider gets paid, who owns the intellectual property in the work, how confidentiality operates, what happens on breach, how disputes are resolved, whether either party can terminate early, and where each party's liability is capped. Its whole point is that these heavy legal terms are negotiated once and then apply to every piece of work the parties do together.

A Statement of Work sits underneath the MSA and describes a particular engagement: what will be delivered, by when, for how much, and what counts as "done". It does not re-run the legal machinery. It records the operational detail that cannot live in the MSA, because that detail changes with every project. If the parties do ten projects together, the MSA applies ten times, and each project gets its own SOW (or, in many software subscription deals, an Order Form doing the same job).

The two documents are designed to work as a stack, and the design only works if each knows its role. An MSA might say the provider will perform services with due skill and care. The SOW is where the parties record whether that means migrating a data warehouse, configuring a SaaS platform, integrating a CRM or building a specific custom feature.

What a Statement of Work should contain

A well-drafted SOW gives both sides a shared, written answer to the questions that most often end up in dispute. The essential elements are:

• Scope of work: the specific tasks the provider will perform, stated precisely enough that a reasonable person can tell whether a task is in or out of scope.
• Deliverables: the tangible outputs of the engagement, such as a configured platform, migrated data, a report or a built feature.
• Milestones and timeline: the sequence of delivery and the dates or deadlines that attach to each stage.
• Acceptance criteria: what "done" means, how the client confirms the work is accepted, and what happens if the work does not meet the criteria, including any testing or review process.
• Assumptions and dependencies: the facts the price and timeline rely on, such as the client providing access, data, decisions or key personnel by agreed dates.
• Pricing and payment: the fee for the engagement and when it is payable, where this is not already dealt with in the MSA.
• Change control: the process for varying scope, price or timeline, and who is authorised to approve a variation.

The two elements most often missing are acceptance criteria and assumptions, and they are the two that decide most disputes. Acceptance criteria turn "we will build you a reporting module" into "the module will produce the seven reports listed in Attachment B, tested against the sample data set, and you will have 10 business days to review each deliverable". Assumptions turn a fixed price into a defensible price: if the client has not provided the data by the agreed date, the provider has a documented basis for extending the timeline or charging for the delay rather than absorbing it.

How a Statement of Work becomes part of the contract

A SOW is not automatically a contract on its own. It becomes binding when it is signed by both parties and incorporated into the framework agreement, usually through a clause in the MSA that says the MSA's terms apply to each SOW as if the two formed a single contract. That incorporation is what makes the legal machinery in the MSA, such as payment terms, IP ownership, confidentiality and the limitation of liability, apply to the work described in the SOW.

It is possible to use a SOW without an MSA, but only if the document carries every term needed to operate as a complete standalone agreement: liability, indemnities, IP ownership, confidentiality, privacy, suspension, termination and dispute resolution. Without those terms, the arrangement contains significant gaps and both parties are exposed. Australian courts are reluctant to strike down commercial contracts for uncertainty, a position the High Court confirmed in Upper Hunter County District Council v Australian Chilling & Freezing Co Ltd [1968] HCA 8, but a document that leaves essential terms to be agreed later, such as a price or scope expressed as "to be agreed", will generally not be enforceable: see Coal Cliff Collieries Pty Ltd v Sijehama Pty Ltd (1991) 24 NSWLR 1. A SOW that defers the details is not a contract; it is an intention to make one.

A Statement of Work in practice: an example

Take a Brisbane logistics business that engages a software provider to set up and customise a workflow automation platform. The parties sign an MSA that covers IP ownership in any custom work, a liability cap, confidentiality, subscription billing and termination rights. The first SOW describes the implementation project: configuring the platform's workflows, migrating the client's historical dispatch data, and integrating the platform with the client's accounting system. It sets out the acceptance criteria (the migration completes within two weeks and the integration passes joint testing) and the assumptions (the client provides clean data extracts and appoints a project contact by a set date).

Six months later a second SOW covers a custom reporting feature, and a third covers training for the client's staff. Mid-way through the second engagement, the client asks for a dashboard that shows the same data on screen, which was never in the second SOW's scope. Because the SOW defines the deliverables precisely, the parties can tell immediately that the dashboard is a variation, not an omission. The change control clause in the SOW requires a signed variation before extra work starts, so the provider quotes for the dashboard and invoices the additional work instead of absorbing it or arguing about it after delivery.

If the second SOW had instead said only that the provider would "improve reporting", none of this would be clear. The client would reasonably expect the dashboard, the provider would reasonably treat it as out of scope, and the dispute would land in the gap between what each party assumed. That gap is where projects overrun and relationships sour.

Common misconceptions about Statements of Work

Several misunderstandings recur when businesses first encounter SOWs:

• The MSA always overrides the SOW: Not necessarily. Most MSAs include an order of precedence clause that states which document wins if the terms conflict. The general rule is that the MSA governs the overarching legal and commercial matters while the SOW controls the specific details of the work, but some parties deliberately flip the position and give the SOW priority for project-specific issues, particularly where the SOW contains bespoke requirements that depart from the standard MSA. If neither document addresses the conflict, the parties face an ambiguity that only a court or a negotiated amendment can resolve.
• A SOW without an MSA works the same as one with it: It can, but only if all the necessary legal and commercial terms are attached or incorporated so the SOW stands alone as a complete contract. A bare SOW typically says nothing about liability, indemnities, IP ownership, confidentiality, suspension, termination or dispute resolution, and neither party can enforce what is not there.
• The SLA and the SOW are the same document: They sit at different layers. The SOW describes what will be delivered in a particular engagement, including scope, deliverables, timelines and acceptance criteria. The service level agreement (SLA) sets out how well the service must perform once it is live, such as uptime targets, response times and support expectations. One governs project delivery; the other governs ongoing service performance.
• An Order Form and a SOW are just different labels for the same thing: Sometimes the label is the only difference. Often the substance differs: an Order Form is a lighter-weight way to start standardised work, recording the product tier, subscription term, user numbers, pricing and billing arrangements, while a SOW suits project-based or customised work that needs detailed scoping, milestones and acceptance criteria.
• A vague SOW is fine because the MSA covers the legal stuff: The MSA cannot fix an underspecified scope. A provider that promises deliverables it cannot supply also takes on risk under the Competition and Consumer Act 2010 (Cth), because the Australian Consumer Law prohibits misleading or deceptive conduct in trade or commerce generally (s 18 of the ACL, which is Schedule 2 of that Act) and false or misleading representations about the standard or quality of services (s 29(1)(b)). Those provisions apply to business-to-business conduct, not just consumer sales. Where services are supplied to consumers, the ACL's consumer guarantees, including the guarantee that services be rendered with due care and skill (s 60), sit on top of whatever the contract says.

When you should get a lawyer to look at the Statement of Work

A commercial lawyer adds the most value at three points. First, when the framework is first put together: drafting or reviewing the MSA and its SOW schedule so the incorporation clause, order of precedence and change control all work together. Second, when a SOW is negotiated for a large or complex engagement, because that is when acceptance criteria, assumptions and milestones are actually tested against the commercial reality. Third, when the parties are trying to make a standalone SOW or Order Form do the work of a full agreement, because that is where the gaps are hardest to see.

On the client side, a lawyer checks that the SOW's deliverables match what the business was promised in the sales process, that acceptance criteria are achievable, and that assumptions do not quietly shift risk to the client. On the provider side, a lawyer checks that the SOW does not promise more than the team can deliver, that the limitation of liability in the MSA is not undermined by an open-ended acceptance testing obligation, and that every variation goes through a signed change control process. The cost of that review is small next to the cost of litigating a scope dispute, and it is often covered by a fixed fee for a document review.

The scope question to ask before you sign

Before you sign the next SOW, ask yourself one question: can you point to the sentence that defines "done"? If you cannot, the dispute is already priced into the deal. Every project overrun, every unpaid variation and every failed acceptance test can be traced back to a SOW that described the work in generalities instead of specifics. The documents are cheap to fix before signing and expensive to litigate afterwards, so treat the SOW as the definition of the deal, not as paperwork that accompanies it. If you cannot define "done" in writing, a lawyer should help you draft it before the work starts.