MSA vs SOW: what each paper does, and which one wins when they disagree

An MSA holds the terms that do not change from project to project. Once it is signed, each new piece of work needs only a short SOW, and nobody reopens liability or IP for a two-week project. The American Institute of Architects publishes this structure as a form: its B121 master agreement holds the common terms, and each B221 service order adds the scope of one engagement, so new work can start “without the necessity to renegotiate the terms.”¹

For a services firm, you negotiate the hard clauses once, with the client’s legal team, while both sides want the relationship to work. Each later project starts with the SOW alone, which your contact can often approve without legal.

The MSA you sign for the first project binds the fifth, cap included. Give it the clause-by-clause read in our MSA review checklist, and give the SOW precision about the work.

A SOW describes one project in enough detail that a stranger could tell whether you delivered it. The U.S. federal rule for service contracts puts the test well: describe the work “in terms of the required results rather than either ‘how’ the work is to be accomplished or the number of hours to be provided.”² A results-based SOW is easier to accept and harder to dispute.

A SOW for a dev shop, an agency or a consultant carries these parts:

• Scope and deliverables: each thing you hand over, named.
• Out of scope: what a reasonable client might assume is included and is not.
• Assumptions and client duties: access, data, approvals, a named person who answers questions within a set time.
• Schedule: milestones with dates, or dates counted from the client’s inputs.
• Fees and payment schedule: fixed fee by milestone, or rates with a monthly invoice and a not-to-exceed figure.
• Acceptance criteria: how each deliverable is judged done, and how long the client has to say so.
• Change orders: how new work is priced and agreed.
• Your tools: the libraries, scripts and templates you bring, named as yours.

Write each amount of the payment schedule with its trigger (“on acceptance of the test plan”) and a date the plan expects that trigger, so an invoice never waits on an event nobody tracks.

NIST describes an SLA as a commitment that covers “expected performance level (e.g., reliability, acceptable quality, and response times), and requirements for reporting, resolution, and termination.”³ That fits a service that runs: managed QA, a support retainer, hosting, an on-call DevOps contract. It does not fit a project with an end date.

If a client sends an SLA with a project, ask what it measures. A response time for defects found during a 90-day warranty is reasonable. Uptime for software you built and handed over, on servers they run, is not yours to promise.

When you do sign one, three lines matter. Service credits are the client’s sole remedy for missing a service level. Credits count toward the liability cap in the MSA. And misses caused by the client, their vendors or planned maintenance are excluded.

Every MSA says what happens when the MSA and a SOW disagree. Clients usually write it so the MSA always wins. Then a SOW that says “three rounds of revisions” loses to an MSA that says “Provider shall revise Deliverables until Client is satisfied.”

You lose twice. The project terms you negotiated lose to general terms written before the project existed. And the preprinted terms on the back of their purchase order now bind you, though nobody on your side has read them.

The second sentence protects you as much as the client. Without it, a SOW signed in a hurry by their project manager could move the liability cap, and so could one signed by yours.

The sample redline, as it reads in their Word file with your changes tracked:

• Struck: “the terms of this Agreement shall govern and control.”
• Inserted in its place: “the Statement of Work controls as to scope, Deliverables, fees, payment schedule, timeline and acceptance criteria for that Statement of Work only, and this Agreement controls as to all other matters.”
• Struck: the whole sentence beginning “Client’s purchase order terms shall apply.”
• Inserted: the purchase order sentence of the counter.
• Comment beside the change: “The SOW is where we agree the project; it should win on the project terms. PO terms were never negotiated, so they stay out.”

No. For a one-off project under about a month, many firms sign a single services agreement that holds both the terms and the scope. For a client who will buy again, the pair saves time from the second project on. If the client has no MSA and does not want one, send your SOW with your own terms attached as an exhibit and a line that says the exhibit governs.

What you should not do is start work on a signed SOW while the MSA is “still with legal.” If the SOW points to an MSA that does not exist yet, the terms of your work are unclear until it does.

Tommos (tommos.ai) is a CRM whose AI agents, the tommos, take a B2B inquiry to a signed contract. On the Sign plan, $899 a month for the firm, both papers of this article are Tommo Legal’s work.

• Their MSA. When the client’s MSA lands on the deal, Tommo Closer passes it to Tommo Legal. Tommo Legal reads it against the positions you wrote once and writes a clause memo: their words, your position, what the gap means, the counter-wording to paste, and whether the point is worth a lawyer. A Word file also gets the changes tracked in the client’s own document.
• Your SOW and NDA. Tommo Legal drafts them as Google Docs from your own templates in your Drive. The SOW’s scope, price and dates come from your estimate; a fact the deal does not hold stays a visible blank, with a line on whom to ask.
• The signature. A person you allow to sign presses Sign on the card, and your signature goes on there. The copy signed by both sides is filed in the client’s folder.
• The invoices. After the deal is won, Tommo Closer reads the signed paper and proposes the payment schedule. A person accepts it and approves each invoice.

Tommo Legal writes to nobody outside your firm, and its memo is research, not legal advice.

What Tommo Legal does · Every plan · Up: the full MSA review

Before you sign the next MSA, get the one-page MSA checklist: ten clauses and a fair counter for each.

• An MSA sets the legal terms once; a SOW sets each project’s work, dates and money.
• Make the SOW control scope, deliverables, fees, schedule and acceptance; the MSA controls the rest.
• A SOW changes an MSA term only when it names the section. That rule protects both sides.
• Keep purchase order terms out of the deal.
• Add an SLA only for a service that runs, and make its credits the sole remedy, under the cap.

This is not legal advice. It is how a services firm reads these papers in practice; for a large deal or an unusual clause, ask a lawyer.

1. AIA Contract Documents, “Summary: B121-2018, Standard Form of Master Agreement Between Owner and Architect for Services provided under Multiple Service Orders”, and “Summary: B221-2018 Service Order”, read Oct 13, 2026
2. Federal Acquisition Regulation 37.602(b)(1), “Performance work statement”, read Oct 13, 2026
3. NIST Computer Security Resource Center glossary, “service level agreement” (from NIST SP 800-47 Rev. 1), read Oct 13, 2026