Usage Billing and Quote-to-Cash
Synthetic benchmark Synthetic data: Parallax, a fictional API platform
A dbt and DuckDB warehouse for a usage-priced API business. It prices every metered token against the contract in effect that day, recognizes revenue as it’s consumed, and reconciles usage to invoices to payments.
- Status
- Write-up ready, code not public yet
- Relevant to
- Data and analytics, GTM Systems
Results · Synthetic data: Parallax, a fictional API platform
- Synthetic benchmarkSynthetic data: Parallax, a fictional API platform. Measured against a hidden answer key in that data. It shows the method works there, not a production result.for break detection against the hidden truth, at 100% precision (135 of 138)Synthetic benchmark
- Synthetic benchmarkSynthetic data: Parallax, a fictional API platform. Measured against a hidden answer key in that data. It shows the method works there, not a production result.run-rate ARR, with Enterprise consuming 32% above commitSynthetic benchmark
- Synthetic benchmarkSynthetic data: Parallax, a fictional API platform. Measured against a hidden answer key in that data. It shows the method works there, not a production result.data-quality SLAs passSynthetic benchmark
- Implementation factA fact about what was built and tested, not a business outcome.in the dbt build, all passing in about 2 secondsImplementation fact
At a glance
- Question
- Does every invoice match the usage and the contract in effect that day, and where it doesn’t, why not?
- Data
- Parallax, a fictional usage-priced API platform I generated, with billing defects injected into a hidden truth file.
- Compared with
- A second, independent revenue ledger written in plain Python, compared with the warehouse on all 4,551 account-months.
- How it was tested
- Re-price each account-month several ways, label each break by the first explanation that reproduces the invoice, and score the labels against the truth file.
- Result
- Break detection found 135 of 138 planted breaks (97.8% recall) with no false positives.
- What it doesn’t show
- The detector and the defects were designed together, so the precision shows consistency with this generator, not with a real billing system.
The problem
In usage pricing, revenue is tokens × a price that depends on the date, the model, the contract version and whether the customer was grandfathered. Seat-based metrics don’t cover commits and credits, a mid-period price change or billing reconciliation.
What I built, in detail
- A seeded generator for Parallax, a fictional API platform, exported the way Salesforce, CPQ, metering and a billing platform would, with defects injected into a hidden truth file.
- Point-in-time rating against versioned price books and contracts, prepaid commit and credit drawdown, and consumption revenue with breakage.
- A reconciliation that re-prices each account-month several ways and labels every break by the first explanation that reproduces the invoice.
- A second, independent revenue ledger in plain Python, compared with the warehouse on all 4,551 account-months.
How I checked it
- The first scoring run found 322 false missing-invoice breaks. They came from a generator bug, not the SQL.
- The three remaining misses are listed with their cause instead of tuning the rules to the test set.
Limitations
- The detector and the defects were designed together, so 100% precision shows consistency with this generator, not with a real billing system.
Stack
dbt, DuckDB, SQL, Python, numpy, pandas, Chart.js, GitHub Actions