Glossary Usage-Based Revenue

Usage-Based Revenue

    What is Usage-Based Revenue?

    Usage-based revenue is a pricing and billing model where customers pay based on how much they actually use a product or service. Instead of locking them into fixed subscriptions or tiered packages, you align pricing directly with consumption.

    “Consumption” could mean anything, depending on your product:

    • API calls
    • Storage volume
    • Transaction count
    • Number of active users
    • You name it

    This model benefits both sides. For customers, it’s fair, flexible, and low-commitment. They pay only for what they get value from. For businesses, it lowers entry barriers, shortens sales cycles, and builds trust early. Once adoption grows, expansion happens naturally. A “land and expand” motion lets you start small with a customer, then scale revenue as their usage increases.

    For RevOps teams, though, there is one consideration. Usage revenue introduces variability into revenue forecasting, so it requires tight alignment between product, sales, and finance. Because revenue fluctuates with usage, your team needs real-time visibility into customer data, usage patterns, and leading indicators to forecast accurately and sustain predictable growth.

    Synonyms

    • UBR
    • Consumption-based revenue
    • Metered service revenue
    • Pay-as-you-go (PAYG) revenue

    Usage-Based Revenue Models

    There are four main usage-based revenue models you might use.

    Usage-based revenue models in SaaS
    Pure pay-as-you-go
    Pure pay-as-you-go
    Tiered with overage
    Tiered with overage
    Prepaid usage
    Prepaid usage
    Hybrid models
    Hybrid models

    Pure pay-as-you-go

    This is the simplest form of usage-based revenue. Customers pay strictly for what they use, with no minimums or commitments. Think of it like paying for electricity: if usage drops, the bill drops too.

    The pay-as-you-go pricing model entails:

    • No upfront commitment or minimum spend
    • Revenue scales directly with usage
    • High transparency and flexibility for customers
    • Lower predictability for finance and RevOps teams

    Take cloud computing services like Amazon Web Services (AWS). A startup might pay only a few dollars a month when traffic is low but scale to thousands as usage grows. There’s no barrier to entry, making it easy for new customers to start small and expand naturally.

    Tiered with overage

    The tiered model sets defined usage tiers with a fixed, predictable base price and additional overage fees when customers exceed their plan limits. It’s a middle ground between fixed and variable pricing.

    What it entails:

    • Predictable monthly baseline revenue
    • Controlled variability through tier limits
    • Upsell opportunities as customers outgrow tiers
    • Encourages proactive monitoring of usage

    HubSpot’s usage-based features consume HubSpot Credits. Examples of this are its AI, automation, and data enrichment tools like Customer Agent, Breeze Intelligence, and Data Agent within its broader platforms like Sales, Marketing, and Service Hub.

    When you exceed the monthly credit limit on these tools, you can elect for (a) an auto-upgrade to a tier with more credits or (b) opt into a “pay-as-you-go” overage setting. If you choose the latter, HubSpot bills you monthly at the current overage rate per additional credit.

    Committed contract / drawdown model (prepaid usage)

    In this model, customers commit to a certain spend or credit amount upfront, which they “draw down” as they consume the product. It blends predictability for the vendor with flexibility for the customer.

    Its key characteristics are:

    • Upfront payment or annual commitment
    • Usage draws down a prepaid balance
    • Predictable revenue for finance teams
    • Reduced churn risk through commitment

    Snowflake’s pricing works this way. Customers pre-purchase compute credits, then deduct usage as queries run. This structure gives Snowflake steady revenue while customers maintain control over how and when they consume resources.

    Hybrid models

    Hybrid models combine elements of subscription and usage-based pricing. You charge a base subscription fee for access, plus a variable usage component. It’s designed to balance predictable revenue with scalability.

    These kinds of models generally entail:

    • Fixed recurring base fee plus variable usage fees
    • Predictable revenue floor with room for expansion
    • Ideal for SaaS products with both access and consumption value
    • Encourages ongoing engagement while maintaining stable cash flow

    Square uses a hybrid model. Businesses pay a base subscription for standard POS software and hardware but incur additional charges for payment processing fees. The model supports predictable ARR while capturing upside from active, high-usage customers.

    Usage-Based Revenue Recognition (ASC 606 / IFRS 15)

    Most U.S. companies are required to comply with ASC 606, while international entities follow IFRS 15, to determine when and how revenue should be recognized. Both frameworks share the same core principle: revenue is recognized when control of goods or services transfers to the customer and the amount can be reliably measured.

    With traditional subscription models, you charge fixed periodic fees. Revenue is predictable and easy to recognize evenly over the contract term. Usage-based models introduce variability. Revenue fluctuates with consumption, so you don’t know the total amount until usage occurs.

    The accounting solution is called variable consideration. This is what lets you estimate and recognize revenue as the customer uses your product, adjusting over time as usage data becomes available.

    The Five-Step Model impact

    Revenue recognition follows a five-step process. Usage-based revenue doesn’t change the framework itself; it just changes how you apply it.

    Revenue recognition with usage-based revenue

    Define the contract
    Report accurately
    Identify customer contract and terms
    Map every performance obligation
    Separate fixed and variable components
    Allocate fixed fees across obligations
    Track usage in real time
    Recognize variable revenue when consumed
    True-up estimates with actual usage
    1

    Identify the contract with a customer.

    No major change here. You still define a valid contract that establishes enforceable rights and obligations between you and the customer. However, usage-based contracts include variable pricing terms and consumption clauses you have to clearly document.

    2

    Identify the performance obligations.

    Performance obligations represent the distinct goods or services you’re selling. In usage-based models, this is a bit nuanced. Instead of a single, fixed deliverable, your obligation would be the continuous provision of access or capacity (like API calls, data storage, or compute time) over the contract term.

    3

    Determine the transaction price.

    Usage-based models diverge here because the standard treats all usage-based amounts as “variable consideration.” So you ask: What is the total amount of usage-based revenue we expect to receive for the services already delivered?

    For usage-based SaaS businesses, it works like this:

    • Pure pay-as-you-go: The transaction price for the month is actual metered usage. Since it’s operationally simple, there’s usually no estimate needed.
    • Hybrid models: If your pricing strategy involves a minimum fee plus usage, tiered pricing, and/or discounts for usage levels, you estimate the expected amount for the portion of service already provided, then true it up when the actual usage is known.
    4

    Allocate the transaction price to the performance obligations.

    Here’s where you decide how much of the total contract value belongs to each promised good or service. If the contract has multiple performance obligations (say, a base subscription plus add-ons), you allocate the estimated transaction price proportionally based on their standalone selling prices.

    The usage component, however, sits off to the side and remains open-ended. For example, imagine a SaaS contract that includes:

    • A $12,000 annual base subscription (fixed), and
    • $0.05 per API call (usage-based).

    You’d allocate the $12,000 fixed fee proportionally across the obligations (e.g., platform access, support) but the API call revenue isn’t allocated ahead of time. It’s recognized as calls are made because the performance obligation (providing API capacity) is satisfied through that usage.

    5

    Recognize revenue as performance obligations are satisfied.

    You’ll recognize the revenue as the customer consumes the service or resource.

    In basic PAYG models, recognition is still straightforward. You invoice customers monthly in arrears for what they used during that period, and you recognize revenue at the same time (now that the service has been delivered and usage confirmed). So if a customer consumed 10,000 API calls in March, that revenue is recognized once those calls are fulfilled and billed.

    More complex models like hybrid pricing structures and committed contract/drawdown models require a split approach. You recognize a base minimum or committed amount evenly over the contract term (since that access or capacity is continuously provided), while overage fees or excess usage are recognized using the process detailed above.

    True-ups and forecasting

    A true-up reconciles what you estimated with what actually happened. You compare estimated variable revenue, actual usage, and recognized revenue, then adjust the books so everything matches real consumption. This keeps your financials clean and compliant.

    And with this business model, forecasting is now a cross-functional effort. Sales and RevOps have to align their usage projections with accounting’s constrained revenue estimates. You can’t optimistically forecast consumption for your stakeholders when ASC 606 requires conservative recognition until uncertainty is resolved.

    Usage-Based Revenue Metrics

    If you’re going to implement usage-based pricing, the metrics you track and how you interpret them will be a bit different from fixed-price models. You focus less on seat counts and more on how customers consume value over time.

    Expansion revenue rate

    When your existing customers grow their spend through increased usage, that’s expansion revenue. It’s the primary growth engine in UBR models because customers naturally scale as they embed your product deeper into their workflows. When usage rises, revenue rises without requiring new deals, new negotiations, or additional sales cycles.

    A strong expansion revenue rate tells you your product drives recurring value, your usage incentives are aligned with customer outcomes, and your land and expand strategy is doing exactly what it should: turning small accounts into large ones through real, sustained adoption.

    Net dollar retention (NDR) and net revenue retention (NRR)

    NDR and NRR show how much revenue you keep and grow from your existing customer base after upgrades, downgrades, and churn. In usage-based revenue models, these metrics become even more important because they capture the true financial impact of your customer retention and expansion efforts.

    Like expansion revenue, high NDR/NRR means people are using your product more deeply and generating organic expansion without heavy sales involvement. Low NDR/NRR signals declining usage, shrinking workloads, and signs of potential churn.

    Gross margin by unit of usage

    Gross margin by unit of usage tracks the exact cost of delivering each consumed unit, like cost per API call, cost per GB processed, or cost per transaction. This metric tells you whether your usage model is profitable at scale or silently eroding your margins as consumption grows.

    Strong unit margins mean your infrastructure scales efficiently and every extra unit of usage contributes meaningful profit. Weak unit margins tell you you need to adjust pricing or implement better cost controls before pushing for higher sales and usage volumes.

    Usage to ARR conversion time

    Usage to ARR conversion time measures how long it takes for a new or expanded customer to reach a stable usage pattern that translates into predictable annual recurring revenue. Early usage is often volatile, but once a customer integrates your product into daily workflows, consumption settles into a reliable baseline.

    Short conversion times mean customers ramp quickly, understand the product’s value, and generate steady ARR you can forecast with confidence. Long conversion times usually signal onboarding friction, slow adoption, or uncertain value realization.

    Predictive usage forecasting accuracy

    Predictive usage forecasting accuracy measures how close your projected usage metrics were to the actual usage that occurred. In usage-based models, this matters more than almost any other forecasting metric because revenue moves with consumption.

    High accuracy means your models capture real customer behavior, seasonality, and growth patterns. Low accuracy shows your forecasts are too optimistic, too conservative, or disconnected from your product analytics. When you track this metric consistently, you sharpen your ability to predict revenue, capacity needs, and future expansion potential.

    UBR Challenges and Solutions for RevOps

    Usage-based revenue grows fast, but it demands tighter coordination across Sales, RevOps, Finance, and Product teams. The variability that makes it powerful also creates operational challenges you need to solve early to keep your GTM engine aligned and predictable.

    Challenge: Revenue predictability and forecasting

    Forecasting usage-based revenue streams is inherently much harder compared with traditional subscription models. Revenue rises and falls with customer consumption, so your team can’t rely on fixed contract values and predictable renewal cycles.

    If you forecast off gut feel or historical averages, you’ll miss major swings in usage, seasonality, and customer growth patterns.

    Solution: Implement a hybrid model with a fixed recurring base fee. Then, track leading indicators like activation events, workload growth, feature adoption, and usage velocity within your product analytics, billing system, or metering service.

    Challenge: Billing complexity and customer disputes

    With a usage model, you’re tracking, rating, and billing millions of small usage events continuously. That leaves you tons of room for errors, revenue leakage, and customers who are shocked at the end of their billing cycle.

    If customers don’t understand how charges accumulate or can’t see their usage in real time cia a dashboard, they won’t trust you. They’ll dispute the charge in the near term (more work for your billing team) and churn in the long term (less profitability overall).

    Solution: Use a platform that specifically offers CPQ and usage-based billing together. Accurate quoting upfront sets the right expectations, and real-time usage monitoring inside the same system gives customers full visibility into their consumption. Connect it to your product so customers always know what they are using, what it costs, and how to control spend.

    Challenge: Sales compensation and incentive alignment

    Traditional sales comp plans reward reps for closing fixed contract values, not for driving healthy usage after the sale. In a usage-based model, that creates a gap: reps win the deal, but they aren’t incentivized to make sure the user actually adopts the product deeply enough to generate meaningful revenue.

    That misalignment slows expansion, hurts onboarding quality, and weakens the land and expand motion.

    Solution: Tie sales compensation to both committed contract value for the initial land and actual usage or expansion revenue for the expansion. That way, reps have a reason to target best-fit customers who will succeed with your product and they’ll collaborate more closely with Customer Success to stay engaged throughout the early adoption phase.

    Challenge: Data silos and single source of truth

    Usage-based revenue falls apart when the core data sets live in different systems.

    • Usage data typically sits in your product analytics stack or data warehouse.
    • Contract terms, pricing, and entitlements sit in your CRM and CPQ.
    • Billing and recognition sit in your finance tools.

    When these systems don’t speak to each other, teams operate with mismatched numbers. Sales thinks a customer has room to grow, but Product sees flat usage. RevOps forecasts one thing and Finance recognizes another.

    The result is misaligned GTM efforts and confused decision-making.

    Solution: Use a revenue platform that centralizes CPQ, contracting, usage metering, billing, and revenue recognition. Sync product usage data with your billing and CPQ platform, push entitlements and contracted rates from CRM into the same system, and make this information visible to Sales, RevOps, Finance, and Product.

    People Also Ask

    How does usage-based revenue differ from a standard subscription model?

    A standard subscription charges a fixed recurring fee regardless of how much a customer uses the product. Usage-based revenue charges customers based on actual consumption, which aligns cost with value and creates natural expansion opportunities as usage grows.

    What is the most critical system for successfully implementing a usage-based revenue model?

    A real usage-based billing platform connected to your product, CRM, and CPQ is the most critical system. You need accurate metering, real-time usage visibility, and automated rating to bill correctly and forecast reliably.

    What is the biggest challenge usage-based revenue creates for the Finance team?

    Finance departments struggle most with revenue predictability. Usage fluctuates month to month, so forecasting, revenue recognition, and cash flow planning require tighter alignment with RevOps and real-time access to usage data.