How teams replace spreadsheets with billing that runs itself.
Illustrative scenarios built from how usage-based companies typically use Kribana — not verified customer accounts. Company names below are generalized to an industry descriptor rather than invented.
Usage lived in a data warehouse, commitments lived in a spreadsheet, and invoices were assembled by a script that broke every time a contract changed shape. Teams in this spot often call it 'invoice week' for a reason: someone spends the first few days of every month reconciling three systems that were never meant to agree with each other by hand.
The pricing itself wasn't the hard part — a committed volume of inference capacity, billed monthly, with metered overage once usage crossed the commit. The hard part was that commit tracking lived nowhere near the usage data. Finance would ask how close an account was to its commit, and the honest answer was a guess updated once a month, not a number anyone could check in real time.
How it works nowMoving usage events into Kribana's ledger means commitments, overage rates and invoice assembly all read from the same source of truth — no reconciliation step left to break. Every inference call lands as a usage event, gets matched against the account's committed volume in real time, and once that commit is exhausted the same event starts accruing at the overage rate automatically.
Commit tracking updates the moment usage happens, not once a month. An account approaching its ceiling shows up days or weeks before the shortfall would otherwise surface at renewal — turning what used to be a surprise into something the account team can act on early.
What changedInvoice week stopped being a fire drill. Invoices generate automatically at period close instead of being hand-assembled from three disagreeing sources, and the engineering time that used to go into patching the invoicing script now goes toward the product. For hybrid commit-and-overage pricing specifically — the model most inference-capacity sellers eventually land on — having commitments, usage and invoicing share one ledger removes an entire category of reconciliation bugs that only show up when a contract's shape changes mid-cycle.
There's a second-order effect too: contract changes stopped being an engineering event. When a customer renegotiates their commit or asks for a different overage rate, that's a configuration change against the same ledger, not a redeploy of a script three different people are afraid to touch. The team that used to dread every contract amendment because it meant another pass through the invoicing script now treats a repriced contract as routine.
“We weren't scared of complex pricing. We were scared of the spreadsheet that made it work.”