Haftungsbegrenzung im Vertrag: So formulieren Sie einen wirksamen Liability Cap, der wirklich gilt

Der heutige Beitrag sieht auf den ersten Blick nach Stoff für Vertrags-Nerds aus. Ist er nicht. Wenn Sie Verträge unterschreiben, verhandeln oder irgendwann in den berüchtigten „Können wir das bitte einfach closen?“-Call gezogen werden, dann ist dieser Text für Sie.

Thema: Haftungsbegrenzungen. Die Klausel, von der alle behaupten, sie sei nicht verhandelbar, bis zu dem Moment, in dem sie vier Wochen lang verhandelt wird. Die Klausel, die es irgendwie schafft, gleichzeitig (i) „Market Standard“ zu sein und (ii) der Grund dafür, dass Ihr Deal seit der letzten Eiszeit im Legal Review festhängt.

Fast alle fokussieren sich auf die Zahl, die man in das Template einträgt. 100% der Gebühren. 200% der Gebühren. „Zwölf Monate vor … irgendwas.“ Ein fixer Euro-Betrag, den jemand aus einem Template von 2017 gezogen hat und den niemand anzufassen wagt. Manchmal ist die Zahl sehr groß. Manchmal ist sie still und leise erschreckend niedrig. In jedem Fall endet die Diskussion oft mit: gut, nehmen wir diese Zahl und weiter.

Hier kommt der unbequeme Teil: Die Zahl ist nicht das eigentliche Problem.

Haftungsbegrenzungen sollen Sicherheit schaffen. Genau daran scheitern sie oft. Denn Parteien einigen sich zwar auf einen Cap-Betrag oder eine fee-basierte Formel, lassen aber die Mechanik des Caps vage. Und genau dort entstehen die Streitigkeiten. Später, wenn etwas schiefläuft, können beide Seiten plausibel für einen anderen Cap argumentieren. Die eine Seite glaubt, sie habe eine harte Obergrenze gekauft. Die andere glaubt, die Obergrenze resetet sich. Oder verschiebt sich. Oder wird nie „verbraucht“. Oder stapelt sich über Projekt-Orders wie Treuepunkte.

Life Sciences ist dafür besonders anfällig, weil dieselbe Cap-Sprache in völlig unterschiedliche Vertragsbeziehungen kopiert wird: CRO-MSAs, CDMO-Supply, F&E-Kooperationen, Software-T&C und Lizenzdeals. Unterschiedliche Fakten, gleiche Mehrdeutigkeit. Alle glauben, sie hätten „einen Cap“ vereinbart. Der Wortlaut lässt aber Raum für mehrere Caps, bewegliche Caps und Caps, die faktisch gar nicht cappen.

Die gute Nachricht: Die meisten dieser Konflikte lassen sich mit vier kurzen Drafting-Ergänzungen vermeiden. Sie brauchen keine längere Klausel. Sie brauchen eine Klausel, die tatsächlich das tut, was sie verspricht.

Die „80%-Lösung“ in vier Ergänzungen, oder: vier Punkte, die Sie vor Unterschrift prüfen sollten

Die meisten Cap-Streits entstehen nicht, weil die Gegenseite besonders kreativ ist. Sie entstehen, weil eine Klausel vertraut genug aussieht, um den Skim-Read zu überstehen, aber vier zentrale Fragen offenlässt. Wenn Sie künftige „Das war doch nicht so gemeint“-Calls vermeiden wollen, sind das die vier typischen Stolperfallen.

1. Gilt der Cap einmal, oder kann er sich still und leise resetten?

   
   

Wenn die Klausel „total aggregate liability“ sagt, aber nicht klarstellt, wovon genau aggregiert wird, sind Sie in der Gefahrenzone. „Aggregate“ kann gelesen werden als „aggregiert pro Claim-Kategorie“, „aggregiert pro Ereignis“ oder „aggregiert zu jedem Zeitpunkt“. Viele nehmen an, es sei „ein Topf“. Nicht alle liegen damit richtig.

Was Sie sehen wollen, ist Sprache, die das Cap-Multiplikationsargument vollständig ausschließt, etwa „for all Claims in aggregate“. Ohne diese Klarstellung kann die andere Seite versuchen, den Sachverhalt in mehrere Ansprüche zu zerlegen und für jeden einen eigenen Cap zu reklamieren.

Fairerweise gilt: Ein Cap pro Claim kann in bestimmten Konstellationen die richtige wirtschaftliche Lösung sein. Wenn Sie Dienstleistungen für viele unabhängige Studien einkaufen oder wenn Sie als Kunde nicht akzeptieren können, dass ein früher Fehler „den gesamten Schutz“ für spätere Jahre aufbraucht, kann ein Cap pro Claim oder pro Studie eine sinnvolle Risikoverteilung sein. Der Punkt ist nicht, dass „ein Topf“ immer richtig ist. Der Punkt ist, dass die Klausel Sie nicht im Unklaren lassen darf, ob Sie eine Obergrenze verhandelt haben oder einen Automaten, der immer wieder neue Caps ausspuckt.

2. Wenn der Cap fee-basiert ist: Was fixiert das Zeitfenster?

   
   

Jede Klausel, die sagt „fees paid in the 12 months preceding the claim“, sollte bei Ihnen dieselbe Reaktion auslösen wie „das klären wir später“. Vor welchem Claim genau? Gemessen zu welchem Datum? Dem Datum der Claim Notice? Dem Datum der Klageeinreichung? Dem Datum des „event giving rise“? Jede dieser Varianten kann den Betrag erheblich verändern, insbesondere in einer wachsenden Beziehung.

Hier zeigt sich die Verhandlungsposition in der Praxis. Die Partei, die ihre Exposure begrenzen will, bevorzugt häufig einen Anker, der den Cap früh einfriert, etwa die erste Claim Notice. Die Partei, die Schutz proportional zur wachsenden Beziehung will, bevorzugt einen Anker, der mitläuft, etwa die zwölf Monate vor dem relevanten Ereignis oder ein Contract-Year-Modell. Beides kann vertretbar sein. Nicht vertretbar ist, den Anknüpfungspunkt offen zu lassen und das dann „market“ zu nennen.

Wenn Sie die Klausel lesen und einem Commercial-Kollegen nicht in einem Satz erklären können, welches Datum die Berechnung fixiert, ist die Klausel nicht fertig.

3. „Fees paid“ vs „fees paid or payable“: Ist der Cap klar, und ist er realistisch?

   
   

Das wirkt wie Haarspalterei, bis es der gesamte Streit wird.

„Fees paid“ ist sauber. Es ist leicht administrierbar. Es ist schwer zu manipulieren. Aber es hat eine offensichtliche Falle: Früh in der Beziehung oder in Projekten, die noch kaum fakturiert sind, kann „fees paid“ zu einem Cap führen, der so niedrig ist, dass er wirtschaftlich bedeutungslos wird. Wenn Sie sich auf den Cap als Schutz verlassen, sollte Sie das beunruhigen. Wenn Sie den Cap anbieten, wirkt es auf dem Papier attraktiv, bis es den Deal torpediert oder im Ernstfall kaum noch zu vertreten ist. Die marktübliche, robuste Lösung ist nicht eine längere Klausel. Es ist ein Floor. Ein schlichtes „greater of € X or fees paid“ verhindert, dass der Cap zu „Taschengeld“ wird, ohne eine Buchhaltungsdebatte zu eröffnen.

„Fees paid or payable“ löst das Low-Cap-Problem, schafft aber ein neues: Was gilt als „payable“? Strittige Rechnungen? Termination Charges? Mindestabnahmen? Meilensteine, die durch Zeitablauf ausgelöst werden statt durch Leistung? Pass-through-Kosten und Drittanbieter-Auslagen? Wenn Sie schon einmal darüber gestritten haben, ob eine Rechnung ordnungsgemäß gestellt wurde, wissen Sie, wie das endet. Wenn Sie „paid or payable“ ohne Leitplanken sehen, sollten Sie davon ausgehen, dass Sie ein künftiges Accounting-Argument unterschreiben. Das kann akzeptabel sein. Es sollte dann aber eine bewusste Entscheidung sein und kein Drafting-Unfall.

4. Cappt der Cap wirklich, oder kann er durch Zahlungen und Stacking überschritten werden?

   
   

Zwei kleine Mechaniken entscheiden, ob der Cap eine echte Obergrenze ist oder nur eine höfliche Empfehlung.

Erstens: Burn-down. Wenn die Klausel nicht sagt, ob bereits gezahlte Beträge den verbleibenden Cap reduzieren, haben Sie Raum für Streit. Eine Seite wird argumentieren, der Cap sei ein Gesamtmaximum über die Laufzeit, also „verbraucht“ jede Zahlung die verbleibende Headroom. Die andere Seite wird argumentieren, jede Zahlung sei separat und der Cap stehe für den nächsten Vorfall wieder voll zur Verfügung. Das ist kein philosophischer Streit. Es ist ein Drafting-Fehler.

Zweitens: Stacking. Life-Sciences-Verträge sind modular aufgebaut. Statements of Work, Change Orders, Study Addenda, Purchase Orders, Batches, Territories, Affiliates. Wenn die Klausel nicht sagt, ob der Cap vertragsweit gilt oder pro Modul erneut greift, wird jemand argumentieren, dass er sich wiederholt. Wenn Sie die exponierte Partei sind, ist das der Moment, in dem „ein Cap“ zu „ein Cap pro SOW“ wird, dann zu „ein Cap pro Site“ und am Ende zu einer Summe, die niemand eingepreist hat. Wenn Sie Schutz suchen, kann ein Cap pro Studie durchaus gewollt sein. Das ist in Ordnung. Es muss nur ausdrücklich geregelt werden.

Wenn Sie aus der Klausel nicht eindeutig entnehmen können, ob der Cap über SOWs, POs, Studien oder Batches hinweg stackt, sehen Sie keinen fertigen Cap.

Ein 30-Sekunden-Sanity-Check vor Unterschrift

Das klingt nach viel. Sie müssen aber nicht die Person werden, die aus Spaß über das Wort „aggregate“ streitet. Sie brauchen nur einen schnellen Check, um die vier typischen Fallen zu erkennen. Hier ist der 30-Sekunden-Test, den wir nutzen. Sie sollten jede Frage in einem Satz beantworten können, ohne zu raten. Wenn nicht, macht der Cap seinen Job nicht.

• Gibt es einen Cap oder mehrere Caps? Stellt der Wortlaut klar einen einzigen Cap „for all Claims in aggregate“ her, oder lässt er Raum für Resets pro Claim, pro Ereignis, pro Vertragsjahr oder pro SOW?

• Was fixiert die Cap-Berechnung? Wenn der Cap fee-basiert ist: Können Sie ein konkretes Datum benennen, das die Berechnung festlegt (erste Claim Notice, erster Incident, auslösendes Ereignis, Vertragsjahr), oder ist es ein bewegliches Ziel?

• Was ist genau die Fee-Basis? Ist es „paid“ oder „paid or payable“? Wenn es „paid“ ist: Gibt es einen Floor, damit der Cap zu Beginn nicht bedeutungslos ist? Wenn es „payable“ ist: Ist es auf fällige und unbestrittene Beträge beschränkt, und schließt es Pass-through-Kosten aus, wenn das gewollt ist?

• Reduziert sich der Cap mit der Zeit oder erhöht sich die Summe mit der Zeit ? Sagt die Klausel, dass Zahlungen die verbleibende Headroom reduzieren? Sagt sie, ob der Cap einmal vertragsweit gilt oder sich über SOWs, POs, Studien, Batches, Affiliates oder Renewals wiederholt?

  
  

Wenn alle vier Antworten klar sind, haben Sie in 30 Sekunden mehr Risikomanagement betrieben als viele Teams in drei Redline-Runden.

Der Vertragstyp variiert, die Mechanik bleibt gleich

An diesem Punkt sagt meist jemand: „Klar, aber ein CRO-MSA ist nicht dasselbe wie ein CDMO-Supply-Agreement, und beides ist kein Out-License.“ Richtig. Der Cap-Betrag, die Carve-outs und das, was sich wirtschaftlich angemessen anfühlt, unterscheiden sich. Ein Clinical-Trial-Services-Vertrag hat andere Failure Modes als eine Manufacturing Campaign. Ein Lizenzdeal hat häufig Economics, die nicht sauber auf „12 months’ fees“ passen. Genau deshalb bringt Copy-Paste von generischer Cap-Sprache Menschen in Schwierigkeiten.

Trotzdem gilt: Über die verschiedenen Vertragstypen hinweg entstehen die Cap-Streitigkeiten, die tatsächlich eskalieren, fast immer aus denselben mechanischen Lücken. Der Counterparty-Label wechselt (Supplier, Manufacturer, CRO, Contractor, Licensor, Licensee). Die Mechanik nicht.

Ein paar Beispiele, wie dieselben vier Mechaniken in unterschiedlichen „Market Standard“-Hüllen auftauchen:

• CRO-MSAs und klinische Vendor-SOWs knüpfen Caps häufig an Studiengebühren oder an ein 12-Monats-Lookback. Das ist grundsätzlich in Ordnung. Der Fehler ist, „preceding the claim“ undefiniert zu lassen oder SOWs unbeabsichtigt stacken zu lassen. Wenn Sie nicht sagen können, ob der Cap pro Studie, pro SOW oder über die gesamte Beziehung gilt, haben Sie noch keinen Cap.

• CDMO-Manufacturing und Supply ist oft modular strukturiert, etwa über Campaigns, Batches, Tech-Transfer-Phasen und Quality Events. Parteien bevorzugen hier manchmal einen Cap pro Batch oder pro Campaign, gelegentlich ergänzt um ein jährliches Gesamtmaximum. Das kann sinnvoll sein. Dann müssen Sie aber definieren, ob mehrere Batches aus einer Abweichung ein Ereignis oder mehrere sind. Und Sie müssen Stacking ausdrücklich regeln. Sonst wird der Cap am Ende zu einer Debatte darüber, wie man Batches zählt, statt darüber, wie man Risiko steuert.

• F&E-Kooperationen starten häufig mit moderaten Cash-Flows, aber hoher strategischer Bedeutung. Ein Cap als „fees paid“ kann glasklar sein und trotzdem wirtschaftlich schief wirken, wenn er zu Beginn faktisch nahe null liegt. Hier hilft ein Floor. Umgekehrt kann „paid or payable“ fairer wirken, aber nur, wenn „payable“ eng definiert ist, um spätere Streitigkeiten über strittige Rechnungen oder nicht erbrachte Commitments zu vermeiden.

• Lizenzierung und Out-Licensing passt selten sauber in „12 months’ fees“. Caps sind hier häufiger fix, oder sie knüpfen an die tatsächlich gezahlte Gegenleistung an, etwa Upfront plus tatsächlich gezahlte Milestones, teilweise ergänzt um eine Zeitkomponente wie „in den [x] Jahren vor dem Claim“ oder „seit Effective Date“. „Payable“ wird häufig vermieden, weil Royalties und künftige contingent payments zu unsicher und zu streitanfällig sind. Teilweise drängt der Lizenznehmer auf ein Anniversary-Reset, etwa einen Cap pro Vertragsjahr, insbesondere wenn die wirtschaftliche Beziehung über Zeit wächst. Am anderen Ende des Spektrums enthalten manche Lizenzdeals gar keinen separaten Cap für direkte Schäden. Sie verlassen sich stattdessen auf (i) einen sauberen Ausschluss indirekter Schäden und (ii) ein Indemnity- und Insurance-Regime, das die wesentlichen Risiken abdeckt. Das kann kohärent sein, aber nur, wenn der Vertrag ausdrücklich regelt, welche Haftungen ausschließlich über Freistellungen abgewickelt werden und welche offen bleiben.

Mit anderen Worten: Der „richtige“ Cap hängt vom Vertragstyp ab. Die Mechanik, die einen Cap zu einem Cap macht, ist universell. Wenn Sie die Mechanik sauber fixieren, verhandeln Sie danach wenigstens über echte Economics und nicht über Auslegungsnebel.

Abschließender Rat

Haftungsbegrenzungen scheitern selten daran, dass die Zahl falsch ist. Sie scheitern daran, dass die Klausel zulässt, dass die Zahl sich je nach Lesart unterschiedlich verhält.

Sie brauchen keine längere Haftungssektion, um das zu lösen. Sie brauchen vier Dinge, die unmissverständlich sind: Gilt der Cap einmal? Welches Datum fixiert die Berechnung? Brennen Zahlungen den Cap ab? Und stackt der Cap? Wenn diese Mechaniken sauber sind, verhindern Sie die meisten Streitigkeiten, die „standard“ Caps in der Praxis alles andere als standard machen.