Usage billing with late events

See how a delayed event should move through the system

Late usage should trigger a visible correction path instead of a hidden edit to a closed invoice.

Keep raw usage as history, not as a mutable total

Persist raw usage as immutable events. When an event arrives late, it should feed the same computation path as everything else, just later in time.

• Require a stable event id, or derive a deterministic hash, and dedupe on ingestion.
• Store the full payload for audit, replay, and support review.
• Record ingestion time separately from the event’s effective time.

Define recomputation rules before the first exception

Pick a window model and decide how far back the system is allowed to recalculate. In practice, teams usually combine deterministic recomputation with explicit adjustment artifacts.

• Deterministic recomputation: the same source events should always produce the same rolled-up result.
• Invoice finality: once an invoice is issued, delayed usage should create a visible correction, not a hidden edit.
• Evidence: keep a record of what changed and why so finance and support can review it later.

Protect the money path with a few non-negotiable rules

• Use idempotency keys for any money-moving operation such as charge, refund, or invoice finalisation.
• Ensure each event contributes at most once to a given window calculation.
• Keep issued invoices immutable and emit corrections as separate artifacts.
• Make every billed line traceable back to its source events.