Accrued Revenue Tracking in Usage-Based Billing Cycles
How to track revenue earned but not yet billed in consumption-based contracts.
A flat-rate subscription closes cleanly: the customer pays on the first of the month, the service period matches the invoice period, and revenue recognition is a formality. Usage-based billing breaks that alignment. Revenue accrues continuously, event by event, while the invoice arrives on a schedule, weekly, monthly, or at a true-up date, so at almost any point inside a billing period there is revenue the company has earned but has not yet billed, and that revenue sits nowhere on the balance sheet until someone puts it there. This is a built-in feature of charging for consumption, not a side effect of sloppy bookkeeping, and it gets harder to manage as usage volume grows, since the gap between what has happened and what has been invoiced scales with the product itself rather than with headcount or deal count. A contract that charges for consumption creates revenue the company has earned but not yet billed from the moment it takes effect, whether or not the finance team has built anything to track it. Every section that follows is really about how to close that gap, consistently, defensibly, and on time.
What accrued revenue means when the billing unit is consumption
Accrued revenue, in a usage-based contract, is the portion of consumption that has been earned but not yet invoiced. It has to show up as a current asset on the balance sheet, carried as accrued revenue or an unbilled receivable, matched by a credit to revenue on the income statement, and both entries have to be made at period-end even though no invoice exists yet. The estimate behind that entry needs real support, because auditors will test it, and the only defensible source for that support is the underlying event data, not a rounded guess carried over from last month. Once the invoice does go out, the accrued revenue asset reverses and a trade receivable takes its place, a two-step that creates reconciliation work whenever the billed amount doesn't match the earlier estimate. Prepaid credit arrangements run the entry in the opposite direction: cash received up front creates a deferred revenue liability, and that liability only converts to recognized revenue as credits are actually consumed. A credit-wallet product can therefore be carrying an accrued revenue asset for in-period usage not yet invoiced and a deferred revenue liability for prepaid credits not yet used, at the same time, on the same contract. Hybrid pricing, where a committed credit wallet sits alongside a postpaid overage component, puts both of these directions, accrual and deferral, into play on a single customer at once.
ASC 606 and IFRS 15 treatment of variable consideration from consumption events
Consumption charges count as variable consideration under both ASC 606 and IFRS 15, and that classification carries a specific obligation: finance teams have to re-estimate the transaction price every reporting period as new usage data comes in, not just at contract signing. That turns the accuracy of the underlying usage data into a compliance requirement rather than an internal operating preference. Deloitte has noted that ASC 606 demands more judgment than the standards it replaced, and consumption billing makes that judgment heavier still, since the estimate has to be rebuilt from raw event data every single period instead of read off a fixed contract line. What this means in practice is that an auditor asking for support behind an accrued revenue balance expects to see the usage log itself, the actual events, not a formula sitting in a spreadsheet. The five-step ASC 606 recognition model doesn't change shape for usage billing, but step five, recognizing revenue as performance obligations are satisfied, now requires "satisfied" to be defined at the level of the individual event rather than at the level of the invoice.
Where the accrual process breaks: the five failure points finance teams hit
Manual accrual workflows built around usage billing tend to fail in the same five places, and each failure pushes the revenue balance in one direction or the other, overstated or understated, often surviving all the way through close and occasionally into audit.
Late-arriving events cause the first failure. Usage generated near the end of a period may not land in the billing system before the close window shuts, so the accrual gets built on incomplete data, and when the missing events finally show up, the correction is recorded in the wrong period. This is a latency problem built into distributed systems, not a data quality defect, and it gets worse for AI-native products generating token-level events at high volume.
Duplicate and missing events cause the second. Duplicated events inflate the accrual; missing events understate it; and without idempotency controls in place, neither error becomes visible until a customer disputes an invoice or an auditor goes looking.
Contract term misapplication causes the third. The rating engine has to apply the right tier, the right discount, the right minimum commitment, and the right credit drawdown rule to every customer's events, and when finance staff apply those terms by hand from a spreadsheet copy of the contract, amendments and mid-cycle changes routinely produce incorrect accruals.
Credit wallet reconciliation causes the fourth. Prepaid balances need to draw down against the correct period's consumption, and a spreadsheet tracking those drawdowns separately from the actual event log will drift over time, leaving a deferred revenue balance that no longer matches what the billing system says is left in the wallet.
System disagreement at close causes the fifth. When the CRM, the billing platform, the ERP, and the accounting system each hold a different number, the first week of every close cycle gets spent reconciling those differences instead of actually closing the books, and the accrual, the entry that depends most on accuracy, ends up built last, from the shakiest data, under the most time pressure. The live video infrastructure company 100ms lived through a version of this directly: manual tracking of startup credits led to underbilling and invoicing errors, and once the process was automated, the invoicing errors disappeared and revenue went up.
The journal entry sequence when metering data feeds it directly
When real-time metering data feeds the accrual directly, the journal entries stop being a judgment call and become a query result. At period-end, before any invoice has gone out, the entry debits Accrued Revenue as a current asset and credits Revenue for the rated value of whatever consumption happened in the period but hasn't been invoiced yet. That number needs to trace back to the event log: which customer, which meter, which rating rule, which period produced it. When the invoice is actually issued in the following period, a new entry debits Accounts Receivable, recognizing that a real trade receivable now exists, and credits Accrued Revenue, reversing the asset booked the period before. If the billed amount ends up different from the original accrual, because events arrived late or a rate got corrected after the fact, that difference is usually recorded in the period the invoice goes out, but ASC 606 can require booking it back to the earlier performance period instead. The accuracy of the original accrual matters period over period, not just in the period it's booked.
Prepaid credit wallets run a parallel but separate sequence. When a customer buys credits, the entry debits Cash and credits Deferred Revenue. As those credits get consumed in each subsequent period, the entry debits Deferred Revenue and credits Revenue, drawn down by exactly the rated consumption amount for that period. If the usage data shows 8.3 million calls in a given period, the revenue schedule has to recognize exactly that figure, draw down exactly that much deferred revenue, and hold up when an auditor pulls the event log behind it.
What separates this from a manual, estimated process is that the billing system is ingesting events in real time and rating them against the contract as they arrive, so the period-end accrual is simply a query against that data rather than someone's best guess, and the same query that produces the accrual entry also produces the audit trail behind it. This exposes a gap in what might be called first-generation billing setups: a system built from a payment processor plus custom orchestration code can invoice a customer correctly and still fail to produce ASC 606-compliant revenue recognition, because invoicing and recognition are different jobs, and most of those earlier stacks only do the first one.
Metering architecture as the upstream constraint on accrual accuracy
Accrual accuracy is downstream of metering quality. A finance team cannot produce a reliable period-end accrual from an event pipeline that drops events, counts them twice, or delivers them hours after the fact, no matter how disciplined the accounting team is about applying the right journal entries.
Two architectures dominate production systems today. Event-driven streaming ingests usage with low latency and aggregates it in windows, and it's the right choice when near-real-time billing visibility matters and volume is high, since the accrual query can run at any point in the period against current data. Batch aggregation collects events in object storage and processes them in nightly jobs; it works fine when real-time visibility isn't required, but it means the period-end accrual is only as current as the last successful batch run.
Both architectures depend on idempotency and late-event handling, and without them the accrual built on top cannot be trusted. Idempotency has to guarantee that a usage event sent twice because of a network retry gets counted once, not twice, since without it duplicate events inflate the accrual directly. Late-event handling has to let the pipeline backfill events that arrive after a period closes without corrupting the invoice already issued or forcing someone to write a manual correcting journal entry.
AI-native products push this harder than most. Token-level events generated at inference speed can reach volumes that force pre-aggregation before the billing layer even sees them, and rolling a million per-token events into one hourly rollup per customer-meter pair doesn't cost any fidelity as long as the aggregation itself is lossless and auditable. Metering failures are revenue assurance failures, not just bookkeeping ones: over-billing erodes customer trust, under-billing loses revenue outright, and both appear in the accrual well before they appear in cash collected.
HubSpot's own product evolution shows how fast this complexity compounds at the metering layer. Breeze AI credits are priced per unit on top of seat pricing, with monthly inclusions that vary by plan, and the Customer Agent has been billed per resolved conversation under outcome-based pricing since April 14, 2026, after HubSpot repriced it that same month from a per-conversation to a per-resolved-conversation model. A metering layer supporting that structure has to track credit consumption, seat entitlements, and outcome-based resolution events all at once, and the accrual built on top of it has to follow all three simultaneously, not sequentially. That is the shape of the problem usage-based pricing creates: the accounting is only as good as the event data feeding it, and the event data is only as good as the pipeline built to carry it.
