Stripe MRR: zo bereken je hem correct

Stripe MRR is geen native metric. Stripe toont omzet, geen maandelijks terugkerende omzet. De Stripe MRR-berekening vereist het normaliseren van ruwe Stripe-abonnementsdata: jaarplannen delen door 12, eenmalige kosten uitsluiten, proraties verwerken en alleen actieve abonnementen tellen. Het “MRR”-getal dat het Stripe-dashboard toont is fout voor de meeste SaaS-bedrijven met een mix van factureringsintervallen. Deze gids legt uit waarom het Stripe MRR-cijfer in Billing → Overview onbetrouwbaar is, doorloopt stap voor stap hoe je MRR uit Stripe correct berekent en behandelt elk randgeval — trials, kortingen, coupons en jaarplannen — dat de meeste gidsen overslaan.

Stripe MRR: het native “MRR”-cijfer van Stripe is niet genormaliseerd. Correcte MRR = som van alle actieve abonnementsbedragen omgerekend naar maandelijkse equivalenten, exclusief eenmalige kosten, trials en gepauzeerde abonnementen. Jaarplannen moeten gedeeld worden door 12.

Bereken je MRR vanuit Stripe → Genormaliseerde MRR met correcte jaarplan-behandeling, gratis tot 10 000 € MRR.

Toont Stripe de MRR?

Ja en nee. Stripe Billing toont een “MRR”-getal in de sectie Billing → Overview. Het probleem: het is niet correct genormaliseerd.

Wat de MRR van Stripe daadwerkelijk telt: Stripe berekent de MRR door alle actieve abonnementen te nemen en hun bedragen op maandbasis te sommeren. De conversielogica klinkt goed, maar behandelt randgevallen verkeerd voor de meeste SaaS-bedrijven.

Waarom het fout gaat bij jaarplannen: De Stripe MRR-berekening voor jaarabonnementen is inconsistent. In sommige configuraties spreidt hij het jaarbedrag correct over 12 maanden. In andere — vooral wanneer je jaar- en maandfacturatie mengt of klanten handmatig tussen plannen bent gemigreerd — toont hij de volledige jaarafschrijving in de incassomaand en nul in de overige maanden.

Het trial-probleem: Stripe kan trials wel of niet meetellen in de MRR, afhankelijk van je configuratie. Heeft een trial een eerste periode op 0 €, dan wordt hij meestal uitgesloten. Gebruikt hij een 100 %-coupon op de eerste maand, dan kan hij worden geteld als 0 € MRR of inconsistent worden uitgesloten.

De praktische test: Vergelijk het MRR-getal van Stripe met een handmatige som van je actieve abonnementsbedragen. Komen ze binnen een paar euro overeen, dan werkt de Stripe-berekening voor jouw configuratie. Lopen ze uit elkaar — vooral als het Stripe-getal piekt in verlengingsmaanden — dan heb je een normalisatieprobleem voor jaarplannen. De meeste SaaS-bedrijven met meer dan 15 % jaarklanten zien significante divergentie, doorgaans 20-40 % inflatie in piek-verlengingsmaanden.

Voor de volledige regels over wat in de MRR thuishoort en wat niet — inclusief proraties, setupkosten en eenmalige kosten — zie de MRR-berekeningsgids.

Waarom een correcte Stripe MRR ertoe doet

MRR is de fundamentele metric waarop bijna elk ander SaaS-getal is gebouwd. Krijg het fout en de cascade breekt.

Churnratio = verloren MRR ÷ start-MRR. Is de start-MRR opgeblazen door jaarplan-pieken, dan klopt de noemer van je churn niet — churn lijkt lager in zware verlengingsmaanden en hoger in lichte verlengingsmaanden, waardoor je belangrijkste retentie-signaal heen en weer slingert.

LTV = ARPU ÷ maandelijkse churnratio. ARPU = MRR ÷ klanten. Blaas MRR op, blaas ARPU op, blaas LTV op. Je acquisitiebeslissingen rusten op een getal dat 20-40 % fout is.

NRR en GRR: beide gebruiken start-MRR als noemer. Hetzelfde probleem.

Forecasting: projecteer je MRR met je huidige groeisnelheid, dan laat een valse piek door jaarverlengingen de groei van deze maand hoger lijken dan ze is. Je 6-maandsprognose schiet over, en je bent verrast als de groei “vertraagt” volgende maand.

Het juiste MRR-cijfer is de fundering. Al het andere volgt eruit. De 15 minuten investering om je Stripe MRR-berekening te normaliseren zijn meer waard dan zowat elke andere analyticstaak die je deze week zou kunnen doen. Doe het één keer, maak er een gewoonte van het maandelijks te checken en elke andere SaaS-metric staat op vaste grond. Bouw het één keer fout en je bent maanden bezig met debugging van opgeblazen LTV en foute churnratio’s voordat je het probleem terugherleidt naar de bron.

Wat Stripe in plaats van MRR toont

Het Stripe Billing-dashboard biedt verschillende omzetcijfers. Begrijpen wat elk vertegenwoordigt helpt te identificeren welk er correctie nodig heeft.

“MRR” in Billing Overview: Stripe’s schatting van maandelijks terugkerende omzet. Onbetrouwbaar om de bovenstaande redenen. Gebruik als sanity check, niet als primaire MRR-bron.

Net volume (tab Payments): Totaal van geïnde afschrijvingen in een periode. Inclusief eenmalige kosten, setupkosten en het volledige bedrag van jaarabonnementsbetalingen. Dit is cashflow, geen MRR. Een jaarplan gefactureerd voor 480 € verschijnt als 480 € net volume in de incassomaand en 0 € in de daaropvolgende 11 maanden.

Subscription revenue: In Stripe Billing → Revenue → Subscription Revenue zie je maandelijkse abonnementsfactureringsactiviteit. Dichter bij nuttig, maar mengt nog steeds factureringsintervallen en normaliseert geen jaarplannen naar maandelijkse equivalenten.

Revenue Recognition (betaalde functie): De Revenue Recognition-add-on van Stripe berekent erkende omzet correct volgens ASC 606, en verdeelt het 480 € jaarabonnement over 12 maanden à 40 €/maand. Boekhoudkundig accuraat, maar het is het cijfer voor erkende omzet — niet de operationele MRR die je voor groei tracking gebruikt.

Hoe je MRR uit Stripe-data correct berekent

De juiste aanpak: neem alle actieve abonnementen, converteer elk naar zijn maandelijkse equivalent en sommeer alles.

De formule:

MRR = Σ (abonnementsbedrag × hoeveelheid × maandelijkse_conversiefactor)

Waarbij maandelijkse_conversiefactor is:

Maandelijkse facturering: 1,0
Jaarlijkse facturering: 1/12 = 0,0833
Kwartaalfacturering: 1/3 = 0,333
Wekelijkse facturering: 52/12 = 4,333

Stap-voor-stap berekening:

Stap 1. Lijst alle actieve abonnementen. Actief = status active of trialing (als je trials in de MRR meetelt). Sluit canceled, past_due, paused en incomplete uit.

Stap 2. Voor elk abonnement: haal het planbedrag en het factureringsinterval op. In Stripe’s datamodel: subscription.items[0].price.unit_amount (in centen) en subscription.items[0].price.recurring.interval.

Stap 3. Converteer naar maandbedrag.

maandbedrag = unit_amount / 100.0 × hoeveelheid × maandelijkse_conversiefactor

Stap 4. Sommeer alle maandbedragen. Die som is je genormaliseerde MRR.

Stripe API-aanpak:

import stripe

stripe.api_key = 'rk_live_...'  # restricted key, alleen lezen

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']
        
        # Normaliseren naar maand
        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} €")

Dit script behandelt alle factureringsintervallen correct. Voor multi-item abonnementen (klanten met add-ons) sommeert het alle items.

Randgevallen verwerken

Trials

Trials meetellen in de MRR? De conventie varieert. De meeste SaaS-oprichters sluiten gratis trials uit de MRR uit omdat er geen omzet wordt geïnd. Als een trial converteert naar een betaald plan, voeg het abonnement toe aan de MRR op het moment van conversie.

“Trialing-maar-betaalde” trials (waarbij de proefperiode een coupon gebruikt die naar 0 € korting geeft): sluit ze uit van de MRR totdat de coupon vervalt en de klant volle prijs betaalt.

Stripe-implementatie: filter alleen op status = 'active' (niet trialing) om alle trials uit te sluiten van de MRR.

Kortingen en coupons

Coupons die het in rekening gebrachte bedrag verlagen, beïnvloeden het geïnde geld maar worden in standaard SaaS-boekhouding meestal NIET van de MRR afgetrokken. MRR vertegenwoordigt de catalogusprijs — de “toegezegde” omzet. Catalogusprijs-MRR vermijdt ook MRR-fluctuaties wanneer tijdsgebonden coupons aflopen.

Vertegenwoordigt een coupon echter een permanente prijsafspraak (een onderhandelde korting die nooit afloopt), gebruik dan het kortingsbedrag in de MRR. Bevraag subscription.discount.coupon.duration; bij forever gebruik je de gekorte prijs.

Stripe-coupon in de MRR-berekening:

# Alleen voor permanente 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  # converteer centen

Jaarplannen: het kritieke randgeval

Jaarplannen zijn de meest voorkomende bron van MRR-inflatie als ze fout berekend worden. De fix: deel jaarplanbedragen altijd door 12.

Jaarplan: 480 €/jaar → MRR-bijdrage: 40 €/maand

Tel je de 480 € als MRR in de verlengingsmaand, dan piekt je MRR bij elke jaarverlenging en lijkt hij lager in niet-verlengingsmaanden. De genormaliseerde versie (40 €/maand constant) is wat je voor groei-metrics wilt volgen.

Wat te doen met deelmaanden: als een klant halverwege de maand abonneert, prorabiliseren sommige teams de MRR-bijdrage van de eerste maand. De meeste oprichters slaan proratie over voor de eenvoud — voeg het volledige maandbedrag toe op de aanmaakdatum van het abonnement en verwijder het op de annuleringsdatum. Het verschil is meestal te verwaarlozen in early stage.

Voor de volledige behandeling van wat een genormaliseerde MRR omvat en uitsluit — en waarom Stripe’s native cijfer voor veel factureringsconfiguraties de plank misslaat — dekt de MRR-definitiegids elk randgeval.

Stripe Sigma: SQL-aanpak

Met Stripe Sigma kun je je Stripe-data direct in SQL bevragen. Hier een Sigma-query voor genormaliseerde 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;

Dit verwerkt maandelijkse, jaarlijkse en wekelijkse factureringsintervallen met correcte normalisatie.

Sigma-beperkingen voor MRR-tracking: Sigma geeft je MRR van nu. Het bewaart geen historische MRR-snapshots — dus je kunt niet zien hoe de MRR er op 1 januari uitzag. Voor trendanalyse zou je deze query dagelijks moeten draaien en resultaten extern bewaren, of een tool gebruiken dat de geschiedenis automatisch onderhoudt.

Sigma mist ook:

De MRR-waterval (new/expansion/contraction/churn-uitsplitsing) zonder maandelijkse snapshot-tabellen te onderhouden
Trial-naar-betaald conversietracking op MRR-niveau
Per-plan en per-cohort MRR-uitsplitsing zonder extra querycomplexiteit

Sigma is de juiste tool als je SQL-vaardigheden hebt en een eenmalige vraag over je Stripe-data. Voor doorlopende MRR-monitoring maakt de onderhoudsoverhead van Sigma-queries — naarmate je pricing evolueert — speciale analyticstools praktischer voor de meeste oprichters.

MRR-bewegingen: voorbij één getal

Zodra je genormaliseerde MRR hebt, is de volgende laag begrijpen wat de veranderingen van maand tot maand drijft. Stripe geeft je totale MRR — een statisch getal. Wat je werkelijk nodig hebt om groei te begrijpen is een MRR-waterval:

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

New MRR: omzet van klanten die de vorige maand niet bestonden. Expansion MRR: extra omzet van klanten die zijn geüpgraded (betalen deze maand meer dan vorige). Contraction MRR: verminderde omzet van klanten die zijn gedowngraded. Churned MRR: omzet van klanten die hebben opgezegd.

Stripe berekent deze uitsplitsing niet native. Het weet dat opzeggingen plaatsvonden maar volgt expansion vs contraction vs nieuwe abonnementen niet in waterval-formaat. Stripe Sigma kan het reconstrueren door twee maandelijkse abonnementssnapshots te joinen, maar je moet die snapshots zelf onderhouden.

Waarom de waterval ertoe doet:

Een MRR-groeisnelheid vertelt je het resultaat. De waterval vertelt je de oorzaak. Twee bedrijven die beide 10 % MRR-groei per maand hebben, kunnen op een enkele MRR-grafiek identiek lijken maar zeer verschillende drijfveren hebben:

Bedrijf A: 15 % new MRR, 8 % churned MRR → acquisitie-gedreven groei, kwetsbaar als acquisitie vertraagt
Bedrijf B: 8 % new MRR, 3 % expansion MRR, 2 % churned MRR → groei uit gemengde bronnen, beter verdedigbaar

De waterval is ook de brug tussen MRR en Net Revenue Retention (NRR): NRR = (start-MRR + expansion − contraction − churn) ÷ start-MRR. Bereken je NRR handmatig, dan heb je de waterval-componenten nodig.

Voor ARR-planning vermenigvuldig je je genormaliseerde maand-MRR met 12. ARR = MRR × 12. Dezelfde normalisatieregels gelden: jaarplannen ÷ 12, dan × 12 = jaarplanbedrag, wat correct is.

Tools van derden voor Stripe MRR

Tool	MRR-normalisatie	Historische trends	Startprijs
NoNoiseMetrics	✅ Correct (jaarlijks ÷12)	✅ Volledige geschiedenis	Gratis → 79 €/maand
ChartMogul	✅ Correct	✅ Volledige geschiedenis	100 €+/maand
Baremetrics	✅ Correct	✅ Volledige geschiedenis	108 €+/maand
Stripe Sigma	✅ (via SQL)	❌ Alleen punt in tijd	~10 €/maand
Handmatige spreadsheet	Hangt af	❌ Vereist onderhoud	Gratis

Voor het bredere beeld van wat de analyticslaag van Stripe biedt versus wat externe tools vereist, zie de analyse van Stripe Analytics-lacunes.

FAQ

Toont Stripe de MRR?

Stripe Billing Overview toont een MRR-cijfer, maar het is vaak onnauwkeurig voor bedrijven met jaarplannen of gemengde factureringsintervallen. Het cijfer kan pieken in verlengingsmaanden voor jaarklanten en lagere MRR tonen in niet-verlengingsmaanden. Voor correcte MRR normaliseer je alle abonnementsbedragen naar hun maandelijkse equivalent: jaarplannen ÷ 12, maandplannen × 1.

Hoe bereken ik de MRR vanuit Stripe?

Lijst alle actieve abonnementen via de Stripe API of Sigma. Voor elk abonnement neem je planbedrag × hoeveelheid en deel je door het factureringsinterval in maanden (jaarlijks = 12, kwartaal = 3, maandelijks = 1). Sommeer alle maandelijkse equivalenten. Sluit trials, geannuleerde abonnementen, gepauzeerde abonnementen en eenmalige kosten uit.

Waarom is de MRR van Stripe fout?

De MRR-berekening van Stripe behandelt jaarplannen inconsistent afhankelijk van je factureringsconfiguratie. Hij kan ook trials meetellen, volledige jaarbedragen tellen in verlengingsmaanden of mid-cycle upgrades missen. De veiligste aanpak is de MRR zelf berekenen vanuit de abonnementenlijst met genormaliseerde intervalconversie.

Hoe zie ik de MRR in Stripe zonder Sigma?

Stripe Billing → Revenue toont een omzetgrafiek en abonnementsmetrics. Voor genormaliseerde MRR de meest betrouwbare handmatige aanpak: exporteer je actieve abonnementen als CSV, voeg een kolom toe voor het maandelijkse equivalent (jaarbedrag ÷ 12) en sommeer. Voor doorlopende MRR-tracking, koppel Stripe aan een tool die de normalisatie automatisch berekent.

Wat is de Stripe MRR-formule?

Genormaliseerde MRR = som van (maandelijks equivalent bedrag × hoeveelheid) voor alle actieve abonnementen. Maandelijks equivalent = planbedrag ÷ factureringsmaanden (1 maandelijks, 12 jaarlijks, 3 kwartaal). Sluit gepauzeerde, geannuleerde, onvolledige en trial-abonnementen uit.

Hoe moet ik jaarplannen behandelen in de Stripe MRR?

Deel jaarplanbedragen altijd door 12. Een plan van 480 €/jaar draagt 40 €/maand bij aan de MRR. Voeg nooit de volledige 480 € toe aan de MRR in de verlengingsmaand — dat creëert valse pieken die je echte groeitrend verhullen. De constante 40 € is het juiste cijfer voor elke maand dat de klant actief is.

Toont Stripe de MRR native?

Nee. Stripe toont brutovolume (alle afschrijvingen), geen genormaliseerde MRR. Stripe annualiseert maandplannen niet, sluit eenmalige kosten niet uit van terugkerende totalen en behandelt proratie niet correct voor MRR-doeleinden. Je moet de MRR zelf berekenen vanuit abonnementsdata, of een analyticstool gebruiken dat met Stripe is verbonden en automatisch normaliseert.

Hoe behandel ik multi-valuta MRR in Stripe?

Converteer alle abonnementsbedragen naar één basisvaluta met de wisselkoers op het moment van de factuur. Stripe levert het veld currency voor elk abonnement. Pas consistente conversiekoersen toe — gebruik maandelijkse gemiddelden of dagelijkse spotkoersen — maar wees consistent. De meeste analyticstools verwerken dit automatisch wanneer ze met Stripe verbonden zijn.

Bereken je MRR vanuit Stripe → Correct genormaliseerde MRR met jaarplan-behandeling, MRR-waterval en cohort-uitsplitsing, gratis tot 10 000 € MRR.

Gratis tool
Probeer het MRR-dashboard-template →
Kant-en-klaar MRR-tracking-template, geen registratie vereist.