Die SaaS-Kennzahlen, die eine KI wirklich richtig berechnet (wenn sie rechnet statt redet)

Fragen Sie einen KI-Assistenten von der Stange nach Ihrer Net Revenue Retention, und Sie bekommen eine Zahl. Sie sieht sauber aus, landet knapp über 100 Prozent und liest sich wie eine Antwort. Das Problem: Es ist fast nie Ihre Zahl. Es ist eine plausible Zahl, zusammengesetzt aus einer Definition, an die sich das Modell halb erinnert, einem Nenner, den es geraten hat, und Umsatztiming, das es nie gegen Ihr Hauptbuch geprüft hat. Für einen SaaS-CFO ist genau diese Lücke zwischen plausibel und korrekt die eigentliche Arbeit.

SaaS-Kennzahlen lassen sich ungewöhnlich leicht falsch berechnen und ungewöhnlich schwer als falsch erkennen. ARR, NRR, Bruttomarge, CAC-Payback, Magic Number, Burn Multiple: Keine davon ist schwierige Arithmetik. Es sind schwierige Definitionen, berechnet gegen unaufgeräumte Quelldaten. Wenn ein LLM über eine dieser Kennzahlen “spricht”, statt sie gegen abgestimmte Ist-Zahlen zu rechnen, driftet es auf eine Weise ab, die unsichtbar bleibt, bis ein Aufsichtsrat oder ein Due-Diligence-Team sie erwischt. Hier steckt der Drift, und das gehört dazu, ihn zu schließen.

”Welcher ARR?” ist die eigentliche Falle

Es gibt nicht den einen ARR. Es gibt vertraglich gebundenen ARR, fakturierten ARR, aktiven ARR, ARR abzüglich zugesagter Kündigungen und den “ARR”, den Ihr CRM anzeigt, weil jemand das Opportunity-Feld aufsummiert hat. Bei einem Unternehmen mit nutzungsbasierten Komponenten, unterjährigen Downgrades oder jährlichen Vorauszahlungen, die noch nicht live sind, können diese Werte um zweistellige Prozentsätze auseinanderliegen.

Ein Sprachmodell weiß nicht, welchen Sie meinen, also greift es sich stillschweigend einen heraus, meist die Definition, die in seinen Trainingsdaten dominierte, und rechnet, als wäre das geklärt. Es sagt Ihnen nicht, dass es gewählt hat. Derselbe Fehler taucht bei der NRR auf, wohl der am meisten strapazierten Zahl im SaaS-Geschäft. Net Revenue Retention hat eine feste Form: Man nimmt eine Kohorte von Kunden zu Periodenbeginn und misst dann den wiederkehrenden Umsatz derselben Kohorte zum Periodenende, inklusive Expansion, Contraction und Churn, aber ohne Neukunden. Verfehlt man eine dieser Grenzen, kommt eine andere Zahl heraus:

Häufiger NRR-Fehler	Was er mit der Zahl macht
Neukundenumsatz in der Endgröße mitzählen	Bläht die NRR auf, verdeckt Churn
MRR- und ARR-Basis über die Periode vermischen	Zufälliger Drift, oft unbemerkt
Durchschnittliche Kundenzahl als Nenner nutzen	Über- oder unterzeichnet Expansion
Reaktivierungen als Expansion werten	Überzeichnet die Retention

Jeder dieser Punkte ist eine Definitionsentscheidung, kein Rechenfehler. Eine KI, die in Prosa argumentiert, trifft die Entscheidung für Sie und präsentiert das Ergebnis in beiden Fällen mit derselben Überzeugung. Die Lösung ist kein klügeres Modell. Die Lösung ist, ARR und NRR ein einziges Mal explizit zu definieren und diese Definition jedes Mal gegen eine abgestimmte Kohorte zu rechnen.

Bruttomarge: der Nenner, auf den sich niemand einigt

Fragen Sie drei SaaS-Finanzverantwortliche, was in die Umsatzkosten gehört, und Sie erhalten drei Antworten. Hosting und Infrastruktur, klar. Aber wie steht es mit den Gehältern im Customer Success? Support? Durchgereichte Kosten für Drittanbieter-APIs und Daten? Abgeschriebene aktivierte Softwareentwicklung? DevOps? Zahlungsabwicklungsgebühren?

Die SaaS-Bruttomarge schwankt um 10 bis 20 Punkte, je nachdem, wo Sie diese Linie ziehen. Wenn eine KI also meldet “Ihre Bruttomarge liegt bei 78 Prozent”, lautet die ehrliche Rückfrage: 78 Prozent nach wessen COGS-Definition, gegen welche Umsatzbasis, nach HGB oder bereinigt? Das Modell nennt seine Annahmen so gut wie nie, weil es keine festen hat. Es rekonstruiert eine vernünftig klingende Berechnung aus Bruchstücken und reicht Ihnen eine Zahl, die sich auf keine Zeile Ihrer GuV zurückführen lässt.

Das ist dieselbe Krankheit wie beim ARR-Problem, und sie hat dieselbe Heilung: Verankern Sie das COGS-Mapping in tatsächlichen Hauptbuchkonten, entscheiden Sie bewusst zwischen HGB und bereinigter Sicht und berechnen Sie das Verhältnis deterministisch, sodass die Zahl jedes Mal zur GuV passt. Eine Marge, die Sie nicht auf Konten zurückführen können, ist keine Marge. Sie ist eine Schätzung mit Komma.

Effizienzkennzahlen scheitern am Timing, nicht an der Arithmetik

CAC-Payback, Magic Number und Burn Multiple sind die Stellen, an denen das Timing abgegrenzter Umsätze leise alles verhagelt. Die Arithmetik ist trivial. Die Inputs sind es nicht.

• CAC-Payback = Vertriebs- und Marketingausgaben zur Gewinnung einer Kohorte, geteilt durch den bruttomargenbereinigten wiederkehrenden Monatsumsatz dieser Kohorte. Die Fallen: Buchungen statt realisierter Umsätze verwenden, die Bruttomargenanpassung vergessen und die Periode der Ausgaben gegen die Periode der tatsächlich gewonnenen Kunden verrutschen lassen. Das S&M dieses Quartals hat nicht den Umsatz dieses Quartals gewonnen.
• Magic Number = Netto-Neu-ARR einer Periode geteilt durch das S&M der Vorperiode. Es bedeutet nur dann etwas, wenn “Netto-Neu-ARR” und “S&M” aus derselben abgestimmten Quelle stammen und die Perioden zueinanderpassen.
• Burn Multiple = netto verbrannter Cash geteilt durch Netto-Neu-ARR. Der Cash Burn kommt aus der Kapitalflussrechnung, der Netto-Neu-ARR aus dem Modell der wiederkehrenden Umsätze. Leben diese beiden in verschiedenen Systemen, die nie abgestimmt wurden, ist das Verhältnis Fiktion.

Ein LLM, das aus einem Haufen exportierter Zahlen arbeitet, kann nicht sehen, dass Ihr fakturierter Umsatz jährliche Vorauszahlungen enthält, die ein Quartal aufblähen, oder dass ein großes einmaliges Servicegeschäft in dem steckt, was es als wiederkehrend behandelt hat. Es rechnet das Verhältnis trotzdem aus. Das ist genau die Gefahr, die wir bei der Cashflow-Prognose beschreiben: In dem Moment, in dem Cash-Timing und Umsatzrealisierung auseinanderdriften, erbt jede darauf aufgebaute Effizienzkennzahl den Fehler.

Warum “über eine Kennzahl reden” der Fehlermodus ist

Treten Sie einen Schritt zurück, und das Muster ist durchgängig. In jedem der obigen Fälle hat die KI eine Zahl erzeugt, indem sie in natürlicher Sprache über die Kennzahl nachgedacht hat, statt sie gegen abgestimmte Ist-Zahlen zu berechnen. Das ist die Ursache, nicht die Modellqualität. Ein probabilistisches System, das sowohl eine Definition wählen als auch die Arithmetik ausführen soll, wird gelegentlich beides falsch machen, und es wird nie kennzeichnen, welches.

Die strukturelle Lösung besteht darin, diese beiden Aufgaben zu trennen. Definitionen und Rechnen gehören in eine deterministische Engine, die jedes Mal gleich läuft. Abruf, Erklärung und “was bedeutet das” gehören zur KI. Trennt man beides, hängt die Kennzahl nicht mehr davon ab, was sich das Modell über NRR gemerkt hat, sondern von Ihrem Hauptbuch. Das ist dasselbe Argument, das echte Modellierungswerkzeuge von KI-Aufsätzen unterscheidet, der Unterschied, den wir gegen Datarails und Mosaic herausarbeiten: Die Frage ist nicht, wie flüssig der Assistent klingt, sondern ob die Zahl darunter gegen abgestimmte Daten berechnet oder improvisiert wurde.

Was “zuverlässig berechnet” tatsächlich verlangt

Damit eine SaaS-Kennzahl vertrauenswürdig ist, müssen drei Dinge gleichzeitig zutreffen, und alle drei scheitern im prosa-getriebenen Ansatz:

1. Die Kennzahl ist einmal definiert. ARR bedeutet genau eine Sache. NRR hat feste Kohortengrenzen. COGS bildet sich auf benannte Hauptbuchkonten ab. HGB oder bereinigt ist eine erklärte Entscheidung, kein Münzwurf.
2. Die Mathematik ist deterministisch. Gleiche Inputs, gleiches Ergebnis, bei jedem Durchlauf. Keine Neuherleitung, kein Drift zwischen der Antwort vom Dienstag und der vom Donnerstag.
3. Jede Zahl ist bis zur Quelle nachvollziehbar. Sie können von der NRR zurück zur Kohorte klicken, von der Bruttomarge zurück zu den Konten, vom Burn Multiple zurück zu Cash und ARR, die es gespeist haben, und es einem Wirtschaftsprüfer oder Käufer zeigen.

Auf dieser Architektur ist Rexfin gebaut: Buchhaltungs-, Bank- und Warehouse-Daten verbinden, sie zu einem Modell abstimmen, das zum Hauptbuch passt, und eine deterministische Engine die Kennzahlen berechnen lassen, während die KI abruft und erklärt. Die Kennzahl ist dann nicht mehr etwas, worüber das Modell redet. Sie ist etwas, das das System berechnet und belegen kann.

Das Fazit

SaaS-Kennzahlen sind nicht schwierig, weil die Formeln schwierig wären. Sie sind schwierig, weil “welcher ARR?” und “welche Bruttomarge?” echte Fragen mit echten, unterschiedlichen Antworten sind, und eine KI, die in Prosa argumentiert, beantwortet sie stillschweigend und uneinheitlich. Die Kennzahlen, die eine KI richtig hinbekommt, sind genau die, bei denen Sie Definition und Arithmetik dem Modell entzogen und einer deterministischen Engine auf abgestimmten Daten übergeben haben. Alles andere ist eine selbstsichere Zahl, die Sie nicht verteidigen können.

Für das größere Bild starten Sie mit dem Pillar zu KI, FP&A-Automatisierung und dem Fundament der Prognose. Wenn Sie Ihre eigene ARR, NRR und Margen gegen Ihr eigenes Hauptbuch berechnet und bis zur Quelle nachvollzogen sehen wollen, buchen Sie eine Demo.