2 min lesson
Reconciliation across the three views of usage
Make the call in this situation: "A usage event with occurred_at inside March arrives on April 5, after you've already issued and the customer has paid the March invoice. How do you handle it correctly?" Explain what supports it.
Step 1 of 3
Reconciliation across the three views of usageraw vs rated vs invoiced
Usage exists in three forms and they must agree. Raw is what the product emitted, rated is what the pricing engine charged and invoiced is what actually hit the customer's bill. Drift between any two is revenue leakage or an overcharge and you want an automated job that alerts on it rather than discovering it in an audit.
- Raw usage
- Sum of deduped events for the period. Ground truth of what happened.
- Rated usage
- What the rater priced. Should equal raw minus anything intentionally excluded.
- Invoiced usage
- What landed on the invoice. Should equal rated for the period.
Run raw → rated → invoiced as a scheduled reconciliation with alerting on drift. A non-zero, unexplained delta at any step is the leak you were hired to catch.
"I'd dedup on a producer-supplied event id, aggregate per meter, then rate against the contract's tiers and entitlements. For late events I never rewrite a closed invoice - I issue a credit memo or true-up and book the catch-up in the current period. And I'd run a standing raw-to-rated-to-invoiced reconciliation that alerts on drift, because that delta is exactly where revenue leaks."