How to draft a liability cap that actually caps: four drafting fixes that prevent most disputes

Today’s post looks like it is for the contract nerds. It is not. If you sign contracts, negotiate them, or get dragged into the “can’t we just close this?” call, this one is for you.

Topic: liability caps. The clause everyone claims is non-negotiable until the moment they negotiate it for four weeks. The clause that somehow manages to be both (i) “market standard” and (ii) the reason your deal has been stuck in legal review since the last ice age. 

Everyone focuses on the number to plug into the template. One times fees. Two times fees. “Twelve months preceding… something.” A fixed euro figure that someone found in a template from 2017 and no one dares to question. Sometimes the number is heroic. Sometimes it is quietly painfully low. Either way, the discussion usually ends with: fine, put that number in and move on.

Here is the uncomfortable part. The number is not the real problem.

Liability caps are supposed to create certainty. They often fail at exactly that because parties agree a cap amount or a fee-based formula, then leave the cap mechanics vague. And vague mechanics are where disputes are born. Later, when something breaks, both sides can credibly argue for a different cap. One side thinks it bought a hard ceiling. The other thinks the ceiling resets. Or moves. Or never burns down. Or stacks across project orders like loyalty points.

Life sciences is especially exposed because the same cap language gets copy-pasted into very different relationships: CRO MSAs, CDMO supply, R&D collaborations, software terms, and licensing deals. Different facts, same ambiguity. Everyone thinks they agreed “one cap”, but the wording leaves room for multiple caps, moving caps, and caps that do not actually cap.

The good news: you can eliminate most of these fights with four short drafting additions. You do not need a longer clause. You need a clause that actually does what it says on the tin.

The “80% fix” in four additions (or: four things to watch for before you sign)

Most cap drama is not caused by a creative counterparty. It is caused by a clause that looks familiar enough to pass a skim-read, but leaves four questions unanswered. If you want to avoid future “that is not what we meant” calls, these are the four tripwires to look for.

1) Does the cap apply once, or can it quietly reset?

If the clause says “total aggregate liability” but never spells out aggregate of what, you are in the danger zone. “Aggregate” can be read as “aggregate per claim bucket”, “aggregate per event”, or “aggregate at any given time”. Everyone assumes it means “one pot”. Not everyone is correct.

What you want to see is language that removes the cap multiplication argument entirely, such as “for all Claims in aggregate”. Without it, the other side can try to slice the fact pattern into multiple claims and argue each gets its own cap.

Now, to be fair: a per-claim structure can be the right commercial answer in some contexts. If you are buying services for many independent studies, or you are a customer who cannot accept that one early failure “uses up” all future protection, a per-claim or per-study cap can be a sensible risk allocation. The point is not that “one pot” is always right. The point is that the clause should not leave you guessing whether you negotiated a ceiling or a vending machine.

2) If the cap is fee-based, do you know what fixes the time window?

Any clause that says “fees paid in the 12 months preceding the claim” should trigger the same reaction as “we will decide later”. Preceding which claim? Measured as of what date? A claim notice date, a court filing date, the “event giving rise” date? Each of those can materially change the number, especially in a scaling relationship.

This is where negotiation posture shows up in practice. The party trying to limit exposure tends to like an anchor that freezes the cap early, for example the first claim notice. The party that wants protection aligned with a growing relationship tends to prefer an anchor that moves with time, such as the 12 months preceding the relevant event, or a contract-year approach. Both can be defensible. What is not defensible is leaving the anchor ambiguous and calling it “market”.

If you read the clause and cannot explain to a commercial colleague, in one sentence, which date sets the calculation, the clause is not finished.

3) “Fees paid” vs “fees paid or payable”: is the cap clear, and is it realistic?

This is the part that looks like nitpicking until it becomes the entire dispute.

“Fees paid” is clean. It is easy to administer. It is hard to game. But it has an obvious trap: early in the relationship, or in a project that has not yet invoiced much, “fees paid” can translate into a cap so low that it is commercially meaningless. If you are the party relying on the cap for protection, that should worry you. If you are the party offering the cap, it may look great on paper until it derails the deal or becomes indefensible when a serious incident happens. The usual market-safe solution is not a longer clause. It is a floor. A simple “greater of € X or fees paid” avoids the “cap equals pocket change” problem without opening accounting debates.

“Fees paid or payable” fixes the low-cap issue, but creates a different one: what counts as “payable”? Disputed invoices? Termination charges? Minimum commitments? Milestones triggered by time rather than performance? Pass-through costs and third-party expenses? If you have ever argued about whether an invoice was properly issued, you already know where that ends. If you see “paid or payable” with no guardrails, assume you are signing up for a future accounting argument. That might still be acceptable, but it should be a conscious choice, not a drafting accident.

4) Does the cap actually cap, or can it be exceeded through payments and stacking?

Two small mechanics determine whether the cap is a real ceiling or a polite suggestion.

First, burn-down. If the clause does not say whether amounts previously paid reduce the remaining cap, you have space for a fight. One side will argue the cap is a total maximum over the life of the agreement, so every payment burns down the remaining headroom. The other side will argue that each settlement is separate, and the cap remains available again for the next issue. That is not a philosophical disagreement. It is a drafting omission.

Second, stacking. Life sciences contracting is modular by design: statements of work, change orders, study addenda, purchase orders, batches, territories, affiliates. If the clause does not say whether the cap is agreement-wide or repeats per module, someone will argue it repeats. If you are the party exposed, that is where “one cap” becomes “one cap per SOW”, which becomes “one cap per site”, which becomes a number no one priced. If you are the party seeking protection, you may actually want per-study caps. Again, that is fine. But it needs to be explicit.

I

f you cannot tell from the clause whether the cap stacks across SOWs, POs, studies, or batches, you are not looking at a finished cap.

A 30-second sanity check before you sign

This all sounds like a lot. But you do not need to become the person who argues about the word “aggregate” for fun. You just need a quick way to catch the four usual traps. Here is the 30-second sanity check we use. You should be able to answer each question in one sentence without guessing. If you cannot, the cap is not doing its job.

1. One cap or multiple caps?

   Does the wording clearly establish a single cap “for all Claims in aggregate”, or does it leave room for a reset per claim, per event, per contract year, or per SOW?

   
   

2. What fixes the cap number?

   If the cap is fee-based, can you point to a single date that fixes the calculation (first claim notice, first incident, event giving rise, contract year), or is it a moving target?

   
   

3. What exactly is the fee base?

   Is it “paid” or “paid or payable”? If it is “paid”, is there a floor so the cap is not meaningless early on? If it is “payable”, is it limited to amounts due and undisputed, and does it exclude pass-through costs if that is the intent?

   
   

4. Does the cap burn down and does it stack?

   Does the clause say that payments reduce remaining headroom? Does it say whether the cap applies once across the agreement, or repeats across SOWs, POs, studies, batches, affiliates, or renewals?

   
   

If all four answers are clear, you have done more risk management in 30 seconds than most teams do in three rounds of redlines.

Contract type varies, mechanics stay the same

At this point, someone usually says: “Sure, but a CRO MSA is not a CDMO supply agreement, and neither is an out-license.” Correct. The cap amount, the carve-outs, and what feels commercially reasonable will differ. A clinical trial services arrangement has different failure modes than a manufacturing campaign. A licensing deal often has economics that do not map neatly to “12 months’ fees”. That is exactly why copy-pasting generic cap language gets people into trouble.

Still, across life sciences contract types, the cap disputes that actually get litigated tend to come from the same mechanical gaps. The label on the counterparty changes (supplier, manufacturer, CRO, contractor, licensor, licensee). The mechanics do not.

A few examples of how the same four mechanics show up in different “market standard” wrappers:

• CRO MSAs and clinical trial vendor SOWs often tie caps to study fees or to a 12-month lookback. That is fine. The failure is leaving “preceding the claim” undefined, or letting SOWs stack by accident. If you cannot say whether the cap is per study, per SOW, or across the relationship, you do not yet have a cap.

  
  

• CDMO manufacturing and supply often has modular building blocks (campaigns, batches, tech transfer phases, quality events). Parties may prefer a per-batch or per-campaign cap, sometimes with an overall annual ceiling. That can be perfectly sensible. But then you need to define whether multiple batches from one deviation are one “event” or many, and you need to be explicit about stacking. Otherwise the cap becomes a debate about how to count batches, not how to manage risk.

  
  

• R&D collaborations often start with modest cash but high strategic value. A cap expressed as “fees paid” can be crystal clear and still commercially awkward if it implies a near-zero cap early on. That is where a floor matters. Conversely, “paid or payable” can feel fairer, but only if “payable” is tightly framed to avoid future fights about disputed invoices or unperformed commitments.

  
  

• Licensing and out-licensing rarely fit neatly into “12 months’ fees”. The cap is more often tied to a fixed amount, or to the total consideration actually paid to date (for example upfront plus milestones actually paid), sometimes with a time-based frame such as “in the [x] years preceding the claim” or “since the effective date”. “Payable” is often avoided because royalties and future contingent payments are too uncertain and too easy to argue about. You also sometimes see the licensee push for an anniversary-style reset, for example a cap per contract year, particularly where the financial relationship grows over time. At the other end of the spectrum, some licensing deals do not include a separate cap on direct damages at all. They rely on (i) a clean exclusion of indirect damages and (ii) an indemnity and insurance regime to do the heavy lifting. That approach can be coherent, but only if the agreement is explicit about which liabilities are handled exclusively through indemnities and which remain exposed.

  
  

In other words, the “right” cap will vary by contract type. The mechanics that make a cap behave like a cap are universal. If you lock the mechanics, the remaining negotiation is at least about real economics, not about interpretive ambiguity.

Final words of advice

Liability caps do not usually fail because the number is wrong. They fail because the clause lets the number behave differently depending on who is reading it.

You do not need a longer limitation section to fix that. You need four things to be unambiguous: whether the cap applies once, what fixes the calculation date, whether payments burn it down, and whether it stacks. Get those mechanics right, and you prevent most of the disputes that make “standard” caps anything but standard.