The short version
- The MSA carries the terms that survive every project: liability, IP, confidentiality, payment mechanics, insurance, termination, governing law. The SOW carries scope, deliverables, milestones, rates, named people and acceptance criteria.
- A statement of work is contract, not a project brief. Whatever it says is enforceable, including the parts drafted by someone who has never opened the MSA.
- The order of precedence clause decides conflicts. The workable default is that the MSA prevails except where an SOW expressly names the clause it is overriding.
- State whether SOWs already running survive expiry of the MSA. If the agreement is silent, that silence is the dispute.
The split, and why it exists
The point of a two-document structure is to negotiate the hard terms once. Liability caps, indemnities, IP ownership, confidentiality, insurance, invoicing and dispute resolution take weeks and involve lawyers on both sides. Scope changes every quarter. Putting the first set in a master services agreement and the second in a statement of work means the second project starts in days rather than restarting the first negotiation.
| Belongs in the MSA | Belongs in the SOW | The one people put in the wrong place |
|---|---|---|
| Limitation of liability and indemnities | Deliverables and specifications | Acceptance criteria — MSA sets the process, SOW sets the criteria |
| IP ownership and licence-back | Milestones and dates | Named key personnel — a commitment, so it belongs in the SOW with a replacement mechanic |
| Confidentiality and data protection | Rates, fee model and invoicing schedule | Payment triggers — the MSA sets terms, the SOW sets what triggers an invoice |
| Insurance, warranties, termination rights | Assumptions, dependencies and exclusions | Service levels, which belong wherever they are actually measured |
| Governing law and dispute resolution | Acceptance criteria and test approach | Change control — process in the MSA, the change itself in a signed change order |
The SOW is a contract, and it is usually written by people who do not know that
This is the failure mode worth naming. The MSA goes through legal review on both sides. The SOW is drafted by a delivery lead or an account manager working from a template, in the same week they are trying to win the work. It then gets signed, sometimes by someone whose authority to bind the company on legal terms was never checked.
What arrives in the document is language nobody intended as a legal position. A sentence promising the platform will "meet the client's business requirements" is a fitness-for-purpose warranty, and it may be wider than the express warranty the MSA spent three rounds narrowing. A line saying the client "will own all materials produced" can conflict with a carefully drafted background-IP carve-out. A payment schedule tied to "client sign-off" can override an MSA deemed-acceptance mechanism that existed precisely so sign-off could not be withheld indefinitely.
The MSA and the SOW disagree. What happens?
The SOW and the MSA say different things about the same subject
The MSA contains a precedence clause
The MSA governs, unless the SOW expressly names the clause it is amending and was signed by someone with authority to amend it.
Neither document says anything
The usual arguments favour the SOW: it is the more specific term and the later document. Which means a project manager just changed your liability position.
Writing a precedence clause that works
A precedence clause ranks the documents and says what happens on conflict. The version that survives contact with reality has three parts.
Four parts, and a ranking on its own is only the first
The precedence clause
App development agreement
Full text, free to read and copy — scope and deliverables, milestones and acceptance, change control, IP assignment, warranty and termination, written to work either as a standalone contract or as the master terms behind a series of statements of work.
Signature, authority and the purchase order problem
Every SOW needs to be signed, and it needs to identify its parent: "This Statement of Work is entered into under and governed by the Master Services Agreement dated [date] between the parties." Without that sentence the SOW is arguably a standalone contract with no liability cap, no IP clause and no indemnity — which is a considerably worse position than the one you negotiated.
- Set a signature threshold. SOWs below a stated value may be signed by named operational roles; above it, the same signatories as the MSA. Write the threshold into the MSA rather than leaving it to habit.
- Deal with purchase orders explicitly. Procurement systems attach standard terms to every PO. State that PO terms have no effect and that a PO operates only as an administrative instrument, or the two of you have a live argument about whose boilerplate applies.
- Watch the counterparty entity. A group company signing an SOW under a parent's MSA needs a joinder or an express extension clause, otherwise the SOW is with an entity that has agreed to nothing.
- Number and date every version. "SOW 4, version 2, dated 3 March" beats "the latest one Priya sent" when the argument is about which scope was agreed.
Change control: the informal email is the problem
Scope changes constantly, and the mechanism for changing it is the clause most often ignored by both sides. A client asks for something in a stand-up. The team builds it. Nobody prices it, and three months later the supplier invoices for it or absorbs it, and either outcome damages the relationship.
A change control clause that people actually use is short: any change to scope, price or date takes effect only when recorded in a change order referencing the SOW and signed by both parties; work outside the SOW is not chargeable and not required until then. Add a lightweight route for small changes — a named approver on each side, an email confirmation, a value ceiling — because a process too heavy for a two-hour change is a process that gets bypassed.
Term, expiry, and the SOWs still running
MSAs usually run for a fixed period and renew. SOWs run for the length of the project. The two calendars do not line up, and the agreement has to say what happens when the MSA reaches its end date with work in flight.
- Say that live SOWs survive, and that the MSA terms continue to apply to them until they complete. This is the conventional and usually correct answer.
- Distinguish expiry from termination for cause. Expiry with work in flight should let the work finish. Termination for a material breach normally should not.
- Set the consequences of terminating a single SOW: payment for work performed to the date of termination, delivery of work in progress, and whether the IP in incomplete deliverables transfers.
- Keep survival explicit. Confidentiality, IP assignment, payment obligations and limitation of liability should survive both documents, and the survival clause should say so by clause number.
When a two-document structure is the wrong answer
For a single project with one deliverable and no expectation of repeat work, an MSA plus SOW is overhead. You are maintaining two documents, a precedence clause and an incorporation clause in order to solve a problem — repeat negotiation — that you do not have. One agreement with the scope in a schedule is shorter, easier to read and has no precedence question at all.
The structure earns its keep from the second engagement onwards, and it earns it decisively by the fifth. That is also the point at which the discipline stops being optional: five SOWs written by four different people under one MSA is exactly how the liability cap ends up meaning something different on each project.
What to check on the SOW in front of you
Before signing a statement of work
- It names the MSA by date and states that it is governed by it.
- It does not restate liability, IP, confidentiality or warranty terms in different words. If it restates them, delete the restatement rather than trying to align it.
- Deliverables are described specifically enough that both sides would agree whether one had been delivered.
- Acceptance has a test, a window and a consequence for silence.
- Assumptions and dependencies are listed, with the effect of a failed dependency stated — usually a schedule and cost adjustment through change control.
- Named personnel come with a replacement standard, not just a name.
- The fee model is unambiguous: fixed price, time and materials, or capped time and materials — and if capped, what happens at the cap.
- It is signed by someone whose authority extends to whatever it actually changes.
Reading it in that order takes ten minutes and catches most of what goes wrong. The general technique is the same one in how to read a contract: read for the money and the exits first, then for the mechanics. The difference with an SOW is that you are also reading for accidental legal drafting — sentences that were meant as reassurance and function as warranties. Those are almost always fixable before signature and almost never afterwards.
Sources
General information, not legal advice. This guide explains how these documents and rules generally work. Law varies by jurisdiction and changes, and none of it is applied to your circumstances here. For anything consequential, consult a licensed attorney where you are.
Frequently asked
What is the difference between an MSA and an SOW?
An MSA sets the terms that stay constant across every engagement: liability, indemnities, IP ownership, confidentiality, insurance, payment mechanics, termination and governing law. An SOW sets what is being delivered on one specific project — scope, milestones, acceptance criteria, rates and assumptions. The MSA is negotiated once; a new SOW is added for each piece of work.
Which prevails if the MSA and the SOW conflict?
Whichever the order of precedence clause says. Where there is no such clause, the arguments generally favour the SOW, because it is the more specific and the later document — meaning project-level drafting can displace negotiated legal terms. The standard fix is to state that the MSA prevails unless the SOW expressly identifies the clause it is varying.
Does a statement of work have to be signed?
Yes, in practice. An unsigned SOW invites an argument about which version of scope was agreed, and a signed one that fails to reference the MSA invites the opposite argument — that it is a standalone contract without the MSA's liability cap, IP terms or indemnities. Sign it, date it, version it, and name the parent agreement in the first paragraph.
What happens to open SOWs if the MSA expires?
It depends on what the MSA says, and many are silent, which is where disputes start. The usual and sensible drafting is that statements of work already in progress survive expiry and continue to be governed by the MSA terms until they complete, while termination for material breach ends everything. Say which applies rather than leaving it to interpretation.
Can a purchase order override the MSA?
It should not, but procurement systems attach standard terms to purchase orders automatically and those terms sometimes claim to prevail. The clean answer is a clause in the MSA stating that purchase orders serve an administrative function only and that any terms printed on or referenced by them have no effect, however the order is issued or acknowledged.