KI-ROI im Finanzbetrieb messen: die Kennzahlen, die CFOs akzeptieren

Ein CFO gibt sein Okay zu Kennzahlen, die an Cash und Risiko gebunden sind: die Amortisation von Bau- und Betriebskosten, die Stückkosten pro bearbeitetem Vorgang vor und nach der Einführung, die Veränderung der Fehler- und Nacharbeitsquoten sowie die Kosten der Fehler, die das System selbst produziert. Eingesparte Stunden fließen in diese Zahlen ein, sind aber keine davon. Präsentieren Sie sie isoliert, wird eine gute Finanzleitung fragen, was sich an der GuV tatsächlich geändert hat.

Diese Frage ist berechtigt, und die meisten KI-Business-Cases scheitern an ihr. Ein Modell, das Abstimmungen schneller vorbereitet, hat nichts eingespart, wenn die Entwürfe weiterhin vollständig von Hand nachgeprüft werden oder wenn die freigewordenen Stunden nie in eine Personalentscheidung, in umgeschichtete Arbeit oder in ohne Neueinstellungen aufgefangenes Wachstum münden. Der Wert zeigt sich an drei Stellen, und für jede gibt es eine Kennzahl, die ein Controller akzeptiert.

Amortisation und Stückkostenrechnung kommen zuerst

Beginnen Sie mit der Zahl, der das Unternehmen ohnehin vertraut: den Kosten pro Arbeitseinheit. Kosten pro bearbeiteter Rechnung, pro abgeschlossener Abstimmung, pro bearbeitetem Alert, pro erstellter Gutschrift. Messen Sie sie vollkostenbewertet, bevor das System existiert, und messen Sie sie erneut, wenn das System im Produktivbetrieb und stabil läuft, die KI-Kosten inklusive.

Die “Nachher”-Zahl ist die Stelle, an der die meisten Schätzungen weich werden. Sie muss tragen:

• Inferenzkosten pro Vorgang beim Produktivvolumen, nicht beim Demo-Prompt. Lange Dokumente, Retries und mehrstufige Ketten kosten in den Quartalsspitzen echtes Geld.
• Die menschliche Prüfung, die der Workflow weiterhin erfordert. Kontrolliert eine Person jede Ausgabe, haben Sie Aufwand verlagert statt beseitigt. Die ehrliche Zahl sind die Prüfkosten bei Ihrer tatsächlichen Straight-Through-Processing-Quote.
• Infrastruktur, den Feature Store und die Datenpipelines, die das Modell speisen, das Monitoring sowie die Engineering-Zeit, um Evals und Retraining aktuell zu halten.

Mit belastbaren Vorher-Nachher-Stückkosten ist die Amortisation reine Arithmetik. Gesamte Baukosten plus Betriebskosten des ersten Jahres, geteilt durch die jährliche Ersparnis beim erwarteten Volumen, ergeben die Dauer. Zwei Dinge entscheiden über Erfolg oder Misserfolg. Das erste ist die Straight-Through-Processing-Quote: der Anteil der Vorgänge, die das System ohne menschliches Zutun abschließt. Ein Sprung von 40 auf 70 Prozent STP bewegt den Case weit stärker als jede Schlagzeile zur Modellgenauigkeit, denn der Prüfaufwand ist meist der größte Posten. Das zweite ist die Volumensensitivität. Fixe Baukosten amortisieren sich über den Durchsatz, sodass ein Workflow mit zehntausend Vorgängen pro Monat und einer mit hundert selbst bei identischen Modellen unterschiedliche Investitionen sind.

Qualitätskennzahlen, die der Finanzbereich wirklich liest

Accuracy und F1 sagen einem Controller nichts. Übersetzen Sie Modellqualität in die Sprache des Abschlusses und der Prüfung.

• Ausnahmequote und ihr Trend. Welcher Anteil der Ausgaben braucht menschliche Korrektur, und sinkt er, während das Eval-Set wächst und das Modell nachjustiert wird?
• Nacharbeitskosten. Wenn das System falsch liegt, wie lange dauert die Korrektur, und kostet eine schlechte Ausgabe mehr an Reparatur als der manuelle Prozess, den sie ersetzt hat? Eine selbstbewusst falsche Zahl in einer Abstimmung kann mehr kosten als der gesamte eingesparte Entwurf.
• Veränderung der Durchlaufzeit bei einer Größe, die das Unternehmen ohnehin berichtet. Tage bis zum Abschluss, Days Sales Outstanding, Alter des Alert-Backlogs. Binden Sie das System an eine Kennzahl, die im Board-Pack auftaucht, und der Case hält der Prüfung stand.
• Vollständigkeit des Audit Trails. Jede KI-gestützte Entscheidung braucht Lineage: welche Inputs eingingen, welche Modellversion und welcher Prompt die Ausgabe erzeugten und was ein Mensch verändert hat. Unter Modellrisiko-Erwartungen wie SR 11-7 ist ein Modell, das Sie nicht dokumentieren können, ein Modell, das Sie nicht einsetzen dürfen. Diesen Trail nachträglich zu rekonstruieren, ist ein eigener Kostenblock.

Die Disziplin, die diese Zahlen ehrlich hält, ist Point-in-Time-Korrektheit in der Art, wie Sie evaluieren. Messen Sie Qualität auf den Daten, wie sie zum Zeitpunkt der Entscheidung vorlagen, ohne Vorgriff auf Informationen, die erst später eintrafen. Leakage bläht Offline-Kennzahlen auf und erzeugt einen Business Case, der im Produktivbetrieb in sich zusammenfällt. Legen Sie ein kuratiertes Eval-Set beiseite, versionieren Sie es und berichten Sie dagegen, nicht gegen das, was das Modell letzte Woche gesehen hat.

Das Risiko bepreisen: False Positives und das, was durchrutscht

Jedes Finance-Ops-Modell sitzt auf einem Schwellenwert, und der Schwellenwert ist eher eine ökonomische als eine technische Entscheidung. Verschieben Sie ihn in die eine Richtung, fangen Sie mehr ab, überschwemmen aber die Prüfer mit False Positives. Verschieben Sie ihn in die andere, erledigen Sie mehr automatisch, lassen aber mehr Fehler durch. Sie können nicht über ROI argumentieren, ohne beide Seiten zu bepreisen.

Die Kosten von False Positives sind konkret. Nehmen Sie die False-Positive-Rate bei Ihrem gewählten Schwellenwert, multiplizieren Sie mit dem Volumen und mit den vollkostenbewerteten Minuten, die ein Analyst für die Bearbeitung jedes einzelnen Falls aufwendet. Im Transaction Monitoring ist diese Zahl oft der dominierende Betriebskostenblock des gesamten Systems, größer als Modelle und Plattform zusammen. Sie zu senken, ist häufig der Ort, an dem die eigentliche Rendite steckt, weshalb ein False-Positive-Budget als expliziter Posten in den Business Case gehört und nicht als nachträglicher Gedanke.

Die Kosten dessen, was durchrutscht, sind schwerer zu fassen, müssen aber geschätzt werden, denn sie zu ignorieren, ist der Weg, einen Case zu bauen, der den falschen Schwellenwert optimiert. Bepreisen Sie für jeden False Negative den erwarteten Schaden: ausgezahlten Betrug, ein Bußgeld, eine korrigierte Zahl, Remediation. Einige davon sind schwerwiegend und selten, also arbeiten Sie mit Erwartungswerten und legen die Annahmen offen. Ein Modell, das den Prüfaufwand halbiert, während es übersehenen Betrug verdoppelt, ist kein Gewinn. Nur ein zweiseitiges Kostenmodell zeigt das.

Zwei weitere Risiken verdienen jeweils einen eigenen Posten. Drift zehrt die Rendite still aus. Ein Modell, das im Januar gut kalibriert war, kann bis zum Quartalsende degradieren, wenn sich Verhalten und Daten verschieben. Die Betriebskosten müssen daher Monitoring und periodische Neukalibrierung enthalten, und der Business Case sollte von gehaltener Leistung ausgehen, nicht von der Leistung am Starttag. Das zweite ist Konzentration. Wenn ein automatisierter Entscheidungspfad den Großteil Ihres Volumens abwickelt, skalieren die Kosten eines Fehlers mit diesem Anteil, was sowohl das Prüfdesign als auch die Risikozahl verändert.

Zusammengenommen liest sich der Case als ein Satz, auf den ein CFO handeln kann: Bei diesem Volumen und diesem Schwellenwert kostet das System X pro Vorgang all-in, erledigt Y Prozent ohne Menschen, und seine Fehler tragen erwartete Kosten von Z, womit der Bau sich in N Monaten amortisiert. Jeder Term in diesem Satz ist messbar. Keiner davon ist “eingesparte Stunden”.