SaaS · Metrics

MRR Calculation Patterns — A Field Guide

MRR looks like a simple sum until you meet annual plans, discounts, and mid-cycle changes. Calculating it consistently is what makes every downstream metric trustworthy.

John Kihiu12 min read

MRR — monthly recurring revenue — underpins most SaaS reporting, so an inconsistent calculation quietly corrupts everything built on it. The concept is simple: the normalised monthly value of your recurring subscriptions. The discipline is in normalising consistently and handling the edge cases the same way every time.

Normalise everything to monthly

Every plan must be converted to a monthly figure so they are comparable. An annual plan contributes its annual price divided by twelve, not its full value in the month it is billed — booking a year's payment as one month's MRR produces a spike that is a data error, not growth. Quarterly and other terms normalise the same way. Recognise the recurring monthly value, regardless of billing frequency.

Break MRR into movements

The total is less useful than how it changed. Decompose the month-over-month change into its components, because two businesses with the same MRR growth can be in completely different health:

New + Expansion − Contraction − Churn equals net new MRR. This breakdown is what tells you whether growth comes from winning new customers or growing existing ones, and whether churn is quietly eating your gains.

Handle the edge cases consistently

Decide the rules once, then never deviate

Most MRR disputes come from calculating it two different ways in two different reports. Write down exactly how you normalise terms, treat discounts, and time mid-cycle changes — and apply that definition everywhere. A consistent, slightly imperfect MRR beats a 'correct' one that is computed differently each time.

Correct MRR is every plan normalised to a monthly value, decomposed into new, expansion, contraction, and churn movements, with discounts and one-time fees handled by a fixed rule. Get the calculation consistent and every metric built on it — growth rate, NRR, forecasts — inherits that reliability instead of that error.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.