Usage-based billing

Usage-based billing charges a customer for what they actually consumed in a billing period — API calls, tokens, compute hours, seats, storage or transaction value — instead of a single flat fee. Usage is captured as events, aggregated per customer, priced against a rate and invoiced when the period closes.

How it works

1. Meter. The product emits a usage event per unit of consumption, each with a customer, a quantity, a timestamp and an idempotency key.
2. Aggregate. Events are summed, counted, or reduced to a max, min, last value or unique count per period.
3. Rate. The aggregate is priced — per unit, graduated, volume, tiered, package, percentage or per seat — after any included units, and within any minimum or cap.
4. Invoice and collect. The rated lines become an invoice at period close, sent with a way to pay.

Most products bill hybrid: a recurring platform or seat fee that includes an allowance, with metered usage above it.

Why it matters

Usage pricing lets revenue follow the cost of serving each customer — essential when every request has a real cost, as with AI inference. It also moves the hard part into billing: an event dropped or double-counted is revenue lost or a dispute won by the customer. Usage models are estimated to leak 4–9% of revenue against 2–4% for flat-rate SaaS.

In the US and the UK

• US: each usage invoice line must be marked taxable or not for state sales tax; since South Dakota v. Wayfair nexus is economic, commonly $100,000 of sales into a state.
• UK: a usage invoice is a VAT invoice — sequential number, time of supply, VAT rate per line and the VAT total in sterling, per HMRC Notice 700/21.

How Fynex does it

Fynex meters events (API, batch, CSV or webhook), rates them on seven pricing schemes with included units, minimums and caps, and issues the invoice at period close with a payment link — then matches the payment back. See usage-based billing for SaaS and API products.