MSA vs SOW: What's the Difference?

A master services agreement (MSA) sets the standing legal terms for an ongoing business relationship — payment, liability, confidentiality, intellectual property, and how disputes get resolved. A statement of work (SOW) describes one specific project under that relationship: the deliverables, the timeline, and the price. You typically sign one MSA per client relationship, then add a new SOW each time you take on a new project.

If you sell services — software development, consulting, design, implementation, managed IT — you will run into both documents constantly. Mixing them up, or stuffing everything into one document, causes real problems: renegotiating legal terms on every project, conflicting terms between documents, and scope disputes with no clear answer. This post walks through what each document does, how they fit together, and the mistakes that show up most often.

What Is a Master Services Agreement?

A master services agreement is the framework contract. It covers the legal terms that stay the same no matter which project you are working on:

• How and when invoices get paid
• Who owns the intellectual property created during the work
• Confidentiality obligations on both sides
• Warranties and disclaimers
• Limitation of liability and indemnification
• How either side can end the relationship
• Governing law and how disputes get resolved

Think of the MSA as the rulebook. It does not say what work will be done — it says how the two companies will treat each other while work is being done. Because those rules rarely change from project to project, you negotiate them once and reuse them for every engagement that follows.

MSAs show up wherever one company provides ongoing services to another: development shops, consultants, agencies, managed service providers, and SaaS vendors. (In SaaS, the project-level document is usually called an order form rather than a SOW, but the layered structure works the same way.)

What Is a Statement of Work?

A statement of work is the project document. It plugs into the MSA and describes one specific engagement:

• What will be delivered, described specifically enough that both sides can tell when it is done
• The timeline, including any milestones
• The price and payment schedule for this project (fixed fee, hourly, or milestone-based)
• Who is responsible for what — including what the client must provide, like content, access, or approvals
• How the work will be reviewed and accepted
• How changes to the scope get requested, approved, and priced

A SOW is deliberately narrow. It should not repeat the legal terms already in the MSA — it should reference the MSA and stick to the details of this one project. Each new project gets its own SOW, and all of them sit under the same MSA.

How Do an MSA and SOW Work Together?

The two documents form a layered structure. The MSA sits on top and governs the whole relationship. Each SOW sits underneath it and incorporates the MSA's terms by reference — usually with a sentence like "This Statement of Work is entered into under, and governed by, the Master Services Agreement dated [date] between the parties."

Here is the difference at a glance:

The practical payoff comes on project two. Once the MSA is signed, starting new work only requires agreement on the SOW — scope, price, timeline. Legal review shrinks because the hard questions were already answered once.

What Should Be in an MSA?

At a minimum, a services MSA should cover:

• Order of precedence. Which document controls if the MSA and a SOW conflict. Most MSAs say the MSA wins unless a SOW expressly overrides a specific section.
• Payment terms. Invoicing schedule, payment deadlines, what happens when payment is late, and how expenses are handled.
• Intellectual property. Who owns the deliverables, what license each side receives, and whether the provider keeps rights to its pre-existing tools and know-how.
• Confidentiality. What information is protected, for how long, and the standard exceptions.
• Warranties and disclaimers. What the provider promises about the work — and what it does not.
• Limitation of liability. A cap on damages and an exclusion of indirect damages, with carve-outs both sides negotiate.
• Indemnification. Who covers third-party claims, such as claims that the work infringes someone's intellectual property.
• Term and termination. How long the MSA lasts, how either party can end it, and what happens to in-progress SOWs if the MSA terminates.
• Dispute resolution. Governing law, venue, and whether disputes go to court or arbitration.

If you sell software as a service, the same framework applies with some industry-specific additions — service level commitments, data handling, and security terms. We cover those in detail in our guide to what should be in every SaaS master services agreement.

What Should Be in a SOW?

A good SOW answers the questions that cause most project disputes:

• Deliverables. Described concretely. "Build a customer portal" invites disagreement; a list of features, integrations, and supported platforms does not.
• Timeline and milestones. Due dates for each phase, and what depends on what.
• Price and payment schedule. The fee structure for this project and when each payment comes due — often tied to milestones.
• Acceptance criteria. How the client reviews the work, how long they have to respond, and what happens if they reject a deliverable.
• Client responsibilities. The content, access, decisions, and approvals the client must provide — and the consequence for the schedule if they are late.
• Change-order process. How scope changes get requested, approved in writing, and priced before anyone does the extra work.
• Assumptions. Anything the price depends on, stated plainly, so a broken assumption becomes a change order instead of an argument.

Vague deliverables are the most common source of SOW trouble. If both sides cannot read the SOW and agree on what "done" means, the document is not finished.

Which Do You Sign First?

The MSA comes first. A SOW depends on the MSA for its legal terms, so it has nothing to plug into until the MSA exists.

In practice, the two are often signed on the same day — the MSA plus the first SOW as its first attachment. That works fine. What causes trouble is signing a SOW with no MSA behind it: work begins, money changes hands, and nobody has agreed on liability, IP ownership, or what happens if the project goes sideways.

Can a SOW stand alone? Technically yes — but then it has to carry all the legal terms itself, which turns it into a one-off service agreement. That can make sense for a single small project with no follow-on work expected. The moment a second project appears, the MSA-plus-SOW structure pays for itself.

Common MSA vs SOW Mistakes

• Putting legal terms in the SOW. A liability or IP clause buried in a SOW can conflict with the MSA, and nobody notices until there is a dispute.
• No order-of-precedence clause. When the documents conflict and neither says which controls, you have bought yourself an argument.
• Vague scope. If the deliverables are fuzzy, the client's version of "done" and yours will differ — and the SOW cannot settle it.
• No change-order process. Scope creep arrives on every project. Without a written process, extra work either goes unpaid or sours the relationship.
• Signing the other side's MSA unread. Large customers send their own MSA, and it is written to favor them. Read it — especially the liability, IP, and payment sections — before you sign.
• Letting SOWs outlive the MSA. If the MSA expires while a SOW is still running, the legal terms behind the project can lapse. The MSA should say its terms survive for any active SOW.

Several of these are cousins of the broader problems we see in technology deals — see 5 contract mistakes that kill tech deals for the rest of the family.

The Takeaway

The MSA is the rulebook; the SOW is the game plan for a single project. Sign the MSA first, keep legal terms out of your SOWs, and give every SOW three things: specific deliverables, clear acceptance criteria, and a written change-order process. Do that, and most project disagreements become short conversations instead of legal fights.

If you want a lawyer to review your MSA or SOW — or draft a reusable set for your business — we handle technology agreements and offer a $50 consultation. Book a consultation here.

Disclaimer: This blog post is intended for informational purposes only and does not constitute legal advice. Every contract and business situation is different. Please consult a qualified attorney for advice specific to your situation.