Die Pflichten, Preisklauseln und Fristen, die in einem unterzeichneten Vertrag vergraben sind, sind genau das, worauf jemand reagieren sollte, und meistens tut es niemand. Contract Intelligence ist die Schicht, die diese Klauseln aus den PDFs extrahiert, jede einzelne dem richtigen Lieferanten und seinem Ausgabenvolumen zuordnet und die Fristen überwacht, damit eine Verlängerung oder eine Preisstufe die Finanzabteilung nicht mehr überrascht.
Die meisten Unternehmen haben die Verträge längst. Sie liegen auf einem geteilten Laufwerk, im CLM-System, als E-Mail-Anhang, in drei Formaten und vier Benennungskonventionen. Niemand liest sie erneut. Das vor zwei Jahren unterzeichnete MSA enthält eine an einen Index gekoppelte jährliche Preisgleitklausel, ein 90-tägiges Kündigungsfenster und eine Mengenstaffel, die im letzten Quartal Ihren effektiven Preis stillschweigend verändert hat. All das ist bekannt. Nichts davon ist sichtbar, es sei denn, jemand öffnet die Datei und liest bis Seite elf. Die Arbeit besteht darin, aus einem statischen Archiv etwas zu machen, das Fragen beantwortet und sich meldet, bevor eine Frist abläuft.
Die Extraktion ist nur so gut wie die Klausel-Taxonomie
Der erste Fehler, den Teams machen, besteht darin, dies als Problem der Dokumentenzusammenfassung zu behandeln. Zusammenfassungen sind nicht nachprüfbar. Sie können einen Fließtext nicht gegen ein Hauptbuch abstimmen, und Sie können keinen Alert auf ein Bauchgefühl setzen. Was Sie brauchen, ist strukturierte Extraktion gegen ein definiertes Schema, und das Schema kommt vor dem Modell.
Wir beginnen damit, eine Klausel-Taxonomie festzulegen: die konkreten Klauseltypen, die Geld, Risiko oder ein Datum tragen. Für ein Einkaufsportfolio sind das in der Regel zwanzig bis dreißig Typen.
- Verlängerung und Kündigung: Auto-Renewal-Flag, Verlängerungslaufzeit, Kündigungsfrist, Kündigungsform, Wirksamkeits- und Ablaufdatum.
- Preisgestaltung: Basispreis, Währung, Preisgleitmechanismus und dessen Cap, Mengenstaffeln, Meistbegünstigungsklauseln, Zahlungsbedingungen.
- Pflichten: SLAs und deren Gutschriften, Mindestabnahmen, Exklusivität, Auftragsverarbeitung und Prüfrechte.
- Haftung und Ausstieg: Haftungshöchstgrenzen, Freistellungen, Abtretung bei Change of Control, anwendbares Recht.
Jedes Feld hat einen Typ, eine Quellenstelle (Source Span) im Dokument und einen Confidence Score. Die Quellenstelle ist wichtiger als der Wert selbst. Wenn das System sagt, die Kündigungsfrist betrage 90 Tage, verweist es auf den Satz, aus dem es das gelesen hat, sodass ein Mensch es in zwei Sekunden bestätigen kann, statt den Vertrag erneut zu öffnen. Diese Stelle ist der Audit Trail. Ohne sie haben Sie eine Zahl ohne Herkunft, und kein Controller wird das abzeichnen.
Die Extraktion läuft pro Dokument, aber gemessen wird gegen die Taxonomie. Wir bauen ein Eval-Set aus Verträgen, die von Hand gelesen und annotiert wurden, und wir bewerten jeden Feldtyp getrennt. Ein Modell, das das anwendbare Recht perfekt trifft, aber Preis-Caps verfehlt, ist ein schlechtes Modell für einen Finanz-Use-Case, denn bei den Caps liegt das Geld. Aggregierte Genauigkeit verdeckt genau die Fehler, die Sie teuer zu stehen kommen.
Bei der Entity Resolution wird das Portfolio abfragbar
Ein einzelner extrahierter Vertrag ist eine Kuriosität. Das Portfolio wird erst nützlich, wenn Sie es abfragen können, und das bedeutet, jedes Dokument den Entitäten zuzuordnen, die das Finanzwesen ohnehin schon führt.
Derselbe Lieferant erscheint über drei Verträge hinweg als “Acme Corp”, “Acme Corporation Ltd” und “ACME (EMEA)”, und keine dieser Zeichenketten stimmt mit dem Namen im ERP-Lieferantenstamm überein. Entity Resolution verknüpft die Vertragspartei aus dem Vertrag mit dem Lieferantensatz, der die Ausgaben, die Zahlungsbedingungen und die Bestellungen trägt. Solange diese Verknüpfung fehlt, können Sie die eigentlich entscheidende Frage nicht beantworten: Wozu haben wir uns diesem Lieferanten gegenüber vertraglich verpflichtet, und was haben wir dagegen ausgegeben?
Verträge bilden außerdem Hierarchien. Ein Rahmenvertrag steuert Statements of Work und Nachträge, die jeweils bestimmte Klauseln überschreiben. Ein im letzten März unterzeichneter Nachtrag mag den Preis geändert und alles andere unberührt gelassen haben, sodass die aktuell geltende Klausel der Rahmentext ist, wie er durch jeden Nachtrag der Reihe nach modifiziert wurde. Das System muss diese Kette rekonstruieren und den aktuellen Zustand berechnen, nicht jedes Dokument isoliert extrahieren. Point-in-Time-Korrektheit gilt hier genauso wie in einem Feature Store: Für einen Drei-Wege-Abgleich zählt der zum Rechnungsdatum geltende Preis, nicht der Preis im neuesten Nachtrag.
Sind Resolution und Hierarchie erst einmal etabliert, beantwortet das Portfolio echte Fragen. Welche Verträge verlängern sich in den nächsten 60 Tagen? Welche tragen eine Preisgleitklausel ohne Cap? Wo übersteigt die Gesamt-Mindestabnahme die prognostizierte Nutzung? Welche Lieferanten haben Meistbegünstigungsklauseln, gegen die wir womöglich verstoßen, weil wir jemand anderem einen besseren Preis geben?
Erst das Monitoring macht aus der Extraktion etwas, das sich rechnet
Extraktion ist ein einmaliger Akt pro Dokument. Monitoring läuft kontinuierlich, und genau hier verdient sich die Schicht ihr Geld. Zwei Mechanismen setzen auf den extrahierten Daten auf.
Der erste ist ein Verlängerungs- und Pflichtenkalender. Jede fristbehaftete Klausel wird zu einem Eintrag mit einer Vorlaufzeit, die aus ihrer Kündigungsfrist abgeleitet wird. Ein Vertrag mit einem 90-tägigen Kündigungsfenster taucht an Tag 120 auf und gibt dem Einkauf Raum, zu entscheiden und nachzuverhandeln, statt die automatische Verlängerung erst zu bemerken, nachdem sie ausgelöst wurde. Pflichten mit wiederkehrenden Fristen, etwa ein Quartalsreporting oder ein jährliches Prüfrecht, erzeugen ihre eigenen wiederkehrenden Alerts.
Der zweite ist die Drift-Erkennung gegen die Realität. Der Vertrag sagt, die Preisanpassung ist bei 4 % gedeckelt. Die Rechnung dieses Quartals weist 6 % aus. Diese Lücke ist ein Monitoring-Alert, erzeugt von derselben Abgleichslogik, die unter dem Rechnungsabgleich sitzt, nur diesmal auf die Vertragsklauseln als Source of Truth gerichtet. Wenn der extrahierte Preisplan und die tatsächlichen Belastungen auseinanderlaufen, erfährt jemand noch innerhalb des Quartals davon, statt erst beim jährlichen True-up.
Beide Mechanismen stehen und fallen mit dem Budget für False Positives. Ein Alerting-System, das ständig falschen Alarm schlägt, wird innerhalb einer Woche stummgeschaltet, und ein stummgeschalteter Alert ist schlimmer als gar keiner, denn er erzeugt die Illusion von Abdeckung. Wir justieren Schwellenwerte und Confidence Gates so, dass der Kalender nur das aufzeigt, was wirklich handlungsrelevant ist, und wir leiten unsichere Extraktionen an einen Menschen weiter, bevor sie überhaupt zu einem Alert werden. Bewerten Sie das System an Ergebnissen, nicht an Klauselzahlen: Wie viele Verlängerungen wurden rechtzeitig bearbeitet, und wie viele Preisfehler wurden abgefangen, bevor sie bezahlt wurden?
Häufige Fragen
Brauchen wir eine Klausel-Taxonomie, bevor wir mit der Extraktion beginnen?
Ja. Die Taxonomie ist das Schema, an dem das gesamte System gemessen wird. Definieren Sie also zuerst die zwanzig oder dreißig Klauseltypen, die Geld oder Pflichten tragen, und extrahieren Sie dann auf dieses Schema. Frei zu extrahieren und später zu ordnen erzeugt Felder, die niemand abstimmen kann.
Wie genau muss die Klauselextraktion sein, damit wir dem Verlängerungskalender vertrauen können?
Die Felder für Verlängerungsdatum und Kündigungsfrist müssen nahezu exakt sein, denn ein verpasstes Kündigungsfenster verlängert automatisch einen Vertrag, aus dem Sie eigentlich aussteigen wollten. Verfolgen Sie diese beiden Felder getrennt vom Rest und legen Sie einen strengeren Genauigkeitsmaßstab an, mit menschlicher Bestätigung bei allem, was das Modell als unsicher markiert.
Kann ein einziges Modell sowohl Einkaufsverträge als auch Kundenverträge verarbeiten?
Das Extraktions-Backbone ist gemeinsam, aber die Klausel-Taxonomie und die nachgelagerten Aktionen unterscheiden sich so stark, dass wir sie als getrennte Eval-Sets behandeln. Eine Preisgleitklausel bedeutet etwas anderes, wenn Sie der Käufer sind, als wenn Sie der Verkäufer sind.