How to Calculate Monthly Recurring Revenue—and Reconcile Every Change

Monthly recurring revenue (MRR) is the normalized monthly value of active recurring subscriptions at a specific point in time. For a B2B subscription company, the useful calculation is not merely a total. It is a bridge that explains exactly how opening MRR became ending MRR.

Ending MRR
= Opening MRR
+ New Business MRR
+ Expansion MRR
+ Reactivation MRR
− Contraction MRR
− Churn MRR

That bridge answers two operating questions at once: how much recurring revenue the business currently has, and which customer events changed it during the month.

MRR is not GAAP revenue, cash collected, or the value of invoices issued. Stripe describes it as a forward-looking subscription metric and notes that invoice totals are an unsuitable shortcut because they can include one-off amounts and cash timing that do not represent recurring monthly value (Stripe Support). Use MRR to analyze the subscription run rate; use the finance team’s accounting records for recognized revenue.

Normalize each active subscription first#

For a fixed-price subscription, convert the recurring charge to one monthly amount:

Subscription MRR = recurring contract amount ÷ months in the service period
Company MRR = sum of subscription MRR for all active customers

A $1,200 annual subscription therefore contributes $100 of MRR while it is active. A $300 quarterly subscription also contributes $100. A $100 monthly subscription contributes $100. Stripe’s billing documentation uses this monthly-normalization approach for active and past-due subscriptions (Stripe Billing documentation).

The formula is simple; the inclusion policy is not. Before publishing MRR, decide in writing:

• which products and charge types are recurring;
• whether discounts reduce MRR and when temporary discounts begin and expire;
• whether usage-based charges, taxes, credits, refunds, and services are included;
• when a subscription becomes active and when a cancellation becomes churn;
• how foreign-currency subscriptions are converted; and
• how backdated changes and corrected billing events restate prior periods.

These choices can change the reported number. For example, Stripe excludes trials, taxes, free plans, and metered products from its MRR calculation, while allowing some discount and subscriber-status settings to be configured. ChartMogul documents its own treatment of discounts, refunds, transaction fees, and one-time line items (Stripe Billing documentation, ChartMogul MRR documentation). Neither vendor’s implementation is a universal accounting rule. The control that matters is a consistent, versioned policy applied to every period.

Classify each change by the customer’s lifecycle#

Once every subscription has a normalized balance, compare each customer’s prior MRR with the new balance. Use five value-changing categories:

ChartMogul documents these lifecycle distinctions and also records a sixth, neutral movement when a subscription changes without changing MRR (ChartMogul movement definitions). Neutral events can be useful operationally, but their signed contribution to an MRR bridge is zero.

Classify the economic transition, not the wording on an invoice. If an active account falls from $1,000 to $700 MRR, the $300 loss is contraction. If it then falls from $700 to zero, the $700 loss is churn. If that same customer later returns at $500, the increase is reactivation.

Customer identity is therefore part of the calculation. A billing migration that creates a second customer record can turn one continuing relationship into apparent churn on the old record and new business on the new one. Keep a durable business-customer ID even when subscription or billing-system IDs change.

Build a movement ledger that proves the total#

Do not calculate the bridge from five manually maintained spreadsheet totals. Create one row for every effective change, with enough detail to trace it back to the source:

For each row:

Signed delta = New MRR − Prior MRR

First reconcile every customer’s opening balance, movements, and ending balance. Then sum those customer results and reconcile the company total. This two-level check catches duplicated customers, missing events, incorrect effective dates, and migrations that a top-line comparison can conceal.

Reconcile the month#

Consider this illustrative month; the amounts are hypothetical, not company results:

Net MRR movement
= 6,000 + 4,500 + 500 − 2,000 − 3,000
= 6,000

Ending MRR
= 80,000 + 6,000
= 86,000

MRR growth rate
= Net MRR movement ÷ Opening MRR × 100
= 6,000 ÷ 80,000 × 100
= 7.5%

The growth rate is meaningful only after the bridge balances. Calculate a residual as the final control:

Reconciliation residual
= Ending MRR − Opening MRR − signed movement sum
= 86,000 − 80,000 − 6,000
= 0

A nonzero residual is not miscellaneous growth. It means the balance snapshots and movement ledger disagree. Trace the difference to timing, currency conversion, customer identity, missing events, duplicate events, or a policy change before anyone uses the bridge to judge acquisition or retention.

The finished monthly report should publish the opening balance, all five value-changing movements, ending balance, residual, and policy version together. When both customer-level and company-level residuals equal zero, the business has an MRR number it can explain—not merely one it can display.