A master service agreement (MSA) establishes the standing legal and commercial rules for an ongoing services relationship. A statement of work (SOW) defines the work for a specific project, including its scope, deliverables, schedule, price, responsibilities, and acceptance criteria. The MSA governs the relationship; each SOW activates a particular engagement within that framework.
If an MSA and SOW conflict, neither document automatically controls in every transaction. The answer depends primarily on the contract's order-of-precedence language and any clause allowing an SOW to override identified MSA provisions. Without clear language, the parties may have to rely on the agreement as a whole, the governing law, and fact-specific rules of contract interpretation.
MSA vs SOW in brief: Use the MSA for terms intended to remain consistent across projects. Use an SOW for project-specific commitments. Connect the documents expressly, identify which document controls a conflict, and require any permitted override to name the MSA section it changes.
This article provides general educational information, not legal advice. Contract interpretation depends on the wording, transaction, governing law, and surrounding facts. Consult qualified legal counsel about a specific agreement.
What Is an MSA?
An MSA is the reusable framework for a continuing services relationship. It resolves the legal and commercial issues that the parties do not want to renegotiate every time they begin a new project.
An MSA commonly addresses:
-Payment mechanics and invoice disputes
-Confidentiality
-Intellectual property ownership and licences
-Data protection and security
-Warranties and disclaimers
-Indemnification
-Limitation of liability
-Insurance
-Term, suspension, and termination
-Governing law and dispute resolution
-How SOWs are created, changed, and prioritized
The MSA may not commit either party to purchase or perform any minimum amount of work. Instead, it creates the rules that will apply when the parties sign an SOW, order form, work order, or similar project document.
For a fuller explanation of the document and its core provisions, read What Is a Master Service Agreement (MSA)? 8 Key Clauses.
What Is an SOW?
An SOW is the project-level document. It translates a commercial objective into concrete obligations that the parties can perform, measure, invoice, accept, and—if necessary—enforce.
-A well-drafted SOW typically identifies:
-The services and deliverables
-Work that is expressly out of scope-
-Milestones and deadlines
-Each party's responsibilities and dependencies
-Staffing or subcontracting requirements
-Fees, rates, expenses, and payment milestones
-Acceptance criteria and testing procedures
-Service levels or performance measures
-Assumptions
-Change-control procedures
-Project-specific security, data, or compliance requirements
-The SOW term and completion or termination rules
An SOW should be detailed enough for an independent reader to understand what must happen, who must do it, when it is due, how success will be determined, and what it will cost.
The current U.S. Federal Acquisition Regulation offers a useful drafting benchmark for government schedule orders: FAR 8.405-2 says an SOW should include the work description, work location, period of performance, deliverable schedule, applicable performance standards, and special requirements. That rule governs the federal procurement context—not ordinary private MSAs—but its focus on operational specificity is useful for commercial drafting as well. See FAR 8.405-2 on Acquisition.gov.
MSA vs SOW: Key Differences at a Glance
MSA vs SOW Comparison
Compare how an MSA and SOW differ in purpose, scope, duration, detail, and contractual priority.
| Issue | MSA | SOW |
|---|---|---|
| Primary purpose | Establishes the rules for the overall relationship | Defines one project or workstream |
| Scope | Broad and reusable | Narrow and project-specific |
| Typical content | IP, confidentiality, risk, liability, indemnities, payment rules, termination, disputes | Deliverables, milestones, price, responsibilities, acceptance, change control |
| Duration | Often covers multiple projects over a longer term | Usually lasts until the project is completed or terminated |
| Frequency | Usually negotiated once per relationship | Usually signed for each project or material phase |
| Commercial commitment | May create no minimum work commitment | Commonly authorizes actual work and spending |
| Level of detail | Relationship-level principles and procedures | Operational instructions and measurable outcomes |
| Changes | Usually requires a formal amendment signed by authorized representatives | May be changed through an SOW amendment or agreed change order |
| Relationship to other documents | Acts as the parent framework | Incorporates and operates under the MSA |
| Conflict treatment | Often controls general legal terms | May control specified project terms if the MSA expressly permits it |
The simplest distinction is this: the MSA explains how the parties will do business; the SOW explains what they will do in a particular project.
How Do an MSA and SOW Work Together?
The MSA and SOW form a layered contract structure. The MSA supplies the reusable legal framework, while each SOW adds the scope and economics for a specific engagement.
1. The parties negotiate and sign the MSA.
2. They identify a specific project.
3. They prepare an SOW that references the MSA by date and party names.
4. Authorized representatives sign the SOW.
5. The provider performs the work under both documents.
6. The parties use the agreed change-control process if the project changes.
7. The SOW ends when the project is completed or terminated, while the MSA may continue for future work.
This structure creates efficiency only when the boundary between the documents is respected. If every SOW repeats or casually rewrites the MSA's legal provisions, the parties lose the consistency they created the MSA to provide. If the MSA tries to contain every future project's operational detail, it becomes rigid and quickly outdated.
One MSA Can Govern Multiple SOWs
The parties may have several SOWs active at the same time. For example, one SOW could cover software implementation, another managed support, and a third a data-migration project. Each can have its own deliverables, team, price, and schedule while sharing the same confidentiality, IP, liability, dispute, and governance framework.
Each SOW should be treated as a separate contractual commitment. Do not assume that a change to one SOW changes another, or that terminating one project automatically ends the MSA or every active SOW.
The SOW Must Be Properly Incorporated
An SOW should identify the MSA it belongs to and state that it is entered into under and governed by that MSA. Incorporation by reference is the drafting mechanism that makes provisions in one document part of another. Cornell Law School's Legal Information Institute explains that an incorporated document must be identified clearly; see its overview of incorporation by reference.
At a minimum, the SOW should identify:
-The full legal names of the parties
-The MSA's effective date
-The SOW number or other unique identifier
-The SOW effective date
-Any documents incorporated into the SOW
-The authorized signers
Avoid references such as "the current MSA" when the parties have amended, replaced, or signed more than one agreement.
Which Agreement Controls: the MSA or SOW?
The agreement that controls is the one selected by the parties' order-of-precedence clause, subject to any express override and the governing law. An MSA does not prevail merely because it is called a "master" agreement, and an SOW does not necessarily prevail merely because it is more specific or signed later.
The review should proceed in the following order.
1. Read the Order-of-Precedence Clause
The order-of-precedence clause should say what happens when two contract documents cannot be reconciled. It may provide that:
-The MSA always controls
-The SOW controls for project-specific matters
-The SOW controls only when it expressly identifies an MSA section and states an intention to override it
-A negotiated amendment controls both documents
-A data processing agreement, security schedule, or other specialized document controls within its defined subject matter
There is no universal hierarchy that fits every deal. The parties must draft the hierarchy they intend.
Current government contracts demonstrate why the hierarchy should be explicit. The 2026 Federal Acquisition Regulation includes a formal order for resolving inconsistencies among parts of a federal contract in FAR 52.215-8. The UK government's Mid-Tier Contract guidance, updated in April 2026, likewise identifies circumstances in which special terms take precedence over core terms. These public-procurement rules do not determine priority in a private MSA, but they illustrate the same drafting principle: hierarchy should be stated, not assumed.
2. Determine Whether the SOW Contains an Express Override
An SOW may need to depart from the MSA for a legitimate project reason. A higher-risk project may require a separate liability cap. A regulated engagement may require stricter security obligations. A customer-funded development project may require different ownership terms.
A safe override is narrow and unmistakable. It should identify:
- The exact MSA section being changed
- The replacement or additional rule
- Whether the change applies only to that SOW
- Whether the rest of the MSA remains unchanged
A vague sentence saying "the SOW controls in the event of conflict" can unintentionally permit operational language to alter core risk provisions. At the other extreme, a rule that the MSA always controls can nullify a carefully negotiated project exception.
3. Try to Reconcile the Documents
Not every difference is a conflict. A general MSA payment provision and a more detailed SOW milestone schedule may work together. One may state that invoices are payable within 30 days, while the other states when milestone invoices may be issued.
A true conflict exists when the parties cannot comply with both provisions or when one document produces a result incompatible with the other. Before invoking priority, read the provisions together and determine whether one adds detail rather than contradicting the other.
4. Check Amendments, Change Orders, and Later Documents
The contract stack may include amendments, addenda, order forms, DPAs, security schedules, service-level agreements, online policies, purchase orders, and change orders. Any of them may contain separate priority language.
Do not assume that the most recently signed document automatically governs. A later SOW may be subject to an MSA provision stating that no SOW can amend the MSA unless it uses specified language and is signed by designated representatives. Conversely, a signed amendment may expressly change the hierarchy for all existing and future SOWs.
5. Apply the Governing Law and the Entire Agreement
When the documents do not answer the question clearly, interpretation becomes jurisdiction- and fact-specific. Courts may consider the contract as a whole, the relationship between general and specific language, the sequence of the documents, defined terms, negotiated provisions, and other interpretive principles recognized by the governing law.
That uncertainty is precisely what an effective order-of-precedence clause should prevent. The drafting goal is not to predict which interpretive doctrine might win in litigation; it is to make litigation over document priority unnecessary.
Three Common MSA–SOW Conflict Examples
Payment Terms
The MSA says invoices are due 30 days after receipt. The SOW says the final 20% is payable only after acceptance.
These provisions may be reconciled: the final invoice becomes eligible for issuance after acceptance and is payable 30 days after receipt. But if the SOW says all invoices are due within 10 days, the documents contain competing deadlines. The priority clause should resolve the inconsistency.
Intellectual Property
The MSA says the provider retains ownership of its background technology and grants the customer a licence to embedded components. The SOW says the customer owns "all work product."
Without careful definitions, the SOW could be read to transfer reusable provider tools that the MSA intended to protect. The SOW should distinguish newly created deliverables from background IP and expressly state whether it changes the MSA's ownership allocation.
Limitation of Liability
The MSA caps liability at fees paid under the affected SOW during the prior 12 months. A high-risk SOW states that the provider's liability is capped at two times the SOW fees.
If project-specific caps are permitted, the SOW should identify the MSA's limitation-of-liability section and state that the replacement cap applies solely to claims arising from that SOW. It should also address whether the MSA's exclusions, carve-outs, and damages waiver remain unchanged.
How to Draft a Clear Order-of-Precedence Clause
A workable clause should do more than announce that one document "wins." It should define the contract stack, distinguish additions from conflicts, control how exceptions are made, and prevent low-level documents from rewriting negotiated terms accidentally.
Consider these drafting principles:
1.List every relevant document. Include the MSA, amendments, SOWs, order forms, DPAs, security schedules, SLAs, policies, exhibits, and change orders where applicable.
2.Define a conflict. Clarify that priority applies only when provisions cannot reasonably be read together.
3.Choose a default hierarchy. State which document controls a genuine inconsistency.
4.Permit targeted exceptions. Require an SOW to identify the MSA section it overrides and say that the exception applies only to that SOW.
5.Protect negotiated legal terms. Consider requiring legal or specifically authorized approval for changes to IP, indemnity, liability, confidentiality, data, governing law, and dispute provisions.
6.Exclude purchase-order boilerplate. State whether terms printed on a purchase order, vendor portal, invoice, or click-through form have any effect.
7.Address specialized schedules. A DPA or security schedule may need to control within privacy or security matters without displacing the MSA for unrelated issues.
8.Align amendment rules. Ensure the amendment, waiver, and signature clauses use the same standard as the hierarchy clause.
Illustrative Clause Structure
The following is a drafting illustration, not language for automatic use:
If a conflict exists between this MSA and an SOW, this MSA controls unless the SOW expressly identifies the section of this MSA to be modified and states that the identified provision is modified solely for that SOW. Additional or more detailed terms in an SOW do not create a conflict if they can reasonably operate together with this MSA.
The appropriate hierarchy may be different for your transaction. For example, the parties may want an SOW's project scope and pricing to control while reserving the MSA's liability and IP provisions from modification. Counsel should tailor the clause to the contract stack, governing law, and approval process.
Should You Sign the MSA or SOW First?
The MSA is usually signed first because it supplies the framework that the SOW incorporates. The SOW can then authorize work without reopening the relationship-level terms.
In practice, parties often negotiate both documents in parallel. If the project must begin quickly, they may sign them on the same day. What matters is that:
-Both documents identify the same legal entities
-The SOW identifies the correct MSA
-Neither document becomes effective on an impossible or ambiguous timeline
-Work does not begin before the required approvals and signatures
-The precedence and amendment rules are consistent
Starting work under an unsigned SOW can create disputes over scope, price, acceptance, and whether the MSA applies at all.
Can You Use an SOW Without an MSA?
Yes, an SOW can operate without an MSA if it contains or incorporates all terms required to form and govern the agreement. That approach may be practical for a small, one-time, low-risk project.
However, a standalone SOW must address more than scope and price. It may also need confidentiality, IP, warranties, liability, termination, disputes, governing law, data protection, and other legal terms that would otherwise sit in the MSA.
For recurring or material work, separating the stable framework from project details usually makes later engagements easier to launch and govern.
Can You Have an MSA Without an SOW?
Yes. Parties can sign an MSA before approving any project, but the MSA may create no obligation to buy, sell, or perform services until an SOW is executed. Whether the MSA creates independent obligations depends on its wording.
Some provisions—such as confidentiality, publicity restrictions, audit rights, or exclusivity—may apply immediately. Others may matter only after an SOW begins. Review the effective-date, minimum-commitment, ordering, and termination provisions rather than assuming the MSA is commercially inactive.
How to Review an MSA and SOW Together
Review the documents as one connected agreement, not as separate files. A clause-by-clause review of the MSA alone will miss the project terms that determine the actual economics and performance obligations.
Use this process:
1.Collect the full contract stack, including amendments, schedules, policies, and prior versions.
2.Confirm incorporation, party names, dates, and signatures.
3.Map the hierarchy and every permitted override.
4.Reconcile scope and obligations, including customer dependencies and assumptions.
5.Trace the money, from pricing and invoicing through expenses, taxes, disputes, and termination charges.
6.Test acceptance and change control, including deemed acceptance and unauthorized work.
7.Compare IP and data provisions across both documents.
8.Calculate the liability structure, including the cap basis, carve-outs, indemnities, and insurance.
9.Test termination, including the effect of ending the MSA on active SOWs and vice versa.
10.Review the clean execution copies and transfer obligations to operational owners.
For the complete process, see How to Review an MSA: A 9-Step Checklist.
Common MSA and SOW Mistakes
Assuming the MSA Automatically Controls
"Master" describes the document's function, not a universal legal priority rule. Read the actual hierarchy and override provisions.
Letting Every SOW Amend the MSA Informally
Broad SOW priority can allow project teams to change liability, IP, data, or indemnity terms without realizing it. Require explicit section references and appropriate approval.
Copying MSA Terms into the SOW
Duplicating legal provisions creates opportunities for small differences to become disputes. Keep stable terms in the MSA and project terms in the SOW unless an exception is intentional.
Using an SOW as a Vague Proposal
An SOW should create measurable obligations. Phrases such as “implementation support” or “industry-standard services” may be too vague without deliverables, boundaries, responsibilities, and acceptance criteria.
Ignoring Customer Dependencies
Projects often depend on access, data, decisions, approvals, or personnel supplied by the customer. State those dependencies and define the schedule and cost consequences of delay.
Allowing Purchase Orders to Introduce New Terms
A purchase order may contain boilerplate that conflicts with the negotiated agreement. The MSA should state whether the purchase order is administrative only and whether its additional terms are rejected.
Failing to Address Active SOWs at MSA Termination
If the MSA ends, do active SOWs terminate immediately, continue until completion, or become terminable by either party? The agreement should say which MSA provisions continue to govern any surviving SOW.
Losing Track of Versions
A correct priority clause cannot fix a missing amendment or an SOW linked to the wrong MSA. Maintain the executed contract family together and preserve the relationships among its documents.
How AI Can Help Compare an MSA and SOW
AI-assisted review can help identify definitions, extract obligations, compare clauses across files, locate inconsistent payment or IP terms, and surface an SOW provision that appears to modify the MSA. It can also help reviewers create a document hierarchy and prepare a first-pass issues list.
Alloomi can support this work by bringing the MSA, SOWs, amendments, and related materials into a connected review workflow. Instead of reviewing each document in isolation, a reviewer can trace a project term back to its governing language, compare versions, and investigate potential conflicts with the underlying source text in view.
AI should support—not replace—legal and commercial judgment. A human reviewer must verify the documents, understand the intended deal, apply the governing law and internal positions, and decide whether a difference is an actual conflict or a permissible project detail.
Frequently Asked Questions
Is an SOW Part of an MSA?
An SOW becomes part of the contractual arrangement when it is validly executed and incorporated under the MSA's requirements. The MSA should define how SOWs are formed, who may sign them, and which terms apply. Merely labelling a document "SOW" does not establish that it belongs to a particular MSA.
Does an SOW Override an MSA?
An SOW overrides an MSA only when the contract permits that result or applicable law produces it. The safest structure requires the SOW to identify the specific MSA section being changed and state that the change applies only to that SOW. A general inconsistency should be resolved under the agreed order of precedence.
Does an MSA Override an SOW?
An MSA commonly controls conflicts because many agreements say so, but that is a drafting choice rather than an automatic rule. Some contracts allow an SOW to control project-specific terms or identified exceptions. Read the hierarchy, amendment, and incorporation provisions together.
What Is the Difference Between a Statement of Work and a Scope of Work?
A scope of work describes the work boundaries, tasks, and deliverables. A statement of work is usually the larger project document that may contain the scope plus schedule, fees, responsibilities, acceptance, governance, and change control. Terminology varies, so the document's content and contractual status matter more than its title.
Can One SOW Cover Multiple Projects?
It can, but combining unrelated projects may make scope, pricing, acceptance, change control, and termination harder to administer. Separate SOWs often produce cleaner accountability and allow one project to change or end without affecting another.
What Happens to an SOW When the MSA Expires?
The answer depends on the survival and active-SOW provisions. The MSA may allow existing SOWs to continue under its terms until completion, or it may cause them to terminate with the MSA. The agreement should address this outcome expressly.
Is an Order Form the Same as an SOW?
Not always. An order form commonly records selected products, subscription quantities, pricing, and term, while an SOW usually describes services and deliverables in more detail. Either can operate as a project-level document under an MSA if the contract gives it that effect.
Final Takeaway
An MSA and SOW solve different contracting problems. The MSA establishes the durable rules for the relationship; the SOW converts a particular project into defined scope, schedule, price, responsibilities, and acceptance criteria. Used together, they let the parties launch new work without renegotiating the entire legal framework.
The title of the document does not decide which one controls. The decisive drafting work happens in the incorporation, amendment, and order-of-precedence provisions. State the default hierarchy, permit only deliberate exceptions, identify specialized documents, and review the entire contract stack before signature.
