What Is MRR and Why Does It Matter?
Monthly Recurring Revenue (MRR) is the normalized monthly revenue your business can reliably expect from active subscriptions. It's not what you invoiced this month. It's not cash collected. It's the predictable, recurring portion of your revenue base, expressed as a monthly figure.
MRR matters because it's the foundation for every other metric that determines your company's health: churn rate, LTV, payback period, ARR, and growth efficiency. Investors speak in MRR. When you say "we're at $12k MRR," everyone in the room instantly understands the scale and trajectory of your business. When you say "we made $14,200 last month," they have to start asking follow-up questions.
For a solo founder or early-stage SaaS company, MRR is your north star. It's the number you report on each month, track week over week, and use to make every pricing, marketing, and hiring decision. Get it wrong and every downstream decision is built on a bad foundation.
The MRR Formula
At its simplest, MRR is the sum of all active monthly subscription revenue. But that's only the beginning. The more useful construct breaks MRR into its components so you can understand why it's moving:
- New MRR — Revenue from customers who subscribed for the first time this month.
- Expansion MRR — Additional revenue from existing customers who upgraded their plan (or added seats).
- Contraction MRR — Lost revenue from existing customers who downgraded.
- Churned MRR — Revenue completely lost from customers who cancelled their subscriptions.
The delta between where you started and ended the month is your Net New MRR. A healthy SaaS business has Expansion MRR partially or fully offsetting churn — that's called negative net revenue churn, and it's the property that makes SaaS businesses compound.
You start April at $8,000 MRR. Five new customers add $600 in New MRR. Two customers upgrade, adding $200 Expansion MRR. One customer downgrades, losing $80 Contraction MRR. Two customers cancel, losing $350 Churned MRR. Net New MRR = $600 + $200 − $80 − $350 = $370. You end April at $8,370 MRR.
Why Calculating MRR from Raw Stripe Data Is Painful
In theory, you open Stripe, look at your active subscriptions, add them up, done. In practice, this breaks down almost immediately. Stripe's data model is built around payments and invoices, not revenue analytics. It records transactions as they happen — it doesn't maintain a clean, normalized view of recurring revenue.
Annual plans
A customer on a $1,200/year plan doesn't contribute $1,200 MRR — they contribute $100 MRR. Stripe records the $1,200 charge as a single invoice. To calculate MRR correctly, you need to divide annual plan revenue by 12 and normalize it. Stripe doesn't do this for you. If you naively sum Stripe invoice amounts, a single annual customer will spike your "MRR" by $1,100 in one month and then disappear.
Prorations
When a customer upgrades mid-cycle, Stripe charges a prorated amount. When they downgrade, Stripe issues a prorated credit. These appear in your invoice data as line items. If you count them as MRR, you'll have noise in your numbers every time anyone changes plans. Prorations need to be excluded from MRR calculations and handled separately as expansion/contraction events.
Trials
Free trials create subscriptions in Stripe before any revenue is collected. A subscription in "trialing" status should contribute $0 to MRR. But if you're pulling all active subscriptions and summing their amounts, trials inflate your numbers. And when a trial converts to paid, you need to attribute that correctly as New MRR — not count the subscription amount twice.
Coupons and discounts
Stripe lets you apply percent-off or amount-off coupons at the subscription level. The plan amount in your subscription object is the full price — not what the customer actually pays. MRR should reflect actual revenue, which means you need to factor in coupon discounts. A 50%-off lifetime coupon on a $100/mo plan contributes $50 MRR, not $100.
Failed payments and dunning
A subscription in "past_due" status has failed to collect payment. The subscription technically still exists, but no revenue is coming in. Including past_due subscriptions in your MRR overstates your true recurring revenue. A customer in a dunning cycle might recover — or they might churn — but until payment clears, they're not contributing real MRR.
Refunds
Stripe refunds don't automatically adjust subscription status. A refunded payment means negative revenue for that period, but the subscription object remains active. Manual handling required.
None of these edge cases is catastrophic in isolation. But as your customer base grows, you'll have all of them simultaneously: a mix of monthly/annual plans, mid-cycle upgrades, trial conversions, discounted accounts, and past-due subscriptions. At 50+ customers, MRR from a Stripe export is routinely off by 15-30% if you're not handling every case correctly.
Connect Stripe, see accurate MRR instantly
RevScope handles annual normalization, prorations, trials, and discounts automatically.
Common Mistakes Founders Make
1. Counting one-time payments as MRR
Setup fees, professional services, one-time add-ons — none of these are recurring. If you charge $500 for onboarding, that's $500 in revenue, not $500 MRR. Including one-time charges inflates your MRR and makes your churn rate look better than it is (since those customers leave without a recurring base to churn from).
2. Ignoring failed charges
Involuntary churn (failed payments) is the sneaky killer of MRR. Founders often only count active subscriptions without checking payment status. A subscription stays "active" in Stripe even when a payment fails and retries are ongoing. Accurate MRR excludes any subscription in past_due or unpaid status where payment recovery has failed.
3. Dividing ARR by 12 and calling it MRR
This works only if 100% of your revenue is on monthly plans. The moment you have a mix of monthly and annual customers, ARR/12 gives you a distorted figure. The correct approach is to normalize each subscription individually to its monthly equivalent, then sum.
4. Wrong proration handling
Prorations can appear in Stripe as both debits and credits on the same invoice. Counting proration line items as MRR movement double-counts the expansion or contraction. Prorations should be excluded from your MRR snapshot and only the normalized plan amounts should count.
5. Using bank deposits to estimate MRR
Some founders look at their Stripe payouts to the bank and divide by the number of months. This conflates timing (Stripe payouts run on their own schedule), failed/recovered payments, refunds, and fees into a single number. It's revenue received, not recurring revenue.
How RevScope Automates MRR from Stripe
RevScope connects to Stripe via a read-only restricted API key — it can read your data but never touch your payments or subscriptions. From there, it handles every edge case automatically:
- Annual plan normalization — Every annual subscription is divided by 12 to produce its monthly equivalent.
- Trial filtering — Trialing subscriptions contribute $0 until they convert to paid.
- Discount application — Coupon discounts are applied at the subscription level to reflect actual revenue.
- Payment status filtering — Past-due and unpaid subscriptions are excluded from active MRR.
- MRR movement breakdown — New, expansion, contraction, and churn are calculated separately so you can see what's driving changes.
The result: connect Stripe once, see accurate MRR immediately. No spreadsheet formulas, no manual Stripe API calls, no edge cases to handle yourself.
RevScope also shows churn rate, LTV, ARR, and a 6-month revenue forecast — all calculated from the same normalized Stripe data. See how it compares to Baremetrics and ChartMogul if you're evaluating tools.
Should You Build This Yourself?
If you're at under 20 customers with only monthly plans, a spreadsheet with manual Stripe exports probably works fine. The math isn't complicated at that scale.
Once you cross 50+ customers with a mix of monthly/annual plans, trials, and coupons, the manual approach starts costing you real time and introducing real errors. At that point, $19/mo for accurate MRR tracking is a straightforward decision.
If you're fundraising or reporting to investors, accurate MRR is table stakes. Investors cross-check your numbers, and "I manually pull Stripe exports" is not a confidence-inspiring answer when you're describing your $15k MRR business.
Stop calculating MRR in spreadsheets
Connect Stripe in 60 seconds. Full MRR, churn, LTV, and forecasts for $19/mo.
Related reading: How to Calculate MRR — Formula & Examples · How to Reduce SaaS Churn · How to Calculate Customer Lifetime Value · RevScope vs Baremetrics vs ChartMogul (2026) · Free MRR calculator →