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
Try these exact numbers in the free billing calculator, then change the usage or add a credit. No signup required.
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.
The five decisions at a glance
| Decision | What it answers | Example |
|---|---|---|
| Billable unit | What counts as one | One API call, one seat-day |
| Aggregation window | How usage sums | Total per billing period |
| Included units | What the base plan covers | 10,000 calls/month |
| Overage rate and tiers | What extra usage costs | 0.40 USD per 1,000 calls |
| Rounding and currency | Where numbers settle | Round at invoice assembly |
Aggregation windows, with numbers
The same raw events produce different invoices under different aggregation rules:
- Sum. 74,200 API calls in September, billed as 74.2 thousand-units. Most common, easiest to dispute-resolve.
- Average. Seat-based metering: 12 seats on some days, 8 on others. Average 9.4 seats x $39 = $366.60. Rewards part-time usage.
- Tier snap. Total usage crosses a breakpoint and the whole amount prices at the new tier, or only the amount above it does. State which — they differ by hundreds of dollars at scale.
Pick the rule a customer could recompute with a calculator and a CSV export. If they cannot, support owns the difference.
Seat-days: usage billing for people
Seat-based products often need usage precision too. A customer adds 4 seats on day 21 of a 30-day month:
- Seat-days: 10 seats x 20 days + 14 seats x 10 days = 340 seat-days
- At $12 per seat-day: $4,080.00 for the month
This is proration applied to seats — same daily formula, different unit. The invoice should show the seat count change date, not just the total.
Commitments, minimums, and drawdown credits
Enterprise-flavored usage deals often include:
- Minimum commits. "At least 500,000 calls per year, billed quarterly against actuals." Track the commit as a credit pool the customer draws down; true-up at period end.
- Prepaid credit balances. Customer pays $5,000 upfront; usage draws the balance down; invoices show the drawdown line by line. Prepaid credits deserve first-class records — when finance asks "what is left on that balance," the answer should be a query, not an investigation.
- Rollover rules. Unused included units expiring vs rolling. Whichever you choose, show it on the invoice.
Five metering bugs that corrupt the math
- Double ingestion. Retries without idempotency keys — every network blip becomes revenue.
- Clock skew. Events timestamped at the edge crossing a period boundary incorrectly. Boundary rules must be explicit (UTC, inclusive start, exclusive end).
- Silent drops. Fire-and-forget events that fail without a dead-letter path. The meter is now an undercount nobody can see.
- Unit confusion. Ingesting "milliseconds" into a field billed as "seconds" — a thousandfold error that survives review because the number looks plausible.
- Late arrivals. Events arriving after the bill run. Define a cut-off and a policy: bill next period, not retroactively.
Each of these is an ingestion problem, not a math problem — which is why trustworthy usage billing starts at the API boundary, not at the invoice.
A second example: tiered overage
Flat overage is easiest to verify, but tiered overage prices volume honestly. Same $49 plan, 10,000 calls included, with two overage tiers: the first 10,000 calls over the included amount at $0.40 per 1,000, and everything beyond that at $0.32 per 1,000.
A customer consumes 25,000 calls in September:
- Base plan: $49.00
- First 10,000 overage calls at $0.40 per 1,000: $4.00
- Remaining 5,000 calls at $0.32 per 1,000: $1.60
- Invoice total: $54.60
Tier boundaries must be printed on the invoice as separate lines. A single blended number is where tiered pricing starts to feel like a trick.
What happens mid-cycle
Plan changes meet usage in one of three policies — pick one and state it:
- Rate at next bill run. Usage keeps accumulating against the old plan until the period closes. Simplest to explain; most teams should start here.
- Prorate the included units. The new plan's included quantity is prorated for the remaining days, and usage rates against it immediately. Most precise, most questions.
- Reset the meter. Cleanest for the customer, easiest to abuse. Only with guardrails.
Frequently asked questions
Can customers dispute metered usage? They can and sometimes should. That is why usage must be reviewable before it bills — a customer-facing usage view plus a draft invoice step turns a dispute into a five-minute check instead of a refund.
Do we charge tax on usage overage? Tax applies to the invoice total according to your tax context, not to the metering itself. Keep tax determination at invoice assembly, where the full picture exists.
Usage-based or seat-based first? Seat-based if your value tracks people, usage-based if it tracks activity. Most B2B SaaS lands on hybrid eventually: a base seat fee with metered components for the expensive part of the product.
How do we handle a metering bug? Fix ingestion, then correct via credit or adjustment on the next invoice with a recorded reason — never by editing historical events. The audit trail is the product's credibility.
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.