Stripe MRR: so berechnen Sie ihn richtig

Stripe MRR ist keine native Kennzahl. Stripe zeigt Umsatz, nicht monatlich wiederkehrenden Umsatz. Die Stripe-MRR-Berechnung erfordert eine Normalisierung der rohen Stripe-Abonnementdaten: Jahrespläne durch 12 teilen, einmalige Gebühren ausschließen, Prorationen behandeln und nur aktive Abonnements zählen. Die im Stripe-Dashboard angezeigte MRR-Zahl ist für die meisten SaaS-Unternehmen mit gemischten Abrechnungsintervallen falsch. Dieser Leitfaden erklärt, warum die Stripe-MRR-Zahl unter Billing → Overview unzuverlässig ist, zeigt Schritt für Schritt, wie du den Stripe MRR korrekt berechnest, und behandelt jeden Sonderfall — Trials, Rabatte, Coupons und Jahrespläne — den die meisten Anleitungen überspringen.

Stripe MRR: die native „MRR”-Zahl von Stripe ist nicht normalisiert. Korrekter MRR = Summe aller aktiven Abonnementbeträge, umgerechnet auf monatliche Äquivalente, ohne einmalige Gebühren, Trials und pausierte Abonnements. Jahrespläne müssen durch 12 geteilt werden.

Berechne deinen MRR aus Stripe → Normalisierter MRR mit korrekter Jahresplan-Behandlung, kostenlos bis 10 000 € MRR.

Zeigt Stripe den MRR an?

Ja und nein. Stripe Billing zeigt eine „MRR”-Zahl im Bereich Billing → Overview. Das Problem: sie ist nicht korrekt normalisiert.

Was Stripes MRR tatsächlich zählt: Stripe berechnet den MRR, indem es alle aktiven Abonnements nimmt und ihre Beträge auf monatlicher Basis summiert. Die Konvertierungslogik klingt richtig, behandelt aber Sonderfälle für die meisten SaaS-Unternehmen falsch.

Warum es bei Jahresplänen schiefläuft: Stripes MRR-Berechnung für Jahresabonnements ist inkonsistent. In einigen Konfigurationen verteilt sie den Jahresbetrag korrekt über 12 Monate. In anderen, vor allem wenn du Jahres- mit Monatsabrechnung mischst oder Kunden manuell zwischen Plänen migriert wurden, zeigt sie den vollen Jahresbetrag im Monat des Einzugs und null in den anderen Monaten.

Das Trial-Problem: Stripe kann Trials je nach Konfiguration in den MRR einbeziehen oder ausschließen. Hat ein Trial eine erste Periode mit 0 €, wird er typischerweise ausgeschlossen. Verwendet er einen 100 %-Coupon im ersten Monat, wird er möglicherweise als 0 € MRR gezählt oder inkonsistent ausgeschlossen.

Der praktische Test: Vergleiche Stripes MRR-Zahl mit einer manuellen Summe deiner aktiven Abonnementbeträge. Stimmen sie auf wenige Euro genau überein, funktioniert Stripes Berechnung für deine Konfiguration. Divergieren sie — vor allem wenn Stripes Zahl in Verlängerungsmonaten hochschießt — hast du ein Jahresplan-Normalisierungsproblem. Die meisten SaaS-Unternehmen mit über 15 % Jahreskunden sehen signifikante Divergenz, typischerweise 20–40 % Inflation in Verlängerungsspitzenmonaten.

Für die vollständigen Regeln, was in den MRR gehört und was nicht — einschließlich Prorationen, Setup-Gebühren und Einmalkosten — siehe den MRR-Berechnungsleitfaden.

Warum korrekter Stripe MRR wichtig ist

MRR ist die fundamentale Kennzahl, auf der fast jede andere SaaS-Zahl aufbaut. Wer ihn falsch berechnet, dem bricht die Kaskade zusammen.

Churn Rate = abgewanderter MRR ÷ Anfangs-MRR. Ist der Anfangs-MRR durch Jahresplan-Spitzen aufgebläht, ist der Nenner deiner Churn-Berechnung falsch — Churn wirkt in renovierungsstarken Monaten niedriger und in renovierungsarmen Monaten höher und schaukelt dein wichtigstes Retention-Signal hin und her.

LTV = ARPU ÷ monatliche Churn Rate. ARPU = MRR ÷ Kunden. MRR aufblähen heißt ARPU und LTV aufblähen. Deine Akquisitionsausgaben-Entscheidungen ruhen auf einer Zahl, die zu 20–40 % falsch ist.

NRR und GRR: beide nutzen Anfangs-MRR als Nenner. Gleiches Problem.

Forecasting: projizierst du MRR mit deiner aktuellen Wachstumsrate fort, lässt ein falscher Spike durch Jahresverlängerungen die Wachstumsrate dieses Monats höher erscheinen, als sie ist. Deine 6-Monats-Prognose schießt über, und du bist überrascht, wenn das Wachstum nächsten Monat „verlangsamt”.

Die korrekte MRR-Zahl ist das Fundament. Alles andere folgt daraus. Die 15 Minuten Investition, um deine Stripe-MRR-Berechnung zu normalisieren, sind mehr wert als fast jede andere Analytics-Aufgabe diese Woche. Einmal richtig machen, monatlich prüfen — und alle anderen SaaS-Kennzahlen stehen auf festem Boden. Einmal falsch bauen und du debuggst monatelang aufgeblähte LTV und falsche Churn Rates, bevor du das Problem zur Quelle zurückverfolgst.

Was Stripe statt MRR zeigt

Das Stripe-Billing-Dashboard liefert mehrere Umsatzzahlen. Zu verstehen, was jede repräsentiert, hilft zu identifizieren, welche korrigiert werden muss.

„MRR” in Billing Overview: Stripes Schätzung des monatlich wiederkehrenden Umsatzes. Aus den oben genannten Gründen unzuverlässig. Als Plausibilitätscheck nutzen, nicht als primäre MRR-Quelle.

Net Volume (Reiter Payments): Gesamtbelastungen in einem Zeitraum. Enthält einmalige Gebühren, Setup-Kosten und den vollen Betrag von Jahresabonnements. Das ist Cashflow, nicht MRR. Ein mit 480 € abgerechneter Jahresplan erscheint im Monat der Belastung als 480 € Net Volume und in den nächsten 11 Monaten als 0 €.

Subscription Revenue: Unter Stripe Billing → Revenue → Subscription Revenue siehst du die monatliche Abrechnungsaktivität von Abonnements. Näher an nützlich, mischt aber immer noch Abrechnungsintervalle und normalisiert Jahrespläne nicht auf monatliche Äquivalente.

Revenue Recognition (kostenpflichtige Funktion): Stripes Revenue-Recognition-Add-on berechnet erfasste Umsätze korrekt nach ASC 606 und verteilt das 480-€-Jahresabonnement auf 12 Monate à 40 €/Monat. Bilanziell präzise, aber das ist die erfasste Umsatzgröße — nicht der operative MRR, den du zur Wachstumsverfolgung nutzt.

Wie du MRR aus Stripe-Daten korrekt berechnest

Der richtige Ansatz: alle aktiven Abonnements nehmen, jedes auf sein monatliches Äquivalent umrechnen, alles aufsummieren.

Die Formel:

MRR = Σ (Abonnementbetrag × Menge × monatlicher_Konvertierungsfaktor)

Wobei monatlicher_Konvertierungsfaktor ist:

Monatliche Abrechnung: 1,0
Jährliche Abrechnung: 1/12 = 0,0833
Quartalsweise Abrechnung: 1/3 = 0,333
Wöchentliche Abrechnung: 52/12 = 4,333

Schritt-für-Schritt-Berechnung:

Schritt 1. Alle aktiven Abonnements auflisten. Aktiv = Status active oder trialing (wenn du Trials in den MRR aufnimmst). canceled, past_due, paused und incomplete ausschließen.

Schritt 2. Für jedes Abonnement Plan-Betrag und Abrechnungsintervall holen. Im Stripe-Datenmodell: subscription.items[0].price.unit_amount (in Cent) und subscription.items[0].price.recurring.interval.

Schritt 3. In Monatsbetrag umrechnen.

monatsbetrag = unit_amount / 100.0 × Menge × monatlicher_Konvertierungsfaktor

Schritt 4. Alle Monatsbeträge summieren. Diese Summe ist dein normalisierter MRR.

Stripe-API-Ansatz:

import stripe

stripe.api_key = 'rk_live_...'  # restricted key, schreibgeschützt

subscriptions = stripe.Subscription.list(status='active', limit=100, expand=['data.items.data.price'])
mrr = 0
for sub in subscriptions.auto_paging_iter():
    for item in sub['items']['data']:
        price = item['price']
        amount = price['unit_amount'] / 100.0
        qty = item['quantity']
        interval = price['recurring']['interval']
        interval_count = price['recurring']['interval_count']
        
        # Auf monatlich normalisieren
        if interval == 'month':
            monthly = amount * qty / interval_count
        elif interval == 'year':
            monthly = amount * qty / (12 * interval_count)
        elif interval == 'week':
            monthly = amount * qty * (52 / 12) / interval_count
        elif interval == 'day':
            monthly = amount * qty * (365 / 12) / interval_count
        
        mrr += monthly

print(f"MRR: {mrr:.2f} €")

Dieses Skript behandelt alle Abrechnungsintervalle korrekt. Bei Multi-Item-Abonnements (Kunden mit Add-ons) werden alle Items summiert.

Sonderfälle behandeln

Trials

Trials in den MRR aufnehmen? Konvention variiert. Die meisten SaaS-Gründer schließen kostenlose Trials aus dem MRR aus, da kein Umsatz eingenommen wird. Wandelt sich ein Trial in einen bezahlten Plan, füge das Abonnement zum MRR zum Konvertierungszeitpunkt hinzu.

Trialing-aber-bezahlte Trials (bei denen die Trial-Periode einen Coupon mit Rabatt auf 0 € nutzt): aus dem MRR ausschließen, bis der Coupon abläuft und der Kunde Vollpreis zahlt.

Stripe-Implementierung: auf status = 'active' filtern (nicht trialing), um alle Trials aus dem MRR auszuschließen.

Rabatte und Coupons

Coupons, die den verrechneten Betrag senken, beeinflussen das eingenommene Bargeld, werden aber typischerweise NICHT vom MRR in der Standard-SaaS-Buchhaltung abgezogen. MRR repräsentiert den Listenpreis — den „zugesagten” Umsatz. Listenpreis-MRR vermeidet zudem MRR-Schwankungen, wenn zeitlich begrenzte Coupons auslaufen.

Repräsentiert ein Coupon jedoch eine dauerhafte Preiszusage (ein verhandelter Rabatt, der nie ausläuft), nutze den rabattierten Betrag im MRR. Frage subscription.discount.coupon.duration ab; bei forever den rabattierten Preis verwenden.

Stripe-Coupon in der MRR-Berechnung:

# Nur für dauerhafte Coupons
if sub.get('discount') and sub['discount']['coupon']['duration'] == 'forever':
    coupon = sub['discount']['coupon']
    if coupon.get('percent_off'):
        monthly *= (1 - coupon['percent_off'] / 100)
    elif coupon.get('amount_off'):
        monthly -= coupon['amount_off'] / 100.0  # Cent umrechnen

Jahrespläne: der kritische Sonderfall

Jahrespläne sind die häufigste Quelle für MRR-Inflation bei falscher Berechnung. Die Lösung: Jahresbeträge immer durch 12 teilen.

Jahresplan: 480 €/Jahr → MRR-Beitrag: 40 €/Monat

Zählst du die 480 € als MRR im Verlängerungsmonat, schießt dein MRR bei jeder Jahresverlängerung hoch und wirkt in Nicht-Verlängerungsmonaten niedriger. Die normalisierte Version (40 €/Monat konstant) ist das, was du für Wachstumsmetriken verfolgen willst.

Was bei Teilmonaten tun: abonniert ein Kunde mitten im Monat, prorationieren manche Teams den MRR-Beitrag des ersten Monats. Die meisten Gründer überspringen die Proration der Einfachheit halber — sie addieren den vollen Monatsbetrag zum Erstellungsdatum des Abonnements und entfernen ihn am Kündigungsdatum. Der Unterschied ist im Frühstadium meist unwesentlich.

Für die vollständige Behandlung, was ein normalisierter MRR einschließt und ausschließt — und warum Stripes native Zahl bei vielen Abrechnungskonfigurationen daneben liegt — deckt der MRR-Definitionsleitfaden jeden Sonderfall ab.

Stripe Sigma: SQL-Ansatz

Stripe Sigma erlaubt es, deine Stripe-Daten direkt per SQL abzufragen. Hier eine Sigma-Abfrage für normalisierten MRR:

WITH active_subs AS (
  SELECT
    s.id,
    si.price_unit_amount / 100.0 as price_amount,
    si.quantity,
    p.recurring_interval,
    p.recurring_interval_count
  FROM subscriptions s
  JOIN subscription_items si ON si.subscription_id = s.id
  JOIN prices p ON p.id = si.price_id
  WHERE s.status = 'active'
)
SELECT
  SUM(
    CASE recurring_interval
      WHEN 'month' THEN price_amount * quantity / recurring_interval_count
      WHEN 'year'  THEN price_amount * quantity / (12.0 * recurring_interval_count)
      WHEN 'week'  THEN price_amount * quantity * 52.0 / (12.0 * recurring_interval_count)
      ELSE 0
    END
  ) AS normalized_mrr
FROM active_subs;

Damit lassen sich monatliche, jährliche und wöchentliche Abrechnungsintervalle mit korrekter Normalisierung handhaben.

Sigma-Limitationen für MRR-Tracking: Sigma liefert MRR von jetzt. Es speichert keine historischen MRR-Snapshots — du kannst also nicht sehen, wie der MRR am 1. Januar aussah. Für Trendanalyse müsstest du diese Abfrage täglich ausführen und Ergebnisse extern speichern oder ein Tool nutzen, das die MRR-Historie automatisch pflegt.

Sigma deckt außerdem nicht ab:

Den MRR-Wasserfall (new/expansion/contraction/churn-Aufschlüsselung) ohne monatliche Snapshot-Tabellen
Trial-zu-Bezahlt-Konversionsverfolgung auf MRR-Ebene
Plan- und kohortenbezogene MRR-Aufschlüsselung ohne zusätzliche Abfragekomplexität

Sigma ist das richtige Werkzeug, wenn du SQL-Skills und eine konkrete Einmal-Frage zu deinen Stripe-Daten hast. Für laufendes MRR-Monitoring macht der Wartungsaufwand für Sigma-Abfragen — wenn dein Pricing sich entwickelt — dedizierte Analytics-Tools für die meisten Gründer praktikabler.

MRR-Bewegungen: jenseits einer einzigen Zahl

Mit normalisiertem MRR ist die nächste Ebene zu verstehen, was Veränderungen Monat für Monat treibt. Stripe gibt dir den MRR-Total — eine statische Zahl. Was du zum Verständnis von Wachstum tatsächlich brauchst, ist ein MRR-Wasserfall:

Net New MRR = New MRR + Expansion MRR − Contraction MRR − Churned MRR

New MRR: Umsatz von Kunden, die im Vormonat nicht existierten. Expansion MRR: zusätzlicher Umsatz von Kunden, die upgegradet haben (zahlen diesen Monat mehr als letzten). Contraction MRR: reduzierter Umsatz von Kunden, die downgegradet haben. Churned MRR: Umsatz von Kunden, die gekündigt haben.

Stripe berechnet diese Aufschlüsselung nicht nativ. Es weiß, dass Kündigungen passiert sind, verfolgt aber nicht Expansion vs. Contraction vs. neue Abonnements im Wasserfall-Format. Stripe Sigma kann sie rekonstruieren, indem zwei monatliche Abonnement-Snapshots verbunden werden — aber du musst diese Snapshots selbst pflegen.

Warum der Wasserfall zählt:

Eine MRR-Wachstumsrate sagt dir das Ergebnis. Der Wasserfall sagt dir die Ursache. Zwei Unternehmen mit jeweils 10 % monatlichem MRR-Wachstum können auf einer einfachen MRR-Grafik identisch aussehen, aber sehr unterschiedliche Treiber haben:

Unternehmen A: 15 % New MRR, 8 % Churned MRR → akquisitionsgetriebenes Wachstum, anfällig wenn Akquisition nachlässt
Unternehmen B: 8 % New MRR, 3 % Expansion MRR, 2 % Churned MRR → Mischquellen-Wachstum, robuster

Der Wasserfall ist auch die Brücke zwischen MRR und Net Revenue Retention (NRR): NRR = (Anfangs-MRR + Expansion − Contraction − Churn) ÷ Anfangs-MRR. Wer NRR manuell berechnet, braucht die Wasserfall-Komponenten.

Für ARR-Planung multipliziere deinen normalisierten Monats-MRR mit 12. ARR = MRR × 12. Es gelten die gleichen Normalisierungsregeln: Jahrespläne ÷ 12, dann × 12 = Jahresplanbetrag, was korrekt ist.

Drittanbieter-Tools für Stripe MRR

Tool	MRR-Normalisierung	Historische Trends	Einstiegspreis
NoNoiseMetrics	✅ Korrekt (jährlich ÷12)	✅ Volle Historie	Kostenlos → 79 €/Monat
ChartMogul	✅ Korrekt	✅ Volle Historie	100 €+/Monat
Baremetrics	✅ Korrekt	✅ Volle Historie	108 €+/Monat
Stripe Sigma	✅ (per SQL)	❌ Nur Punkt-in-Zeit	~10 €/Monat
Manuelle Tabelle	Variabel	❌ Wartung erforderlich	Kostenlos

Für das Gesamtbild dessen, was die Analytics-Schicht von Stripe liefert versus was externe Tools erfordert, siehe die Stripe-Analytics-Lückenanalyse.

FAQ

Zeigt Stripe den MRR an?

Stripe Billing Overview zeigt eine MRR-Zahl, sie ist aber für Unternehmen mit Jahresplänen oder gemischten Abrechnungsintervallen oft ungenau. Die Zahl kann in Verlängerungsmonaten von Jahreskunden hochschießen und in Nicht-Verlängerungsmonaten niedrigeren MRR zeigen. Für korrekten MRR normalisierst du alle Abonnementbeträge auf ihr monatliches Äquivalent: Jahrespläne ÷ 12, Monatspläne × 1.

Wie berechne ich den MRR aus Stripe?

Liste alle aktiven Abonnements über die Stripe-API oder Sigma. Für jedes Abonnement nimmst du Plan-Betrag × Menge und teilst durch das Abrechnungsintervall in Monaten (jährlich = 12, quartalsweise = 3, monatlich = 1). Summiere alle monatlichen Äquivalente. Trials, gekündigte Abonnements, pausierte Abonnements und Einmalkosten ausschließen.

Warum ist Stripes MRR falsch?

Stripes MRR-Berechnung behandelt Jahrespläne je nach Abrechnungskonfiguration inkonsistent. Sie kann auch Trials einbeziehen, volle Jahresbeträge in Verlängerungsmonaten zählen oder Mid-Cycle-Upgrades verpassen. Der sicherste Weg ist, MRR selbst aus der Abonnementliste mit normalisierter Intervallumrechnung zu berechnen.

Wie sehe ich MRR in Stripe ohne Sigma?

Stripe Billing → Revenue zeigt ein Umsatzdiagramm und Abonnementmetriken. Für normalisierten MRR der zuverlässigste manuelle Ansatz: Aktive Abonnements als CSV exportieren, eine Spalte für monatliches Äquivalent (Jahresbetrag ÷ 12) ergänzen und summieren. Für laufendes MRR-Tracking Stripe an ein Tool anbinden, das die Normalisierung automatisch berechnet.

Wie lautet die Stripe-MRR-Formel?

Normalisierter MRR = Summe von (monatlich äquivalenter Betrag × Menge) für alle aktiven Abonnements. Monatliches Äquivalent = Plan-Betrag ÷ Abrechnungsmonate (1 monatlich, 12 jährlich, 3 quartalsweise). Pausierte, gekündigte, unvollständige und Trial-Abonnements ausschließen.

Wie behandle ich Jahrespläne im Stripe MRR?

Jahresbeträge immer durch 12 teilen. Ein Plan zu 480 €/Jahr trägt 40 €/Monat zum MRR bei. Füge niemals die vollen 480 € im Verlängerungsmonat zum MRR hinzu — das erzeugt falsche Spikes, die deinen echten Wachstumstrend überdecken. Die konstanten 40 € sind die korrekte Zahl für jeden Monat, in dem der Kunde aktiv ist.

Zeigt Stripe den MRR nativ?

Nein. Stripe zeigt Bruttovolumen (alle Belastungen), nicht normalisierten MRR. Stripe annualisiert keine Monatspläne, schließt Einmalkosten nicht aus wiederkehrenden Summen aus und behandelt Proration für MRR-Zwecke nicht korrekt. Du musst MRR selbst aus Abonnementdaten berechnen oder ein Analytics-Tool nutzen, das mit Stripe verbunden ist und automatisch normalisiert.

Wie behandle ich Multi-Währungs-MRR in Stripe?

Wandle alle Abonnementbeträge mithilfe des Wechselkurses zum Rechnungszeitpunkt in eine Basiswährung um. Stripe stellt das Feld currency für jedes Abonnement bereit. Wende konsistente Umrechnungskurse an — entweder monatliche Durchschnitte oder tägliche Spotkurse — aber bleibe konsistent. Die meisten Analytics-Tools handhaben das automatisch, wenn sie mit Stripe verbunden sind.

Berechne deinen MRR aus Stripe → Korrekt normalisierter MRR mit Jahresplan-Behandlung, MRR-Wasserfall und Kohorten-Aufschlüsselung, kostenlos bis 10 000 € MRR.

Kostenloses Tool
Probiere das MRR-Dashboard-Template →
Vorgefertigtes MRR-Tracking-Template, keine Anmeldung erforderlich.