The hidden cash problem: Post 3 of 10
1.3 Why Usage-Based Billing Breaks Traditional Invoicing
Short answer: Usage-based billing breaks traditional invoicing because the amount due is not known until usage data arrives, often late and from systems finance does not own. Finance ends up reconciling it in a spreadsheet before every invoice run.
Usage-based billing is now the default model for a large share of B2B SaaS. API platforms charge by the call and infrastructure tools by compute or storage, while data products bill per row processed or query run. Even seat-based products have started adding consumption charges on top of the base fee. It makes sense commercially, and it makes invoicing much harder than most teams expect.
Traditional invoicing assumes you know the billable amount when the cycle starts. With usage billing, the number doesn't exist until the cycle ends, and getting it right means pulling data from systems built to measure product behavior rather than feed a billing workflow.
How each model breaks differently
Each billing structure fails a little differently. In every case finance depends on product data it doesn't own, and that data rarely arrives on the invoicing schedule.
| Billing model | Where it breaks |
|---|---|
| Consumption / API calls | Raw event counts need deduplication and gap-filling before they map to a billable number. A missed ingestion window means underbilling. A double-count means overbilling and a dispute. |
| Seat-based with overages | Seat counts change mid-cycle. Reconciliation sits between HR systems, the product, and the contract, and usually belongs to nobody. |
| Milestone or event-based | Milestone completion lives in a project tool or CRM. Finance has no automated signal for when to trigger the invoice. |
| Hybrid (flat fee + usage) | Two data sources and two billing logics feed one invoice. The flat portion is straightforward. The usage portion inherits all of the above. |
The spreadsheet that owns your revenue
Most finance teams absorb this by building a reconciliation spreadsheet that tracks overages and usage figures by data source, along with the edge cases that need a manual adjustment before invoices go out. Keeping it current eats hours every cycle. Most AR automation tools, including some that advertise usage-based billing support, still need finance to enter inputs by hand and fix the errors the system can't handle.
Late invoices push payment out by the same number of days. Errors that make it through get disputed, which can add weeks to the collection cycle. And the finance team spends its time reconciling data exports, work a properly automated system would do without finance stepping in every billing cycle.
Up next: Post 4 looks at overdue AR differently, starting with why many late invoices aren't a collections problem at all.
Part of a 10-post series on where B2B AR loses cash, stage by stage.