ARR-Reporting im CRM: Custom Snapshots und Waterfall

Native ARR-Reports im CRM scheitern, weil ein CRM nur den aktuellen Stand jedes Deals speichert. Es vergisst die Historie, kann einen mehrjährigen Vertrag nicht auf Jahre verteilen und vermischt Einmalgebühren mit wiederkehrendem Umsatz. Die Lösung ist ein Custom ARR Snapshot, also ein Datensatz pro Vertragsjahr mit wiederkehrendem Umsatz nach Art und Datum, sodass sich der Waterfall nicht mehr verschiebt, wenn jemand einen Deal bearbeitet.

Fragen Sie einen Gründer nach seiner ARR, bekommen Sie meist eine selbstbewusste, runde Zahl. Bitten Sie ihn, sie zu belegen, sie Jahr für Jahr aufzuschlüsseln oder zu zeigen, wie sie sich in den letzten zwei Quartalen entwickelt hat, und die Sicherheit verschwindet oft schnell. Die Zahl, auf der Ihre Board-Decks, Ihre Finanzierungsrunden und die Vergütungspläne vieler Teammitglieder beruhen, erweist sich häufig als die weichste Zahl im Unternehmen.

Wir betreiben Revenue Operations für ein Portfolio von B2B-Softwareunternehmen und haben das oft genug erlebt, um ein Muster zu erkennen. Wenn ARR-Reporting versagt, liegt das meist an einem von wenigen Gründen, und die Lösung ist fast immer dieselbe. Lassen Sie das CRM ARR nicht mehr live berechnen, sondern bauen Sie einen eigens dafür vorgesehenen Datensatz, den wir Snapshot nennen. Dieser Beitrag erklärt, was das bedeutet, anhand von zwei sehr unterschiedlichen Projekten, in denen ein Custom Snapshot still und leise dafür sorgte, dass die Zahlen des Finance-Teams wieder Sinn ergaben.

Warum natives ARR-Reporting in Salesforce und HubSpot scheitert

Annual Recurring Revenue (ARR) klingt nach einer einzigen Zahl, ist aber eigentlich eine Frage mit Datum. Wie hoch ist unser wiederkehrender Umsatz zum heutigen Tag? Zum Ende des letzten Quartals? In einem Jahr, wenn diese Verlängerungen eingehen und jene Verträge auslaufen? Jede dieser Fragen ergibt eine andere Zahl, und ein gesundes Unternehmen muss sie alle sehen können.

Das Problem ist, dass CRMs wie Salesforce und HubSpot dafür gebaut sind, laufende Deals zu managen, nicht dafür, sich zu merken, wie Ihr Umsatz zu einem bestimmten Zeitpunkt aussah. Ihre nativen Reports lesen den aktuellen Live-Stand Ihrer Datensätze. Für einen Pipeline-Report funktioniert das gut. Für ARR bricht es zusammen, aus drei Gründen, die immer wieder auftauchen.

• Erstens gibt es kein Gedächtnis. Ein nativer Report kann Ihnen sagen, was heute in einem Deal steht, nicht was im März darin stand. Sobald jemand einen abgeschlossenen Vertrag bearbeitet, eine Verlängerung rabattiert oder einen Wert korrigiert, ist die Historie verloren, und mit ihr jede Hoffnung auf einen korrekten ARR-Waterfall, der zeigt, wie Sie von der Zahl des Vorjahres zur diesjährigen gekommen sind. In Xactlys Umfrage von 2024 unter 405 Vertriebs- und Finanzverantwortlichen gaben 66% an, dass ihre Reporting-Systeme nicht auf historische CRM- oder Leistungsdaten zugreifen konnten (Xactly, 2024).
• Zweitens sprengen mehrjährige Verträge das Modell. Ein Dreijahresdeal über €300k sind keine €300k ARR und oft nicht einmal €100k pro Jahr, weil der Jahresbetrag über die Laufzeit steigen oder sinken kann. Ein einziges Betragsfeld in einer einzigen Opportunity kann keinen Umsatz abbilden, der gleichzeitig in mehreren Jahren liegt. Teams klonen am Ende Datensätze von Hand, und die manuellen Kopien laufen fast sofort auseinander. In der EU können Kunden zudem inzwischen nach dem Data Act mitten in der Vertragslaufzeit den Anbieter wechseln.
• Drittens werden wiederkehrende und einmalige Umsätze vermischt. Onboarding-Gebühren, Professional Services und Einrichtungskosten landen alle in derselben Summe wie Abonnements und Lizenzen. Solange nichts sie trennt, übernimmt Ihre ARR stillschweigend Umsatz, der nie wiederkehrt, und die Zahl, die Investoren am meisten interessiert, ist nun diejenige, die am ehesten falsch ist.

Was ein Custom ARR Snapshot ist und wie er funktioniert

Die Lösung ist weniger exotisch, als sie klingt. Statt einen Report ARR spontan aus Live-Deals ableiten zu lassen, legen wir eigene Datensätze an, deren einzige Aufgabe es ist, ARR so vorzuhalten, wie Sie sie sehen müssen. Diese Datensätze sind der „Snapshot“.

In der Praxis bedeutet das meist ein Objekt, das an allen Deals oder Opportunities hängt. Wenn ein Vertrag abgeschlossen wird, liest eine Automatisierung ihn aus und erzeugt einen untergeordneten Datensatz pro Laufzeitjahr. Ein Einjahresvertrag ergibt einen Datensatz. Ein Dreijahresvertrag ergibt drei, jeder mit dem wiederkehrenden Betrag des jeweiligen Jahres, der Umsatzart und dem abgedeckten Zeitraum. Jeder Datensatz klassifiziert den Umsatz als wiederkehrend oder einmalig, sodass Abonnements und Nutzung in die ARR einfließen, Onboarding und Services dagegen nicht.

Sobald die Daten diese Form haben, wird das Reporting ziemlich einfach. Einfache Roll-ups summieren ARR nach Jahr, Umsatzart, Produkt oder Account. Sie können die aktive ARR zum heutigen Tag zeigen, die ARR, die nächstes Jahr ausläuft, und die Verlängerungen und Expansions, die sie ersetzen werden, alles aus derselben Menge an Datensätzen.

Der tiefere Punkt liegt in der Entkopplung. Ihre Live-Deals bleiben bearbeitbar und unordentlich, und das Vertriebsteam arbeitet ungestört weiter. Ihre ARR liegt in einer separaten, stabilen Schicht, die festhält, was stimmt, und sich nicht stillschweigend umschreibt, wenn jemand eine Opportunity anfasst. Diese Trennung macht aus ARR eine Zahl, der man vertraut, statt einer Zahl, über die man streitet. Die beiden Projekte unten, beide anonymisiert, kamen von zwei völlig unterschiedlichen Ausgangsproblemen zur selben Trennung.

Wie ein Snapshot ein ARR-Dashboard korrigierte, das um Millionen danebenlag

Das erste war ein wachsendes B2B-Softwareunternehmen, das mehrjährige Abonnements mit einem Mix aus Lizenzen, Nutzung und Onboarding-Gebühren verkaufte. Sein ARR-Dashboard zeigte rund 3 Millionen Dollar. Die tatsächliche Closed-won-ARR lag eher bei 5,5 Millionen. Eine Lücke dieser Größe ist kein Rundungsfehler; sie ist der Unterschied zwischen einem Unternehmen, das stagniert zu sein scheint, und einem, das schnell wächst, und sie tauchte falsch in den Zahlen auf, mit denen die Geschäftsführung das Unternehmen steuerte.

Die Ursachen waren genau die oben genannten, nur kumuliert. Rund 2 Millionen Dollar Geschäft steckten in Opportunities, die nie sauber erfasst worden waren, sodass native Reports sie schlicht nicht sehen konnten. Historische Verträge enthielten manuelle Rechenfehler, darunter Deals, deren nutzungsbasiertes Pricing nicht mit dem erfassten Vertragswert übereinstimmte. Und weil das CRM keine kumulierte ARR im Zeitverlauf darstellen konnte, hatte das Team zu einem fragilen Workaround gegriffen. Es kombinierte gewonnene und Renewal-Opportunities, filterte auf aktive Verträge und nahm hin, dass offenes Neugeschäft unsichtbar blieb. Das Dashboard log nicht direkt, es beantwortete eine Frage, die niemand gestellt hatte.

Wir haben ein ARR-Snapshot-Objekt auf der bestehenden Quote-to-Deal-Struktur des Unternehmens aufgebaut. Wurde ein Vertrag abgeschlossen, rechnete eine Automatisierung ihn auf Jahreswerte um, in einen Snapshot-Datensatz pro Produkt und Laufzeitjahr. Ein Einjahresdeal erzeugte einen Datensatz, ein Mehrjahresdeal einen pro Jahr. Jede Zeile wurde als wiederkehrend oder einmalig markiert, sodass der Gesamtvertragswert und die wiederkehrende ARR endlich getrennte Größen waren statt derselben Zahl mit zwei Hüten. Roll-up-Felder summierten die ARR dann nach Jahr und Umsatzart über den gesamten Bestand.

Auch der Reporting-Standard änderte sich. Statt einen Durchschnitt oder den vollen Vertragswert zu nennen, stellten alle auf Year One ARR als gemeinsame Währung um, vom Vertriebstool bis zur Vergütung der Account Executives, sodass von Anfang bis Ende dieselbe Definition galt. Abgeschlossene Deals erzeugten automatisch die Opportunity für den nächsten Zyklus und einen neuen Satz Snapshots. So konnte das Team Verlängerungen zwei und drei Jahre im Voraus projizieren und jederzeit sehen, welche ARR aktiv war, welche auslief und welche Expansions sie ersetzen sollten.

Nichts davon ging sofort. Die ARR-Definition selbst wurde in den ersten Monaten vier- oder fünfmal nachgeschärft, als Sonderfälle auftauchten, von Expansions mit abweichenden Enddaten bis zu historischen Deals, die neu geprüft werden mussten. Das ist die ehrliche Realität dieser Arbeit. Das Snapshot-Objekt gibt Ihnen einen Ort, an dem Sie richtigliegen können, aber den Abgleich, um dorthin zu kommen, müssen Sie trotzdem machen. Dauerhaft geändert hat sich, dass das Unternehmen endlich eine einzige Wahrheitsquelle für ARR hatte, gestützt auf die zugrunde liegenden Produkte, statt eines Dashboards, das sich jedes Mal still verschob, wenn ein Rep einen Deal bearbeitete.

Wie ein Snapshot einen ARR-Waterfall für die Due Diligence lieferte

Das zweite Projekt betraf ein Softwareunternehmen im Bereich Nachhaltigkeit, das auf eine Finanzierungsrunde zusteuerte und für das der ARR-Waterfall kein Nice-to-have, sondern eine Voraussetzung für die Due Diligence war. Provisionspläne, Quartals- und Jahresziele, Board-Reporting und die OKRs des Unternehmens hingen alle daran, und kommerzielle und finanzielle Due Diligence liefen parallel. Der Forecast musste sogar von zwei auf drei Jahre verlängert werden, um den Anforderungen des Prozesses zu genügen. Hier hätte eine falsche ARR nicht nur das Team in die Irre geführt; externe Investoren hätten sie Zeile für Zeile geprüft.

Hier war der frühere, einfachere Ansatz selbst zum Problem geworden. Das Unternehmen hatte sich auf statische ARR-Zahlen zu einem Stichtag verlassen, und diese verschleierten genau die Dinge, auf die es in der Due Diligence ankommt. Mehrjährige Deals mit von Jahr zu Jahr unterschiedlichen Beträgen wurden zu einer einzigen Zahl plattgedrückt. Vorzeitige Verlängerungen und Expansions überschnitten sich mit ihren ursprünglichen Verträgen, wodurch Umsatz über Quartale hinweg doppelt gezählt wurde. In einem Fall bündelte eine Expansion ursprüngliche und neue Produkte, mit Abo-Zeiträumen, die sich um rund fünf Monate überschnitten, und der statische Snapshot konnte das nicht sauber abbilden.

Die Antwort kombinierte zwei Schritte. Erstens schützten wir die Integrität des Waterfalls selbst. Als jemand vorschlug, einen Renewal-Rabatt durch das Umschreiben historischer Produktdaten umzusetzen, widersprachen wir, weil das die ARR-Historie, die Provisionsberechnungen und die Board-Zahlen auf einen Schlag verfälscht hätte. Die Regel lautete, nie die Vergangenheit umzuschreiben. Wenden Sie den Rabatt bei der Verlängerung an, dokumentieren Sie die Änderung und lassen Sie den Datensatz zeigen, was tatsächlich passiert ist. Knifflige Szenarien wurden explizit behandelt statt zurechtgebogen. Ein Dreijahresdeal mit Ausstiegsklausel nach drei Monaten wurde zunächst als kurzer, nicht wiederkehrender Pilot behandelt und ab Monat vier als reguläre ARR, sofern der Kunde blieb.

Zweitens entwickelte sich der Snapshot von einer einzelnen Zahl zu einem Plan nach Vertragsjahren. Ein Vertrag über €300k war nicht mehr eine Zahl, sondern €100k pro Jahr über drei Jahre, jeweils mit eigenen Rechnungsterminen und jeweils als eigener Datensatz erfasst. Dieser Jahresplan speiste den Waterfall direkt und diente zugleich als Rückgrat einer Finanzübung. Ausgehend vom Vertrag dokumentierte das Team, was wann hätte fakturiert werden müssen, glich das mit den historischen Buchhaltungsdaten ab und erstellte Entwürfe für die fehlenden künftigen Rechnungen. Der Vertrag galt als Source of Truth, und das Buchhaltungssystem wurde daran angepasst, nicht umgekehrt. Diese Reihenfolge war entscheidend, denn sie brachte echte Revenue Leakage zutage, darunter separat vertraglich vereinbarte Services, die nie in Rechnung gestellt worden waren.

Das Ergebnis war ein Waterfall, hinter dem das Unternehmen wirklich stehen konnte. Mitte Januar war er funktionsfähig und ergab für das Jahr 5,4 Millionen Dollar, vorbehaltlich der finalen Validierung gegen die Rechnungsdaten, wobei nur noch eine Handvoll Opportunities ohne ARR war. In der Due Diligence ist der Unterschied zwischen einer Zahl, die Sie behaupten, und einer Zahl, die Sie nachvollziehbar belegen können, Vertrag für Vertrag und Jahr für Jahr, der Unterschied zwischen einem reibungslosen und einem schmerzhaften Prozess.

Warum ARR-Snapshots funktionieren, wo native CRM-Reports scheitern

Das waren unterschiedliche Unternehmen, auf unterschiedlichen CRMs, mit unterschiedlichen Problemen. Das eine wies die ARR um Millionen zu niedrig aus; das andere zu hoch, durch doppelt gezählte Überschneidungen und plattgedrückte Mehrjahresdeals. Das eine musste die eigene Geschäftsführung überzeugen, das andere Investoren. Dennoch kamen beide zur selben strukturellen Lösung, und das ist kein Zufall.

Der Grund ist, dass ARR im Kern eine Zeitreihenfrage an ein System ist, das nur die Gegenwart speichern soll. Kein noch so ausgefeilter Report-Bau behebt diese Diskrepanz, denn die benötigte Information, welcher Umsatz wiederkehrend war, in welchem Jahr, zu welchem Stichtag, steckt schlicht nicht in einem einzelnen Live-Deal. Sie können nur über Daten berichten, die Sie erfasst haben, und native Datensätze erfassen diese nicht. Ein Snapshot schon. Er hält ARR in der Form fest, in der die Frage tatsächlich gestellt wird, also nach Jahr, nach Art und zu einem Zeitpunkt, der fest bleibt.

Alles Weitere ergibt sich daraus, dass die Daten die richtige Form haben. Roll-ups werden trivial. Waterfalls werden ehrlich, weil sich die Historie darunter nicht mehr verschiebt. Vergütungspläne und Board-Decks greifen auf dieselben Datensätze zu, sodass Vertrieb, Finance und Board endlich über Strategie streiten statt darüber, wessen Zahl stimmt. Der Snapshot ist nicht raffiniert; er ist einfach der Unterschied zwischen ARR, die unter Druck abgeleitet wird, und ARR, die bereits erfasst ist.

Wann Sie eine ARR-Snapshot-Ebene in Ihrem CRM brauchen

Eine Snapshot-Schicht brauchen Sie am ersten Tag wahrscheinlich nicht. Wenn jeder Deal ein Einjahresabonnement ist und Sie ein paar Dutzend Kunden haben, reichen die nativen Reports aus. Das Muster lohnt sich, sobald Komplexität hinzukommt, und es gibt einige verlässliche Anzeichen dafür.

Das deutlichste Signal ist, dass Sie Ihrer eigenen ARR-Zahl nicht mehr ganz trauen oder dass zwei Personen im Unternehmen zwei verschiedene Versionen davon liefern können. Dicht dahinter folgen der Mehrjahresvertrag, bei dem niemand so recht weiß, wie er zu berichten ist, die Verlängerung oder Expansion, die doppelt zu zählen scheint, und Finance- und Vertriebsteams, die mit Zahlen arbeiten, die nie ganz zusammenpassen. Steht eine Finanzierungsrunde oder ein Audit an, steigt die Messlatte erneut, denn Sie müssen ARR nach Jahr und Vertrag nachvollziehbar belegen, nicht nur eine Summe behaupten, und eine aus dem Gedächtnis rekonstruierte Tabelle hält einer Prüfung nicht stand.

Wenn Sie nicht sicher sind, wie weit Sie Ihrer eigenen ARR-Zahl trauen können, priorisiert unser CRM and GTM Health Check die Lücken und behebt die erste.

Die gute Nachricht ist, dass das Problem gelöst ist. Sie müssen weder Systeme migrieren noch eine weitere Plattform kaufen; in beiden Fällen oben wurde die Lösung im CRM gebaut, das das Unternehmen bereits hatte. Es braucht nur, ARR als Daten zu behandeln, die bewusst erfasst werden, statt als Zahl, die unter Druck abgeleitet wird, und die Bereitschaft, den Abgleich einmal sauber zu machen, damit die Zahl danach stimmt.

Wenn sich Ihre ARR eher wie eine Streitfrage als wie eine Tatsache anfühlt, ist das meist der Moment, in dem sich das Snapshot-Muster bezahlt macht. Es gehört zu den wirkungsvollsten Bausteinen der Revenue-Infrastruktur, die ein wachsendes Softwareunternehmen einbauen kann, gerade weil alles Nachgelagerte, Forecasting, Vergütung und die Geschichte, die Sie Investoren erzählen, davon abhängt, dass diese eine Zahl stimmt.

FAQ zum ARR-Reporting

Was ist ARR-Reporting?

ARR-Reporting zeigt den annualisierten Wert Ihrer wiederkehrenden Verträge zu einem Stichtag und erklärt, wie er sich zwischen zwei Daten verändert hat. Ein solides ARR-Reporting trennt wiederkehrende von einmaligen Umsätzen, teilt Mehrjahresverträge nach Jahren auf und lässt sich für jedes vergangene Datum reproduzieren.

Warum stimmt die ARR in unserem CRM nicht mit der Zahl von Finance überein?

Meist, weil beide unterschiedliche Dinge zu unterschiedlichen Zeitpunkten messen. Native CRM-Reports lesen den Live-Stand der Deals, die Historie ändert sich also, sobald jemand einen Datensatz bearbeitet. HubSpots Standard-ARR-Property wird zum Beispiel aus den wiederkehrenden Line Items und der Laufzeit eines Deals berechnet, nicht aus dem Deal-Betrag (HubSpot), während Finance mit Billing-Daten arbeitet. Vereinbaren Sie eine Definition und gleichen Sie Datensatz für Datensatz ab.

Was ist ein ARR-Waterfall?

Ein ARR-Waterfall, auch Bridge genannt, erklärt die Veränderung der ARR über einen Zeitraum. Anfangs-ARR plus neue und Expansion-ARR minus Contraction und Churn ergibt End-ARR. Unsere Five-Dots-Methode baut ihn Kunde für Kunde auf, zählt nur wiederkehrende Umsätze und zeigt Bewegungen brutto, denn eine Expansion und ein gleich hoher Churn sind nicht „keine Veränderung“.

Wie sollten mehrjährige Verträge in die ARR einfließen?

Eine allgemeingültige Konvention gibt es nicht, aber es muss eine geben, abgestimmt mit Finance. Die Varianten, die wir am häufigsten sehen, sind Year One ARR für Bookings und Provision, Jahreswerte für den Waterfall, durchschnittliche ARR für Ramp-Deals und die ARR des letzten Jahres als Basis für die Verlängerung. Der Gesamtvertragswert sollte nie in die ARR einfließen.

Können HubSpot oder Salesforce ARR nativ berichten?

Beide können über Felder für wiederkehrenden Umsatz berichten, aber was sie zeigen, hängt davon ab, wie Deals aufgebaut sind. Die Recurring Revenue Analytics von HubSpot erfordern zum Beispiel ein Enterprise-Abonnement und lesen manuell gepflegte Properties für wiederkehrenden Umsatz, nicht die Produkte oder Angebote an einem Deal (HubSpot). Für mehrjährige Verträge und einen Waterfall, den Finance abzeichnet, ergänzen die meisten Teams, mit denen wir arbeiten, ein Snapshot-Objekt.