Master Service Agreement vs Statement of Work: How MSAs and SOWs Fit Together

Anyone who has hired an agency, a software developer, or a consulting firm for more than one project has probably been handed two documents at once. One is long, dense, and full of legal terms. The other is shorter and actually describes the work. People tend to skim the first and focus on the second, which makes sense until something goes wrong and it turns out the long one was doing most of the heavy lifting.

In most cases, the longer document is a master service agreement and the shorter one is a statement of work. They’re meant to be read as a set, and once you understand what each one covers, problems in either document get a lot easier to catch before you sign. Below I’ll go through the differences between them, what usually ends up in each, and the places where they can end up disagreeing with each other.

I’m not a lawyer, and this post is a general explainer, not legal advice. For contracts with real money or risk involved, have an attorney review the documents.

What a Master Service Agreement Is

A master service agreement, usually shortened to MSA, is a contract that sets the ground rules for an ongoing business relationship. It doesn’t describe any particular project. Instead, it covers the terms that will apply to every project the two parties do together, so they don’t have to negotiate the same issues over and over.

PandaDoc’s guide to MSAs and statements of work describes the MSA as a framework document that makes later agreements faster to put in place, and that matches how I’ve seen them used. Once the MSA is signed, starting a new project can be as simple as drafting a new SOW.

Most of the terms lawyers pay close attention to end up in the MSA. That’s usually where you’ll find the rules for payment and invoicing, confidentiality obligations, who owns the intellectual property, warranties, and how disputes get resolved. It’s also where the risk gets divided up, mainly through the indemnification provisions and the limits on liability. On top of that, an MSA typically explains how either party can end the relationship and what happens to unfinished work if they do, and many include insurance requirements and data protection terms as well.

What a Statement of Work Is

A statement of work, or SOW, describes a specific project. If the MSA is about how the two parties will work together in general, the SOW is about what they’re doing this time.

A useful SOW leaves very little open to interpretation. It describes the work being done, the specific deliverables, the deadlines, and the price. Many also lay out milestones, name the main contacts on both sides, and list what the client is responsible for providing, such as system access or feedback within a set number of days. The better ones explain how finished work will be reviewed and signed off. They also state what isn’t included in the project, and in my experience that section gets left out more often than any other, even though it prevents a lot of arguments later.

Every new project gets a separate SOW that points back to the same MSA. That’s how one MSA can end up covering dozens of projects over several years.

How They Work Together

Picture a retail company that brings on a marketing agency. They start by signing an MSA that settles payment terms, confidentiality, ownership of the creative work, limits on liability, and how either side can walk away. The first project is a website redesign, so they sign an SOW describing the scope, the timeline, and a fixed fee. About six months later, the company decides it wants the agency to manage a paid ad campaign too. Rather than drafting a whole new contract, the two sign another SOW under the existing MSA, and that document only has to address the details specific to the ad campaign.

That structure saves time for both sides, and it keeps the legal terms consistent across projects. It also lets the people who care most about risk negotiate the MSA carefully once, while project managers handle the SOWs.

MSA vs SOW Side by Side

When the Two Documents Disagree

This is where I’d slow down. Because MSAs and SOWs are written at different times, often by different people, they sometimes contradict each other. The MSA might say invoices are due in 30 days while an SOW says 15. The MSA might give the client ownership of all deliverables while an SOW says the agency keeps rights to certain templates.

The usual fix is an order of precedence clause in the MSA, which spells out which document controls when the two don’t match. Contracts handle this in different ways. In some, the MSA comes first, and its terms apply unless an SOW clearly states that it’s overriding them. In others, the SOW takes priority, since it was written later and deals with the specific project, so it’s assumed to better reflect what the parties actually agreed to. You can see how much the wording varies in these sample precedence clauses from Law Insider, some of which put the individual service agreement at the top of the list.

Neither approach is automatically right, but the choice matters. If the SOW takes priority, a project manager filling in a template could accidentally change the liability cap or IP ownership for that project without legal ever noticing. If the MSA takes priority, a deliberate deal-specific change might not hold unless the SOW explicitly says it overrides the MSA. Whichever structure you use, it’s worth reading every SOW with the MSA open next to it.

Common Mistakes

Vague scope causes more trouble than anything else in these documents. If an SOW just says “website design” or “marketing support” and never defines the actual deliverables, the two sides are likely to remember the deal differently once the work is underway. That gap is also where scope creep tends to begin, with the client asking for more and more while the price stays the same.

A close second is ignoring intellectual property. The MSA should say who owns the work, and if the provider uses contractors, that ownership needs to flow through to you. Paying for work doesn’t automatically mean you own it, which I explain in more detail in my post on work for hire.

A few other gaps come up regularly. Some SOWs never define acceptance criteria, which leaves both sides unsure when a deliverable counts as finished. Others have no change order process, so any adjustment to the scope ends up negotiated through scattered emails that are hard to piece together later. People also tend to forget that an MSA often stays in effect long after the first project is done. Unless someone revisits it, terms negotiated years ago can end up governing work that looks nothing like what the parties originally had in mind.

Do You Always Need Both?

Not always. For a one-time project with a vendor you’re unlikely to hire again, a single services agreement that combines the legal terms and the project details can work fine. The MSA and SOW structure earns its keep when you expect repeat work, since it lets you negotiate the important legal terms once and move quickly on each new project after that.

On the other hand, if you’re a service provider, having your own MSA ready can make you look more established and give you more control over the terms. Plenty of freelancers and small agencies adopt this setup for exactly that reason.

Final Thoughts

An MSA governs the relationship as a whole, while each SOW covers a single project. Most of the legal protections, like liability limits, indemnification, IP ownership, and termination rights, sit in the MSA. The SOW is where the practical details go: what’s being delivered, by when, and for how much.

Because the two depend on each other, I’d never review one without the other. When a new SOW comes across your desk, pull up the MSA it falls under and read them side by side. Check the order of precedence so you know which one controls if they conflict, and read the scope as if you were the other party. If you can imagine the two of you describing the finished work differently, fix the wording before anyone signs.