Subscription & Usage Billing
Subscription and usage billing is the process of metering consumption, generating invoices, and reconciling the resulting revenue against what was recognized in the general ledger — with enough detail to satisfy an auditor that the billing system and the books agree. This cluster covers metering, billing-system-to-ERP reconciliation, and the deferred-revenue accounting that results.
What subscription and usage billing covers
This cluster covers how recurring and usage-based charges get billed, and how that billing connects to revenue recognition once the invoice is issued. It sits next to the Revenue Recognition cluster rather than inside it, because billing and recognition are genuinely separate systems answering separate questions: billing determines what a customer is charged and when; recognition determines when that consideration is allowed to hit revenue. A charge can be billed in one period and recognized over several, and getting that distinction wrong is where most of this cluster's diagnostic pages start.
Why usage-based billing is a harder recognition problem than flat subscriptions
A flat monthly subscription is fixed consideration: the price is known at contract inception, so ratable recognition over the service period is mechanical. Usage-based fees are variable consideration under ASC 606 — the amount depends on something that hasn't happened yet, which is exactly the uncertainty ASC 606's constraint on variable consideration exists to address. The standard permits recognizing a variable amount only to the extent it's probable a significant reversal won't occur once the uncertainty resolves, which means usage-based revenue recognition has to be re-estimated as actual usage comes in, not set once at contract signing the way a flat subscription's schedule can be.
Where this breaks in practice
Most of the breakage in this cluster isn't in the accounting rule itself — it's in the handoff between the system that meters or bills usage and the system that recognizes revenue against it. A usage event that's recorded but never billed, a billing run that fires before the period's usage is fully in, or a billing system and an ERP that simply disagree on what a customer owes, all produce the same downstream symptom: revenue that doesn't tie to what was actually billed. The pages in this cluster work through those specific handoff points rather than restating the ASC 606 mechanics already covered under Revenue Recognition.
What's in this cluster
This cluster is new and starts with three pages: how subscription billing works end to end for a SaaS finance team, what to look for in ERP-integrated billing software, and how to meter and reconcile usage-based billing accurately. More gets added as billing-specific questions come in — for the underlying revenue recognition mechanics this cluster assumes, see the Revenue Recognition hub.
How does subscription billing work end-to-end for a SaaS finance team?
Subscription billing starts with a contract or pricing plan, generates recurring invoices on a defined schedule, collects payment, and posts the resulting cash to the AR subledger. The finance complexity is on the ledger side: billing and collection are separate steps from revenue recognition — a subscription invoiced up front creates a receivable and deferred revenue; cash arrives when the invoice is paid. Recognition is recorded separately as each period passes.
How do you meter and reconcile usage-based billing accurately at period end?
Usage-based billing requires a metering system that records consumption at the event level, an aggregation step that converts events into a billable amount, and a reconciliation that proves the billed amount matches the metered amount — and that both match the revenue posted to the general ledger. Any gap between what was metered, what was invoiced, and what was recognized is an error that a billing audit will surface.
What billing platform integrates with an ERP for subscription revenue accounting?
Billing platforms differ in how much of the accounting they own: some generate invoices and leave posting entirely to the ERP; others manage the deferred revenue waterfall internally and send only summary journal entries. The right choice depends on whether your ERP can model your billing complexity or whether the billing platform is a better fit for revenue schedule management. The articles in this cluster document the specific integration patterns for the platforms Loopfour connects.
How do you automate the journey from usage data to a posted invoice?
A usage-to-invoice workflow reads metered consumption from a data table your product writes to, aggregates it against each customer's pricing tier, flags anomalous usage for human review, and raises the invoice for accounts that clear. The workflow records what data it read, what it calculated, and what it raised, so any discrepancy can be traced without reconstructing the calculation from scratch.
When does this not apply?
This cluster covers billing-to-ledger reconciliation, not the revenue recognition accounting that results. ASC 606 treatment — performance obligations, variable consideration, deferred revenue — is covered in the Revenue Recognition cluster. Cash application of subscription payments to open invoices is covered in Payment Reconciliation & Cash Application. If your subscription billing runs entirely within one platform that also handles the ERP-side ledger entries, many of these reconciliation steps may be internal to that system.
Frequently Asked Questions
Sources
Next step
Map the finance workflow with the most exposure and prove the automation path.
Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.
