ARR vs MRR: What They Are, How to Calculate Them, and How to Track Them Cleanly

ARR and MRR are the two headline numbers every recurring-revenue business reports on. The maths behind them is simple. The hard part, as most finance and RevOps teams discover, is trusting the figure once your revenue is spread across a CRM, a billing platform and a few spreadsheets. This piece defines both metrics, shows the calculations with the standard adjustments, then looks at why the number so often drifts and how to fix the underlying data problem.

What are ARR and MRR?

MRR (Monthly Recurring Revenue) is the predictable, recurring revenue your active subscriptions generate in a single month. It only counts recurring contracted revenue. One-off setup fees, professional services and usage spikes do not belong in it.

ARR (Annual Recurring Revenue) is the same idea over a year: the recurring revenue you can expect across twelve months from your current subscription base. ARR is the metric investors and boards tend to anchor on. MRR is the one operators watch month to month.

The two are versions of the same number at different time scales, which is why getting MRR right is the foundation for everything else.

How to calculate MRR and ARR

The base calculation is straightforward.

MRR = the sum of all monthly recurring subscription amounts from active customers.

ARR = MRR × 12.

A worked example. Say you have 100 customers, each paying £500 per month.

• MRR = 100 × £500 = £50,000
• ARR = £50,000 × 12 = £600,000

If some customers pay annually up front, normalise them first. A £6,000 annual contract is £500 of MRR (£6,000 ÷ 12), not a £6,000 spike in the month it was billed. Mixing billing frequency without normalising is one of the most common reasons reported MRR jumps around for no real reason.

The adjustments that actually matter

A static snapshot is rarely the useful number. Recurring revenue moves every month, and a credible MRR figure accounts for those movements. The standard build-up looks like this:

• New MRR: recurring revenue added by customers who signed this month.
• Expansion MRR: extra recurring revenue from existing customers who upgraded, added seats or moved to a higher tier.
• Contraction MRR: revenue lost when existing customers downgrade or drop seats but stay on.
• Churned MRR: revenue lost from customers who cancelled entirely.

From those you get the figure that tells you whether the base is actually growing:

Net New MRR = New MRR + Expansion MRR − Contraction MRR − Churned MRR.

Worked through: start the month at £50,000 MRR. Add £4,000 of new MRR and £1,500 of expansion. Subtract £800 of contraction and £2,000 of churn. Net New MRR is £2,700, taking you to £52,700. Annualise and your ARR is £632,400.

Two related ratios fall straight out of the same components. Gross revenue churn measures the revenue you lost (contraction plus churn) as a percentage of the MRR you started with. Net revenue retention measures where existing customers ended up after expansion, contraction and churn, with no new logos counted. If expansion outweighs losses, net retention runs above 100%, which is the signal most boards care about.

Why the formula is easy but the number is hard to trust

None of the maths above is difficult. The difficulty is that the inputs almost never live in one place. New deals close in the CRM. Upgrades and downgrades get processed in the billing tool. Annual prepayments sit in finance. Edge cases such as discounts, mid-month changes, paused accounts and trials get patched in a spreadsheet that one person maintains.

So the same company often has three different ARR numbers depending on who you ask, and each is defensible on its own terms. The usual culprits are familiar:

• A deal marked "closed won" in the CRM with a contract value that never matches what billing actually invoices.
• Upgrades and downgrades recorded in billing but never written back to the CRM, so pipeline reporting and revenue reporting disagree.
• Annual and monthly contracts thrown into the same total without normalising, so MRR looks volatile.
• Churn that is dated inconsistently, so the month a customer left is ambiguous and retention drifts.
• One-off fees and recurring fees blended in the same field, inflating "recurring" revenue.

The result is predictable. Forecasts get questioned in board meetings. Finance and RevOps reconcile by hand every month. Nobody fully trusts the dashboard, so decisions slow down. The problem is not the formula. It is the data architecture underneath it.

Accurate ARR and MRR is a data problem, not a spreadsheet problem

Reliable recurring-revenue reporting comes from fixing the plumbing, not from a smarter spreadsheet. In practice that means a few specific things.

One agreed definition. Decide exactly what counts as recurring revenue, how annual contracts normalise to MRR, and how upgrades, downgrades and churn are dated. Write it down once so every team calculates the same way.

One source of truth. Pick the system that owns the canonical recurring revenue figure, usually the CRM or billing platform, and make the others defer to it rather than competing with it. Getting CRM data structured and consistent is the foundation; this is where a well-run CRM implementation earns its keep.

Clean integrations between systems. CRM, billing and finance need to share the same contract values automatically, so an upgrade in billing updates the CRM and a closed deal flows into revenue reporting without rekeying. Reliable two-way integrations and a sound data-engineering layer are what turn three disagreeing numbers into one. Where the underlying records are already inconsistent, a structured data migration is usually the cleanest way to reset the foundation.

Reporting on trusted data. Once the inputs are clean and connected, MRR build-up, churn and net retention can be calculated automatically and the same way every month. That is when the dashboard becomes something people actually act on.

This is the operational side of recurring revenue, and it is exactly the kind of work a managed RevOps function exists to own: keeping the CRM, the data and the integrations in a state where the numbers can be trusted without a monthly reconciliation exercise.

Get to a number you can defend

The ARR and MRR formulas will not change. What changes is whether you can stand behind the figure in front of your board. If your recurring revenue is scattered across systems and reconciled by hand, the fix is structural, not another spreadsheet. SpotDev's managed RevOps service connects your CRM, billing and data so ARR and MRR come out clean, consistent and ready to act on.

Explore Managed RevOps