How do I meter and reconcile usage-based billing accurately?

Assume usage events can arrive more than once — retries, network issues, and reprocessing all produce duplicates in at-least-once delivery systems — and deduplicate on a unique event ID before counting. Reconciliation means confirming the invoiced usage total traces back to a specific, replayable set of deduplicated events, not just that the final number looks plausible.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 16, 2026Last reviewed September 16, 2026Editorial policy

Part of the subscription and usage billing guide.

Why duplicates happen at all	Most usage-event pipelines use at-least-once delivery, which guarantees duplicates under retries, not just occasionally produces them
The fix	Every usage event needs a unique event ID; deduplicate on that ID before aggregating, enforced at the storage layer
Reported industry impact	Metering errors are estimated to account for 3–7% of annual billing leakage in usage-based SaaS businesses
What reconciliation actually means here	The invoiced total should be traceable back to a specific, replayable set of deduplicated events
When this matters most	A customer dispute — being able to replay the exact event sequence that produced the disputed number

Why duplicate events are the expected case, not an edge case

A usage-metering pipeline built on at-least-once delivery — the standard pattern for distributed event ingestion — guarantees that some events will arrive more than once under normal operating conditions: a network retry, a consumer restart mid-processing, a producer resending after a timeout it assumed was a failure. Treating duplicate delivery as a rare failure mode to patch around misreads the actual guarantee the system is built on; the pipeline needs to assume duplicates will happen continuously and handle them as routine, not exceptional.

Why a unique event ID is the actual fix

Exactly-once accounting on top of at-least-once delivery is achieved through idempotency: every usage event carries a unique identifier, and the storage layer enforces uniqueness on that identifier so a redelivered event with the same ID is recognized and discarded rather than counted again. This needs to be enforced at the storage layer specifically — deduplicating only in application logic, without a uniqueness constraint underneath it, leaves a race condition where two near-simultaneous deliveries of the same event can both pass an in-memory check before either is recorded.

Why this is a real, measured revenue problem

Metering errors aren't a theoretical risk — they're estimated to account for 3–7% of annual billing leakage in usage-based SaaS businesses specifically, which is a meaningful share of revenue for a business model where the invoice total is entirely derived from metered events rather than a fixed subscription price. Both directions of error matter: double-counted events inflate what a customer's charged (a real customer-trust and dispute problem), while dropped events understate it (a real revenue-leakage problem) — deduplication addresses the first; a separate completeness check is needed to catch the second.

What reconciliation needs to actually prove

A usage-based invoice total that simply looks plausible isn't reconciled — reconciliation means the total can be traced back to a specific, replayable set of deduplicated events, so that when a customer disputes a number, the exact sequence of events that produced it can be reconstructed and shown. A metering pipeline that can only produce an aggregate total, with no way to replay the underlying event set that generated it, hasn't actually solved the reconciliation problem even if the number it outputs happens to be correct.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Worked example

A retried API call, deduplicated before it doubles a customer's bill

A customer's application calls a metered API endpoint, generating a usage event with event ID evt_8f3a2c and a billable quantity of 1. The network times out before the client receives a success response, so the client — following standard retry logic — resends the identical request. The API actually succeeded the first time, so this retry produces a second usage event, also carrying event ID evt_8f3a2c (generated deterministically from the same request), arriving 400ms after the first.

Without deduplication, both events would count, billing the customer for 2 units of usage for a single actual API call — a 100% overcount on this specific request. With a uniqueness constraint enforced on event ID at the storage layer, the second delivery of evt_8f3a2c is recognized as a duplicate of the first and discarded before aggregation, leaving exactly 1 billable unit recorded. At scale, across millions of metered events, this exact scenario recurring even a small percentage of the time is what accounts for measurable billing leakage if deduplication isn't enforced consistently.

Frequently Asked Questions

It needs to be deterministic from the request itself — generated by the client from stable request attributes, or assigned once and reused on any client-side retry — rather than freshly generated server-side on each delivery attempt, since a freshly generated ID on every attempt defeats deduplication entirely by making every retry look like a genuinely new event.

No — deduplication only addresses over-counting from duplicate delivery. A dropped event that never arrived at all needs a separate completeness check, typically comparing expected event volume from the source system against what actually landed in the metering pipeline.

Long enough to cover realistic retry delays, which can be well beyond an immediate retry — a client might not retry for minutes or longer depending on its own backoff logic, so a short dedup window (checking only the last few seconds) can still let a delayed retry duplicate through undetected.

Sources

How-to

How do I recognize revenue for usage-based/consumption pricing?

If the contractual right to bill corresponds directly to the value the customer received that period, ASC 606's right-to-invoice practical expedient lets an entity recognize revenue in the exact amount it has the right to bill for that period — no separate estimate of total contract value is required, as long as usage-based billing genuinely tracks value delivered.

Topic

Subscription & Usage Billing

This cluster covers how recurring and usage-based charges get billed, and how that billing connects to revenue recognition once the invoice is issued. It sits next to the Revenue Recognition cluster r…

Definition

How does subscription billing work end-to-end for a SaaS finance team?

A subscription ties a customer to a recurring price; the billing platform auto-generates an invoice each cycle, attempts payment, and if it fails, moves to past_due and runs a retry schedule before giving up. Revenue recognition is a separate final step: once invoiced, ASC 606 determines when that amount is actually allowed to hit revenue — usually not the moment the invoice was generated.

Comparison

What subscription billing software integrates with my ERP?

The platform name matters less than what data it actually exports: whether invoice-level detail includes what your ERP needs for ASC 606 allocation (service period dates, per-line SSP basis), whether proration and mid-term changes are represented explicitly rather than netted into one number, and whether multi-currency and dunning events are exposed as data, not just dashboard-only features.