Stripe MRR: How to Calculate It Correctly

Stripe MRR isn’t a native metric. Stripe shows revenue, not monthly recurring revenue. The stripe monthly recurring revenue calculation requires normalizing raw Stripe subscription data: dividing annual plans by 12, excluding one-time fees, handling prorations, and counting only active subscriptions. The MRR Stripe dashboard number Stripe does show is incorrect for most SaaS businesses with a mix of billing intervals. This guide explains why the stripe subscription mrr figure in Billing → Overview is unreliable, walks through how to calculate mrr stripe correctly step-by-step, and covers every edge case, trials, discounts, coupons, and annual plans, that most guides skip.

Stripe MRR: Stripe’s native “MRR” figure is not normalized. Correct MRR = sum of all active subscription amounts converted to monthly equivalents, excluding one-time fees, trials, and paused subscriptions. Annual plans must be divided by 12.

Calculate Your MRR from Stripe → Normalized MRR with correct annual plan handling, free up to €10k MRR.

Does Stripe Show MRR?

Yes and no. Stripe Billing shows an “MRR” number in the Billing → Overview section. The problem: it’s not correctly normalized.

What Stripe’s MRR actually counts: Stripe calculates MRR by taking all active subscriptions and summing their amounts, converted to a monthly basis. The conversion logic sounds right, but it handles edge cases incorrectly for most SaaS businesses.

Why it’s wrong for businesses with annual plans: Stripe’s MRR calculation for annual subscriptions is inconsistent. In some configurations, it distributes the annual amount across 12 months correctly. In others, particularly when you’ve mixed annual billing with monthly billing, or when customers have been manually migrated between plans, it shows the full annual charge in the month of collection and zero in other months.

The trial problem: Stripe may or may not include trials in MRR depending on your configuration. If a trial has a $0 first period, it’s typically excluded. If it uses a 100% coupon on the first month, it may be counted as $0 MRR or excluded inconsistently.

The practical test: Compare Stripe’s MRR figure to a manual sum of your active subscription plan amounts. If they match within a few euros, Stripe’s calculation is working correctly for your configuration. If they diverge, especially if Stripe’s number spikes in renewal months, you have an annual plan normalization problem. Most SaaS businesses with more than 15% of customers on annual plans will see significant divergence, typically 20–40% inflation in peak renewal months.

For the complete rules on what belongs in MRR and what doesn’t, including prorations, setup fees, and one-time charges, see the MRR calculation guide.

Why Correct Stripe MRR Matters

MRR is the foundation metric that almost every other SaaS number is built on. Get it wrong and the cascade breaks.

Churn rate = churned MRR ÷ starting MRR. If starting MRR is inflated by annual plan spikes, your churn rate denominator is wrong, churn looks lower in heavy-renewal months and higher in light-renewal months, swinging your most important retention signal.

LTV = ARPU ÷ monthly churn rate. ARPU = MRR ÷ customers. Inflate MRR, inflate ARPU, inflate LTV. Your acquisition spending decisions rest on a number that’s 20–40% wrong.

NRR and GRR: both use starting MRR as denominator. Same problem.

Forecasting: if you’re projecting MRR forward at your current growth rate, a false spike from annual renewals makes this month’s growth rate look higher than it is. Your 6-month forecast overshoots, and you’re surprised when growth “slows” next month.

The correct MRR figure is the foundation. Everything else follows from it. The 15-minute investment to normalize your Stripe MRR calculation is worth more than almost any other analytics task you could do this week. Do it once, build the habit of checking it monthly, and every other SaaS metric you calculate will be on solid ground. Build it wrong once and you’ll be debugging inflated LTV and wrong churn rates for months before you trace the problem back to the source.

What Stripe Shows Instead of MRR

The Stripe Billing dashboard provides several revenue figures. Understanding what each one represents helps you identify which needs correction.

“MRR” in Billing Overview: Stripe’s estimate of monthly recurring revenue. Unreliable for the reasons above. Use as a sanity check, not as your primary MRR source.

Net volume (Payments tab): Total charges collected in a period. Includes one-time fees, setup charges, and the full amount of annual subscription payments. This is cash flow, not MRR. An annual plan billed at €480 shows as €480 in net volume the month it charges, and €0 in the next 11 months.

Subscription revenue: In Stripe Billing → Revenue → Subscription Revenue, you can see monthly subscription billing activity. This is closer to useful but still mixes billing intervals and doesn’t normalize annual plans to monthly equivalents.

Revenue Recognition (paid feature): Stripe’s Revenue Recognition add-on calculates recognized revenue correctly per ASC 606, spreading the €480 annual subscription across 12 months at €40/month. This is accurate from an accounting standpoint, but it’s the recognized revenue figure, not the operational MRR you’d use for growth tracking.

How to Calculate MRR from Stripe Data Correctly

The correct approach: take all active subscriptions, convert each to its monthly equivalent, sum them up.

The formula:

MRR = Σ (subscription_amount × quantity × monthly_conversion_factor)

Where monthly_conversion_factor is:

Monthly billing: 1.0
Annual billing: 1/12 = 0.0833
Quarterly billing: 1/3 = 0.333
Weekly billing: 52/12 = 4.333

Step-by-step calculation:

Step 1. List all active subscriptions. Active = status is active or trialing (if you count trials in MRR). Exclude canceled, past_due, paused, and incomplete.

Step 2. For each subscription, get the plan amount and billing interval. In Stripe’s data model: subscription.items[0].price.unit_amount (in cents) and subscription.items[0].price.recurring.interval.

Step 3. Convert to monthly amount.

monthly_amount = unit_amount / 100.0 × quantity × monthly_conversion_factor

Step 4. Sum all monthly amounts. That sum is your normalized MRR.

Stripe API approach:

import stripe

stripe.api_key = 'rk_live_...'  # restricted key, read-only

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']
        
        # Normalize to monthly
        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}")

This script handles all billing intervals correctly. For multi-item subscriptions (customers with add-ons), it sums all items.

Handling Edge Cases

Trials

Include trials in MRR? Convention varies. Most SaaS founders exclude free trials from MRR because no revenue is being collected. If a trial converts to a paid plan, add the subscription to MRR at conversion time.

Trialing-but-paid trials (where the trial period uses a coupon discounting to €0): exclude these from MRR until the coupon expires and the customer pays full price.

Stripe implementation: filter to status = 'active' only (not trialing) to exclude all trials from MRR.

Discounts and Coupons

Coupons that reduce the charged amount affect the cash collected but typically are NOT subtracted from MRR in standard SaaS accounting. MRR represents list price, the “committed” revenue. Using list price MRR also avoids MRR fluctuations when time-limited coupons expire.

However, if a coupon represents a permanent price commitment (a negotiated discount that never expires), use the discounted amount in MRR. Query subscription.discount.coupon.duration, if forever, use the discounted price.

Stripe coupon in MRR calculation:

# For permanent coupons only
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  # convert cents

Annual Plans: The Critical Edge Case

Annual plans are the most common source of MRR inflation when calculated incorrectly. The fix: always divide annual plan amounts by 12.

Annual plan: €480/year → MRR contribution: €40/month

If you count the €480 as MRR in the month of renewal, your MRR will spike every time annual plans renew and look lower in off-renewal months. The normalized version (€40/month constant) is what you want to track for growth metrics.

What to do with partial months: when a customer subscribes partway through the month, some teams prorate the first month’s MRR contribution. Most founders skip proration for simplicity, add the full monthly amount at subscription creation date and remove it at cancellation date. The difference is usually immaterial at early stage.

For the full treatment of what normalized MRR includes and excludes, and why Stripe’s native figure misses the mark for many billing configurations, the MRR definition guide covers every edge case.

Stripe Sigma: SQL Approach

Stripe Sigma lets you query your Stripe data directly in SQL. Here’s a Sigma query for normalized 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;

This handles monthly, annual, and weekly billing intervals with correct normalization.

Sigma limitations for MRR tracking: Sigma gives you MRR as of now. It doesn’t store historical MRR snapshots, so you can’t see how MRR looked on January 1st. For trend analysis, you’d need to run this query daily and store the results externally, or use a tool that maintains MRR history automatically.

Sigma also misses:

The MRR waterfall (new/expansion/contraction/churn breakdown) without maintaining monthly snapshot tables
Trial-to-paid conversion tracking at the MRR level
Per-plan and per-cohort MRR breakdown without additional query complexity

Sigma is the right tool if you have SQL skills and a specific one-time question about your Stripe data. For ongoing MRR monitoring, the maintenance overhead of keeping Sigma queries updated as your pricing evolves makes dedicated analytics tools more practical for most founders.

MRR Movements: Beyond a Single Number

Once you have normalized MRR, the next layer is understanding what’s driving changes month-over-month. Stripe gives you total MRR, a static number. What you actually need to understand growth is an MRR waterfall:

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

New MRR: revenue from customers who didn’t exist in the prior month. Expansion MRR: additional revenue from customers who upgraded (paid more this month than last). Contraction MRR: reduced revenue from customers who downgraded. Churned MRR: revenue from customers who cancelled.

Stripe doesn’t calculate this breakdown natively. It knows cancellations happened but doesn’t track expansion vs contraction vs new subscriptions in the waterfall format. Stripe Sigma can reconstruct it by joining two monthly subscription snapshots, but it requires maintaining those snapshots yourself.

Why the waterfall matters:

An MRR growth rate tells you the result. The waterfall tells you the cause. Two businesses both growing MRR at 10% per month can look identical on a single MRR chart but have very different drivers:

Business A: 15% new MRR, 8% churned MRR → acquisition-led growth, vulnerable if acquisition slows
Business B: 8% new MRR, 3% expansion MRR, 2% churned MRR → mixed-source growth, more defensible

The waterfall is also the bridge between MRR and net revenue retention (NRR): NRR = (starting MRR + expansion − contraction − churn) ÷ starting MRR. If you’re calculating NRR manually, you need the waterfall components.

For ARR planning, multiply your normalized monthly MRR by 12. ARR = MRR × 12. The same normalization rules apply, annual plans ÷ 12, then × 12 = the annual plan amount, which is correct.

Third-Party Tools for Stripe MRR

Tool	MRR Normalization	Historical Trends	Starting Price
NoNoiseMetrics	✅ Correct (annual ÷12)	✅ Full history	Free → €79/mo
ChartMogul	✅ Correct	✅ Full history	€100+/mo
Baremetrics	✅ Correct	✅ Full history	€108+/mo
Stripe Sigma	✅ (via SQL)	❌ Point-in-time only	~$10/mo
Manual spreadsheet	Depends	❌ Requires maintenance	Free

For the broader picture of what Stripe’s analytics layer provides versus what requires external tooling, see the Stripe analytics gap analysis.

FAQ

Does Stripe show MRR?

Stripe Billing’s Overview shows an MRR figure, but it’s often inaccurate for businesses with annual plans or mixed billing intervals. The figure may spike in renewal months for annual customers and show lower MRR in off-renewal months. For correct MRR, normalize all subscription amounts to their monthly equivalent: annual plans ÷ 12, monthly plans × 1.

How do I calculate MRR from Stripe?

List all active subscriptions via the Stripe API or Sigma. For each subscription, take the plan amount × quantity and divide by the billing interval in months (annual = 12, quarterly = 3, monthly = 1). Sum all monthly equivalents. Exclude trials, cancelled subscriptions, paused subscriptions, and one-time charges.

Why is Stripe’s MRR wrong?

Stripe’s MRR calculation handles annual plans inconsistently depending on your billing configuration. It may also include trials, count full annual amounts in renewal months, or miss mid-cycle upgrades. The safest approach is to calculate MRR yourself from the subscription list using normalized interval conversion.

How do I see MRR in Stripe without Sigma?

Stripe Billing → Revenue shows a revenue chart and subscription metrics. For normalized MRR, the most reliable manual approach: export your active subscriptions as a CSV, add a column for monthly equivalent (annual amount ÷ 12), and sum. For ongoing MRR tracking, connect Stripe to a tool that calculates normalization automatically.

What is the Stripe MRR formula?

Normalized MRR = sum of (monthly equivalent amount × quantity) for all active subscriptions. Monthly equivalent = plan amount ÷ billing months (1 for monthly, 12 for annual, 3 for quarterly). Exclude paused, cancelled, incomplete, and trial subscriptions.

How should I handle annual plans in Stripe MRR?

Always divide annual plan amounts by 12. A €480/year plan contributes €40/month to MRR. Never add the full €480 to MRR in the renewal month, this creates false spikes that obscure your real growth trend. The €40 constant is the correct figure for every month the customer is active.

Does Stripe show MRR natively?

No. Stripe shows gross volume (all charges), not normalized MRR. Stripe does not annualize monthly plans, does not exclude one-time charges from recurring totals, and does not handle proration correctly for MRR purposes. You need to calculate MRR yourself using subscription data, or use an analytics tool that connects to Stripe and normalizes automatically.

How do I handle multi-currency MRR in Stripe?

Convert all subscription amounts to a single base currency using the exchange rate at the time of the invoice. Stripe provides the currency field on each subscription. Apply consistent conversion rates, either use monthly average rates or daily spot rates, but be consistent. Most analytics tools handle this automatically when connected to Stripe.

Calculate Your MRR from Stripe → Correctly normalized MRR with annual plan handling, MRR waterfall, and cohort breakdown, free up to €10k MRR.

Free Tool
Try the MRR Dashboard Template →
Pre-built MRR tracking template, no signup required.