Net Revenue Retention Calculation for Usage-Based SaaS Businesses

Net revenue retention, as applied to usage-based SaaS, produces numbers that look precise and mean something different than the team reporting them believes. The formula itself is not in dispute: NRR equals Starting ARR plus Expansion ARR, minus Contraction ARR, minus Churned ARR, divided by Starting ARR, measured over a fixed cohort. That definition comes from the 2026 Aleph × Benchmarkit SaaS & AI Performance Benchmarks, and it is consistent across the industry. The load-bearing assumption sits in one clause: the cohort excludes any new logos acquired during the period. In a seat-based business, that rule holds cleanly, because a customer either signed a contract within the window or did not, and there is no ambiguity about which side of the line they fall on.

Usage-based revenue does not respect that line. A customer who went dormant for six months and then resumed consumption does not fit cleanly into "existing" or "new." Neither does a customer whose first month of meaningful spend follows a long stretch of low-consumption trial activity. Both cases force a judgment call that the seat-based version of the formula never had to make, and most finance teams make that call by default. The result is not noise from sloppy bookkeeping. It follows directly from how usage revenue accumulates inside a customer relationship, and that mechanism is where the rest of this problem starts.

How Usage Revenue Accumulates and Conflicts With Cohort Logic

Usage-based revenue grows continuously and non-linearly inside a single customer relationship, and that behavior is what makes the NRR cohort boundary a gradient rather than a line. Seat-based revenue moves in discrete steps: a customer's bill in month 1 and their bill in month 12 differ only because of a deliberate contract change, an upgrade, a downgrade, or a cancellation. The cohort stays stable because the underlying unit of revenue, the seat, only changes when someone signs something.

Usage-based revenue has no such anchor. A customer running inference workloads against an API can double their monthly spend in a single quarter purely because their own product shipped a feature that drove more token consumption, with no sales call, no contract amendment, and no event that would ever reach a CRM. The same pattern appears in API call volume or GPU minutes: the billing line moves because the customer's business moved, not because anyone sold them anything new. That automatic expansion is the mechanism behind a real and measurable gap in the data. The 2026 Aleph × Benchmarkit benchmarks put the median NRR for usage-based companies at 108%, above the median for seat-based companies, and the 75th percentile for usage-based models reaches 155%.

Dormancy sits on the other side of the same mechanism. A customer who consumed heavily, went quiet for several months, and then resumed usage has not re-signed anything. Naive cohort logic, built for a world where silence means churn, will often tag that customer as a new logo on reactivation, which erases the fact that the relationship, and the revenue history attached to it, never actually ended.

Drawing the cohort boundary correctly

The most consequential decision in a usage-based NRR calculation is the moment a customer is deemed to have entered the cohort, and most teams let that decision happen implicitly, by defaulting to whatever date their billing system already stamps on the account. Using the contract signature date or the first invoice date as that entry point works fine for seat-based deals, where the first bill already reflects the committed revenue. It fails for usage-based products, where the first few months are often close to zero while the customer tests the product, migrates workloads, or onboards slowly.

Consider a cohort of customers who signed in January, measured against their revenue in December of the following year. Three of those customers had near-zero consumption in January and ramped sharply in the second quarter, each going from a few hundred dollars a month to several thousand. If the cohort window is measured from the January signature date, that ramp reads as massive expansion, because the denominator, Starting ARR, is anchored to a month when the customers were using the product only barely. The NRR for that cohort will look exceptional, and it will have nothing to do with upsell behavior. It will reflect customers finding their footing.

There is a second, sharper version of the same error. If a customer who signed in month 3 of a measurement window is allowed to contribute revenue to "expansion" by month 12, the formula is inflated by construction, because that customer's revenue has no business being in the cohort's numerator or denominator. Correcting both errors requires the same discipline: define cohort entry as the first month a customer crosses a minimum meaningful usage threshold, not the date on the contract. The threshold itself, whether it is the first month revenue exceeds the cost of one real workload or the first billing period after a trial ends, matters less than applying it the same way every time.

Handling dormant customers and reactivation revenue without distorting the metric

Reactivation revenue belongs inside the NRR calculation only if the formula is built to recognize it as reactivation. Most standard implementations do one of two things with a dormant customer: they ignore the dormancy period entirely, or they classify the customer's return as a new logo. Both choices produce the wrong number, just in different directions.

A dormant customer in a usage-based business is a customer producing zero revenue in a given month because they are not consuming anything, which many billing and analytics systems cannot distinguish from a churn event once the silence stretches past a few billing cycles. If that customer later reactivates and the system tags them as new, their returning revenue inflates the company's new-ARR figures while simultaneously deflating NRR for the cohort they actually belong to. The business ends up looking worse at retention and better at acquisition than it actually is, which is a distortion in both directions at once.

One practitioner method for handling this is the "double-back" approach: calculate NRR using standard cohort methodology, but extend the comparison window back two years, measuring months 13 through 24 of revenue against months 1 through 12 from the same starting cohort. Because the window spans two full years, dormancy periods that occur inside it get absorbed into the cohort's own history. A complementary fix is to track reactivation MRR as its own labeled category sitting alongside standard expansion, so a team can see what portion of its reported expansion is genuinely new consumption growth and what portion is a returning customer picking back up where they left off. The underlying decision is a business judgment, not a technical one: whether a customer sitting at zero usage for an extended stretch still counts as "dormant" (retained, at zero) or has actually "churned" (removed from the cohort) should follow from whether that customer still holds an active account and identity in the product, not from the fact that billing has gone quiet.

Credit-based and hybrid pricing models and the additional NRR wrinkles they introduce

Pricing delivered through prepaid credit wallets or a subscription-plus-overage structure adds a layer of complexity on top of the cohort and reactivation issues already in play, because it introduces two economically distinct revenue signals that a single NRR number will otherwise blur together. In a pure usage model, revenue in any period equals consumption in that period, a relationship that is simple to attribute even when it is volatile to forecast. Credit and hybrid structures break that equivalence. A customer pays a committed amount upfront, either a subscription fee or a bulk credit purchase, and may draw it down slowly, quickly, or not at all, with any overage arriving as a separate, later charge.

That separation matters because the two signals point in different directions. A customer who renews their credit package at the same dollar amount but consumes less of it looks, on paper, like flat NRR, but it may be an early signal of coming contraction. A customer who buys a larger credit package while their actual consumption rate stays flat looks like expansion, but may simply be pre-purchasing in a way that will not repeat next renewal. The accurate approach is to track credit purchases and actual consumption as two separate series: NRR calculated from credit purchases alone can run ahead of real demand, while NRR calculated from consumption alone sits closer to economic reality but lags behind, since it only reflects revenue as credits are actually drawn down.

The committed-plus-overage structure, now described as the prevailing default among enterprise buyers of AI-enabled SaaS, carries its own version of this problem. The overage component in that structure is pure usage-based revenue and needs to be tracked and labeled separately from the subscription or tier component, so a team can tell whether its expansion is coming from seat or tier upgrades sold by a rep, or from organic consumption growth that no one at the company actively drove. Making that distinction computable requires metering infrastructure built to track committed purchases and consumption events as genuinely separate streams, not infrastructure that was designed to post a single subscription charge and treats everything else as an exception.

How the measurement window length changes what NRR is reporting

The length of the measurement window determines what story NRR is actually telling, and the conventional 12-month window, built for annual seat-based contracts, tends to understate the real retention picture for usage-based businesses whose revenue ramps slowly. In a seat-based model, a 12-month window captures one complete contract cycle: the customer renewed, downgraded, or churned, and the resulting number is stable because the underlying unit of revenue does not drift on its own.

In a usage-based model, a 12-month window measured from the moment a customer enters the cohort frequently captures the ramp period itself, the stretch of months where consumption is climbing from a low starting base. That ramp inflates the numerator through what looks like expansion while simultaneously shrinking the denominator, since Starting ARR is anchored to a period when the customer had barely begun using the product. The double-back method addresses this directly: comparing months 13 through 24 against months 1 through 12 shifts the comparison to a period when usage has already stabilized, so the denominator reflects a matured consumption level.

A 12-month NRR and a 24-month double-back NRR calculated from the same cohort will produce different numbers and tell different stories. A team that reports only the 12-month figure to investors may be showing a number that will mechanically flatten as the cohort matures, because the early-ramp effect fades out of the calculation as retention stays the same. Knowing which window underlies any reported NRR figure is a precondition for comparing it to an external benchmark. The practical guidance follows from that: run both windows in parallel for at least the first two years of a usage-based product's life, and state which window is behind any number shared externally.

What a Correctly Adjusted NRR Reveals

A usage-based NRR calculated with the right cohort boundaries, the right reactivation treatment, and the right measurement window shows the real size of a company's expansion engine, and that engine is structurally larger than anything a seat-based peer can produce. That structural difference means the benchmark a team compares itself against has to be matched to its pricing model. Measuring a usage-based business against a blended SaaS median, one that mixes seat-based and usage-based cohorts together, will flatter the business relative to its true peer-adjusted standing, since the usage-based segment already pulls that blended median upward on its own.

NRR cannot be read in isolation from gross revenue retention. The 2025 median GRR is in the mid-eighties, and the gap between NRR and GRR is a direct measure of how large the expansion engine actually is. A team whose adjusted NRR looks strong while its GRR is eroding is running a model where a small number of large, expanding accounts are masking a retention problem spreading through the rest of the base. Snowflake and Datadog, both consumption-based businesses, offer a useful reference point for what a mature expansion engine looks like at scale, but their figures describe companies operating at a size and maturity that most usage-based teams have not yet reached, so they should be read as a calibration point.

AI-native products priced low face a particular version of this risk. If a low-switching-cost AI tool is losing a high share of its logos even while its surviving accounts expand, a correctly calculated NRR, which measures how revenue from existing customers changes over time, can still look acceptable while GRR shows the underlying erosion. The adjusted NRR tells a team how well it expands the customers it keeps. GRR tells it how many customers it is keeping in the first place, and neither figure substitutes for the other.

The billing infrastructure beneath the calculation determines whether any of this is computable

Every adjustment described above, the cohort boundary fix, the reactivation treatment, the credit-versus-consumption split, the double-back window, depends on data that most billing systems built for subscription contracts were never designed to produce. Granular, event-level usage data, timestamped and attributed to a specific customer, queryable across any arbitrary time window, is the precondition for computing any of it. A system that only knows how to generate a monthly invoice cannot answer the question a corrected NRR calculation actually asks.

The cohort boundary fix requires knowing the exact date and volume of a customer's first meaningful usage event, which is event-level data, not the invoice-level summary most billing platforms store. The reactivation treatment requires a system that can hold a continuous customer identity record even through months of zero consumption, distinguishing that silence from an actual churn event. This means tracking consumption events separately from billing events. The double-back method requires pulling two full years of per-customer consumption data and aggregating it on demand, a query-time operation that a standard subscription billing report was never built to generate. Credit wallet and hybrid pricing structures require tracking committed purchases and actual drawdown as two distinct revenue streams per customer, so NRR can be computed against either series or both.

Teams running separate billing codepaths, one for subscriptions, one for usage, one for credits, run into a further problem: a consistent NRR figure becomes impossible to produce because cohort definitions and revenue attribution differ across each system, forcing reconciliation that is manual, slow, and prone to error. Building that infrastructure from scratch means building the metering pipeline, the underlying data model, the cohort query layer, and the reconciliation logic across all of it, a substantial engineering investment that has to exist before a finance team can run even one correctly adjusted NRR query. What the calculation actually requires, underneath the formula, is a metering and billing layer that ingests usage events in real time, maintains customer identity continuously through dormancy, and supports prepaid credit wallets and postpaid invoicing on the same underlying engine. That infrastructure is the condition that makes the formula computable at all, not a refinement to add once the formula is fixed.