How to Calculate ARR for Usage-Based Pricing

ARR was built for subscriptions with a fixed contract value, and consumption pricing breaks the assumption underneath it. There is still a defensible ARR figure for a usage-based business. Producing it means deciding which dollars are recurring, choosing an annualization window, and holding both decisions constant across periods so the number stays comparable to itself.

Can you calculate ARR when pricing is usage based?

Yes. Annualize the contracted floor, then add the portion of usage revenue that has proven it recurs.

``` Usage-Based ARR = Annualized Platform Fee + Annualized Committed Minimum + Normalized Recurring Overage ```

Take an account paying a $60,000 annual platform fee with usage billed monthly on top. Trailing twelve month usage billings total $84,000, of which $18,000 came from a one-time data migration in March. Recurring usage is $66,000, so ARR is $126,000.

A more conservative version counts only what the customer is contractually obligated to pay. If the committed usage minimum is $48,000, contracted ARR is $108,000 and the remaining $18,000 sits in a run rate line. Both numbers are defensible. Publishing one figure in a board deck and the other in a diligence file is not.

Which usage revenue belongs in ARR?

Recurring obligation belongs in ARR, and everything event-driven belongs outside it. The judgment call is the third row. A customer whose overage has run between $4,000 and $6,000 every month for a year has a run rate. A customer with one $30,000 month and eleven quiet ones has an event. Set a rule, such as overage present in at least nine of the last twelve months, and apply it to every account rather than case by case.

Which annualization window should you use?

Match the window to the shape of the account's consumption. Consumption follows the customer's own business cycle, so a retail customer peaks in Q4 and a tax software customer peaks in Q1. Annualizing either one from their peak quarter creates ARR that will visibly evaporate the following period. The trailing twelve month window absorbs that cycle at the cost of reacting slowly to genuine growth. Sales seasonality compounds the problem on the bookings side. In our data, Q2 and Q4 usually run stronger than Q1 and Q3, and the third month of a quarter runs stronger than the first two. Building a run rate from a quarter-ending month picks up both the customer's cycle and the seller's cycle in a single inflated number.

How do you handle contracts with commitments plus overage?

Count the commitment as contracted ARR and treat sustained overage as expansion in the waterfall.

A customer who commits to $100,000 and consumes $130,000 is a $100,000 contracted account producing $30,000 of expansion. When that overage persists across periods and the customer raises the commitment at renewal, the expansion converts into contracted ARR with no change to what they actually pay.

That conversion is worth tracking on its own. Sustained overage is the strongest renewal signal a usage-based business has, since the customer has already demonstrated the demand the higher commitment would formalize. Accounts consuming below their commitment are the inverse signal, and they show up as contraction at renewal rather than as churn.

How does churn appear in a usage-based model?

As declining consumption, months before any cancellation event.

Subscription churn is binary and dated. Usage churn is gradual, so a business waiting for cancellation notices sees the erosion after it has already cost a year of revenue. Measure each account against its own trailing baseline and treat a sustained decline as contraction in the net revenue retention calculation.

Support activity adds a second signal. In ORM customer data, accounts with no support cases at all are at churn risk, as are accounts with seven or more in a year. Three to five cases, usually tier 2 or tier 3, indicates an engaged customer. Pairing that with a consumption trend line identifies at-risk accounts while a renewal conversation can still change the outcome.

How do you forecast usage-based ARR?

Forecast consumption per account and roll it up, rather than applying a growth percentage to a total.

A blended growth assumption across a usage-based base averages accounts that are scaling with accounts that are winding down, and the average hides both. Account-level projection surfaces concentration, which matters more here than in a subscription model because a single large consumer can swing the total.

The forecast also has to update as conditions change. Consumption responds to the customer's own volume, and their volume responds to their market. That is the same reason a revenue forecast built on last year's assumptions misses, and the reason a usage-based ARR figure needs a rebuild cadence rather than an annual review. Our sales forecasting approach rebuilds against current data as the quarter progresses rather than running on an assumption set fixed at planning time.