Usage-Based Revenue Recognition

Usage-based revenue — API calls, transactions, data volume — is recognized as the customer consumes. This is the "right to invoice" practical expedient under ASC 606: if you have the right to invoice the customer for an amount that corresponds directly to the value transferred, you can recognize revenue at the invoiced amount. This simplifies recognition for pure usage models. But hybrid models (base fee + usage) require splitting the fixed and variable components and applying different recognition patterns to each.

1. Pure Usage (Pay-as-You-Go) Recognized as consumed. Customer uses 10,000 API calls at $0.01 each in March — recognize $100 in March. No deferred revenue, no upfront recognition. The simplest pattern but the most volatile from a revenue predictability standpoint.
2. Committed Usage (Prepaid Credits) Customer prepays $50K for credits consumed over 12 months. Recognition depends on whether unused credits expire. If they expire: recognize ratably over the term (the customer is buying access, not specific credits). If they roll over: recognize as consumed (the customer is buying specific units). The expiration policy determines the accounting treatment.
3. Hybrid (Base + Overage) The base fee is a separate performance obligation recognized ratably. Usage above the included threshold is a separate variable consideration recognized as consumed. A $10K/month platform fee with $0.01/call above 1M calls has two recognition streams: $10K ratable monthly, plus overage recognized in the month consumed.