SaaS Metrics from Xero: Why MRR, ARR, and Deferred Revenue Aren't in Your Ledger

Your board asks for one number: MRR. You open Xero, and it isn't there.

What's there is revenue — invoices raised, payments received, a tidy P&L. All correct, all useless for the question being asked. Because SaaS metrics from Xero aren't a report you forgot to run. They're a layer your ledger was never built to hold. MRR, ARR, net revenue retention, churn, deferred revenue movement — none of it lives in your chart of accounts, and no amount of clicking through Xero's reporting menu will surface it.

This is the gap every subscription business hits the moment a real investor, board, or acquirer starts asking questions. Here's why it's there, and what it actually takes to close it.

Xero records billing events, not subscriptions

Xero is an accounting system. It thinks in transactions: an invoice goes out, a payment comes in, a credit note reverses something. Each one has a date, an amount, and an account code.

A subscription is a different kind of object entirely. It has a start date, a billing cadence, a contract value, a plan, an upgrade history, and — crucially — a customer who may have been with you for three years across four plan changes. None of that structure exists in the general ledger. Xero sees the January invoice and the February invoice as two unrelated events. It has no concept that they're the same customer on the same recurring plan, that one is an expansion and one is flat, or that a third customer just churned and isn't in the file at all.

So when you ask Xero for monthly recurring revenue, you're asking a transaction database to reconstruct a subscription model it never recorded. It can't. The information was lost at the point of entry.

The deferred revenue trap

The problem gets worse the moment you sell annual plans.

A customer pays $12,000 upfront for a year. In cash terms, you've got $12,000. In revenue terms, you've earned $1,000 — one month's worth. The other $11,000 is deferred revenue: a liability on your balance sheet that you recognise into the P&L month by month as you deliver the service.

Xero can hold the deferred balance — but it won't do the recognition for you. There's no native engine that reads "annual plan, billed today, recognise in twelve equal slices starting now" and posts the schedule automatically. So most finance teams run deferred revenue the manual way: a spreadsheet of every contract, a recognition schedule per customer, a monthly journal to release the right slice, and a reconciliation back to the balance sheet liability. Miss a step, or fat-finger a start date, and your revenue is wrong and your deferred balance drifts.

This is the same class of derived, rules-based work we've written about elsewhere — the kind that looks like a calculation but behaves like a logic problem, and that quietly eats senior hours every close. (Recognised revenue is also why your SaaS cash and your SaaS revenue tell completely different stories, which is its own headache — related to why Xero can't reliably tell you next month's cash.)

MRR and ARR aren't an account code

Here's the thing that trips people up: MRR isn't in the chart of accounts because it can't be. It's not an accounting figure at all.

Recognised revenue and MRR diverge constantly. A customer who signs a $12,000 annual deal on the 28th adds $1,000 to MRR immediately, but barely anything to this month's recognised revenue. A usage-based overage spikes recognised revenue without moving MRR. A discount, a mid-month upgrade, a paused account, a multi-year deal with a step-up in year two — every one of these breaks the assumption that "revenue in the P&L" equals "recurring revenue run-rate."

MRR is a normalised, forward-looking measure of contracted recurring revenue per month. ARR is just MRR × 12. To compute either correctly you need the subscription layer — plans, contract values, billing frequency, active status per customer per month — and then you have to net out one-off charges, annualise correctly, and decide how to treat usage. The ledger has none of those ingredients in a usable shape.

The metrics a SaaS board actually wants

MRR and ARR are table stakes. The questions that follow are the ones that really expose the gap, because they all require comparing the same customer to itself over time:

• Net revenue retention — what last year's customers are worth this year, after expansion, contraction, and churn. The single most-watched SaaS metric, and entirely a cohort calculation.
• Gross churn / logo churn — how much recurring revenue and how many customers you lost, which requires knowing who was active last month and isn't now.
• Expansion vs. new — how much of this month's MRR growth came from existing customers upgrading versus brand-new logos.
• MRR movement (the waterfall) — new, expansion, contraction, churn, reactivation, reconciling opening MRR to closing MRR.

Every one of these is a movement between two points in time, sliced by customer. Xero's reporting is built to summarise a period, not to track a customer's recurring revenue across periods. It's structurally the wrong shape for the question.

Why this is genuinely hard

It's tempting to assume the answer is "pull it from Stripe" or "Xero should add a button." Neither closes the gap cleanly.

The subscription truth usually lives in your billing system — Stripe, Chargebee, GoCardless, or a homegrown setup — while the financial truth lives in Xero. The two rarely agree out of the box. Stripe knows the plan and the upgrade history but not your revenue recognition policy. Xero knows the invoices and the deferred liability but not the subscription structure. Reconciling them — making MRR tie to billing, recognised revenue tie to the P&L, and deferred revenue tie to the balance sheet, all at once — is the actual work. It's a mapping and logic problem across two systems, repeated every month, and it's exactly where most SaaS finance functions end up back in a spreadsheet.

The workarounds people actually use

In practice there are three.

Build it in Excel. Export invoices and the customer list, rebuild the subscription model by hand, maintain a recognition schedule, and calculate the metrics off the side. Most early-stage teams do this. It works until the file gets too big, the person who built it leaves, or a formula silently misclassifies churn for three months before anyone notices.

Bolt on a metrics tool. ScaleXP, Maxio (formerly SaaSOptics), and similar platforms sit on top of Xero and a billing system to produce SaaS metrics and revenue recognition. They're good when your billing is clean and your model looks like the brochure. They bend less well when your contracts are non-standard, your recognition policy has judgement in it, or your board wants the metrics framed your way rather than the tool's. (We compared the broader reporting add-on landscape in the best Xero reporting add-ons.)

Keep it in the management pack. Some teams fold MRR, ARR, and retention into their monthly management accounts from Xero as bespoke KPIs — which is the right instinct, but only as good as the logic feeding them.

What good SaaS metrics from Xero look like

A SaaS reporting setup that actually holds up does a few things Xero's native reports can't:

• Reconciles three layers — billing (Stripe et al.), recognised revenue (the P&L), and deferred revenue (the balance sheet) — so the same dollar tells one consistent story.
• Computes MRR and ARR from the subscription layer, with one-off charges netted out and annualisation handled consistently.
• Tracks customers across periods, so NRR, churn, and the MRR waterfall fall out of the data instead of being rebuilt by hand.
• Runs the deferred revenue schedule automatically, recognising each contract on its own timeline and tying back to the balance sheet liability every month.
• Produces the same output every period, so the board's month-on-month comparison is real and not an artefact of someone classifying an upgrade differently in May than in April.

None of that is exotic. It's just logic that has to be encoded once and run reliably — rather than reassembled in a spreadsheet every close.

Where Cheetah fits

This is squarely the kind of derived, cross-system reporting Cheetah was built for. We build custom reporting on top of Xero — and, where it matters, your billing data — that computes MRR, ARR, retention, and the MRR waterfall, runs your deferred revenue schedule, and reconciles billing to recognised revenue to the balance sheet, the way your business actually contracts and recognises. Because it's built around your model rather than a generic SaaS template, it handles the non-standard contracts and recognition rules that off-the-shelf tools quietly can't.

If your month-end currently includes a subscription spreadsheet you don't fully trust and a board deck where MRR is keyed in by hand, it's worth a look.

Xero will tell you what you invoiced. What it recurs to, retains, and defers is a different question — and one your ledger was never going to answer on its own.