Customer prepaid wallets and stored-value credits versus revenue

Platforms that let customers prepay into a wallet or purchase stored-value credits for future usage receive cash before any performance obligation is satisfied, so the prepayment is a contract liability, not revenue, until the credits are consumed, expire, or a reliable breakage estimate justifies earlier recognition; treating the top-up itself as revenue overstates current-period results and hides a real liability owed back to customers in the form of future service.

Is the initial cash receipt from a wallet top-up or stored-value purchase recognized as a contract liability rather than revenue, since no service has yet been transferred? Is there statistically credible historical redemption data across a large, stable customer base to support a reliable breakage estimate? Do unused balances legally escheat to the customer (requiring a refund liability) or to the entity (supporting breakage recognition), and does this vary by jurisdiction?

1. Recognize the initial cash receipt from a wallet top-up or stored-value credit purchase as a contract liability, not revenue, since no good or service has yet been transferred to the customer.
2. Recognize revenue only as the customer draws down credits to pay for actual services rendered, at the point or over the period the underlying service performance obligation is satisfied.
3. Assess whether breakage (credits that customers are not expected to ever redeem) can be reliably estimated, based on sufficient historical redemption data across a large enough customer base with stable behavior patterns.
4. If breakage can be reliably estimated, recognize the expected breakage amount as revenue in proportion to the pattern of actual customer redemptions (i.e., as a consistent overlay applied as other credits are redeemed), not all at once and not only upon formal expiry.
5. If breakage cannot be reliably estimated (e.g., a new program with limited redemption history, or a highly heterogeneous customer base), recognize breakage revenue only when the likelihood of the customer exercising its remaining rights becomes remote.
6. Reassess the breakage estimate periodically as redemption experience accumulates or the customer base composition changes, adjusting the estimate prospectively.

Measure the contract liability at the full amount of cash received for unredeemed wallet or credit balances, reduced as revenue is recognized on redemption. Measure breakage revenue, where reliably estimable, as a percentage of the total prepaid balance derived from statistically credible historical redemption patterns (e.g., the proportion of balances historically left unredeemed), applied proportionately as actual redemptions occur rather than as a single upfront adjustment. Reassess the breakage percentage at least annually, or more frequently if redemption behavior shifts materially (e.g., following a change in the customer base or platform pricing), and true up the estimate prospectively.

Disclose: the contract liability balance for unredeemed wallet or stored-value credit balances, presented separately where material; the accounting policy for recognizing revenue on redemption and for breakage; whether breakage is reliably estimable and the basis for the estimate, or, if not, the policy of recognizing breakage only when exercise becomes remote; significant changes in the breakage estimate during the period and their effect on revenue.

• Recognizing the full cash received as revenue at the point of wallet top-up rather than as a contract liability, overstating revenue before any service has been delivered
• ignoring breakage entirely and only ever recognizing revenue on actual redemption even when a mature, statistically credible redemption history reliably supports an earlier proportionate breakage estimate
• recognizing breakage revenue as a single lump-sum adjustment rather than proportionately as other credits are redeemed
• applying a breakage percentage derived from a small or unrepresentative customer sample to the entire wallet balance population
• failing to update the breakage estimate as the customer base grows or its behavior changes, relying on stale assumptions from an early, unrepresentative period.