MRR vs ARR Stripe: How to Calculate Both Without Lying to Investors

A founder I know walked into a board meeting last spring with $52K MRR on the deck. Two weeks later, in a fundraising call with the same numbers reformatted, the figure was $61K. Same company, same month, same Stripe account, two different numbers. He had not lied once. He had calculated MRR two different ways, and nobody noticed until an associate at the lead fund pulled his own data from the Stripe API and asked which version was real.

If you are reading this, you know what MRR and ARR are. The problem is not the definition. The problem is that Stripe gives you fifteen plausible ways to compute each one, and the gap between “what Dashboard shows” and “what your board wants to see” is wide enough to drive a Series A through.

This post covers MRR vs ARR Stripe math the way you actually have to do it: which subscriptions count, how to handle annuals, trials, prorations, pauses, and which tools get it right.

The simple definitions

MRR (Monthly Recurring Revenue): the sum of all active recurring subscription revenue, normalized to one calendar month. Annual subscriptions get divided by twelve. Quarterly by three. Weekly multiplied by 52/12.

ARR (Annualized Run Rate): MRR multiplied by twelve.

That is it. ARR is a derived metric. If you know MRR you know ARR. If two people compute the same MRR honestly, they get the same ARR. The mistakes never live in the multiplication; they live in what gets included in MRR in the first place.

Three non-obvious things implied by those definitions:

• ARR is not what you expect to collect over the next 12 months. It is a snapshot of the current run rate annualized. Treating ARR as a forecast is a category error.
• MRR is a point-in-time metric. “MRR for March” means “MRR as of March 31.” It is not the cash collected in March.
• MRR only counts recurring revenue. One-time fees, setup charges, and professional services do not belong in MRR.

Internalize those three and most arithmetic mistakes disappear. Then Stripe enters the picture.

Why Stripe makes MRR vs ARR Stripe math hard

Stripe is excellent at processing payments. Stripe is mediocre at telling you what your MRR is, because Stripe sees every dollar of recurring and non-recurring revenue through the same plumbing and trusts you to label it correctly. The complications stack up fast.

Annual subscriptions show up as a single $1,200 charge once a year. If you read “March charges = $1,200” and call that March MRR, you will publish a number 12x too high every March and 0 every other month.

Mid-cycle upgrades create proration line items. The proration is not recurring, so it is not MRR, but it lives in the same Stripe invoices table as the actual subscription line.

Refunds reduce cash but do not, by themselves, reduce MRR. Whether a refund affects MRR depends on whether the underlying subscription was cancelled.

Churn is silent in Stripe. A subscription set to cancel_at_period_end = true is still active until the period ends. Some founders book churn on the cancellation request date, others at period end. Pick one and stick with it.

Trials create subscriptions in trialing status with a non-zero plan amount but no payment. Most rigorous SaaS definitions exclude trials; Stripe’s own dashboard sometimes includes them.

Paused subscriptions are still subscriptions. No billing, no churn. Exclude from MRR and exclude from churn until they resume or cancel.

Free plans are not MRR. Founders still sometimes include them because they appear in the active customer count. Resist.

Multi-currency subscriptions need to be converted to a single reporting currency at a consistent FX rate. Pick spot-at-month-end or trailing-90-day average. Document the choice.

Past-due (delinquent) subscriptions are nominally active but the payment failed. Industry convention: include for a 7 to 30 day grace window, then exclude. Document your policy.

Each of these has a correct answer. Each correct answer is a policy choice, and most founders make those choices implicitly, then unknowingly make a different choice next quarter. Hence the $52K to $61K spread.

The mistakes most founders make

In rough order of frequency:

1. Using cash collected as MRR. “We did $80K in March, so MRR is $80K.” No. Cash includes annual prepayments, one-time fees, late payments, and proration top-ups. Cash is cash. MRR is the normalized recurring run rate as of a date.

2. Including trials. If 40 of your 200 “paying” customers are on day 3 of a 14-day trial, MRR is $15,840 not $19,800. Including trials hides churn at the trial-to-paid boundary, exactly where most SaaS leakage happens.

3. Forgetting to divide annuals by 12. “We closed three annual $24K deals, so MRR went up $72K.” MRR went up $6K. ARR went up $72K. Conflating these is the single most common error in pitch decks.

4. Ignoring proration on upgrades. A customer going from $100 to $200 mid-month increases the recurring run rate by $100, not $150. The $50 proration is one-time.

5. Counting paused subscriptions as active. Stripe shows them as paused not cancelled. If your sum-of-active query does not filter on status, paused subs sneak in.

6. Including non-recurring add-ons. Setup fees, training fees, implementation fees. The “R” in MRR is doing actual work.

7. Trusting Stripe Dashboard’s MRR blindly. Dashboard rounds per-subscription, includes some trial states, and has changed methodology at least twice since 2020. Use it as a sanity check, not a reporting source.

8. Mixing booked and recognized revenue. Booked MRR is the normalized run rate. Recognized revenue (the GAAP number) follows ASC 606 and ratably amortizes annual contracts across 12 months. For MRR you want booked. We covered the recognition side in the Stripe ASC 606 revenue recognition guide.

9. Inconsistent treatment of discounts. A $100 plan with a permanent 50% off coupon is $50 MRR. A $100 plan with a one-month introductory discount is $100 MRR. Most spreadsheets get this wrong half the time.

Avoid those nine and your number will be defensible.

The right way: a procedure that survives an investor’s pull

A procedure that produces a single, reproducible MRR number on any given date:

1. Pull all subscriptions with status in (active, past_due) as of your reporting date. Exclude trialing, paused, incomplete, incomplete_expired, canceled. Apply your past_due grace policy.
2. For each subscription, sum its line items. Each line is unit_amount times quantity times any active discount.
3. Normalize to monthly. Yearly /12, quarterly /3, monthly x1, weekly x52/12, daily x365/12.
4. Subtract permanent discounts. Apply percent-off coupons to the line amount before summing. Skip one-time and limited-time discounts.
5. Convert to your reporting currency at a consistent FX rate.
6. Sum across all subscriptions. That is your MRR.
7. Multiply by 12. That is your ARR.

That procedure is what ERPClaw’s MRR engine does, and it is roughly what Baremetrics, ChartMogul, and ProfitWell do too. The point is the procedure, not the tool. You should be able to point at the line in your code or spreadsheet that implements each step.

If your investor pulls the Stripe API and runs the same seven steps with the same policy choices, they should get the same number you do. If they do not, one of you is making a different policy choice, and you should know which.

A worked example: Acme SaaS

Let’s actually compute it.

Acme SaaS, as of March 31, 2026:

• 47 monthly subscriptions on the Pro plan at $99/month
• 12 annual subscriptions on the Pro plan at $1,200/year
• 8 customers on a 14-day trial (excluded)
• 3 customers paused (excluded)
• 2 customers in past_due for 4 days (included; within grace)
• 1 customer with a permanent 20% off coupon on the $99 plan (counted as $79.20)
• 5 customers on the free Hobby plan (excluded; not recurring revenue)
• $4,500 in one-time setup fees collected in March (excluded; not recurring)

The math:

Bucket	Count	Per-sub MRR	Subtotal
Monthly Pro at $99 (no discount)	46	$99.00	$4,554.00
Monthly Pro at $99 with 20% off	1	$79.20	$79.20
Annual Pro at $1,200/yr	12	$100.00	$1,200.00
Past-due monthly (within grace)	2	$99.00	(already in 46 above)
MRR total			$5,833.20

ARR = $5,833.20 x 12 = $69,998.40

Total active subs in MRR: 47 monthly + 12 annual = 59. Trials, paused, free, and one-time fees excluded.

The deck-friendly numbers:

• MRR: $5,833 (or to the cent if your audience is finance)
• ARR: $70,000 (round to nearest thousand for investor decks)

What you do not report: cash collected (includes prepayments and one-time fees), customer count (includes trials, paused, free), or “what ARR would be if trials convert” (speculation, not a metric).

What makes the number defensible: every line is traceable to a Stripe object, every exclusion has a documented reason, and the math is a sum, not an estimate. An investor asking “where does the $5,833 come from” can be handed the per-customer breakdown and walk away satisfied in five minutes.

Tools that calculate MRR for you

If you do not want to maintain the procedure above by hand, here are the main options. Honest one-line assessment of each.

• Stripe Dashboard’s built-in MRR. Free, on by default with Stripe Billing. Approximately right, but rounds per-subscription and sometimes includes trials. Sanity check, not source of truth.
• ChartMogul. $129/month and up. Mature, well-documented, used by a lot of Series A SaaS companies. Strong cohort retention.
• Baremetrics. $129/month and up. Cleaner UI than ChartMogul, with a public-dashboard feature some founders use as a trust signal. Their methodology docs are worth reading even if you do not subscribe.
• ProfitWell (now Paddle Metrics). Free tier exists. Strong on retention analytics and industry benchmarking. The free tier is genuinely useful under $10M ARR.
• Stripe Sigma. Pay-per-query SQL on your Stripe data. Powerful if you have a data person; useless if you do not.
• ERPClaw. Free, open source, AI-native, self-hosted on your own infrastructure. Computes MRR, ARR, churn, expansion, contraction, and cohort retention from Stripe subscription data, and posts the underlying journal entries to a real GL. If you only need MRR reports, ERPClaw is overkill. If you also want ASC 606 revenue recognition, three-layer payout reconciliation, and an actual general ledger, it is the only free AI-native option that does all three. See the Stripe MRR reports doc and the Rillet comparison for the head-to-head.

The right tool is the one that makes your reporting cadence faster without changing your number. If you switch tools and your MRR moves more than 2%, the tool was wrong, your old number was wrong, or both. Restate the prior periods and document the change.

What MRR alone hides

Here is the part most founders do not internalize until they get asked about it on a partner call.

Cohort retention is the metric MRR cannot tell you. Two companies can both have $100K MRR. Company A keeps 95% of each cohort a year out. Company B keeps 60%. Identical headline, completely different businesses. OpenView’s annual SaaS benchmark report publishes cohort retention curves by ARR band; comparing your curve to the median in your band is one of the fastest ways to know if you have a real product or a leaky bucket.

The way to read a cohort retention table:

Cohort	M0	M3	M6	M9	M12
Jan 2026	$5,000	$4,800	$4,650	$4,500	$4,000
Feb 2026	$7,000	$6,700	$6,500	$6,300	---
Mar 2026	$9,500	$9,100	$8,900	---	---

Each row is a single signup cohort. M0 is MRR at signup, M12 is what is left a year later. Decay across the row is churn. Flat or up means net negative churn (expansion offsets churn): a special business. If headline MRR grows but every cohort row collapses from $5,000 to $4,000 in 12 months, you are buying growth that leaks out the back. Investors spot it within minutes.

Logo churn vs revenue churn: which to trust

Two definitions, both legitimate, both report-worthy:

Logo churn = (customers who cancelled in period) / (customers active at start of period). What percentage of your customers left, counted by company.

Revenue churn = (sum of MRR lost to cancellation in period) / (MRR at start of period). What percentage of your revenue left, counted by dollars.

These two diverge when customer size varies. If you have 100 customers paying $100 and 1 customer paying $10,000, your MRR is $20,000. If you lose the one big customer, your logo churn is 1% and your revenue churn is 50%. Same event, two stories.

Which one to trust depends on what you are trying to learn:

• Product-market fit: logo churn. If 30% of new signups leave within 90 days regardless of size, the product is the problem.
• Revenue durability: revenue churn. If a few enterprise deals carry your business, watch the dollars.
• Investor reporting: report both. Smart investors ask if you only report one.

Cohort retention plus split logo/revenue churn tells you the actual health of a SaaS business in ninety seconds. MRR alone does not.

Closing

MRR vs ARR Stripe math is not arithmetic. It is policy. The math is trivial; the policy choices about what to include and exclude are where two honest founders end up with two different numbers.

If you take three things from this post:

1. Pick a procedure, write it down, and apply it the same way every month. The number being defensible matters more than the number being optimized.
2. ARR is MRR x 12. Anything else dressed up as ARR is a forecast, not a metric. Investors know the difference.
3. MRR alone hides everything that matters. Pair it with cohort retention and split logo/revenue churn or your dashboard is lying by omission.

If you want a tool that computes this from your Stripe data without sending it through someone else’s servers, ERPClaw is one free option. The Stripe integration page, the SaaS landing page, and the pricing cover what is and is not included. ChartMogul, Baremetrics, and ProfitWell are good paid alternatives. The right choice is the one that makes your number boring to compute.

Boring numbers are the ones investors trust.

Frequently asked questions

What is the difference between MRR and ARR Stripe-side?

Stripe stores subscriptions with billing intervals and amounts, not either metric directly. MRR is computed by normalizing every active subscription to a monthly rate and summing. ARR is that sum multiplied by 12. Stripe Dashboard shows its own MRR computation, which is approximate and best treated as a sanity check.

How do I calculate MRR from Stripe with annual subscriptions?

Pull every active annual subscription, divide each annual amount by 12, and add to your monthly subscription total. A $1,200/year customer contributes $100 to MRR. Do not include the $1,200 cash payment in the month it was charged.

Should I include trials in MRR?

No. Trials have not generated cash and may never convert. Including them inflates MRR and hides churn at the trial-to-paid boundary. Track trial counts and conversion rates separately as a leading indicator.

What about past-due subscriptions?

Industry convention is to include for a 7 to 30 day grace window then exclude. The grace window gives dunning time to recover the payment. Pick a window, document it, do not change it without restating.

Does Stripe Dashboard’s MRR match what my investors will compute?

Probably not exactly. Expect a 1 to 5% gap when an investor pulls the API and runs their own computation. The gap reflects different policy choices. The question is whether your reported number ties to a procedure you can defend.

What is annualized run rate Stripe-side, and is it the same as ARR?

For pure-Stripe SaaS, yes: current MRR multiplied by 12. Some tools distinguish “ARR” (contractually committed annual revenue) from “run rate” (current MRR annualized) for companies mixing month-to-month and annual contracts. For most Stripe-only reporting, the two collapse to the same number.

Should I report booked MRR or cash MRR to investors?

Booked MRR. Cash MRR is useful for runway modeling but is not the standard SaaS metric. Most decks report booked; if you report cash, label it.

How does ASC 606 revenue recognition relate to MRR?

Different metrics. MRR is a normalized run rate snapshot. ASC 606 recognized revenue is a GAAP measure that ratably amortizes annual contracts across the service period. They will not match month-to-month and they should not. Use MRR for SaaS metrics, use recognized revenue for financial statements. The ASC 606 guide covers the recognition side in depth.