ARR vs Revenue: What Counts as Annual Recurring Revenue

Every guide to this term gives you the same two sentences. ARR is the annualised value of your recurring contracts. Revenue is what you recognise in a period. Exclude one-time fees and professional services.

That is correct, and it will not settle a single argument you are actually having.

The arguments are about the cases the definition does not cover. A customer on a rolling monthly contract who can leave in thirty days. A three-year deal with a price step in year two. A contract signed in March that goes live in June. We read the pages ranking for this term and checked them against seven of these cases. The best-sourced one, at roughly 2,700 words from a payments company with more authority on this subject than anyone, resolves none of them.

So this page covers the part that is missing.

What is ARR in SaaS?

Annual recurring revenue is the annualised value of the recurring contracts you hold right now. Not what you billed last year, not what you hope to sign. What the current contract base is worth over the next twelve months if no customer joins, leaves or changes.

Three properties follow from that, and each one causes a predictable misunderstanding.

It is a snapshot, not a period. ARR has a date attached, the way a bank balance does. Asking what your ARR was last year is like asking what your balance was last year. You have to say when.

It is contracted, not collected. A customer who has signed and not yet paid is in ARR. A customer who paid a large one-off implementation fee contributes none of it. This is the single most common source of the gap between what finance reports and what the go-to-market team believes.

It is a projection, not a record. It assumes continuation. That assumption is exactly what retention metrics exist to test. ARR on its own is a weak number. ARR read next to net revenue retention is a strong one.

For SaaS specifically, ARR became the headline metric because subscription businesses are valued on the durability of the base rather than last year's receipts. It is also why the edge cases below matter more in SaaS than they would elsewhere. When a number drives a valuation, its definition stops being a detail.

ARR vs revenue: the difference in one line

Revenue is backward-looking and governed. ARR is forward-looking and conventional.

Revenue is what you earned in a period, recognised under accounting rules you do not get to choose. It includes everything: subscriptions, services, one-off fees, overages.

ARR is a snapshot of what the recurring part of your contract base is worth over the next twelve months if nothing changes. It is a projection dressed as a number.

The gap between the two is usually services and one-off work. A company with three million in revenue, of which eight hundred thousand is implementation and professional services, has an ARR of 2.2 million. Those are two true numbers describing the same business, and anyone who conflates them will misread it.

Why nobody agrees on the edge cases

This is the part that explains everything else, and the guides skip it.

ARR is not an accounting standard. Revenue recognition is governed. There are rules, they are published, and an auditor can tell you that you applied them wrongly. ARR has none of that. It is an operating metric, reported outside the financial statements.

A voluntary standards body does publish a definition, and it is a good one. It is also voluntary, which is the whole problem. Nobody is required to adopt it, no auditor checks it, and most companies have never read it. So the definition exists and the enforcement does not.

That is not a scandal. ARR is useful precisely because it looks forward in a way recognised revenue cannot. But it means that when your finance lead and your CS lead disagree about whether a rolling monthly customer counts, there is no binding answer. There is only a decision, and whether you wrote it down.

Which is why the useful output of this page is not a definition. It is seven decisions.

The seven cases that decide whether your ARR is right

Each has a defensible answer either way. What is not defensible is answering them differently in different quarters, or leaving them to whoever builds the report.

1. Rolling monthly contracts that can cancel in thirty days

The common treatment: count them, annualised.

The cost of that: your ARR now contains revenue that can leave before the next board meeting, sitting next to annual contracts that cannot. Two companies with identical ARR can have completely different durability.

What to do: count it, and report committed ARR separately from annualised monthly. One number, two components. The split takes a column and prevents the argument permanently.

2. Multi-year contracts with a price step

A three-year deal at 100k, 110k, 121k. Which number is the ARR?

The defensible answer: the current contracted annual value. This year it is 100k. Worth saying plainly that this one is reasoning rather than settled convention. The published guidance in this category does not address price steps at all, so the argument for it is consistency with how the rest of ARR works, not an authority you can cite.

The tempting answer: the average, or the final year, because it is larger.

The cost of the tempting answer: you book growth before you have earned it, and when year two arrives your expansion number is flat because you already counted it. Retention metrics built on that ARR will read as a slowdown that never happened.

3. Contracts signed but not yet live

Signed in March, goes live in June.

The defensible answer: exclude it from ARR until service starts. The standard bucket for it has its own name, contracted ARR, usually written CARR, which is ARR plus the annualised value of signed contracts not yet live, minus churn the customer has already told you about. Report both and the ambiguity disappears.

The cost of counting it early: ARR moves on signature, which breaks the link between ARR and the customer base you actually serve. It also means a deal that signs and never implements shows as churn later, which is misleading about the thing that failed.

4. A discounted first year

Fifty per cent off year one, full price after.

The defensible answer: count the discounted value. The ARR is what they are contracted to pay now.

The cost of counting list price: next year your net revenue retention shows expansion that is nothing but a discount expiring. If you report NRR to a board or an investor, that is a number you will have to walk back.

5. Usage overages that recur every month

They are recurring in practice. They are not contracted.

The defensible answer: exclude from ARR unless committed. Report consumption revenue separately.

Why the exclusion is uncomfortable: for usage-based products it can exclude most of what the customer actually pays, and the resulting ARR understates the business badly. The fix is not to fold it in. It is to report committed ARR and consumption revenue as two numbers and stop pretending one metric describes both models.

6. A customer who cancels and re-signs in the same period

Treating it as continuous: your churn looks better and your retention is smoother.

Treating it as churn plus new business: your churn is honest and your acquisition number is inflated.

The defensible answer: continuous if the gap is short and the service never stopped, churn if the relationship genuinely ended and was rebuilt. Write the threshold down in days before you need it, because deciding it with a specific account in front of you is how the number gets bent.

7. Free converting to paid

The defensible answer: new ARR, not expansion.

The cost of calling it expansion: your net revenue retention inflates with every free user who converts, and NRR is supposed to measure what happened to existing paying customers. A product-led company that counts conversions as expansion will report an NRR that cannot be compared with anyone else's.

The ARR metric vs MRR, run rate and bookings

Four numbers that get used interchangeably and are not interchangeable.

ARR and MRR are the same metric at different resolutions. MRR is the monthly version, ARR the annualised one. Use MRR if most of your base bills monthly and changes often, ARR if most of it is on annual contracts. Running both and reconciling them monthly catches errors that neither shows alone.

Annualised run rate is the trap. It takes all revenue from one period and multiplies it out, which means it includes services, one-off fees and anything else that happened to land in that window. A quarter with a large implementation project produces a run rate that looks like growth and is not. Run rate and ARR are often quoted as if they were the same figure. They are not, and the difference is usually the services line.

Bookings is the total contracted value of what you signed, including multi-year commitments and one-time fees. A three-year deal worth 300,000 is 300,000 of bookings and roughly 100,000 of ARR. Reporting bookings growth next to ARR growth without saying which is which is how a flat year gets presented as a strong one.

The formula, and where it breaks

It is fine when every customer is on the same monthly plan at the same price. It breaks in three specific places, all of them common:

Annual prepay. A customer who pays 120k once a year does not appear in a monthly number unless you divide it back out first. Do that wrong and ARR swings depending on which month you measure.

Mid-month changes. An upgrade on the fifteenth gives you a partial month of MRR, and multiplying that by twelve gives you a number that describes neither the old contract nor the new one.

Mixed billing cycles. Monthly, annual, and multi-year customers in the same base cannot be reconciled by one multiplication.

The more reliable method is the longer one: take each customer's current contracted recurring amount, normalise it to an annual figure, and sum them. It is slower, it is harder to automate badly, and it does not move when you change the measurement date.

Is your ARR defined the same way every period?

What a live ARR definition should include

If you take one thing from this page, make it this. Write down a short definition memo and put it where the report is built.

It needs six lines. What counts as recurring. How rolling monthly contracts are treated. Which year of a multi-year contract is used. When a signed contract enters the number. How overages are treated. What counts as churn versus a pause.

Six lines, and the question stops being re-litigated every quarter. Without it, your ARR is whatever the last person to touch the spreadsheet believed, which is the real reason two reports of the same business disagree.

Where ARR goes next

ARR is an input, not an output. The metrics built on top of it inherit every decision above.

Net revenue retention and gross revenue retention are both ARR comparisons across a period, which means an inconsistent ARR definition produces a retention number that is wrong in a way nobody can see. Our net revenue retention calculator and gross revenue retention calculator run those formulas, and our guide to calculating net revenue retention sets out the rules for the period comparison itself.

If the ARR going in is defined differently in each period, nothing downstream can be trusted. That is the whole argument for spending an afternoon on the six lines.

The bottom line

ARR is not revenue, and the difference is not only timing. Revenue is governed by rules you must follow. ARR is governed by a convention you have to choose and then hold.

If you want the audited version of the forward-looking question, it exists and it is not ARR. Remaining performance obligations, reported under the revenue recognition standard, is the figure for contracted revenue not yet delivered, and it is checked. It answers a narrower question than ARR and it is the number to reach for when the conversation needs to be defensible rather than directional.

The definition is the easy part and every guide gives it to you. The seven decisions above are the hard part and almost nobody publishes them. Make them once, write them down, and your ARR becomes a number two people can argue about productively instead of a number they argue about the meaning of.