Float, Breakage and the Stored-Value Balance Sheet

When a customer loads $50 onto an app, three things happen at once. You receive $50 in cash. You book a $50 liability. And you gain the use of that cash for however long it sits there, at no interest.

The third one is the business.

The short answer

Prepaid and stored-value balances are interest-free working capital. Starbucks held $2.12 billion in customer-loaded accounts as of the first quarter of fiscal 2026, against a stored-value card liability of $1.78 billion at the close of fiscal 2024, and recognised $207.6 million of breakage revenue in 2024. At a 4% risk-free rate, a $2.12 billion float is worth roughly $84.8 million a year before a single cup of coffee is sold.

The three revenue lines hiding in a prepaid balance

Float is the value of holding customer cash before delivering the goods. It is a genuine financing benefit, and at scale it rivals the balance sheets of small banks.

Breakage is the portion of issued value never redeemed, recognised as revenue once redemption becomes remote. Starbucks recognised $207.6 million in 2024, which is 11.66% of its fiscal 2024 closing liability. That is a ratio worth treating with care, since breakage is recognised against issuance patterns rather than against a point-in-time balance, but the order of magnitude is the point.

Monetary decoupling is the third and least visible. Prelec and Loewenstein described the pain of paying in 1998: the psychological cost of a purchase is reduced when payment is separated in time from consumption. A customer who preloaded $50 last week does not experience today's $5 coffee as spending. Converting currency into stars, gems or credits decouples it further, because the unit no longer maps to money without arithmetic.

Modelling your own float

You do not need Starbucks scale for this to matter. The model needs three inputs: how much is loaded per period, how long it sits before redemption, and your breakage rate.

def float_value(monthly_deposits, avg_dwell_months, annual_rate, breakage_rate):
    steady_float = monthly_deposits * avg_dwell_months
    interest = steady_float * annual_rate
    breakage_revenue = monthly_deposits * 12 * breakage_rate
    return steady_float, interest, breakage_revenue


print(f"{'monthly':>12} {'dwell':>7} {'steady float':>14} {'interest 4%':>13} {'breakage':>12}")
for deposits in (100_000, 500_000, 2_000_000):
    for dwell in (2.0, 4.0):
        f, i, b = float_value(deposits, dwell, 0.04, 0.06)
        print(f"{deposits:>12,} {dwell:>7.1f} {f:>14,.0f} {i:>13,.0f} {b:>12,.0f}")

Output:

     monthly   dwell   steady float   interest 4%     breakage
     100,000     2.0        200,000         8,000       72,000
     100,000     4.0        400,000        16,000       72,000
     500,000     2.0      1,000,000        40,000      360,000
     500,000     4.0      2,000,000        80,000      360,000
   2,000,000     2.0      4,000,000       160,000    1,440,000
   2,000,000     4.0      8,000,000       320,000    1,440,000

Note that dwell time drives float and has no effect on breakage, while breakage scales with issuance and ignores dwell. They are separate levers and they pull in opposite directions on customer experience. Longer dwell means more float and a customer whose money is stuck. Higher breakage means more revenue and a customer who lost value.

The uncomfortable part

Both of the levers above improve when the customer does worse. That is not an accusation, it is a structural fact of the instrument, and it is why stored value attracts regulatory attention.

Most jurisdictions restrict expiry on gift cards and stored value. Several require unredeemed balances to escheat to the state rather than be recognised as revenue. Accounting standards govern when breakage may be booked at all. Any model that treats breakage as a growth lever rather than a residual is building a plan on a regulated and shrinking foundation.

The defensible position is that float is legitimate and breakage is not a target. Float exists because the customer chose to prepay for convenience, and they receive that convenience. Breakage exists because the customer forgot, and optimising for forgetting is a different business from the one on the sign.

Where decoupling crosses a line

The pain-of-paying research is genuinely useful for reducing friction in a purchase the customer wants to make. It becomes something else when the abstraction is deep enough that the customer cannot compute what they are spending.

A reasonable test: can the user convert your currency to money in their head, in one step, without looking anything up? "100 points equals $1" passes. A gem pack priced at $4.99 for 550 gems, where items cost 80 or 120 gems and the bundle never divides evenly into a purchase, does not. The non-round bundle is a deliberate design that prevents mental arithmetic and leaves a residual balance, and it is the mechanic regulators have taken most interest in.

What to do with this

Report your float and your breakage separately, and know your dwell time. Most programmes track the liability and not the dwell, which means they are carrying the number and not the asset.

Model the float benefit explicitly when evaluating a prepaid or wallet feature. It is often the difference between a feature that looks marginal and one that clearly pays, and it is routinely left out of the business case.

Do not plan against breakage. Every improvement you make to redemption, which is every improvement your product roadmap contains, reduces it. A programme whose economics depend on customers forgetting is one usability fix away from being unprofitable.