MSA vs SOW: What Goes in Each and How They Fit Together

Think of the MSA as the rulebook and the SOW as the game being played. The MSA answers questions that don't change from project to project: who owns the work product, how confidential material is handled, what happens when something goes wrong, and how disputes get resolved. The SOW answers the questions that change every time: what exactly are you delivering, when, at what price, and what do you need from the client.

The SOW becomes part of the MSA by reference. One sentence saying the SOW is governed by the MSA dated a certain day is what lets you sign a two-page SOW for a new project without reopening legal negotiation. A client who signs five SOWs over three years negotiated the legal terms once.

The split also decides who does the work internally. Legal terms go through an attorney or a named contracts owner. A SOW should contain only business facts, so your delivery lead can draft it and your sales lead can approve it within a day.

Put the clauses that shouldn't change with project size in the MSA:

• Intellectual property. Who owns what you bring to the engagement, who owns what you create, and what license the client receives to your pre-existing tools.
• Confidentiality. What counts as confidential, how long the duty lasts, and what happens to materials when the relationship ends.
• Liability and indemnity. The cap on damages, what's excluded from the cap, and who covers third-party claims.
• Payment mechanics. Invoice timing, late-payment terms, and expense rules in general form. The amounts themselves go in the SOW.
• Term and termination. How either side can exit, how much notice is required, and what's owed on the way out.
• Governing law and disputes. Which state's law applies and whether disagreements go to court or arbitration.

Limits on liability and IP assignment vary by state and industry, so let your attorney confirm the wording before it goes into a template.

The SOW carries everything specific to one project:

• Scope and deliverables. Named outputs written so a stranger could tell whether they were delivered, such as "a twelve-page brand guide in an editable file" rather than "branding work".
• Timeline and milestones. Start date, milestone dates, and how long the client has to review each one.
• Fees and billing schedule. A fixed fee tied to milestones, hourly rates with an estimate, or a monthly retainer.
• People. Who's staffed on the project and who on the client side makes decisions.
• Client dependencies. The access, files and approvals you need, each with a date. Late client inputs are a common reason schedules slip, so write them down.
• Exclusions and change process. What's explicitly not included, and how a change request gets priced and approved.

The exclusions line does more work than it looks like it does. Scope disputes rarely begin with a clear breach. They begin with an assumption nobody wrote down.

Add a precedence clause to the MSA saying the MSA controls if the two documents disagree, unless the SOW names the specific MSA section it's changing. The exception matters. Occasionally a project really does need a different liability cap or a special IP arrangement, and the SOW should be able to say so openly instead of burying it.

The usual failure is drift. A project manager trying to close a deal types a custom warranty or a liability carve-out into a SOW. Nobody in legal sees it. Two years later it's the term that governs a dispute. Set an internal rule that any SOW touching a legal term goes to your attorney or contracts owner first, and give your SOW template a labeled "Exceptions to the MSA" box that stays blank by default.

Decide how acceptance works while you're at it. Many teams add a deemed-acceptance clause to the SOW: the client has a fixed number of business days to report defects in writing, and silence counts as approval. Pick a window that matches how your client really reviews work, and ask your attorney how the clause reads in your state.

Say a small design agency signed an MSA with a client last year, and the client now wants a website refresh. The paperwork goes like this.

1. Pull the signed MSA and confirm it's still in its term and covers this kind of work.
2. Copy your SOW template and fill in scope, deliverables and the client's asset dependencies.
3. Set milestone dates and tie each invoice to a milestone.
4. Leave the "Exceptions to the MSA" box empty unless the client asked for something unusual.
5. Send it for signature and file it beside the MSA so the two are always found together.

If the client also asks for an unusual data-handling term, stop there and call your attorney. That request may belong in an amendment to the MSA rather than in a single SOW.

A shared folder and two well-built templates handle most small businesses. Software starts to pay off when you're producing many SOWs a month, need approvals before anything goes out, or have to track which SOW sits under which MSA and when each expires.

A document-generation tool like PandaDoc fits the first case: locked template fields, pricing tables and signature in one flow. A contract lifecycle tool like Ironclad fits the second: clause libraries and parent-child tracking across many agreements. Before you buy either, ask for a demo of the exact case you have, adding a SOW to an existing MSA, and confirm pricing and limits in writing.

For a side-by-side look at the tool categories, read the Ironclad and PandaDoc comparison. Once SOWs are moving, a contract approval workflow keeps legal terms from slipping through, and a renewal tracking sheet tells you when each agreement expires.