What is Usage Metering?

What is usage metering?

Usage metering is the measurement and recording of how much of a product or service a customer consumes, so that consumption can be priced, billed, and analyzed. Every usage-based invoice starts with a meter. If the meter is wrong, everything downstream (the invoice, the revenue number, the margin analysis) is wrong with it.

The term comes from utilities, where a physical meter counts kilowatt-hours. In software the meter is a data pipeline: events go in, billable quantities come out.

How does a usage meter work?

A meter has 3 parts, and each one is a place where accuracy is won or lost:

The aggregation step matters more than most teams expect. "Monthly active users" is a unique count. "Peak concurrent connections" is a maximum. "Tokens processed" is a sum. Pick the wrong function and the invoice is legally wrong.

What should an AI product meter?

For AI products the metering question has become the pricing question. The candidate units:

Whichever unit is chosen, the meter has to record enough dimensions to answer later questions: which model served the request, which feature triggered it, which customer entity to bill. Metering only the total is the most common regret.

Why does metering accuracy matter so much?

Because metering errors are silent. A wrong subscription fee gets noticed by the customer. Unmetered usage gets noticed by no one: the events simply never become revenue. This is the largest single source of revenue leakage in usage-based businesses.

Accuracy in practice means idempotent ingestion (the same event counted once, even when sent twice), handling late-arriving events (a batch job that reports yesterday's usage today), and auditable recalculation (when a customer disputes an invoice, you can replay the events that produced it). These are ledger properties. A meter that can't replay its history is a guess with a dashboard.

Should metering and billing be separate systems?

They often are, and it's usually a mistake. A standalone metering tool that exports totals to a separate billing system creates a reconciliation gap: the meter says one number, the invoice says another, and finance spends month-end finding out why. The argument for keeping them in one system is covered in don't split metering and billing, and the common failure patterns in usage metering pitfalls and how to avoid them.

Solvimon runs metering as part of the billing ledger itself: events are ingested once and priced, invoiced, and recognized from the same record. Built by the team that ran this kind of infrastructure at Adyen at €1T+ volume.

FAQ

What's the difference between usage metering and metering?

In billing contexts, none worth defending. Metering is the general term; usage metering emphasizes that the measured quantity drives billing.

How real-time does metering need to be?

As real-time as your customer-facing needs, not your invoice. Invoices are periodic, but customers checking a usage dashboard, or hitting an entitlement limit, expect current numbers. Prepaid and credit models raise the bar further: you can't let a customer with an empty balance keep consuming.

Can you meter retroactively?

Only if the raw events were captured. This is the argument for ingesting events even for things you don't bill yet: repricing later is a configuration change instead of a data archaeology project.

What happens when a meter and an invoice disagree?

In a split stack, a reconciliation project. In a unified ledger, it can't happen, because the invoice is computed from the meter's own records.

Related

• Metering: the general concept

• Usage-based pricing: the pricing model meters enable

• Usage metering pitfalls: the failure patterns

• Neocloud metering: attributing GPU consumption per tenant at infrastructure scale