ML LABS designed and built the billing system behind HeartSciences' AI ECG platform — the cloud backend ML LABS engineered, which has reached clinical production in the US and the UK and keeps expanding. In it, per-unit fees across pricing categories, per-site monthly minimums, and annual spending caps are applied in a fixed order and flow into one invoice, with a calculation finance can trace. Its enterprise customers needed role-based finance access with auditable invoices; the system ran from deployment infrastructure through invoice PDF generation, deployed across three environments with self-service finance access.
The contracts it bills are not simple. There is a per-unit rate, a minimum under it so a quiet quarter does not sink the year, a cap over it so the customer's finance team can forecast, and categories switched on and off as the relationship changes. Assembled by hand once a month, under time pressure, usually in a spreadsheet, each invoice is a chance to be wrong in a direction the customer will find. This is the shape enterprise AI contracts converge on: three out of five SaaS companies now use some form of usage-based pricing (OpenView, 2023), and enterprise contracts are where it stops being a pricing page and becomes an engineering problem.
Contract Rules Applied In A Fixed Order
Every pair of pricing rules produces its own failure mode: an invoice that is technically defensible and commercially wrong. These are not edge cases. They appear on the regular cycle for the largest accounts, whose contracts contain all three dimensions at once. And the problem is not one of metering. A minimum, a cap, and a category toggle all land on the same invoice line, and the order in which they are applied changes the number that the customer receives. Off-the-shelf billing tools price one dimension well and two if they do not interact. The interaction is the product, and it is the part they do not build.
Take a schematic contract — illustrative, not a client's — to see the trap. A site carries a $10k monthly minimum, two billable categories, and a $100k annual cap on the rated total. In a quiet month, category A rates to $4k and category B to $3k. The rated total is $7k, so the invoice charges the $10k minimum. A naive engine then debits $10k against the cap, leaving $90k of headroom. But the contract says only the rated $7k reduces the cap, because the $3k top-up is a floor, not a consumption charge. Over a year of quiet months, that single misclassification hands the customer tens of thousands of dollars of cap headroom they never bought — or takes it away, which is worse, because they will find it.
Now disable category B mid-period for a renegotiation. The rated total drops to $4k, the minimum still applies, the cap contribution must be recomputed from category A alone, and no closed period may be re-rated. The bug surface is not arithmetic — it is sequencing and attribution: which dollar counts toward which limit, and in what order the rules apply.
Every processing event emits a billing event tagged with site, category, and timestamp. The metering layer captures, classifies, and aggregates those events by period and site, and the pricing engine applies the contract rules with the interactions made explicit rather than emergent. Billing events are treated the way payment systems treat idempotency (Stripe): a retry that double-counts an event is not a logging defect, it is an overcharge.
Dashboard And Invoice Show One Number
The billing dashboard shows the current period in near real time. The invoice shows the closed period. The two must match, and the architecture that makes them match derives both from the same reconciled dataset — deriving state from an ordered log of events (Fowler, 2005), not maintaining two independently mutable totals that agree only by luck. Automated reconciliation runs inside the billing cycle, and discrepancies above a threshold block the invoice from releasing until someone has looked at it.
A dashboard and an invoice that disagree are two systems computing the same number twice. The fix is not a better reconciliation report. It is one dataset with two renderings.
Pricing Changes Without A Release
Everything else in the pricing surface — new sites with their own minimums, renegotiated rates, category toggles per site, cap values — is configuration, effective at the next period boundary, with full change history for audit. That is the difference between a pricing change taking an afternoon and taking a release. It is the same property that lets the platform's search layer absorb a new AI output type without a deployment.
Invoices are generated as structured documents with summary totals, per-site breakdowns, and verification totals that prove the breakdown sums to the header. Finance teams reach them through role-based authentication with MFA: self-service access to invoices and dashboards without seeing anything operational.
Where Custom Billing Earns Its Cost
Invoices ship late because someone reconciles categories in a spreadsheet. The same customer disputes the same line item across consecutive cycles and gets a one-off credit rather than a rule fix. The dashboard and the PDF disagree by an amount large enough to argue about and small enough that nobody escalates it. When configuration changes are gated on deploys, and finance no longer trusts the dashboard enough to show a customer, the cost of the wrong abstraction has passed the cost of building the right one.
When Stripe Alone Saves More
Not every AI product needs custom billing. If pricing is one per-unit rate with no minimums, caps, or category splits, Stripe's metered billing handles it. The threshold is interaction, not volume. The moment two or more rules must be enforced on the same invoice line at once — a minimum that interacts with a cap, a toggle that interacts with both — generic tools stop saving work and start creating reconciliation work that recurs every billing cycle.
Metering, Rating, Invoicing Kept Apart
The architecture holds by separating three concerns that tangle in generic billing tools: metering is what happened, rating is what it costs, invoicing is what the customer sees. A pricing change should touch only rating configuration; a new site only metering.
Wiring a billing engine into a live AI platform is one contained workflow with a hard correctness bar and a finance team that notices every mistake, the shape an engineering partnership is built for: targets written into the SOW before work starts, then kept running by the person who built it. If your contracts have minimums, caps and toggles, the interactions are already priced into what you charge. They may as well be priced into what you bill.
References
- OpenView Partners. The State of Usage-Based Pricing: 2nd Edition. OpenView, 2023.
- Stripe. Idempotent Requests. Stripe API Reference.
- Fowler, M. Event Sourcing. martinfowler.com, 2005.
