Reading a master services agreement: the clauses we negotiate
Summary:
- The MSA sets the relationship; the SOW sets the engagement. Confusing them causes most disputes.
- Acceptance criteria must be written before work starts and must be testable.
- What sits outside the liability cap matters more than the cap itself.
- A termination clause without a handover list leaves the client stuck.
Software contracts are mostly boilerplate. Somewhere inside them sit five clauses that determine what actually happens when a project runs late, a stakeholder changes their mind, or the relationship ends.
This is what we look at, from either side of the table.
One: intellectual property assignment
The clause everyone assumes is fine and often is not.
What a client needs is clear: on payment, ownership of everything built for them. What the clause usually gets wrong is the carve-outs.
| Category | Who should own it |
|---|---|
| Work product | The client, on payment. Unambiguous. |
| Vendor background tools | The vendor, with a perpetual license to the client. A vendor cannot assign a library it uses across every project. |
| Open source components | Nobody. They come with their own licenses and the contract should acknowledge that instead of pretending otherwise. |
| Third-party services | The provider. What matters is that accounts are in the client's name. |
A clause that assigns everything without carve-outs looks client-friendly and is a red flag: either the vendor did not read it, or it is not enforceable, and neither is comforting.
Two: acceptance criteria
This is where most disputes actually live.
If the SOW says a deliverable is accepted when it "meets the requirements," you have an argument waiting to happen. Requirements are prose and prose is interpretable.
Testable criteria are the fix. They take an extra hour to write and they remove the entire category of disagreement about whether something is done.
The related term is the review window: how long the client has to accept or reject. Without one, a deliverable can sit unreviewed while the vendor waits to invoice and the client waits to be sure.
Three: the liability cap
Every vendor caps liability. The number matters less than the exclusions.
Typically outside the cap: confidentiality breaches, IP infringement and gross negligence. That is reasonable and both sides usually agree quickly.
What deserves attention is indirect damages. Vendors exclude them and clients should understand what that means: if a defect causes lost revenue, that loss is generally not recoverable. Whether that is acceptable depends on how critical the system is, and it is a conversation worth having before signing rather than after an incident.
Four: warranty period
How long after delivery does the vendor fix defects at no charge, and what counts as a defect versus a change?
The distinction is the whole clause. A defect is the software not doing what was agreed. A change is the agreement being different from what is now wanted. Without that line drawn, every disagreement becomes a negotiation about whether to bill.
Five: termination and handover
Most termination clauses cover notice and money. Fewer cover the thing that actually matters operationally.
A handover list should be explicit: source code repository access, credentials for every third-party service, deployment documentation, and a database export in an open format. With a deadline attached.
We have seen clients who terminated correctly, paid what they owed, and then spent six weeks trying to get a hosting password from a company that no longer had a commercial reason to answer.
Frequently asked questions
What is the difference between an MSA and an SOW?
The master services agreement sets the legal relationship once: liability, ownership, confidentiality, termination. The statement of work defines a specific engagement: scope, deliverables, timeline, price. You sign one MSA and many SOWs under it.
Who should own the code?
The client, on payment, with the agreement saying so explicitly. What needs carving out is pre-existing vendor tooling and open source components, which cannot be assigned. A clause claiming the client owns absolutely everything is either unenforceable or means the vendor is giving away tools it uses elsewhere.
What makes acceptance criteria enforceable?
Being written before work starts and being testable. "Works correctly" is not a criterion. "Processes a file of 10,000 rows in under 60 seconds without data loss" is. Without testable criteria, acceptance becomes a matter of opinion and opinions are not resolvable.
Are liability caps negotiable?
Usually within a range. A cap at the fees paid is common. What matters more than the number is what sits outside the cap: confidentiality breaches and IP infringement are typically excluded, and that is reasonable for both sides.
What should the termination clause say?
Notice period, what happens to work in progress, and above all what gets handed over: code, credentials, documentation and data. A termination clause that covers money but not handover leaves the client legally correct and operationally stuck.
The clause nobody thinks about
Change orders. How a change to scope gets requested, priced and approved.
It sounds procedural and it is the mechanism that keeps a project honest. Without a defined path, changes arrive verbally, get absorbed informally, and the schedule slips for reasons nobody can reconstruct afterward.
A one-paragraph change order process — request in writing, impact assessment within two days, written approval before work begins — prevents more disputes than any other clause in the document.
Reading order for a non-lawyer
If you have twenty minutes and no legal background, read these sections in this order. It covers most of the practical risk.
- Intellectual property. Who owns what, and when the transfer happens.
- Acceptance. How a deliverable is declared complete and how long you have to object.
- Termination. Notice, and specifically what gets handed over.
- Change orders. How scope changes get priced and approved.
- Liability. The cap and, more importantly, the exclusions.
Everything else is either standard or lower stakes. Confidentiality, governing law and force majeure rarely determine outcomes in software engagements.
The asymmetry worth noticing
Most of these clauses protect the client, and most vendors accept them without much negotiation. That surprises clients who expect a fight.
The reason is straightforward: a vendor planning a long relationship has no interest in ambiguous ownership or undefined acceptance either. Ambiguity produces disputes, and disputes cost the vendor more than the clause would have.
Resistance to these terms is therefore informative. It usually indicates either a vendor who has not thought about the contract or one whose commercial model depends on the ambiguity.