Metered billing and usage-based billing get used as synonyms. They are two layers of the same system, and separating them makes the architecture much easier to reason about.
Metering is measurement. It counts API calls, GPU seconds, or tokens processed. Usage-based billing is the layer above it that turns those numbers into money. Most billing bugs live at the seam between the two, where an aggregation window disagrees with a billing period or a retried request gets counted twice.
Short answer
Metered billing measures actual product usage as discrete events, then a rating layer converts that measured usage into charges. It runs in four stages: event ingestion with idempotency, aggregation into billable metrics, rating against pricing rules, and invoicing.
The four layers
Event ingestion
Every billable action emits an event. An API call, a token generation, a completed workflow. These flow into the metering pipeline through a queue or an ingest endpoint, and each carries an idempotency key so a retry cannot become a second charge.
{
"event_id": "evt_9f2c41ba7d",
"event_name": "tokens_processed",
"external_customer_id": "cust_4812",
"timestamp": "2026-09-11T14:22:05Z",
"properties": {
"model": "gpt-4o",
"input_tokens": 1840,
"output_tokens": 612,
"region": "eu-west-1"
}
}
Two things make this layer survivable. The event_id is generated by the caller, not the receiver, so the same event submitted twice collapses into one. And the pipeline needs replay and backfill, because a consumer will eventually fall over and has to resume from the last committed offset rather than from now.
The Flexprice event ingestion overview covers the ingest contract, and there is an event debugger for inspecting what actually arrived, which is the question you want answered when an invoice looks wrong.
Aggregation
Raw events are not billable. A billable metric is an aggregation over a window, and the function you choose changes what the customer sees on the invoice.
-**Sum **totals a numeric property. Total tokens processed in a period.
-**Count **counts events. Number of API requests.
-Count unique counts distinct values of a property. Active users, distinct documents touched.
**Max **takes the highest value in the window. Peak concurrent seats.
-Latest takes the most recent recorded value. Current storage allocated.
-Average takes the mean of a property across events.
-Sum with multiplier sums a property and applies one configured rate to the total, which is how a raw count becomes a currency amount.
-Weighted sum is time-proportional, prorating values by how long they were held. This is the one for capacity billing such as reserved storage measured in GB-hours.
The aggregation reference documents each of these. The window matters as much as the function: hourly, daily, and per billing period each produce different numbers from the same event stream, and a mismatch between the aggregation window and the invoice period is one of the most common sources of disputed charges.
Rating
Rating converts aggregated usage into currency. The standard shapes:
-Per unit. A flat rate for every unit consumed. Easy to predict, easy to explain.
-Tiered. The rate changes as consumption crosses thresholds, with each tier priced separately.
-Volume. The whole quantity is priced at the rate the total volume qualifies for, so unit price falls as volume rises.
-Overage. A quota is included, then per-unit charges apply above it.
-Minimum commitment. A floor the customer pays regardless of consumption, with usage charged above it.
Tiered and volume are frequently confused and produce different invoices for the same usage. Under tiered, the first 10,000 units keep their original rate when the customer reaches 50,000. Under volume, all 50,000 reprice at the higher-volume rate. Flexprice documents volume tiered pricing separately for exactly this reason.
Invoicing
Rated usage becomes line items. This stage combines usage charges with subscription fees and one-off charges, applies credits and discounts, handles proration for mid-cycle changes, and calculates tax and currency conversion.
The requirement that gets underestimated is traceability. Every line item should resolve back to the events that produced it, because the first question on a disputed invoice is always "which requests are these". Invoice calculation describes how charges are assembled.
AI-specific metering choices
Tokens, requests, or GPU time?
Three metrics, three tradeoffs.
**Tokens **are precise and map closely to provider cost. They also confuse buyers who have no intuition for how many tokens a conversation consumes, and they punish the user for iterating on a prompt.
Requests are the easiest to understand and the easiest to forecast. They also hide the fact that one request can be a hundred times more expensive to serve than another.
GPU time tracks actual resource consumption, which lines up with cost for training runs and heavy analysis. It is opaque to a customer who only sees a task complete.
The right choice depends on who reads the invoice. Precision that the buyer cannot interpret creates support tickets, and simplicity that ignores cost variance creates margin problems.
Composite metrics
A composite metric multiplies a base count by coefficients that reflect real cost. Requests times a model coefficient times a latency bucket, for example, so a slow query on a larger model costs more than a fast one on a small model.
This is fairer than a flat per-request rate and it is closer to the underlying cost curve. The tradeoff is that every coefficient has to travel with the event, because the aggregation can only use what the event carries, and a coefficient change has to be versioned so historical invoices stay reproducible.
The primitive for this is a custom expression, a CEL formula evaluated per event that computes the quantity to aggregate. input_tokens + output_tokens combines two fields, ceil(duration_ms / 1000) converts and rounds, and gpu_seconds * device_weight applies a coefficient sent as a property. It works with Sum, Average, Max, and Latest. Missing properties evaluate to zero and nested paths are not supported, so flatten anything the formula reads to a top-level property.
What customers need to see
Live usage visibility has moved from a differentiator to an expectation. Customers want current-period consumption, remaining quota, and enough history to predict next month.
Alerts do the rest of the work. A notification at 75% of quota costs nothing and prevents the support conversation that starts with a surprise invoice. Flexprice supports spend alerts at the subscription and line item level.
Prepaid credits and postpaid billing solve the predictability problem from opposite directions. Credits are bought up front and drawn down, with optional auto top-up and rollover, which caps exposure by construction. Postpaid gives full flexibility and defers the number to the end of the cycle, which is where bill shock comes from.
Finance alignment
Raw meters become unit economics when usage per customer is joined against cost to serve. That is what tells you which accounts are profitable and which are subsidised, and it is the number that decides whether a pricing model works.
Inside organisations, two patterns handle internal accountability. Showback gives teams visibility into their consumption and its cost without moving money. Chargeback bills internal teams for what they consume. Both depend on consistent resource tagging and normalised unit costs, which is standard FinOps practice.
Reliability and reconciliation
Design for failure. Queues, retries, and dead-letter queues for events that cannot be processed. A dropped event is unbilled revenue and a duplicated event is an angry customer, so the pipeline needs both directions covered.
Keep usage logs immutable. Once recorded, a usage event should never be altered or deleted. That gives both sides a single source of truth during a dispute, and it is what makes an audit possible.
Let customers export raw usage. A customer who can check the arithmetic themselves stops needing to trust the invoice.
Common failure modes
Silent overages. Usage passes the limit with no warning and the invoice arrives at four times the expected amount. Alerts and spending caps fix this, and they have to exist before the pricing launches, not after the first complaint.
Aggregation mismatches. One meter rolls up in minutes, another in hours, timezones differ between the ingest layer and the billing period. The result is double counting or missed charges. Standardise the window and the timezone across every meter.
Meter drift and duplicate events. Without idempotency keys and deduplication before the pipeline, retries inflate bills. This is the failure that erodes trust fastest, because it is invisible until a customer audits their own logs.
Build or integrate
Four questions decide it.
Scale. Events per second at peak, not average. High volume changes the storage and aggregation architecture completely.
Metric complexity. Counting API calls is straightforward. Combining model type, duration, and latency into a composite metric with versioned coefficients is a system.
Financial alignment. If billing has to reconcile against CRM, ERP, tax, and accounting systems, most of the work is integration rather than metering.
Visibility. Dashboards and exports for both developers and finance are a product in themselves.
The integration pattern splits into four components that can be one stack or separate services: a metering pipeline for ingestion, a rating engine for pricing logic, a billing engine for invoices, and a payment gateway for collection. Keeping them separable is what lets you replace one without replacing all four.
Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud, so usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud.
A starting checklist
Choose the value metric. It should represent value to the customer and correlate with your cost. These are not always the same unit, and the customer's version usually wins.
Fix the windows and aggregation functions. Pick them once and apply them consistently across every meter.
Prevent bill shock before launch. Invoice previews, threshold alerts, and either credit wallets or capped plans.
Plan reconciliation up front. Immutable logs, export tooling, and a documented dispute workflow.
Getting started
Ingest is the layer to prove first. The sending events guide covers the payload contract and idempotency handling, and the implementation is on GitHubif you want to read how aggregation and rating are wired together.
Top comments (0)