Start with the right mental model
Raw usage is durable history. Rollups, invoice-period totals, and reconciliation views are derived outputs. That distinction is what makes delayed events fixable without rewriting the past.
How usage totals stay correct when events arrive late
Invoice correctness comes from keeping raw usage as immutable history and treating period totals as derived outputs that can be recalculated when reality changes.
Ingest immutable events with tenant, meter, source id, effective time, and ingestion time.
Aggregate by day, week, or month with a clear late-arrival buffer before treating totals as final.
Recompute invoice-period usage deterministically when backfills or delayed events land.
Keep reconciliation artifacts per period so support and finance can see why a number changed.
Use a model that stays fair after the invoice closes
- Store raw usage events immutably.
- Aggregate into billing windows with a short late-arrival buffer before treating totals as final.
- Allow deterministic recomputation when delayed events arrive.
- Keep reconciliation artifacts for every invoice period.
Decide the correction policy before operations need it
Decide what happens when an event arrives after an invoice has closed: credit note, next-invoice adjustment, or a controlled reopen. The implementation should enforce that policy instead of inventing one during an incident.
Keep reading on the site, or start the guided email sequence if you want the same lessons delivered in order.