What is a master services agreement, and when do you need an SOW?

A master services agreement (MSA) is a contract that sets the terms for an ongoing relationship between a customer and a service provider — payment, confidentiality, ownership of the work, warranties, liability, termination — without ordering any work. The work itself is ordered by a statement of work (SOW): a shorter document that describes one project's scope, deliverables, timeline and fees, and says it is governed by the MSA.

The point of splitting them is that the two halves change at very different speeds. The legal terms between an agency and its client are the same in month one and month thirty. The work is different every quarter. Put both in one contract and every new project reopens the liability cap; split them and the lawyers negotiate once while the people doing the work agree scope as often as they need to.

MSA vs SOW at a glance

The names vary. A professional services agreement, a framework agreement (common in the UK) or a customer's "vendor terms" usually do the same job as an MSA. Work orders, task orders, project schedules and, in software, order forms usually do the job of an SOW. As with NDAs, what matters is the structure — standing terms in one document, each piece of work in another that refers back to it — not the heading.

When you need an MSA

• You expect more than one project with the same client. This is the main reason. The second project costs a two-page SOW instead of a full contract.
• The client's procurement process is slow. Large customers often take weeks to approve a new vendor contract. Getting an MSA through once means later projects need only budget approval.
• Different teams will order work. An MSA lets several departments of the same customer each sign SOWs on terms that legal has already approved.
• You sell retainers or ongoing services that will be re-scoped from time to time.

If it really is a single, self-contained job, an MSA is more paperwork than you need. A consulting agreement or an independent contractor agreement puts the terms and the work in one document.

What goes in the MSA

1. 1

   Structure and precedence

   Say that work is ordered by SOWs signed by both parties, and what happens when an SOW and the MSA disagree. The usual rule is that the MSA wins unless the SOW expressly says it is overriding a named clause. Without that rule, a project lead can quietly rewrite the liability cap in a scope document.

2. 2

   Fees, invoicing and late payment

   The SOW sets the price; the MSA sets the mechanics — how often the provider invoices, how long the customer has to pay, and what happens if it does not.

3. 3

   Change orders

   Scope changes. The MSA should say a change only takes effect when both sides sign a written change order setting out the effect on scope, schedule and fees. This is the clause that turns "could you just" into a priced decision.

4. 4

   Confidentiality and IP

   Each side protects the other's information. The customer typically owns the deliverables named in an SOW once they are paid for, and the provider keeps its pre-existing tools and know-how, licensed to the customer where they are built into the work.

5. 5

   Warranties, liability and indemnities

   The negotiated core. A warranty that the services will conform to the SOW for a period after delivery, with re-performance as the remedy; a cap on each party's liability, commonly tied to the fees paid over a recent period, with carve-outs; and indemnities for third-party claims such as IP infringement.

6. 6

   Term and termination

   How long the MSA lasts, whether it renews, how either side can end it, and what happens to SOWs in progress when it does.

What goes in the SOW

A good SOW is specific enough that a stranger could tell whether it has been performed. Most disputes under an MSA are really disputes about an SOW that was vague.

• Scope, as a list of activities, followed by an explicit out of scope list. The second list is the one that saves arguments.
• Deliverables with dates. Named things, each with a due date.
• Acceptance. How long the customer has to review each deliverable, what counts as a rejection (a written explanation of how it fails the SOW), and what happens if nobody responds. Deemed acceptance after a fixed review period protects the provider from a deliverable that is never quite signed off.
• Pricing model and schedule. Fixed fee, or time and materials at a stated rate with a cap, and the milestones or dates on which each amount falls due.
• Assumptions and customer responsibilities. Access, data, decision-makers. If the timeline depends on the customer delivering something by a date, say so here.
• Contacts. One lead on each side.

Common mistakes

• Starting work on an MSA alone. The MSA orders nothing. Without a signed SOW there is no agreed scope or price, and the provider is working on trust.
• Legal terms creeping into SOWs. An SOW that adds its own liability or IP language creates two sets of terms. If a project genuinely needs different terms, say expressly which MSA clause it overrides.
• Letting the MSA lapse. If the MSA has a fixed term and nobody renews it, SOWs signed afterwards may have no governing terms at all. Check the renewal clause, and diarise the date.
• Change by email. A string of emails agreeing extra work is not a change order. Write it down and sign it, even if it is a paragraph.

Our templates

The master services agreement template follows the structure above. The MSA controls unless an SOW expressly says otherwise; the provider invoices monthly in arrears unless an SOW sets a different schedule; changes need a signed change order; liability is capped at the fees paid or payable in the twelve months before a claim, with carve-outs for breach of confidentiality and indemnities; and the agreement runs for two years and renews annually unless either side gives notice. Every negotiable number is a bracketed placeholder.

The statement of work template refers back to the MSA by name and date and covers the overview, scope and out-of-scope list, deliverables with dates, a timeline, an acceptance clause with deemed acceptance after the review period, a pricing model with payment milestones, assumptions and contacts. Number your SOWs — the template has a slot for it — so a change order can say which one it changes.

Both open in the editor with the customer and provider signature blocks in place. The usual flow is to sign the MSA once, then duplicate the SOW for each new project. When the client returns a redlined MSA in Word, which they will, attach it and XDocs reconciles it against what you sent, as tracked suggestions in their name; we explain how in the half of the deal that happens after you send. And because sending freezes a snapshot, an SOW signed in March cannot be changed by an edit to the template in May.