Der monatlich wiederkehrende Umsatz, englisch Monthly Recurring Revenue (MRR), ist eine zentrale Kennzahl für Unternehmen mit Abonnement-Modellen, vor allem im SaaS-Bereich. MRR gibt Aufschluss darüber, wie viel Umsatz ein Unternehmen monatlich aus aktiven Abonnements generiert. Trotz der scheinbaren Einfachheit ist die korrekte Berechnung von MRR aus Rohdaten vor allem bei Stripe-Zahlungsdaten eine durchaus komplexe Herausforderung. Die Standard-Dashboards von Stripe bieten zwar schon grundlegende MRR-Metriken, doch viele Unternehmen suchen nach individuellen Lösungen, die auf ihre speziellen Geschäftsanforderungen zugeschnitten sind und auch weitere Datenquellen wie CRM-Systeme integrieren. Im Folgenden wird erläutert, wie man MRR mithilfe von SQL aus den rohen Stripe-Daten exakt berechnet und die gängigen Stolperfallen vermeidet.
Dabei werden auch praktische SQL-Beispiele vorgestellt. Die beschriebenen Vorgehensweisen basieren auf einem realen Anwendungsfall mit einer DuckDB-Datenbank und einer angepassten Stripe-Datenextraktion. Die Konzepte lassen sich aber auf ähnliche Setups übertragen. Um das Verständnis zu erleichtern, starten wir mit einem Blick auf die Datenbasis und dann auf die Herausforderung bei der MRR-Berechnung. Der Ausgangspunkt für die MRR-Berechnung bilden die Rohdaten aus Stripe, die durch eine API-Integration oder Tools wie den Singer Stripe Tap in ein Data Warehouse geladen werden.
Besonders wichtig für die MRR-Berechnung sind die Tabellen, welche Rechnungszeilen (Invoice Line Items), Rechnungen (Invoices), Abonnements (Subscriptions) und Rabatte (Discounts) enthalten. Stripe repräsentiert diese Objekte jeweils mit bestimmten Schemas, in denen neben Beträgen auch Zeitangaben, Währungsangaben und periodische Intervalle der Abonnements enthalten sind. Ein häufig genutztes Objekt sind die Invoice Line Items, die einzelne Positionen einer Rechnung darstellen, etwa monatliche Abogebühren oder einmalige Zusatzkosten. Hier finden sich auch wichtige Zeitangaben über den Zeitraum, auf den sich die Rechnung bezieht. Eine der größten Herausforderungen bei der MRR-Ermittlung über Stripe-Daten ist die Tatsache, dass die Abonnement-Objekte in der Stripe-API lediglich den aktuellen Status und nicht die historische Entwicklung eines Abonnements zurückliefern.
Änderungen wie Planwechsel, Preisänderungen oder Unterbrechungen gehen damit verloren, was eine exakte historische Abbildung erschwert. Um ein realistisches Bild des MRR zu erhalten, ist es deshalb sinnvoller, direkt die Rechnungsdaten samt zugehöriger Rechnungszeilen zu nutzen. Die Rechnungslinien enthalten detaillierte Informationen über die gebuchten Zeiträume und dienen als Grundlage für die Berechnung von monatlichen Umsätzen. Allerdings darf man sich nicht allein auf die angezeigten Rechnungszeilen verlassen. Es gibt mehrere Fallstricke, die beachtet werden müssen.
So stellen Rechnungsperiodenstart- und enddaten in den Rechnungen oft nur dar, wann Positionen hinzugefügt wurden, sie sind also keine verlässlichen Abrechnungszeiträume für einzelne Abonnements. Vielmehr sollten die periodischen Daten in den einzelnen Rechnungszeilen untersucht werden, die als Teilobjekte mit Start- und Enddatum des jeweiligen Abrechnungszeitraums vorliegen. Ebenfalls kritisch ist die Tatsache, dass nicht alle Rechnungspositionen abonnementbezogen sein müssen. Es gibt viele nicht wiederkehrende Zahlungen wie Einrichtungsgebühren oder Mahnkosten, welche die MRR-Berechnung verfälschen würden und deshalb vorher gefiltert werden sollten. Ein weiterer komplexer Punkt ist die Berücksichtigung von Rabatten.
In vielen Fällen enthalten die Rechnungszeilen Beträge, die noch keine Rabatte widerspiegeln. Die tatsächlichen Abschläge befinden sich oft in separaten Rabattobjekten. Um die korrekten, rabattbereinigten Beträge zu bekommen, muss man die Rechnungszeilen mit den Rabattinformationen verknüpfen und die Rabatte entsprechend abziehen. Dies ist wichtig, um keine zu hohen Umsätze auszuweisen. Darüber hinaus erschweren unterschiedliche Abrechnungsintervalle die MRR-Berechnung.
Einige Kunden haben monatliche Abonnements, andere Quartals- oder Jahresabos. Hierbei erscheinen Rechnungszeilen jeweils nur bei der vollständigen Abrechnung im Quartal oder Jahr, der Betrag entspricht also nicht dem Monatswert. Um dennoch einen korrekten monatlichen MRR zu errechnen, ist eine Normalisierung nötig, bei der der Abrechnungsbetrag durch die Anzahl der Monate im jeweiligen Abrechnungszeitraum geteilt und anschließend auf die einzelnen Monate verteilt wird. Diese Aufteilung kann man in SQL durch Zeitreihengenerierung und Verknüpfung mit den Abrechnungsdaten umsetzen. Ein praxisnaher Ansatz zur Umsetzung der MRR-Berechnung in SQL beginnt mit der Extraktion der relevanten Rechnungszeilen.
Hierbei werden nur Positionen mit dem Typ „subscription“ herausgefiltert. Anschließend verknüpft man sie mit den Rabattdaten, um die rabattbereinigten Beträge zu erhalten. Um die Zeitperioden korrekt abzubilden, werden die Start- und Endmonate der Rechnungszeilen extrahiert und die Länge des Abrechnungszeitraums in Monaten berechnet. Dieser Wert dient für die spätere Normalisierung. Das Normalisieren von Quartals- oder Jahresabos geschieht, indem man eine Zeitreihe von Monatsdaten erstellt und dann für jeden Abrechnungszeitraum jeweils die zugehörigen Monate diesem Zeitraum zuordnet.
Die Rechnungssumme wird dabei durch die Periodenlänge geteilt und so jedem Monat anteilig zugewiesen. Dies ermöglicht monatliche Vergleichbarkeit der Umsätze verschieden langer Abonnements. Im nächsten Schritt werden alle normalisierten Umsätze mit einem vollständigen Zeitreihen-Datensatz verknüpft, der alle relevanten Monate umfasst. Dadurch werden auch Monate mit null Umsatz für aktive Subscriptions erfasst, was wichtig ist, um beispielsweise die Stornierung und Reaktivierung von Abonnements im Zeitverlauf abzubilden. Mit Hilfe von Fensterfunktionen in SQL können anschließend Veränderungen des MRR pro Subscription von Monat zu Monat berechnet werden und Metriken wie Neuzugänge, Expansion, Kontraktion, Churn sowie Reaktivierung abgeleitet werden.
Solch ein datenbankgestützter MRR-Report liefert Unternehmen eine transparente und detaillierte Übersicht, wie sich das Abonnementgeschäft im Laufe der Zeit entwickelt. Er unterstützt fundierte Entscheidungen hinsichtlich Marketing, Produktentwicklung und Kundenbindung. Zudem kann die SQL-gestützte Methode flexibel erweitert werden um weitere Filterkriterien oder Fremddatenquellen wie CRM- oder Support-Daten, was die Verlässlichkeit und Aussagekraft der MRR-Analysen weiter steigert. Abschließend lässt sich festhalten, dass die MRR-Berechnung aus Roh-Stripe-Daten zwar komplex, aber mit systematischem Vorgehen und den richtigen SQL-Transformationen gut umsetzbar ist. Die typischen Schwierigkeiten wie fehlende historische Abonnement-Stati, uneinheitliche Abrechnungsperioden und fehlende Rabattberücksichtigung können durch gezielte Abfragen und Datenaufbereitung gemeistert werden.
So entsteht ein präzises, zeitlich differenziertes MRR-Dashboard, das über die Standardfunktionen von Stripe hinausgeht. Für Unternehmen mit Abonnement-Modellen stellt dies eine wesentliche Grundlage für Wachstum und Nachhaltigkeit dar.
