Monthly recurring revenue: how to calculate MRR without fooling yourself
Monthly recurring revenue is the total predictable subscription revenue a business expects in a given month, with every plan normalised to a monthly amount. An annual plan billed at $1,200 counts as $100 of MRR, not $1,200 in the month the card is charged. That single normalisation rule is where most MRR calculations go wrong, and it is not the only place.
The formula is arithmetic. The judgement calls around it are what separate an MRR figure you can run a business on from one that quietly disagrees with your bank account.
Table of contents
- The MRR formula and the normalisation rules
- MRR, recognised revenue and cash are three different numbers
- The four movements inside a single MRR number
- Where monthly recurring revenue breaks on real billing data
- Usage-based pricing and the limits of MRR
- What MRR cannot tell you
- Frequently asked questions
The MRR formula and the normalisation rules
MRR is the sum of every active subscription's monthly-equivalent value:
MRR = sum of (contracted amount / billing period in months)
Normalise every plan to one month before adding anything up. Annual divided by twelve, quarterly divided by three, biennial divided by twenty-four. A customer on a two-year $4,800 contract contributes $200, the same as a customer paying $200 every month, because MRR measures the rate of recurring revenue rather than the timing of invoices.
Four things stay out of the sum:
- One-time fees. Setup, onboarding, implementation, migration. They are real money and they do not recur, so they do not belong in a recurring revenue metric.
- Professional services. Custom development, training days, consulting retainers with a fixed end date.
- Free trials. A trial that has not converted is not contracted revenue. It is a forecast.
- Taxes and payment processing fees. MRR is gross of processor fees and exclusive of VAT or sales tax.
Discounts come off. If a customer's list price is $500 and they hold a permanent 20% discount, they contribute $400, not $500. A discount with an end date is harder, and the honest treatment is to book the discounted amount while it applies and let the increase show up as expansion when it expires. Booking list price and calling the gap "negative revenue" produces an MRR number nobody can reconcile.
Stripe's own MRR documentation follows the same normalisation, which matters if you ever need your numbers to agree with your billing provider's dashboard.
MRR, recognised revenue and cash are three different numbers
The most common source of an argument between a founder and a finance lead is that MRR, recognised revenue and cash collected are three separate figures that almost never match, and each one is correct for a different question.
Take one customer who signs a $1,200 annual contract on 1 March and pays upfront.
| Metric | March | April | Each month to February |
|---|---|---|---|
| MRR | $100 | $100 | $100 |
| Recognised revenue | $100 | $100 | $100 |
| Cash collected | $1,200 | $0 | $0 |
MRR and recognised revenue agree here, and both disagree with cash by an order of magnitude in March. Now change one detail: the customer signs on 15 March. MRR at month end is still $100 because the subscription is active at the rate of $100 per month. Recognised revenue for March is roughly $50, because only half the month elapsed. The two diverge, and neither is wrong.
MRR answers "what is the run rate of the business right now". Recognised revenue answers "what did we earn in this period" under ASC 606 and IFRS 15. Cash answers "what can we spend". Treating any one of them as a proxy for the others is how a company with growing MRR runs out of money.
Annual prepayment makes this sharper. A business selling only annual contracts collects twelve months of cash on day one, which feels like a windfall and is actually a liability sitting on the balance sheet as deferred revenue. The MRR line will not mention it.
The four movements inside a single MRR number
MRR went from $84,000 to $86,500. Good month?
You cannot answer that from the total. The number is a sum of four independent forces, and they can move in opposite directions while the total sits nearly still:
- New MRR. Customers who did not exist last month.
- Expansion MRR. Existing customers paying more: seats added, plan upgrades, usage tiers crossed.
- Contraction MRR. Existing customers paying less, but still paying.
- Churned MRR. Customers who stopped paying entirely.
Reactivation is sometimes split out as a fifth, covering customers who churned previously and came back. Whether you fold it into new or track it separately matters less than being consistent, because the two treatments produce different new-MRR trends from identical underlying events.
Net new MRR is what the total movement actually was:
Net new MRR = new + expansion - contraction - churned
That $2,500 increase could be $12,000 of new business against $9,500 of churn, or $2,600 of expansion against a near-total collapse in acquisition. The first is a retention emergency. The second is a pipeline emergency. Both print as "MRR up 3%".
Contraction is the component most worth watching, because it is the only one that arrives early. A customer dropping from five seats to three has told you something about their next renewal, and by the time that signal becomes churn the conversation that would have saved the account happened two months ago.
Expansion can mask a contraction problem for several quarters, which is exactly why net revenue retention has to be read alongside gross revenue retention rather than instead of it.
Where monthly recurring revenue breaks on real billing data
Every MRR definition is clean until it meets a production billing system. These are the cases that produce two dashboards showing two different numbers for the same month.
Past-due subscriptions. A customer whose card failed on the 3rd is still marked active in most billing systems. Are they MRR? They are contracted, they have not cancelled, and they are producing no money. Different tools answer differently, and the gap between "active" and "paying" is where a slow payment failure problem hides. Pick a rule, usually excluding subscriptions past a defined dunning window, and apply it everywhere.
Mid-cycle plan changes. Upgrading from $100 to $300 on the 15th generates a prorated invoice for roughly $100 covering the rest of the month. Stripe's proration behaviour issues credits and charges against the remainder of the period. If you compute MRR from invoice totals, that month looks like $200 of MRR and the following month jumps to $300, inventing an expansion event that did not happen. Compute MRR from the subscription's current rate, not from what was invoiced.
Mixed billing periods in one account. An enterprise customer on an annual platform fee plus monthly per-seat add-ons needs each component normalised separately before summing.
Multi-currency. A customer paying €500 contributes an MRR figure that moves when the euro moves, without anything changing about the customer. Fixing the rate at contract signing keeps MRR stable and makes it disagree with cash. Using spot rates keeps cash aligned and introduces currency noise into your growth rate. Most companies fix the rate for the reporting period and disclose it.
Small numbers. At forty customers, one $2,000 account churning moves MRR by more than most product decisions will all quarter. Percentage changes computed on small bases mostly measure the largest customer.
Usage-based pricing and the limits of MRR
MRR assumes a contracted monthly amount exists. Under pure usage-based pricing, it does not.
If a customer pays for what they consume with no commitment, there is no recurring contracted figure to normalise. The common workarounds each distort something. Using trailing three-month average usage smooths spikes and lags real changes by design. Using last month's usage makes MRR as volatile as the underlying consumption, which defeats the purpose of a run-rate metric. Using the committed minimum on a hybrid contract undercounts customers consistently running above their floor.
None of these is wrong. All of them need stating, because a usage-heavy business reporting "MRR" without saying which convention it used is reporting a number that cannot be compared to anyone else's, including its own from last year.
For businesses selling annual and multi-year contracts, the annual view carries more information than the monthly one, and annual recurring revenue is the metric that matches how the contracts are actually written.
What MRR cannot tell you
MRR is a lagging aggregate. It reports the state of the business at month end with no account of how it got there or when the change began.
It cannot tell you when something started. A churn problem that began in week two shows up as a single month-end number four weeks later, by which point the cohort that triggered it has mostly finished leaving.
It cannot tell you why. A pricing page change, a failed payment provider migration, an outage during a renewal window and a competitor launch all produce the same shape of dip.
It cannot tell you which customers. Aggregates dissolve exactly the information you need to act, which is the list of accounts behind the movement.
That is the gap between a metric and a decision. Decomposing MRR into its four movements narrows it. Attaching the accounts behind each movement, and the change that preceded it, closes it.
Frequently asked questions
What is a good MRR growth rate?
It depends entirely on stage and starting base. Growing from $10,000 to $11,000 is 10% and routine. Growing from $1m to $1.1m is the same percentage and rare. Judge the rate against your own trailing months and your segment rather than against a headline number from a growth-stage benchmark report, since those samples skew heavily toward companies that raised venture capital.
Should annual contracts be counted in MRR or only ARR?
Both, from the same underlying data. Divide the annual contract by twelve for MRR and report the contracted annual value as ARR. They describe the same subscription at different resolutions, and they should reconcile exactly. If they do not, one of them is being computed from invoices rather than subscriptions.
Does MRR include one-time setup fees?
No. Setup, onboarding, implementation and professional services fees are excluded because they do not recur. Including them inflates the run rate and makes any month with heavy onboarding look like a growth month.
What is the difference between MRR and net new MRR?
MRR is the total run rate at a point in time. Net new MRR is the change over a period, calculated as new plus expansion minus contraction minus churn. One is a level, the other is a movement.
Is a past-due subscription still MRR?
There is no universal answer, which is the problem. Most teams exclude subscriptions once they pass the end of the dunning window, on the basis that a subscription nobody is paying for is not recurring revenue. The rule matters less than applying it consistently and knowing which rule your billing dashboard uses.
Ready to see which of the four movements moved?
A single monthly recurring revenue figure tells you the total changed. It will not tell you whether new business collapsed, whether expansion papered over churn, or which accounts were behind either.
GainSignal decomposes every MRR movement into new, expansion, contraction and churn, connects each one to the accounts that drove it, and ties the change back to what happened before it: a pricing change, a failed payment run, a release, a shift in acquisition mix. The question you answer stops being "did MRR go up" and becomes "which part moved, who moved it, and what changed first".