Monthly recurring revenue
MRR is what a customer's subscription pays per month, taken at month end, if nothing changes.
Also Recurring run rate
MRR is the month-end recurring run rate of a resolved customer: subscription revenue normalized to a monthly rate, held through qualifying pauses, stated in base currency. It is a state, not a flow — and it is deliberately not the same number as recognized revenue.
- Formula
MRR = the month-end recurring rate, normalized to monthly, held through qualifying pauses- Unit
- currency per month
- Bounded
- ≥ 0
- Defaults
- 3-month reactivation window · comped excluded (locked) · monthly-average FX
- Biggest lever
- Reading an ARR-basis export as monthly — overstates MRR twelvefold
- Read with
- ARR · Revenue types · Revenue tie-out
- Appears in
- MRR build · Board deck · MRR bridge
- Switches
- 2 · 1 locked — see the choices
What it measures
MRR answers: if nothing changes, what does this customer pay us next month? That question is about a state at a point in time, which is why MRR is not simply “revenue divided by months.” Every downstream measure — movements, the bridge, retention, cohorts, concentration — is built on this state series, so an error here propagates everywhere.
The standard carries three parallel views of recurring revenue per customer-month, because a single number cannot answer every legitimate question:
| View | What it holds | What it answers |
|---|---|---|
mrr | Month-end run rate; pauses held | What will recur? |
recurring_recognized | Rev-rec view: prepaid spread over term, prorated months as billed, nothing during unpaid pauses | What ties to the P&L? |
recurring_billed | Raw billed amounts at their billed period, lump sums intact | What did we invoice? |
Confusing these three is the most common source of “your ARR doesn’t tie” in diligence. They are all correct; they answer different questions, and the gaps between them are themselves informative — see tie-out.
How it is computed
- Filter to type. Only
recurring_subscriptionlines contribute. Usage, services, one-time, transactional and credits are carried on the customer-month row as separate measures and excluded from MRR. - Normalize the period grain. A row covering a quarter or a year is recognized evenly across the months it covers. Grain is declared by a person when the file is described, never inferred silently from row spacing.
- Normalize the amount basis. A file exporting annualized run-rate (“ARR by customer”) carries figures twelve times the monthly rate. Declaring the basis converts it. Reading an ARR export as monthly revenue overstates MRR by 12× — the single most destructive input error in this domain, and the reason the basis is an explicit, confirmed declaration.
- Spread prepaid lump sums across the contract term where a contract is known, rather than spiking one month.
- Follow contracted ramps. Where a contract specifies a ramp schedule, the run rate follows the contracted step, and the step-up is recognized as expansion.
- Take the month-end state for mid-month changes. A customer who upgrades on the 15th is billed a prorated amount but ends the month at the new rate. MRR takes the month-end rate; the prorated billing shows in the recognized and billed views. Proration is flagged so the difference is traceable.
- Hold through qualifying pauses. A billing gap no longer than the reactivation window, followed by resumption, holds MRR at the pre-gap level rather than dropping to zero and back. See pause vs churn.
- Convert to base currency at the month’s flow rate. See FX.
Worked example
A customer on an annual contract of 24,000, billed once in January, upgrading to 30,000 annualized effective 15 April:
| Month | recurring_billed | recurring_recognized | mrr |
|---|---|---|---|
| Jan | 24,000 | 2,000 | 2,000 |
| Feb | 0 | 2,000 | 2,000 |
| Mar | 0 | 2,000 | 2,000 |
| Apr | 3,000 | 2,250 | 2,500 |
| May | 0 | 2,500 | 2,500 |
April is the instructive row. Billed shows the upgrade invoice; recognized shows half a month at each rate; MRR shows the month-end run rate of 2,500 — the number that answers “what recurs next month.” Reading the billed column as MRR would show a customer whose revenue collapsed 87% in February.
The choices that change the number
- Declared grain and basis. Not really choices — they are facts about the file — but they must be declared, and a wrong declaration is catastrophic rather than merely imprecise.
reactivation_window_months(default 3). Governs whether a gap holds MRR or drops it. Shortening the window converts pauses into churn-and-win-back pairs, which lowers retention and raises both gross churn and new business.exclude_comped(LOCKEDtrue). Comped customers carry no MRR toward totals.- Contract-informed spreading. Without contracts, a lump sum can only be recognized where billed; with them, it spreads. This changes the recognized view, never the run-rate view.
How it is misread
The dominant error is treating MRR as a flow — dividing a period’s total revenue by the number of months. That silently includes services and one-time revenue, and it averages away exactly the month-end state the metric exists to capture.
The second is the 12× error described above: an ARR-basis export read as monthly. It is easy to spot once suspected (the ARR figure will be implausibly large relative to reported revenue) and nearly invisible until then, which is why tie-out is never optional.
What it cannot tell you
MRR is a run rate, not a promise. It says what recurs if nothing changes; it says nothing about whether the customer has thirty days’ notice or three years remaining. For that, see committed ARR. It also says nothing about collection — MRR counts billed-and-recognized revenue, not cash received.
How to state it
A disclosure that travels with the number. Replace the braces; keep the parenthesis.
MRR {x} (SoF Standard v1.0: month-end run rate · subscription only · 3-month pause window) Before you quote it
- Amount basis and period grain declared, not inferred?
- Annual invoices normalized to monthly, not spiked?
- Month-end rate used for mid-month changes?
- Pauses within the window held, and logged?
Related questions
- Is MRR the same as monthly revenue?
- No. MRR is the month-end recurring run rate: the subscription revenue that recurs next month if nothing changes. Monthly revenue is a flow that includes services, one-time fees, usage and credits. Dividing a period's total revenue by its months mixes the two and averages away the month-end state MRR exists to capture.
- How do annual or multi-year contracts count in MRR?
- A contract billed annually is normalized to its monthly rate and held at that rate every month of its term: a 24,000 annual contract is 2,000 of MRR in January and in July. The lump-sum invoice shows in the billed view and the spread in the recognized view; neither is MRR.
- Why doesn't MRR match recognized revenue?
- Because they answer different questions. MRR is the month-end run rate; recognized revenue is what accounting earned in the month, including prorations, services, usage and credits. The standard carries both views on every customer-month, and the tie-out explains the gap instead of forcing one to equal the other.
- How are mid-month upgrades and proration handled?
- MRR takes the month-end state: a customer upgrading on the 15th ends the month at the new rate, and that is the MRR. The prorated invoice appears in billed and recognized revenue, and the proration is flagged so the difference is traceable.
- Does usage or a one-time fee count toward MRR?
- No. Only
recurring_subscriptionlines contribute. Usage, services, one-time and transactional revenue are carried on the same customer-month row as separate measures, so they are never lost and never mistaken for run rate. - Is a paused customer still in MRR?
- If the billing gap is no longer than the reactivation window (three months by default) and the customer resumes, MRR is held at the pre-gap level and no churn is recorded. A longer gap drops to zero, producing churn at the gap start and reactivation on return.
- How should a file that lists ARR by customer be read?
- As an annualized basis, declared explicitly and divided by twelve. Reading an ARR-basis export as monthly revenue overstates MRR twelvefold, the single most destructive input error in customer-level revenue analysis. The basis is a declared fact about the file, never inferred from row spacing.
Strategy of Finance. “Monthly recurring revenue.” SoF Standard Definitions v1.0 (2026-09-18). https://www.strategyoffinance.com/standards/monthly-recurring-revenue/