What Is MRR? Monthly Recurring Revenue Explained

MRR, or Monthly Recurring Revenue, is the total predictable revenue a subscription business can expect to collect every month from its active customer base. It only includes revenue that repeats on a fixed schedule, such as monthly and annual subscription fees converted to a monthly equivalent, and it deliberately excludes anything that does not recur, such as one-off setup charges, professional services invoices, and single purchase add-ons.

The reason MRR exists as a distinct metric, separate from plain revenue, is that subscription businesses need a number that reflects the underlying health and predictability of the business rather than the timing quirks of cash collection. A company that signs a large annual deal in January will see a spike in cash revenue that month and nothing in February through December, even though the customer is paying for value delivered every month. MRR smooths this out by dividing the annual contract value across the twelve months it covers, giving founders, investors and finance teams a consistent, comparable monthly figure.

For a Stripe-based SaaS business, MRR is derived from active subscriptions rather than from the raw payments ledger. Every subscription has a plan, a billing interval and a price. To compute MRR you look at every subscription in a non-cancelled, non-trialing state, normalise its price to a monthly figure based on its billing interval, and sum across the customer base. This is conceptually simple but operationally fiddly once you have multiple plans, currencies, discounts, proration events and multiple Stripe accounts, which is exactly the kind of work a dedicated Stripe revenue analytics tool exists to automate.

The core MRR formula is: MRR equals the sum, across all active subscriptions, of each subscription's monthly-equivalent price. Written as a simple equation for a single customer: Monthly value = billing amount divided by number of months the billing period covers. For a whole business: Total MRR = sum of (monthly value) for every active subscriber.

Applied practically, there are three common cases:

• A customer on a 49 dollars per month plan contributes exactly 49 dollars to MRR, because the billing interval already matches the monthly reporting period.
• A customer on a 588 dollars per year plan contributes 588 divided by 12, which equals 49 dollars to MRR. This is the same underlying value as the monthly plan above, just paid annually up front.
• A customer on a quarterly plan of 150 dollars contributes 150 divided by 3, which equals 50 dollars to MRR.

Once every subscription is normalised this way, you simply add them together. If you have 40 customers on the 49 dollars monthly-equivalent plan and 10 customers on a 99 dollars monthly-equivalent plan, total MRR is (40 times 49) plus (10 times 99), which equals 1,960 plus 990, giving 2,950 dollars MRR. This is the number that feeds directly into ARR, LTV, ARPU and the valuation multiple, so getting the normalisation right at this stage matters more than almost any other step in your reporting.

For a deeper walkthrough of doing this specifically against the Stripe API, including handling discounts, proration and multi-currency accounts, see how to calculate MRR in Stripe.

MRR matters because it isolates the predictable, repeatable part of your revenue from the noisy, one-off part, which makes it the single best number for judging growth trajectory, forecasting cash flow and comparing performance month to month. Total revenue can spike or dip based on invoice timing, annual renewals landing in a particular month, or a single large services contract, none of which tell you anything about whether the underlying subscriber base is healthy or shrinking.

Because MRR is normalised to a monthly cadence, it also becomes the common denominator for almost every other SaaS metric. Churn rate is usually expressed as a percentage of MRR lost each month. ARPU (average revenue per user) is MRR divided by active customers. Customer lifetime value is built from ARPU and churn, both of which trace back to MRR. Even the 5x ARR valuation heuristic that investors and acquirers commonly reference is just MRR multiplied by 12 to get ARR, then multiplied by a market multiple. Get MRR wrong and every downstream metric inherits that error.

Investors and board members also use MRR as a shorthand for momentum. A steadily rising MRR line, even a modest one, signals product-market fit and retention. A flat or declining MRR line, even alongside decent total revenue from services or one-off projects, is treated as a warning sign because it implies the recurring engine is not growing. This is why board decks and investor updates almost always lead with an MRR chart rather than a total revenue chart.

MRR and ARR describe the same recurring revenue, but on different time horizons: ARR (Annual Recurring Revenue) is simply MRR multiplied by 12. MRR is the operational metric used for week-to-week and month-to-month decision making, while ARR is the strategic metric used for annual planning, fundraising conversations and valuation.

A common mistake is treating ARR as a forecast of guaranteed future revenue rather than an annualised snapshot of current MRR. ARR assumes today's MRR persists unchanged for twelve months, which is rarely exactly true given churn, expansion and new business. It is a useful shorthand, not a contractual guarantee. When a valuation is quoted as, for example, 5x ARR, it is really 5x (current MRR times 12), calculated from whatever your MRR happens to be on the day of the snapshot. Read more on how this is applied in SaaS valuation multiples.

MRR movement is the breakdown of how your MRR changed from one period to the next, split into new MRR, expansion MRR, contraction MRR and churned MRR, so you can see not just that MRR went up or down but why. Looking only at the ending MRR figure hides important signals; two businesses can end the month at the same 50,000 dollars MRR while one is bleeding existing customers and masking it with strong new sales, and the other is retaining everyone and growing steadily.

• New MRR: revenue from brand-new customers who started a subscription during the period.
• Expansion MRR: additional revenue from existing customers who upgraded plans, added seats, or purchased add-ons.
• Contraction MRR: revenue lost from existing customers who downgraded but did not fully cancel.
• Churned MRR: revenue lost from customers who cancelled entirely.

The net movement formula is written as: Net new MRR = New MRR + Expansion MRR minus Contraction MRR minus Churned MRR. As a worked example, imagine a business starting the month at 20,000 dollars MRR. During the month it adds 3,000 dollars in new MRR, 1,200 dollars in expansion from existing accounts upgrading, but loses 500 dollars to contraction and 1,800 dollars to churn. Net new MRR = 3,000 + 1,200 minus 500 minus 1,800 = 1,900 dollars. Ending MRR = 20,000 + 1,900 = 21,900 dollars.

Tracking these four components separately is what allows you to diagnose problems early. If churned and contraction MRR are growing faster than new and expansion MRR, your net movement can still look positive for a while, but the underlying retention problem will eventually catch up with you. This is closely related to SaaS churn rate and net revenue retention, both of which are calculated from these same movement components.

Normalising annual plans means dividing the total annual contract value by 12 so it can be added to monthly plans on a like-for-like basis, and this step is the single most common source of MRR errors in Stripe-based businesses. Because Stripe records the full annual charge as a single payment on the day it happens, a naive report that simply sums "amount charged this month" will show a huge spike in the month an annual customer pays and nothing for the following eleven months, which is not MRR at all, it is cash collected.

The correct approach is to look at the subscription object, identify its billing interval (month, year, week or a custom interval count), and convert the price to a monthly-equivalent value regardless of when the actual charge lands. For a yearly subscription priced at 1,188 dollars, the monthly-equivalent contribution to MRR is 1,188 divided by 12, which is 99 dollars, applied every month the subscription remains active, not just the month payment was received.

Worked example: mixed billing intervals

Suppose a company has 25 customers on a 40 dollars per month plan, 8 customers on a 480 dollars per year plan, and 5 customers on a 120 dollars per quarter plan. The MRR calculation is:

• Monthly plan: 25 times 40 = 1,000 dollars
• Annual plan: 480 divided by 12 = 40 dollars per customer, times 8 = 320 dollars
• Quarterly plan: 120 divided by 3 = 40 dollars per customer, times 5 = 200 dollars
• Total MRR = 1,000 + 320 + 200 = 1,520 dollars

Notice that every plan in this example works out to a 40 dollars monthly-equivalent value despite having very different sticker prices and billing cadences, which is exactly the kind of distortion normalisation is designed to remove. If you skipped normalisation and instead summed raw charge amounts for the current month, you would only capture whichever customers happened to be billed that month, producing a wildly inconsistent number from one month to the next.

The most frequent MRR mistakes all stem from either mixing in revenue that is not truly recurring, or failing to normalise billing intervals correctly, and both are easy to avoid once you know what to check.

• Including one-off payments. Setup fees, professional services and single purchase items are not recurring and should be excluded, tracked separately as one-off revenue rather than folded into the MRR figure.
• Counting trialing subscriptions. A subscription still in its trial period has not converted and generates no committed revenue yet, so it should be excluded until the first successful charge occurs.
• Forgetting to normalise annual and quarterly plans. As covered above, failing to divide non-monthly billing periods by the correct number of months produces enormous, meaningless swings in the reported figure.
• Ignoring discounts and coupons. If a customer has a 20 percent lifetime discount applied in Stripe, MRR should reflect the discounted price they actually pay, not the plan's list price.
• Double counting during plan changes. When a customer upgrades mid-cycle, Stripe can generate proration invoices; naive summing of invoice amounts can double count the old and new plan value in the same period.
• Mixing currencies without conversion. A business billing in both dollars and dollars needs a consistent conversion approach, or MRR figures will silently understate or overstate true recurring revenue.
• Treating failed or past-due charges as paid. A subscription with a failed payment that has not yet been resolved should not continue to count toward MRR as if it were healthy revenue.

Because Stripe's own dashboard does not natively expose a clean, normalised MRR figure across mixed billing intervals, discounts and multiple connected accounts, most teams either build a bespoke script to reconcile these edge cases or use a dedicated analytics layer that reads directly from the Stripe API with a restricted read-only key and applies these rules automatically.

MRR is the foundation metric that feeds directly into churn rate, ARPU, customer lifetime value and the standard SaaS valuation multiple, which is why getting it right at the source matters far more than any single downstream calculation.

• Churn rate is usually expressed as churned MRR divided by starting MRR for the period, giving a percentage of recurring revenue lost. See SaaS churn rate for the full formula and worked examples.
• ARPU (average revenue per user) is total MRR divided by the number of active paying customers, giving you a per-customer benchmark for pricing and packaging decisions. See ARPU for more detail.
• Customer lifetime value (LTV) is typically calculated as ARPU divided by churn rate, which itself depends on both the ARPU derived from MRR and the churn rate derived from MRR movement. See customer lifetime value.
• Valuation is commonly estimated using a multiple of ARR, and ARR is just MRR times 12. A business at 10,000 dollars MRR has 120,000 dollars ARR, and applying a commonly cited 5x ARR multiple as a rule of thumb suggests a rough valuation of 600,000 dollars. See SaaS valuation multiples for the caveats around this heuristic.

Because so many metrics trace back to MRR, a single normalisation error, such as forgetting to divide an annual plan by 12, does not just distort MRR itself, it inflates ARPU, deflates the apparent churn rate, skews LTV and ultimately produces a misleading valuation estimate. This cascading effect is the strongest argument for calculating MRR carefully and consistently from the outset, ideally using a single source of truth rather than recalculating it manually in different spreadsheets for different purposes.

If your subscription billing runs entirely on Stripe, the most reliable way to track MRR is to read subscription and price data directly from the Stripe API using a restricted, read-only API key, rather than relying on manual spreadsheet exports or Stripe's default dashboard views. Stripe stores everything you need, including plan intervals, current subscription status, discounts and quantities, but it does not present a single normalised MRR number out of the box, particularly once you have a mix of monthly, annual and custom-interval plans.

A minimal manual approach is to export active subscriptions, tag each with its billing interval, convert to a monthly-equivalent value, and sum in a spreadsheet. This works for small subscriber counts but breaks down quickly as volume grows, plan variations multiply, or you start combining data across more than one Stripe account, for example if you run separate accounts for different products or regions.

A more scalable approach is to connect a restricted, read-only Stripe key to a dedicated analytics tool that recalculates MRR, churn, LTV, ARPU, subscriber lifetime and top customers by LTV automatically, and keeps the figure updated daily rather than requiring a manual export each time you need a number. Because the key is read-only, the tool can never move money or change your Stripe configuration, it can only read subscription and payment data to compute the metrics. Subscription Metric is built specifically for this use case, and it also separates daily subscription revenue from one-off payments, applies the 5x ARR valuation heuristic automatically, and lets you export CSV, JPG or PDF reports for investors or your own records. Multiple Stripe keys can be connected and combined, which is useful if you run more than one Stripe account.

Whichever approach you take, the underlying principle is the same as described throughout this guide: normalise every subscription to a monthly-equivalent value, exclude non-recurring revenue, exclude trials, and recalculate frequently enough that MRR movement is visible before it becomes a trend you cannot reverse. For a step-by-step technical walkthrough of the calculation itself, see how to calculate MRR in Stripe, and for a broader glossary of related terms see the SaaS metrics glossary.