Eine Covenant-Verletzung kündigt sich selten an. Der Vertrag legt einen Test fest, die Zahlen des Kreditnehmers driften, und die Schwelle wird Wochen überschritten, bevor irgendjemand es meldet. Covenant-Überwachung zu automatisieren heißt, die vertraglichen Bedingungen in maschinell prüfbare Definitionen zu übersetzen, sie an unterjährige Daten anzubinden und den Test bei jeder neuen Eingabe neu zu rechnen, damit ein Bruch am Tag seines Eintretens sichtbar wird und nicht erst zum Quartalsende.
Die meisten Kreditgeber verfolgen ihre Covenants bereits irgendwo in einer Tabelle. Die Bedingungen zu kennen war nie das Schwere. Das Problem ist strukturell: Diese Tabelle wird jedes Quartal von Hand neu gebaut, nur bei Eingang der Abschlüsse getestet und ist von dem Vertrag abgekoppelt, aus dem sie stammt. Dieser Aufbau garantiert, dass man von einem Bruch spät erfährt.
Das Schwere an der Extraktion sind die Definitionen
Die Covenant-Klausel aus einem Kreditvertrag zu ziehen ist der einfache Teil. Das Schwere ist, dass ein Covenant selten in sich abgeschlossen ist. Ein Leverage-Test liest sich als “Consolidated Net Leverage Ratio darf 3,50:1,00 nicht überschreiten”, und jeder Großbuchstaben-Begriff in dieser Zeile verweist woanders hin. Consolidated Net Leverage hat eine Definition. Diese Definition verweist auf EBITDA, das seine eigene Definition mit einem Stapel erlaubter Add-backs hat, auf einen Prozentsatz gedeckelte Run-rate-Synergien und ein Rückschaufenster. Net Debt saldiert Barmittel, aber nur solche, die einen definierten Test erfüllen.
Extrahiert man die Klausel und hört dort auf, hat man eine Schlagzeilenzahl erfasst und die Arithmetik weggeworfen. Die Extraktion muss also die Kette auflösen:
- Die Covenant-Klausel, ihre Schwelle, Richtung und Testfrequenz.
- Jeden definierten Begriff, von dem die Klausel abhängt, aus dem Definitionsteil gezogen und verlinkt, nicht paraphrasiert.
- Die Carve-outs und Baskets, die die Berechnung verändern, samt ihrer Caps und Reset-Bedingungen.
- Die Heilungsrechte und Equity-Cure-Mechanik, denn ein technisch gebrochener Covenant kann innerhalb eines Fensters noch geheilt werden, und ein Überwachungssystem, das das ignoriert, schlägt falschen Alarm.
Wir führen über all das Lineage. Jedes extrahierte Feld trägt einen Verweis zurück auf die Seite und Klausel, aus der es stammt, sodass ein Kreditverantwortlicher bei Zweifeln an einem Testergebnis die genaue vertragliche Formulierung dahinter sieht. Extraktion ohne diesen Audit-Trail ist in einer Kreditentscheidung unbrauchbar, weil die verantwortliche Person die Maschine nicht überprüfen kann.
Die Point-in-Time-Falle
Der mit Abstand häufigste Weg, wie Covenant-Automatisierung schiefgeht, ist, den heutigen Covenant gegen die gestrige Verpflichtung zu testen oder umgekehrt. Kreditverträge sind lebende Dokumente. Sie werden geändert. Ein Leverage-Step-down kann die Schwelle zu einem festgelegten Datum von 3,50 auf 3,25 verschieben. Ein Waiver kann einen Test für zwei Quartale aussetzen. Abschlüsse werden restatet, und die Zahl, die man letztes Quartal getestet hat, ist nicht mehr die maßgebliche.
Ein Überwachungssystem muss stichtagsgenau sein. Wenn es den Leverage-Covenant für die Periode zum 31. März testet, muss es die Schwelle, die Definitionen und die Finanzzahlen verwenden, die zu diesem Datum in Kraft waren, nicht die im Mai wirksam gewordene geänderte Schwelle. Das ist dieselbe Disziplin, die Lookahead aus einem Kreditmodell heraushält, angewendet auf Vertragsbedingungen statt auf Features. Der Speicher führt versionierte Datensätze: Schwellenhistorie, Definitionshistorie, Waiver-Historie und eine Finanzzahlen-Historie, die ein Restatement übersteht. Jeder Test ist gegen den Weltzustand an seinem Teststichtag reproduzierbar.
Hier verdient sich auch die Entity Resolution ihren Platz. Überwachung auf Portfolio-Ebene bedeutet, dass derselbe Kreditnehmer über mehrere Fazilitäten auftaucht und seine Töchter in Konsolidierungskreisen erscheinen, die sich zwischen Verträgen unterscheiden. Kann das System die berichtende Einheit in einem Compliance-Zertifikat nicht zuverlässig mit dem Schuldner im Vertrag verknüpfen, testet es mit voller Überzeugung die falschen Zahlen.
Testen zwischen den Berichtsstichtagen
Der Grund, warum Brüche spät erkannt werden, ist, dass Finanz-Covenants getestet werden, wenn das Compliance-Zertifikat eintrifft, und das ist bei den meisten Mittelstandsfazilitäten quartalsweise. Aber die zugrunde liegende Lage verschlechtert sich fortlaufend. Der Wert der Automatisierung liegt darin, die Lücke zwischen dem tatsächlichen Bruch eines Covenants und seiner Beobachtung zu schließen.
Zwei Kategorien verhalten sich unterschiedlich:
- Mechanische Finanz-Covenants können durchlaufen. Sind die Definitionen erfasst und die Eingaben abgestimmt, ist ein Leverage- oder Zinsdeckungstest reine Arithmetik. Das System rechnet ihn, vergleicht mit der geltenden Schwelle und verbucht ein Pass, ein Fail oder einen Headroom-Wert samt angehängter Berechnung.
- Ermessensbehaftete Covenants können das nicht. Eine Material-Adverse-Change-Klausel, ein Permitted-Investment-Test, der von einer Absicht abhängt, oder ein Berichts-Covenant mit Wesentlichkeitsvorbehalt darf nie automatisch als gebrochen behauptet werden. Das System kennzeichnet die Nähe und leitet an eine Person weiter.
Bei den mechanischen Tests warten wir nicht auf das Zertifikat. Wo unterjährige Daten vorliegen, etwa monatliche Management Accounts, Borrowing-Base-Zertifikate oder Cash-Positionen der Agentenbank, testet das System bei jeder neuen Eingabe neu und verfolgt Headroom als Trend. Ein Covenant mit 40 % Headroom, der über zwei Monate auf 5 % zuläuft, ist ein anderes Gespräch als eine statische Zahl, und es ist genau das Signal, das verloren geht, wenn man nur quartalsweise hinsieht.
Fortlaufendes Testen zwingt einen, False Positives direkt anzugehen. Ein Test, der auf veraltete oder unvollständige Daten anspringt, ist schlimmer als kein Test, weil er das Kreditteam darauf trainiert, Alerts zu ignorieren. Wir halten jeden Test gegen ein Eval-Set bekannter historischer Ausgänge, Brüche, Heilungen und saubere Passes, und wir setzen ein explizites False-Positive-Budget, bevor irgendetwas in der Queue eines Kreditverantwortlichen landet. Ein Alert, der sich mit den Quellzahlen abstimmen lässt und die getestete Klausel zitiert, ist einer, auf den eine Person reagiert. Ein Alert, der seine Herleitung nicht zeigen kann, wird binnen einer Woche stummgeschaltet, und dann ist die Automatisierung schlechter als die Tabelle, die sie ersetzt hat.
Unter all dem sitzt die Abstimmung. Ein Leverage-Test ist nur so gut wie die Debt- und EBITDA-Zahlen, die ihn speisen, und die stammen aus verschiedenen Systemen, die sich widersprechen. Die Überwachungsschicht muss die Zahlen, die sie testet, an eine Source of Record zurückbinden und die Diskrepanz sichtbar halten, damit ein fehlgeschlagener Test als echter Bruch und nicht als Datenkonflikt vertraut werden kann.
Häufige Fragen
Kann ein Modell selbstständig entscheiden, ob eine Auflage verletzt ist?
Bei einem mechanischen Finanz-Covenant mit klarer Formel ja, die Berechnung kann durchlaufen. Bei allem, was Ermessen erfordert, etwa einem Wesentlichkeitsvorbehalt oder einer erlaubten Ausnahme, sollte das System kennzeichnen und an eine Person weiterleiten, statt einen Bruch zu behaupten.
Wie geht ihr mit Auflagen um, die auf Definitionen an anderer Stelle im Vertrag verweisen?
Wir lösen sie zum Zeitpunkt der Extraktion auf. EBITDA in einem Covenant verweist meist auf einen definierten Begriff mit eigenen Anpassungen und Add-back-Baskets, also erfasst die Extraktion Verweis und Definition zusammen, und der Test nutzt die vertragliche Definition statt einer generischen.
Was ist das Point-in-Time-Problem bei der Covenant-Überwachung?
Ein Covenant muss gegen die Zahlen und Definitionen getestet werden, die am Teststichtag galten, nicht gegen die von heute. Nachträge, Waiver und restatete Abschlüsse ändern das Ergebnis, deshalb muss der Überwachungsspeicher die Versionshistorie führen und stichtagsbezogen testen.