The MSA and the SOW: Which Document Controls When They Conflict
Ongoing services relationships are commonly documented in two parts. A master services agreement sets the legal framework that governs the overall relationship, and one or more statements of work describe the specific work to be performed. The MSA is signed once and stays in place. Each new project or engagement gets its own SOW under the umbrella of the MSA.
The structure is efficient. The parties negotiate the legal terms once in the MSA, then add work through SOWs without renegotiating the whole agreement each time. That efficiency is also where the structure goes wrong. The division of terms between the two documents determines which terms govern, and when the same subject is addressed inconsistently in both, the question of which document controls can decide the outcome of a dispute. The two-document structure looks administrative, but the terms governing how the documents interact determine whether the relationship is clearly defined or quietly ambiguous.
Getting the structure right means understanding what belongs in each document and what happens when they conflict.
What Belongs in Each Document
The MSA holds the legal terms and recurring commercial terms that apply across the relationship, regardless of the particular project. These are the terms the parties want to negotiate once and apply to all work: payment terms, intellectual property ownership, confidentiality, limitation of liability, indemnification, warranties, insurance, term and termination, dispute resolution, and governing law. These provisions are stable across projects and do not need to change from one SOW to the next.
The SOW holds the project-specific terms: the description of the services, the deliverables, the timeline and milestones, the acceptance criteria, the fees for the specific engagement, and any staffing or resource commitments particular to that project. The SOW answers what is being done, by when, and for how much, within the legal framework the MSA already established.
The division is not always clean in practice. Some terms sit at the boundary. Payment timing might be set in the MSA but the specific fee in the SOW. Intellectual property ownership might be a general rule in the MSA with project-specific exceptions in a particular SOW. The boundary cases are where the drafting has to be deliberate, because a term that appears in both documents, addressed differently, is the source of the conflict problem discussed below.
As a working principle, terms that should be consistent across all projects belong in the MSA, and terms that are specific to a project belong in its SOW. When a project genuinely needs a different legal term than the MSA provides, that difference should be stated explicitly as a modification of the MSA for that SOW, rather than simply written into the SOW as though the MSA did not address it.
The Conflict Problem
The central risk in the MSA and SOW structure is that the two documents address the same subject inconsistently. The MSA caps liability at one amount, and the SOW states a different one. The MSA assigns intellectual property to the customer, and the SOW says the provider retains certain rights. The MSA sets net thirty payment terms, and the SOW says net forty-five. When that happens, the parties need to know which document controls, and the answer depends entirely on what the documents say about that question.
A well-drafted MSA includes an order of precedence provision that states, expressly, which document governs in the event of a conflict. The provision resolves the ambiguity before it arises. Without it, a conflict between the MSA and the SOW becomes a question of contract interpretation, argued after the dispute has already developed, with each party pointing to the document that favors its position.
There is no single correct answer to which document should control. Two approaches are common, and they point in opposite directions. The first provides that the MSA controls over any conflicting SOW term, which protects the negotiated legal framework from being undercut by a SOW that a project team drafted without legal review. The second provides that the SOW controls over the MSA, on the theory that the SOW is the more specific and more recent document and reflects what the parties actually intended for that project. Each approach has a rationale, and the right choice depends on how the parties actually operate.
The cleanest practical structure is usually a middle position: the MSA controls unless the SOW expressly identifies the MSA provision being modified and states that the modification will apply to that engagement. That default protects the negotiated framework while still allowing a project to depart from it, but only when the departure is deliberate, identified, and approved rather than introduced unintentionally. It reinforces the principle that a deviation from the legal terms should be a conscious act rather than an accident of drafting.
Another approach separates the two categories of term. The MSA controls on the core legal terms, such as liability, indemnification, and intellectual property, so that a SOW cannot inadvertently rewrite the risk allocation the parties negotiated. The SOW controls on the project-specific terms it is meant to define, such as scope, deliverables, and fees. That split preserves the legal framework while letting each SOW govern the work it describes. The categories should be defined expressly rather than left to a later argument over whether a term is legal or project-specific. Fees may be project-specific while payment conditions are recurring, and intellectual property provisions can have elements of both.
The hierarchy should also address the other documents that enter the relationship. Purchase orders, proposals, estimates, exhibits, and online policies can all contain inconsistent language. A complete precedence clause should identify where those documents sit in the hierarchy and, in many cases, state that purchase-order boilerplate has no effect. The conflict is often not limited to the MSA and the SOW, and a precedence provision that addresses only those two leaves the other documents to create ambiguity of their own.
When the SOW Starts Rewriting the MSA
A recurring problem is that legal and commercial terms end up in the SOW that should have been governed by the MSA. This usually happens because the SOW is drafted by the people running the project, not by the people who negotiated the MSA. A project team focused on scope and deliverables adds a payment term, a liability provision, or an intellectual property statement to the SOW without checking it against the MSA.
This creates two problems. The first is the conflict problem already described. A liability term in the SOW that differs from the MSA sets up a dispute about which controls. The second is more subtle. Even where the order of precedence resolves the conflict cleanly, the presence of the stray term signals that the parties may have intended something different for this project, which can muddy the interpretation of what they agreed to. A SOW that reads as though it is establishing its own legal terms invites argument about whether it was meant to displace the MSA, even when a precedence provision says it does not.
The discipline that avoids this is to keep the SOW focused on the work and to route any change to the legal terms through a deliberate amendment process. If a project genuinely requires a different liability cap or a different intellectual property arrangement, that change should be documented as an express modification of the MSA, identified as such, and reviewed by whoever is responsible for the legal terms. Before a SOW is signed, someone should confirm that it does not contain legal or commercial terms that conflict with the MSA, and that any intended deviation is flagged and documented rather than slipped in. A one-line deviation buried in a SOW is easy to miss and hard to defend as an intended change to the negotiated framework.
The SOW is where the work is defined, and keeping the legal terms out of it, except by deliberate amendment, is what keeps the structure clean.
Scope and Change Orders
Scope and change-order terms also need a clear home. The MSA may establish the change-control process across the relationship, while each SOW defines the initial scope and any project-specific approval requirements. This is where services relationships most often break down. A SOW that describes the deliverables vaguely, or that does not clearly separate what is included from what is not, leaves both parties exposed to a dispute about whether a given task was within the agreed scope or an extra the provider should be paid for.
A well-drafted SOW is specific about deliverables and, where it matters, explicit about exclusions. Stating what the engagement does not include is often as valuable as stating what it does, because the disputes tend to arise at the boundary. The acceptance criteria matter for the same reason. A SOW that defines how a deliverable is judged complete, and what happens if it is not accepted, gives both parties a clear standard rather than a later argument about whether the work was adequate.
The change order mechanism is the other half of scope discipline. Services engagements evolve, and work that was not in the original SOW gets requested as the project proceeds. Without a defined process for handling changes, that additional work becomes a source of friction: the provider believes it is out of scope and billable, the customer believes it was always included. A change order provision, whether in the MSA or the SOW, establishes how scope changes are proposed, priced, and approved, so that additional work is documented and agreed rather than assumed.
Define the scope specifically, state the exclusions where the boundary is unclear, set acceptance criteria, and provide a change order process for the work that was not anticipated. These are the terms that determine whether a scope disagreement is resolved by reference to the document or by negotiation after the relationship has already soured.
The Takeaway
The MSA and SOW structure works well when the division of terms is deliberate. The MSA carries the legal framework that applies across the relationship, each SOW defines a specific project within that framework, and a precedence provision resolves conflicts before they arise, ideally by providing that the MSA controls unless a SOW expressly and deliberately overrides it. Handled that way, the structure lets the parties add work without renegotiating the whole agreement each time.
The structure breaks down when the division is careless. A SOW that drifts into legal terms, an MSA and SOW that address the same subject inconsistently, and the absence of a precedence provision to sort it out all convert an efficient structure into a source of ambiguity. The two-document structure looks administrative, but the discipline that keeps it clean is straightforward: legal terms stay out of the SOW except through an express amendment.
This post is general information only and does not constitute legal advice. For questions about a particular agreement, contact Cruxterra Law Group.
