1Context
Three systems, one invoice
Plans and trials lived in the product, overages in a spreadsheet, taxes in the accounting tool. Each pricing change required a release; finance reconciled invoices by hand every month.
2Challenge
Pricing couldn't move
- Numbers differed between product, spreadsheet and accounting.
- Proration and mid-cycle upgrades were calculated manually.
- Regional tax rules were hard-coded.
- Usage spikes and revenue leaks were noticed only after invoicing.
3What we build
A billing core with metered usage
- Event-based metering with idempotent ingestion and replay.
- Versioned plans: prices change without a release, existing customers keep their terms.
- Proration, trials, overages and regional tax as configuration.
- Connectors to payment providers and accounting; anomaly models flag unusual usage before the invoice goes out.
- # stack · models · guardrails
- metering: event-based usage over Kafka, idempotent ingestion, replayable
- ledger: double-entry, immutable postings, period close
- pricing: versioned plan catalog; proration and trials as rules, not code
- tax: region rules as configuration, validated against provider APIs
- anomalies: seasonal-hybrid ESD + isolation forest on usage series, pre-invoice gate
- connectors: Stripe / Adyen for collection, accounting export
4Outcome
Finance stopped reconciling by hand
One source of truth for revenue, pricing experiments in days instead of quarters, and leaks caught before they reach the customer.
0releases
per pricing change
3days
to launch a pricing experiment
100%
of usage anomalies flagged before invoicing
was: found by the customer
1ledger
for revenue
+4%
recovered revenue
overages & leaks billed, not missed
−12days
DSO
invoices out on time, no reconciliation lag