What counts as recurring revenue?

Under this standard only `recurring_subscription`: a committed, repeating charge for continued access that persists until someone acts to end it. Usage, services, one-time fees, transactional charges and credits are real revenue and belong in every total, but they do not carry the promise that ARR asserts.

Are implementation, setup or onboarding fees recurring?

No. They are `services` or `one_time` and never enter MRR or ARR, however large they are or however often the company sells them. Repetition across customers is not commitment from a customer.

Is usage or consumption revenue recurring? Can it be in ARR?

It is typed `usage`, not subscription, because a customer can reduce it to zero without cancelling anything, so it is excluded from MRR and run-rate ARR. It can be included in retention: NRR is usage-inclusive by default, and that switch is disclosed. An "ARR" that annualizes usage is legitimate only when it is labelled as such.

Are committed minimums and overages recurring?

A contractually committed minimum behaves like a subscription and is typed that way; consumption above the minimum is `usage`. The split is made once, at classification, rather than argued inside every retention figure.

Do discounts and credits reduce MRR?

Discounts reduce the recurring charge, so MRR is the discounted rate, never list price. Credits and refunds are their own type, `credit_refund`, kept out of MRR movements and shown in the tie-out, because netting them silently hides the reversal rate.

What if the file has no revenue-type column?

The standard does not assume. A genuinely single-type file gets one fallback, recorded as an assumption. A file with evidence of mixed revenue stops the computation until a person classifies it, by product if necessary. A guess here produces an ARR that is simply total revenue times twelve.

Is month-to-month revenue recurring?

Yes, if it is a subscription that persists until cancelled. Recurring describes the commitment mechanism, not the term length. Durability — thirty days' notice versus three years remaining — lives in contract terms and in committed ARR, not in the type.

SoF Standard Definitions v1.0

Revenue types

Only committed subscription revenue is recurring. Usage, services and one-time fees are real revenue, but never MRR.

Also Revenue classification · Recurring vs non-recurring revenue

Rohit Agarwal Reviewed Sep 2026

The standard

Every revenue line carries exactly one type from a closed seven-value enumeration. Only recurring_subscription contributes to MRR. A line whose type cannot be determined is not guessed — the computation stops, or the type is resolved by a person and the resolution is logged.

At a glance

Formula: MRR = Σ lines typed recurring_subscription; every other type stays out
Unit: classification (7 types)
Bounded: closed enumeration
Defaults: 7 locked types · a file with no type column stops and asks
Biggest lever: Typing usage or services as recurring — the worked example's ARR moves from 72,000 to 120,000
Read with: MRR · ARR · NRR
Appears in: ARR build · Revenue schedule · Tie-out

What it measures

This is the most consequential classification in the entire standard, and the one most often performed implicitly. “What is your ARR?” is really the question “what portion of your revenue do you believe will still be there next year without another sale?” — and every dispute about that question is a dispute about revenue type.

The enumeration is closed on purpose. An open taxonomy invites a category like “other recurring,” which is where contested revenue goes to avoid scrutiny.

How it is computed

Each type has a specific meaning:

recurring_subscription — a committed, repeating charge for continued access. The subscription persists until someone acts to end it. This is the only type that becomes MRR.
usage — consumption-based charges that vary with volume. Real, often sticky, frequently the fastest-growing line — but not committed. A customer can reduce usage to zero without cancelling anything.
services — implementation, configuration, training. Typically non-repeating for a given customer and frequently sold at or below cost.
one_time — setup fees, hardware, licence purchases.
transactional — per-event charges that are neither subscription nor metered consumption of the core product.
credit_refund — negative amounts issued against prior billings. Kept as its own type rather than netted silently, because why revenue reversed is diagnostic.
other_nonrecurring — the explicit residual. Naming it “other” and marking it non-recurring is a deliberate act: revenue with no better home does not get the benefit of the doubt.

When a source file provides no revenue-type column, the standard does not assume. If the file is genuinely single-type, one fallback is applied to every row and recorded once as an assumption. If the file shows evidence of hybrid revenue — several products, mixed magnitudes, per-product rules — the computation stops and asks. A question is cheaper than a wrong ARR.

Where a product column exists but a type column does not, the type may be assigned per product (“Email → recurring_subscription, SMS → usage”). The rule applies only to rows with no explicit type of their own, and is recorded as a confirmed assumption naming each product rule.

Worked example

A customer bills 10,000 in a month:

Line	Amount	Type
Platform subscription	6,000	`recurring_subscription`
API overage	2,500	`usage`
Onboarding (one-off)	1,000	`services`
Service credit	(500)	`credit_refund`

MRR for the month is 6,000, not 10,000. Annualized run-rate ARR is 72,000. The other 4,000 is real revenue and belongs in every revenue total — it simply does not carry the promise that ARR asserts.

Read carelessly, this customer has “120,000 of ARR.” The gap between 72,000 and 120,000 is not a rounding difference; it is the entire question.

The choices that change the number

Usage as recurring. The single largest lever in the standard. Usage that is contractually committed with a minimum resembles subscription; pure pay-as-you-go does not. This standard keeps them in separate types and lets retention decide whether to include usage in its basis — a choice made once, visibly, rather than smuggled into the classification.
Multi-year services amortization. Long implementation programmes can look repeating. They remain services; repetition is not commitment.
Credits netted vs typed. Netting credits into subscription revenue hides the reversal rate.

How it is misread

The characteristic failure is aspirational classification: revenue that management expects to repeat is typed as recurring before it has repeated. This is rarely dishonest. It is usually a genuine belief, arrived at without the discipline of asking what would happen if the customer simply stopped buying.

A second failure is silent single-typing — a file with no type column read as 100% recurring because that was the default. This produces an ARR that is simply total revenue × 12, a number that will not survive its first serious question.

What it cannot tell you

Classification cannot tell you whether recurring revenue is durable. A subscription cancellable at thirty days’ notice and one with three years remaining are both recurring_subscription. Durability lives in contract terms — see committed vs run-rate ARR — not in the type.

How to state it

A disclosure that travels with the number. Replace the braces; keep the parenthesis.

Recurring revenue {x} (SoF Standard v1.0: recurring_subscription only · usage included in retention, excluded from MRR · credits typed, not netted)

Before you quote it

Every line carries exactly one type?
Services and one-time fees excluded from MRR?
Usage typed separately, with its retention treatment stated?
Credits and refunds typed, not netted into subscription?

What it measures#

How it is computed#

Worked example#

The choices that change the number#

How it is misread#

What it cannot tell you#