5 Questions to Answer Before You Make the Switch to a Usage-Based Pricing Model

3. How will you meter usage?

Capturing product activity is the starting point. Turning it into usable billing and accounting data takes additional work.

Ben broke the process into several steps:

1. Capture events: What happened, who did it, and when?
2. Transform and enrich the data: Which customer, contract, region, or deployment does the activity belong to?
3. Aggregate it: Does the business need usage by day, week, month, or another interval?
4. Apply the relevant rates and rules: What does that activity mean for billing and revenue?

Those rules can become intricate. A customer might have a commitment, receive invoices in arrears, and have free credits that apply only at a particular point in the contract.

The data also serves different audiences.

A customer approaching a usage limit may need an immediate alert. Finance may need a monthly calculation with a clear audit trail. Customers may want usage detail alongside their invoices so they can understand the charges.

Those requirements shape the build-versus-buy decision.

Ben favors building metering internally when it closely controls the product experience: overage alerts, service cutoffs, or shared usage limits. Where those needs are less immediate, a third-party solution may reduce the engineering and maintenance burden.

The right choice depends on what metering needs to do for your customers as well as your back office.

Ben also highlighted metering as an area auditors scrutinize closely: how events are captured, how they are transformed, and how the company establishes completeness. Estimates and unusual contract terms introduce further review.

4. How will you account for the revenue?

Knowing what a customer consumed doesn’t automatically tell you how much revenue to recognize.

Usage needs to map to the right contract and contract line. Discounts, commitments, free credits, and modifications can all affect the calculation.

Ben used three simplified scenarios to illustrate how the requirements change:

The important distinction is that each model requires different information upstream. A system cannot apply a monthly minimum correctly if that minimum never made it out of the contract and into structured data.

Contract changes make that dependency especially visible.

Ben described a failure scenario in which a revenue engine correctly processes usage and recognizes unused balances at expiry—but deal desk separately promises the customer a rollover by email.

If the system follows its configured rules, but the commercial agreement has changed outside it, then that disconnect can create a material error.

Reliable revenue accounting depends on keeping contracting, metering, and accounting connected.

5. How will you build a system that scales?

Ben outlined four approaches, each with different tradeoffs.

A simple approach for smaller companies

For early-stage companies whose immediate reporting centers on cash and burn, with no near-term audit requirement, a simpler revenue process may fit the business better than investing immediately in a fully automated engine for allocations and contract modifications.

The scope should follow the reporting requirements the company actually has. Before committing to a larger implementation, understand which calculations you need today, how much manual work they create, and where the current process becomes difficult to explain or maintain.

Even while keeping the process simple, capture the contracts, usage, and amendments a future system will need. As Ben explained in the Q&A, reshaping historical agreements into structured records can become one of the hardest parts of a transition.

Then define what will trigger the next investment: more negotiated enterprise contracts, frequent pricing changes, a growing close workload, or more demanding reporting and audit requirements. A simpler starting point works best with a clear plan for when to move on.

Build internally

Metering can be a natural internal investment because it supports the customer experience. Numeric CTO Andrew Bihl extends this point in his writing on billing architecture for AI companies: usage measurement, pricing, and live balances form a fast feedback loop that the product depends on.

When a customer approaches a spending limit, the product needs current information to decide whether to warn them, stop service, or allow overages. Enterprise customers may also need shared credit pools and spending controls by team. Owning that infrastructure gives engineering control over how those experiences evolve.

Ben cautioned that extending the internal build into invoicing and revenue accounting introduces substantial engineering work. Andrew recommends using specialist software for those functions, ideally keeping invoicing and revenue recognition together.

Buy a point solution

A dedicated billing or revenue tool can make sense when a company already has a substantial investment in its general ledger or broader enterprise systems.

Integration work still matters. In the Q&A, Ben highlighted the challenge of keeping multiple systems aligned on data granularity, accuracy, and timing.

Buying a tool leaves the team responsible for those connections.

Integrate billing and revenue into the system of record

Ben’s preferred approach brings billing, revenue, and the rest of accounting into a shared data model. A credit note illustrates why: an action commonly treated as a billing operation can also affect revenue. Keeping the two connected helps the system reflect that relationship.

Andrew adds a specific requirement for connecting that back office to customer-facing metering: a shared model of the customer agreement.

Finance and accounting interpret the full contract, including discounts, bundled services, and modifications. Metering receives the terms it needs to apply prices and manage balances. Both sides work from the same agreement rather than reconstructing it independently.

As the business grows, teams also need to reconcile bookings, billings, recognized revenue, and collections—and identify usage events that never received a price. Those controls help the system remain explainable as pricing and contracts become more complex.

Shared data can also support richer reporting, such as connecting bookings, billings, and revenue by sales representative or analyzing customer usage across geographies and business units.

Bring billing and revenue onto the same foundation

Numeric’s Billing & Revenue product puts contract terms, rate cards, and usage events into a shared model, so invoices and revenue schedules are generated from the same underlying data. It supports tiered usage, overages, and minimum true-ups, flags usage events that do not match a rate card, and applies allocation and contract-modification logic consistently.

For teams keeping customer-facing metering in-house, Andrew describes how Numeric can own the back office and coordinate the agreement layer. Engineering retains control over the product experience, while finance manages the contract interpretation and downstream billing and revenue work.

Today? Start with the contracts and data you already have

During the Q&A, an audience member asked what makes the transition especially difficult.

Ben pointed to data transformation.

A company may have thousands of active contracts written before anyone contemplated the new system. Those agreements need to become structured records that the billing and revenue engine can use.

He described AI as increasingly useful for reading documents, identifying missing fields, and helping reshape that data. Review, validation, and reconciliation remain part of the process.

That work offers a practical starting point: define the contract information your future system requires, compare it with what you capture today, and identify the gaps.

The five questions ultimately connect. Your business model shapes your contract terms. Those terms determine what you need to meter and calculate. And those requirements determine the system you need to build.