Usage-based billing looks like a multiplication problem. It is not. It is five decisions that have to be made before the multiplication means anything, and one review step that keeps the result honest.
The five decisions
1. The billable unit. Define what counts as one unit in language a customer could not misread: an API call, a message delivered, a seat active on a given day, a gigabyte stored. Ambiguity here becomes a support ticket later.
2. The aggregation window. Decide whether usage sums over the billing period, averages, or snaps to tiers. Summing is the most common and the most explainable: 74,200 API calls in September.
3. Included units. Most usage pricing is really hybrid: a base plan that includes some quantity, with metered overage beyond it. State the included quantity on the subscription item, not in a doc.
4. The overage rate and tiers. Flat per-unit, tiered with breakpoints, or volume-based. Flat is easiest to verify on an invoice — start there unless pricing genuinely demands tiers.
5. Rounding and currency. Round at invoice assembly, not per event, and document it. Per-event rounding drifts.
A worked example
A plan costs $49/month and includes 10,000 API calls; overage is $0.40 per 1,000 calls. In September a customer consumes 12,400 calls.
- Base plan: $49.00
- Overage: 2,400 calls over the included 10,000, billed as 2.4 thousand-units at $0.40: $0.96
- Invoice total: $49.96
Nothing here is hard. What makes it trustworthy is that 12,400 came from idempotent event ingestion, was visible before invoicing, and assembled into a draft a person checked before it posted.
Metering integrity: idempotency or nothing
If your ingestion endpoint can double-count a retried request, every downstream number is fiction. Usage ingestion must be idempotent — attach an idempotency key to every write so a network retry produces one recorded event, not two. In Floatless, the usage events endpoint requires an Idempotency-Key header for exactly this reason.
Review before revenue
Usage should surface as a reviewable quantity before it becomes an invoice line: what was metered, what fell inside included units, what rates as overage. A 30-second human check per bill run catches the metering bug that would otherwise become a hundred refund conversations.
Where this lives in Floatless
Usage events attach to subscription items, included units and overage are part of the plan, rated usage appears for review before the bill run, and the posted invoice shows base and usage as separate lines. The usage events API handles ingestion; the usage-based billing guide covers the model end to end.