Usage-based billing sounds simple: measure what customers consume, calculate what they owe, and send an invoice. Turning product usage into an accurate bill requires several connected processes. Usage data must be collected from different sources, cleaned, measured against customer entitlements, and converted into charges.
Four processes make this possible: ingestion, mediation, metering, and rating.
Understanding how they work together is essential for software companies implementing usage-based pricing. It also raises an important architectural question: Should all of these processes happen inside your billing system or should they happen in a decoupled usage metering solution? The choice affects how quickly you can launch usage-based offers, how widely you can use consumption data, and how easily you can adapt as pricing models evolve.
Although terminology varies between platforms, ingestion, mediation, metering, and rating represent four distinct functions in the usage-to-revenue process.
| Process | What it does | Output |
|---|---|---|
| Ingestion | Collects usage events from products and services | Raw usage data |
| Mediation | Cleans, validates, standardizes, and enriches usage records | Trusted usage data |
| Metering | Measures consumption according to defined usage metrics and commercial terms | Metered consumption |
| Rating | Applies pricing rules to measured consumption | Calculated charges |
Each stage builds on the previous one, converting product activity into information that billing and other business systems can use.
Usage ingestion is the process of collecting raw consumption events from software products, applications, services, and devices. Every time a customer performs a measurable action, the product may generate a usage event. That could be an API request, a transaction, an AI inference, or a message sent from a connected device.
The challenge is that usage data rarely comes from one place.
Software vendors may need to capture events across cloud, on-premises, online, offline, and connected-device environments. Different products may also generate different event formats and data structures.
An effective ingestion process must reliably collect these records without losing relevant usage or introducing duplicate events. For example, an AI-powered logistics platform may receive millions of API calls each month from customers operating across different locations. Ingestion captures those events and brings them into the usage-processing environment.
At the ingestion stage, the relevant data is collected, but it is not necessarily ready to be measured or billed.
Consumption-based pricing is on every software vendor’s radar today.
Find out how to implement the right infrastructure without disrupting your tech stack. Read this new white paper, The Usage Monetization Era: The Business Model for the AI Revolution.
Usage mediation transforms raw telemetry into clean, consistent, auditable usage data.
Raw events may contain duplicates, missing fields, inconsistent formats, or information that cannot yet be associated with a customer or product.
Mediation addresses these issues through processes such as:
Consider the logistics platform again. An API request might appear twice because an event was retransmitted. Without deduplication, that request could be counted twice, resulting in higher, inaccurate, usage.
Mediation removes the duplicate and ensures the valid event has the information needed for accurate measurement.
The distinction is straightforward: ingestion captures usage data, while mediation makes that data trustworthy and usable.
Usage metering measures customer consumption according to defined metrics and commercial rules. Once usage data has been validated and standardized, the meter can aggregate relevant events and associate consumption with the customer's plan or entitlement.
A meter might:
Suppose a customer has purchased a plan that includes two million API calls per month.
The meter measures valid API interactions and tracks consumption against that allowance. If the customer exceeds the limit, the measured usage can identify how much consumption falls beyond the commitment.
However, metering does not have to wait until the billing period ends.
When connected to customer entitlements and product-level controls, usage metering can also support decisions as consumption occurs.
For example, when a customer reaches a usage threshold, the software vendor can configure the product to issue a warning, enforce a limit, or allow additional consumption.
That distinction matters for usage-based SaaS billing, where waiting until invoice time can expose vendors and customers to unexpected costs.
Usage rating applies pricing rules to measured consumption to determine the amount a customer should be charged. Metering establishes how much a customer consumed. Rating determines the financial value of that consumption.
Depending on the pricing model, rating may involve:
Returning to the logistics platform, imagine the customer's plan includes two million API calls, with additional calls priced at $0.01 each.
If metering establishes that the customer consumed 2.2 million calls, the rating process calculates the applicable charge for the additional 200,000 calls.
In a simple pricing arrangement, that would produce a $2,000 overage charge.
The rated charges can then be passed into the billing process, where they are incorporated into the customer's invoice.
Metering determines how much was consumed. Rating determines how much that consumption costs.
Many modern billing platforms already offer sophisticated rating capabilities, including support for complex pricing tiers, commitments, and hybrid pricing structures.
The question is not whether billing platforms can perform these calculations. It is whether they should also be responsible for collecting, preparing, and controlling all the underlying product usage data.
For the logistics API vendor introduced earlier, each stage has a distinct role in putting the usage-based plan into practice. The customer’s two-million-call monthly allowance is recorded in its entitlement. As usage accumulates, the platform needs to establish which calls count toward that allowance, identify any overage, and prepare the information needed to calculate charges.
Here’s how the process works, from collecting raw activity to issuing the invoice:
Step 1: Ingest. The platform collects raw API interaction records as the customer uses the service.
Step 2: Mediate. Duplicate and invalid events are removed, and valid records are enriched with customer and product context.
Step 3: Meter. Valid API interactions are counted and compared against the customer's two-million-call commitment.
Step 4: Rate. The applicable pricing rules are used to calculate charges for usage beyond the included allowance.
Step 5: Invoice. The billing platform incorporates the charges into the customer's invoice.
The same underlying usage data can also serve other purposes. It can reveal when a customer is approaching their limit, help account managers identify expansion opportunities, and provide product teams with insight into consumption patterns.
This is why usage data should not be viewed solely as an input to billing.
Usage metering tools vary in the requirements they support. For software vendors managing multiple products, business models, and deployment environments, five capabilities are particularly important.
Can the platform capture consumption across all relevant products, services, devices, and deployment environments, including on-premises and offline software?
Can it deduplicate, validate, standardize, and enrich raw telemetry to produce trustworthy usage records?
Can it support different consumption metrics and measure usage against customer-specific allowances, commitments, and entitlements?
Can usage data inform product decisions before the billing cycle closes, including warnings, limits, and permitted overages?
Can the platform deliver accurate, usable consumption data to billing, CRM, ERP, and other downstream systems without requiring a billing replacement?
For enterprise software vendors, keeping ingestion, mediation, and metering independent of billing gives the business more freedom to introduce and evolve usage-based offers.
In this architecture, a dedicated usage layer sits between software products and the business systems that consume usage data. It collects activity, prepares trusted records, and measures consumption against customer entitlements. The existing billing platform can continue to handle rating and invoicing.
This separation supports three business priorities.
Implement new usage metrics and allowances without making billing replacement part of the project. Prepared consumption data flows into the existing billing platform, allowing teams to retain established invoicing and financial processes.
Keep usage data available to every part of the business that needs it. Customers can track consumption, account teams can identify expansion opportunities, and product teams can assess adoption using consistent records. These functions can evolve without making the billing platform the central dependency for every use of consumption data.
Usage-based, hybrid, credit-based, and AI-driven offers can introduce new measurement and control requirements. Keeping usage processing independent lets vendors add sources, adjust meters, and change entitlement rules without tying every decision to a billing vendor’s capabilities or roadmap.
For large software businesses, this provides a way to support today’s commercial models while keeping options open as products, customer needs, and pricing change.
Thales’s Sentinel Software Monetization platform provides a purpose-built usage layer that handles ingestion, mediation, and metering independently of billing.
It captures usage from multiple products and deployment environments, transforms raw telemetry into trusted records, and measures consumption against commercial entitlements. This connects what customers consume with what they purchased and are allowed to use.
The resulting data supports product-level consumption controls, feeds existing billing systems, and provides usage intelligence to customer-facing business systems. Billing receives prepared consumption records for rating and invoicing, while other teams receive the information they need to manage adoption and account growth.
For enterprises managing complex portfolios, Sentinel brings these capabilities together across products and deployment environments. You can launch usage-based and hybrid offers within your existing commercial stack, then adapt your monetization approach as the next model takes shape.
Learn how Sentinel enables usage-based and hybrid pricing models across your software portfolio while integrating with your existing billing systems.