Usage Meter Reconciliation

A usage-based plan charges according to a measured activity, such as API requests or data processed, so the product records actions while a billing meter aggregates them, and reconciliation checks whether the billed quantity reflects the qualifying actions. Start with the contract definition, specifying which events count, the unit, exclusions, allowance and billing period, because a system count without a commercial definition cannot settle a dispute.

Then trace each event from origin to bill with a customer identifier, event time, unit and unique reference as appropriate, mapped to the billing meter. Stripe's meter documentation describes aggregating usage events over a billing period using methods such as sum, count or last value, and the selected method changes the result and must fit the actual price rule.

Define the time zone and cutoff, since an event near midnight can fall in one period in the product log and another in billing. Check duplicate delivery, because a retry after a network error can resend an event, and use suitable idempotency controls and unique references so a customer is not billed twice.

Check missing events and separate gross from billable activity. A failed data pipeline or delayed batch can omit valid usage, while internal tests, reversed events and included allowances may reduce the chargeable quantity, so document each exclusion.

A simple reconciliation difference is source-system qualifying usage minus metered qualifying usage, so if the source shows 12,400 eligible requests and the meter shows 12,360 for the same period, the difference is 40 requests. That number does not identify a cause, so investigate mapping rules, timing, retries and missing customer IDs rather than adjusting an invoice just to make totals match.

Reconcile by customer and plan, because a company-wide total can look right while one customer is underbilled and another overbilled, and watch unit conversions where a source counts bytes while billing uses gigabytes. Decide when invoices freeze and how legitimate late arrivals are handled under the contract, and leave an audit trail for any corrected or cancelled event.

Validate first and last events, since boundary cases often expose a cutoff error, and test aggregation with known examples, as sum, count and last-value rules can produce different quantities from the same events. Once quantities match, compare the rated amount, because tiered pricing, minimum commitments and free allowances may still change the charge.

Quantity reconciliation is one stage, not a full invoice audit, and a meter feeds billing calculations while accounting timing and revenue recognition policy may differ. Assign exception ownership so that product engineering owns missing source events and billing operations own mapping and invoice corrections.

Preserve evidence for disputes, measure recurring issues after releases by recording cause codes, and review plan migrations, since changing the meter or price mid-cycle can split an allowance or create overlap. For owners, usage meter reconciliation protects customer trust and recurring revenue, and the right comparison matches the same events, customer, units, rules and time window.