Sign a large vendor deal and you get two documents instead of one, and wonder why the lawyers could not combine them. They are separate on purpose. Keep the split right and you can start a new project in a day; get it wrong and every project reopens the liability cap.
The Master Service Agreement carries the legal and commercial terms of the relationship and is signed once; the Statement of Work sits under it and defines one project's scope, timeline and price.
The bottom line
In the MSA: liability, IP, confidentiality, payment terms, warranties, termination and dispute resolution. Negotiated once.
In each SOW: scope, deliverables, timeline, acceptance criteria and the fee for that project. Issued per engagement.
What makes it work: every SOW referencing the MSA, and a clear order-of-precedence clause saying which one wins in a conflict.
The Master Service Agreement
The foundational contract between two parties who expect to do business repeatedly. It fixes the terms that should stay constant across every project: payment and invoicing rules, intellectual property ownership, confidentiality, warranties, limitation of liability, indemnity, insurance, term and termination, and dispute resolution.
Once signed, those terms apply to everything that follows. You negotiate them once rather than every time.
The Statement of Work
A project-specific document executed under an existing MSA. It covers the operational detail: the scope of work and deliverables, the timeline and milestones, the acceptance criteria, the fees for that project, and any project-specific assumptions or dependencies.
Each new project gets its own, and inherits all the legal protections of the MSA without restating them.
How the two fit together
A hub and spokes. The MSA is the hub, signed once and carrying the legal terms. Each SOW is a spoke — a short document defining one project, referencing the MSA and incorporating its terms.
When a client wants a second or third project, nobody reopens liability and IP. You issue a new SOW.
The MSA usually states that its terms govern, and that in a conflict the MSA controls — or sometimes that the SOW controls on defined project specifics. Define that order of precedence explicitly, because the alternative is arguing about it during a dispute.
What goes where
| In the MSA (once) | In each SOW (per project) |
|---|---|
| Payment and invoicing rules | Specific project fees and schedule |
| IP ownership framework | Project deliverables and ownership specifics |
| Confidentiality | Project assumptions and dependencies |
| Liability cap and indemnity | Scope of work |
| Warranties and insurance | Timeline and milestones |
| Term and termination | Acceptance criteria |
| Dispute resolution and governing law | Project personnel/contacts |
Why bother separating them
Speed and consistency.
Negotiating an MSA is slow, because that is where the hard legal terms live. Once it is done, launching a project is fast — a short SOW signed in a day.
It also keeps the relationship consistent. The same liability cap, the same IP rules and the same dispute clause apply to every project, so nothing slips through while teams are moving quickly. For agencies, consultancies and software vendors with repeat clients, this structure is the efficient default rather than a formality.
A worked example
A software development firm signs an MSA with an enterprise client covering payment terms of net 30, IP where the client owns custom code on payment while the vendor keeps its own libraries, a liability cap, confidentiality and arbitration.
Over the next year the client commissions three projects — a mobile app, an analytics dashboard and an integration — each launched with a one-page SOW specifying that project's scope, milestones and price, all referencing the MSA.
Three projects, three quick documents, no renegotiation. When a dispute arises on the dashboard project, the MSA's liability cap and arbitration clause apply automatically, because the SOW pulled them in.
Common mistakes
- Putting project scope in the MSA, which makes it rigid and forces a renegotiation for the next project.
- Putting legal terms in the SOW, so they drift inconsistently from project to project.
- No order-of-precedence clause, which creates a conflict nobody can resolve cleanly.
- An SOW that never references the MSA, leaving it stranded without the legal terms.
- Vague scope in the SOW, which is the same trap as in any service agreement.
A working checklist
- Put the durable legal terms — liability, IP, confidentiality, disputes — in the MSA.
- Put project-specific scope, timeline and price in each SOW.
- Reference the MSA in every SOW and incorporate its terms expressly.
- Add a clear order-of-precedence clause.
- Keep the SOW scope specific, with acceptance criteria that can actually be tested.
- Sign the MSA once, and issue a fresh SOW per project.
Frequently asked questions
What is the difference between an MSA and an SOW? The MSA sets the legal and commercial terms of an ongoing relationship. The SOW defines a specific project's scope, timeline and price under it.
Do I sign a new MSA for every project? No. Sign it once, then issue a new SOW for each project, which inherits the MSA's terms.
Which document controls if they conflict? Whatever the order-of-precedence clause says. Commonly the MSA governs, with the SOW controlling on defined project specifics.
Can I just use one combined contract? For a one-off engagement, yes. For repeat work the two-document structure is faster and more consistent.
What must an SOW include? Scope, deliverables, timeline and milestones, acceptance criteria and the project fee, while referencing the MSA.
The client wants to change scope mid-project. Do we need a new SOW? Usually a change order or an amended SOW, depending on the size of the change. Either way it belongs in writing under the same MSA.