The first enterprise deal I ever closed almost died over a contract. We were a six-person SaaS shipping a niche analytics tool — let's call us Acme Cloud — and a mid-market customer (PixelPipe, a creative agency in Berlin) wanted to pay $24,000 a year for a multi-seat plan. Their procurement team sent me a 38-page paper-trail nightmare titled "Master Services Agreement, Schedule A, Schedule B, DPA, SLA Annex." I'd never seen most of those documents before. I had a Stripe link and a one-page Terms of Service.
Two weeks of back-and-forth later, we got it signed. But it taught me something. Once you cross roughly $5,000 ARR per customer, the click-through ToS stops being enough. Procurement wants paper. Legal wants paper. Compliance wants paper. And you, the founder, need to know what you're agreeing to before someone slips a clause into your contract that turns your runway into theirs.
This is the practical guide I wish someone had handed me back then. What goes into a SaaS agreement, how MSAs work alongside order forms, the clauses that actually matter, and how to get the whole thing signed online without a fax machine or a notary. Not legal advice — for jurisdiction-specific terms, consult a lawyer who knows your market. But for the structural decisions, this should keep you out of the worst traps.
The SaaS contract problem
Most SaaS founders start with a click-through Terms of Service and a Stripe checkout. Customer pays, customer agrees, contract done. That works beautifully for self-serve and small teams. It falls apart the second a customer's procurement team gets involved.
Three things happen at the enterprise threshold:
- The customer wants to negotiate. Specifically, indemnity caps, data processing terms, SLAs with credits, and termination rights.
- The customer wants signatures. Not click-throughs. Real signatures from authorized representatives on both sides.
- The customer wants a document that lives in their contract management system — usually a PDF with named parties, an effective date, and a signature block.
If you don't have a workable answer for all three, deals stall. I've watched startups lose six-figure contracts because they couldn't produce a signable MSA in under a week. Nobody asks for their money back. They just... go quiet.
Master Service Agreement (MSA) vs Order Form
This is the single most important structural concept in B2B SaaS contracting and it confused me for the longest time. Once it clicks, everything else is easier.
An MSA is the legal scaffolding. It covers the boring-but-critical stuff that doesn't change deal-to-deal: warranties, IP ownership, confidentiality, indemnification, limitation of liability, governing law. Sign it once with a customer, and it governs your entire commercial relationship.
An Order Form is the commercial document. It says "Customer is buying X seats of Y product for Z dollars from this date to that date." It references the MSA. The customer can sign multiple order forms over the years (renewals, expansions, new products), all under the same MSA.
Why bother splitting them? Two reasons. First, negotiation. The MSA is heavy and slow — your legal team and theirs go back and forth on indemnity language for two weeks. The order form is light — pricing, term, seats. Once the MSA is signed, every subsequent deal with that customer takes minutes instead of weeks.
Second, internal sanity. Your sales team can issue order forms without re-opening the legal can of worms every quarter. Renewals stop being existential.
A typical structure for Acme Cloud closing PixelPipe:
- MSA (15-25 pages) — signed once by both legal/finance teams.
- Order Form #1 (1-2 pages) — 50 seats of Pro at $99/month/seat, 12-month initial term, $59,400 annual, signed by the procurement lead.
- DPA (5-10 pages) — attached as an exhibit to the MSA, governs how Acme Cloud handles PixelPipe's customer data.
- SLA (1-2 pages) — also attached, sets uptime commitments and credit remedies.
Twelve months later when PixelPipe renews and adds 30 seats? New order form. Same MSA. Same DPA. Same SLA. Nobody re-negotiates the foundation.
Essential clauses every SaaS agreement needs
Now to the meat. Here's what actually matters.
Subscription terms
The contract has to spell out what the customer is buying. Not "access to Acme Cloud" — that's marketing copy. Specifically:
- Product/Plan name. Pro, Enterprise, Team — match exactly what's in your billing system.
- Number of seats or units. And what counts as a seat. ("A named user with a unique login" is bullet-proof; "an active user" leads to fights.)
- Subscription term. Initial term length (usually 12 months for B2B), and how renewals work.
- Effective date. When access starts. Often different from the signature date — don't conflate them.
- Permitted use. What the customer can do with the service. Affiliates? Subsidiaries? Resellers? Be explicit.
I've seen deals collapse because the order form said "100 users" and the customer interpreted it as "100 named accounts that can rotate among 400 employees." That's not what you want. Spell it out.
Payment and auto-renewal
Auto-renewal is the single most contested clause in modern B2B SaaS contracts and the regulatory landscape keeps shifting. As of 2026, several US states (California's AB 2863, plus tightening rules in New York and Illinois) require explicit, conspicuous notice before any auto-renewal kicks in. The EU's Directive 2019/2161 has similar consumer-facing rules and member states have been getting stricter on B2B too.
What to put in your contract:
- Payment terms. Net 30 is standard for invoicing; Stripe-style charges are immediate. State which.
- Currency. USD vs EUR matters more than people realize for international deals — pick one and stick with it, with a clear FX clause if needed.
- Auto-renewal language. Default in most modern MSAs: the agreement renews for successive 12-month terms unless either party gives 30, 60, or 90 days' written notice before the renewal date. Pick one window. Be consistent.
- Price increase cap. Customers will push hard for a cap on renewal price increases. A 7% or CPI-linked cap is common. Don't agree to "no increase ever" — inflation will eat you.
- Late payment. Interest on overdue invoices (often 1.5%/month or the legal max) and the right to suspend service after X days late.
The cleanest pattern: auto-renew at the same plan, with a notice period that gives the customer real opportunity to opt out, and a price-increase cap that gives you breathing room.
Cancellation and termination
Three flavors of termination matter, and they're not the same.
Termination for convenience. Either party can walk away with notice, no reason needed. Most enterprise customers want this; most SaaS vendors should resist it. If you must include it, make it expensive — require the customer to pay the remaining term, or only allow it at the end of an order form term.
Termination for cause. Either party can terminate if the other materially breaches the contract and doesn't cure within a notice period (usually 30 days). This is non-negotiable. Both sides need it.
Termination for insolvency. If your customer goes bankrupt, you want out. If you go bankrupt, they want out. Standard.
Add a post-termination data clause: how long the customer has to export their data, how long you retain it before deletion, and who pays for any extended retention. Thirty days for export, then deletion within 60 days, is a common middle ground.
Service Level Agreement (SLA)
The SLA is where over-promising will hurt you. Don't commit to numbers you can't actually meet.
A typical mid-market SaaS SLA:
- Uptime target: 99.9% (which is ~43 minutes of downtime per month). 99.99% is the enterprise target — only commit to it if you've actually built for it.
- Measurement window: Calendar month, not rolling.
- Exclusions: Scheduled maintenance (with notice), force majeure, customer-caused outages, third-party dependency outages outside your control.
- Remedies: Service credits, not cash refunds. Typical structure: 10% credit if uptime drops below 99.9%, 25% if below 99%, 50% if below 95%. Cap total credits at one month of fees.
- Customer's only remedy: The credits. Not lawsuit damages. This protects you from a customer claiming downtime cost them $2M in revenue.
If a customer pushes for cash refunds instead of credits, push back hard. That's a structural risk shift.
Data Processing Agreement (DPA / GDPR)
Any customer with EU users (and increasingly, California users under CCPA) will demand a DPA. It's a legal requirement under GDPR Article 28 if you process personal data on their behalf, which you almost certainly do.
What goes in:
- Roles: You're the Processor, the customer is the Controller. State this explicitly.
- Subject matter and duration of processing. What data, for what purpose, for how long.
- Sub-processors. A list of any third parties you use (AWS, Stripe, Sentry, etc.) and a process for notifying the customer of changes.
- Security measures. Reference your security documentation — encryption at rest and in transit, access controls, breach notification timelines.
- International transfers. Standard Contractual Clauses (the 2021 version) for any data leaving the EU/UK.
- Audit rights. The customer's right to audit your compliance, usually limited to once per year and at their expense.
Get a template DPA from a lawyer who knows EU data protection law. Use it as your baseline for every customer. Don't try to write one from scratch.
Limitation of liability
Two numbers matter here.
The cap. Total liability under the contract, usually capped at fees paid in the prior 12 months. Customers will push for "two times" or "three times" fees; you'll push for "the lesser of fees paid and a fixed dollar amount." Land somewhere reasonable.
The carve-outs. Things that aren't capped — usually breach of confidentiality, IP indemnification, gross negligence, and willful misconduct. Some customers also want data breach liability uncapped, which is a fight worth having (and usually losing partway).
If your contract caps liability at "fees paid in the last 12 months" and excludes consequential damages, you're in solid shape for a small SaaS.
IP ownership
Spell this out clearly:
- You own your software. The customer is buying a license to use it, not the IP.
- The customer owns their data. You have a limited license to use it to provide the service.
- Feedback and improvements. If the customer suggests features and you build them, you own the resulting IP. State this — without it, ambiguity creeps in.
How to sign SaaS contracts online (with e-signatures)
Once you have the document, signing it shouldn't take two weeks of paper trails.
For US-based SaaS, ESIGN and UETA make standard electronic signatures legally enforceable for B2B contracts. For EU customers, eIDAS gives you SES (simple), AES (advanced), and QES (qualified) tiers — for ordinary B2B SaaS deals, AES is the safe default. We covered this in detail in our cross-border contracts guide.
The practical workflow:
- Generate the document. PDF from your template, with the customer-specific fields filled in.
- Send for signature. Through an e-signature platform — both parties sign in their browser, no printing needed.
- Capture an audit trail. IP addresses, timestamps, signer identity, document hash. This is your enforceability evidence if you ever need it.
- Store the signed copy. In your contract management system, a Drive folder, your CRM — somewhere structured and findable.
This is exactly what CanUSign is built for. We handle MSAs, order forms, DPAs, and SLAs every day for B2B SaaS teams. At $1 per document or $14.90/month for unlimited Pro signing, the math beats DocuSign by an order of magnitude — and our pricing is transparent. For the deeper background on the legal mechanics, see our electronic signature legal guide.
Common pitfalls
A handful of mistakes I see repeatedly when reviewing SaaS contracts for early-stage founders:
- Conflating MSA and order form. Putting pricing in the MSA means you renegotiate the entire contract every renewal. Keep them separate.
- Auto-renewal without notice. A clause that auto-renews silently with no notice period is unenforceable in several US states and most of the EU. Always include a notice window.
- Promising 99.99% uptime without an architecture that supports it. Your SLA is a contractual commitment. Match it to reality.
- No DPA for EU customers. This isn't optional. Have a template DPA ready before you need it.
- Vague "active user" definitions. Always define seats as named users with unique credentials, or risk arguing about it later.
- Unlimited liability for data breaches. Cap it. Insurance can fill the gap.
- No price-increase cap. Customers will hate it later, and "later" arrives faster than you think.
FAQ
Do I need an MSA if I only sell to small businesses? For self-serve customers under ~$5K ARR, a click-through ToS plus an order confirmation is usually enough. Above that, customers will start asking for a signed MSA. Have one ready.
Can my Terms of Service double as an MSA? Sort of. A well-drafted ToS covers most of the same ground but is one-sided (you wrote it, they accepted it). Enterprise customers want a negotiated, mutually signed document. The two can coexist — many SaaS use ToS for self-serve and a proper MSA for negotiated deals.
How long should a SaaS MSA be? Fifteen to twenty-five pages is typical. Shorter than that and you're probably missing something material. Longer than that and you're probably over-engineering it for a startup-stage business.
What's the difference between a DPA and a privacy policy? The privacy policy is a public-facing document about how you handle personal data generally. The DPA is a binding contract between you and a specific customer about how you process their data on their behalf. Different audience, different legal weight.
The bottom line
SaaS contracts feel intimidating until you see the structure. MSA for the legal scaffolding, order form for the commercials, DPA for data, SLA for uptime. Get those four documents into a tight templated set, learn which clauses are negotiable and which aren't, and you can close enterprise deals in days instead of weeks.
Don't let contracts be the thing that kills your deals. Get them written, get them signed, and get back to building. If you want a tool that handles the signing part — fast, cheap, and legally solid for both US and EU customers — give CanUSign a try. Your future self, three deals from now, will thank you.