Master Service Agreement vs SOW: How They Fit Together (2026)

A Master Service Agreement (MSA) and a Statement of Work (SOW) are two documents that work as a pair. The MSA sets the legal ground rules for an ongoing relationship between a customer and a supplier. The SOW describes a specific piece of work to be done under those rules. You sign the MSA once, then attach a new SOW each time there is a new project. Understanding which terms belong in which document, and how they interact, prevents the most common contracting disputes in services. ## What the MSA covers The MSA is the stable, long lived layer. It contains the terms that should not change from project to project. Typical MSA contents include: - Definitions and the structure of the relationship.

• Payment mechanics, invoicing, and late payment.
• Intellectual property ownership and licences.
• Confidentiality and data protection.
• Warranties and service standards.
• Limitation of liability and indemnities.
• Insurance.
• Term, termination, and what happens on exit.
• Governing law, dispute resolution, and boilerplate. Because the MSA is negotiated once and reused, both sides invest effort in getting it right. It is the risk allocation document. ## What the SOW covers The SOW is the project specific layer. It describes the actual work and the commercial detail for that engagement. Typical SOW contents include: - Scope of services and deliverables.
• Timeline, milestones, and acceptance criteria.
• Fees for this project, the pricing model (fixed price, time and materials, or milestone based), and the payment schedule.
• Named personnel or roles, and customer responsibilities and dependencies.
• Assumptions and anything expressly out of scope.
• Any project specific service levels. A new SOW is created for each project, so the relationship can run many SOWs under one MSA at the same time. ## How they fit together The MSA usually states that it governs all SOWs entered under it, and that each SOW incorporates the MSA terms by reference. So the SOW does not repeat the legal terms; it simply says the work described is subject to the MSA dated whenever between the parties. This keeps each SOW short and focused on scope and money, while the heavy legal terms live once in the MSA. This structure is efficient for three reasons. You negotiate the hard legal points only once. New projects start quickly because only the SOW needs agreement. And the terms stay consistent across every project, so you are not managing conflicting legal language in many separate contracts. ## The precedence question, which matters most The single most important term is the order of precedence: if the SOW and the MSA conflict, which one wins. There is no universal right answer, and that is exactly why it must be stated. Many MSAs say the MSA prevails, so that a project team cannot accidentally sign away carefully negotiated protections like liability caps in a quick SOW. Others say the SOW prevails for project specific commercial terms but the MSA prevails for the core legal terms, which is often the most sensible split. Whatever you choose, write it down. A missing or vague precedence clause is a frequent source of litigation, because each side later reads the conflict in its own favour. ## Which terms belong where A useful test: if a term should be the same for every project, it belongs in the MSA. If it changes with the project, it belongs in the SOW. Liability caps, IP ownership, and confidentiality belong in the MSA. Deliverables, timelines, and project fees belong in the SOW. Problems arise when a SOW quietly changes an MSA term, for example by adding an uncapped obligation or a different IP position. Either keep those changes out of the SOW, or make the change deliberate and have it approved by the people who own the MSA. ## Common mistakes to avoid - No precedence clause, so conflicts between the SOW and MSA are unresolved.
• SOWs that silently override MSA protections, such as liability caps or IP ownership, without the right approvals.
• Vague scope and no acceptance criteria in the SOW, which drives change requests and fee disputes.
• Signing work before the SOW is final, so the project runs on emails rather than an agreed scope.
• Forgetting to reference the correct MSA date, so it is unclear which terms apply.
• Letting SOWs drift from a template, creating inconsistent language across projects.
• Not addressing what happens to in progress SOWs if the MSA terminates. ## A short SOW skeleton > This Statement of Work is entered under, and subject to, the Master Service Agreement dated [date] between [Customer] and [Supplier]. Capitalised terms have the meaning given in the MSA.

1. Services and deliverables. 2. Timeline and milestones. 3. Acceptance criteria. 4. Fees and payment schedule. 5. Personnel and customer dependencies. 6. Assumptions and out of scope. 7. Project specific service levels, if any. 8. Precedence: in the event of conflict, [state which document prevails for which terms]. ## Jurisdiction note The MSA and SOW model is used worldwide, but the enforceability of specific terms (liability caps, IP assignment formalities, mandatory consumer or procurement rules) varies by jurisdiction, including between the US, UK, and India. This page is general information, not legal advice. Confirm specific terms for your jurisdiction with a qualified lawyer. ## Keeping the MSA and its SOWs connected The practical risk in the MSA and SOW model is losing the link: SOWs pile up, each referencing an MSA that lives in a different file, and nobody can quickly see every active SOW, its precedence terms, and its deadlines against the one master agreement. Drafting SOWs from a consistent template, reviewing each for terms that clash with the MSA, and tracking them all against the parent agreement in one AI workspace built on Claude keeps the stack coherent. Adira links each document to its agreement and tracks versions and dates, with transparent per-seat pricing. Learn more. The guidance above stands on its own. ## Bottom line An MSA sets the reusable legal ground rules; a SOW defines a specific project under those rules. Put stable legal terms in the MSA and project detail in the SOW, always state the order of precedence, and stop SOWs from quietly overriding the protections you negotiated once. Get the precedence clause right and most MSA and SOW disputes disappear.