When an enterprise customer funds a prepaid credit wallet, two things happen simultaneously: cash arrives on your balance sheet, and a deferred revenue liability appears. The wallet balance burns down each month as the customer consumes your product. When it hits zero, API calls fail. Tracking deferred revenue burn-down manually is one of the bigger close delays. Automated journal entry posting is how teams reduce your month-end close time on prepaid wallet models.

Most teams discover a wallet is running low from a support ticket. The customer’s engineers notice failed requests, escalate internally, and the vendor’s finance team is caught off guard. The top-up conversation happens under pressure, not as a planned cash-flow event.

The calculator above handles the math that makes reactive depletion predictable. Enter the wallet balance, monthly burn, and usage growth rate (the three variables that determine depletion timing), and see exactly when the wallet runs out, how the deferred revenue balance falls over six months, and what top-up revenue looks like over the next year.

The prepaid wallet model exists because it solves procurement problems on both sides of the transaction.

For the customer, it converts an unpredictable monthly usage bill into a single purchase order. Enterprise procurement teams are built around discrete approvals. A $50,000 PO for a credit wallet clears the same process as any other software purchase: budget holder approves, finance issues the PO, accounting cuts the check. The monthly variable billing that would otherwise require a new approval every month disappears. Spend is bounded by the wallet size.

For the vendor, the wallet model is attractive for the opposite reason: cash arrives upfront. The customer pays before a single API call is made. This improves cash flow materially compared to net-30 invoicing on monthly usage and eliminates the collections process for that customer entirely: there is no invoice to chase because the money is already in the bank.

The model also aligns with how AI spend is typically approved internally. Many enterprise AI deployments start as experiments with a fixed budget. A $50,000 wallet maps cleanly to “we are allocating $50,000 to evaluate this platform.” If the experiment succeeds and consumption grows, the wallet depletes faster than planned, which is actually the signal the vendor wants to see. High burn rates indicate adoption.

The risk is at the boundary. A wallet that depletes without warning interrupts the customer’s production workflows. Failed API calls at 2 AM do not feel like a billing issue to the engineering team on call. They feel like an outage. The vendor that let this happen has a trust problem, not just a cash-flow gap.

The Revenue Recognition Complexity#

Cash receipt and revenue recognition are decoupled under ASC 606 and IFRS 15, and prepaid wallets make that decoupling visible on every balance sheet.

When the $50,000 wallet is funded, the journal entry is: debit cash $50,000, credit deferred revenue $50,000. No revenue is recognized at that point. The performance obligation (providing API access as the customer consumes it) has not been satisfied yet.

As the customer burns through the wallet each month, the corresponding deferred revenue is recognized: debit deferred revenue, credit revenue. If the customer burns $8,000 in month one, $8,000 of deferred revenue becomes recognized revenue. The deferred balance falls to $42,000.

Finance teams managing a portfolio of prepaid customers must track four numbers per customer at any point in time: wallet funded, cumulative usage, deferred balance remaining, and recognized revenue to date. These four numbers must reconcile with the ERP at every month-end. For companies with dozens of enterprise customers each holding wallets of different sizes and burn rates, the reconciliation is not trivial.

The additional complexity is that burn rates are not static. A customer whose usage grows 5% per month will deplete a $50,000 wallet faster than a customer whose usage is flat, and both will deplete it faster than simple division predicts. The deferred revenue schedule needs to reflect actual consumption, not a straight-line estimate.

Enso’s revenue recognition handles this automatically: usage events post deferred revenue entries in real time, so the balance sheet is always current rather than updated in a manual reconciliation at month-end.

Why Usage Growth Makes Depletion Non-Linear#

The most common forecasting error is dividing the wallet balance by the current monthly burn rate and treating the result as the depletion date.

For a flat burn rate, this is correct: $50,000 ÷ $8,000/month = 6.25 months. But AI product usage rarely stays flat. A customer who integrates your API into a new workflow adds volume. A team that expands from one business unit to three triples the call count. Monthly growth rates of 5–15% are common in the first year of adoption.

At 5% monthly growth, the month-by-month burn looks like this:

MonthMonthly BurnCumulative Burn
1$8,000$8,000
2$8,400$16,400
3$8,820$25,220
4$9,261$34,481
5$9,724$44,205
6$10,210$54,415

The $50,000 wallet is exhausted partway through month 6, not at 6.25 months as flat-rate math predicted, and notably, the month 6 burn ($10,210) is 28% higher than month 1. By the time depletion is visible in the customer’s account, the burn rate is substantially higher than when the wallet was funded.

This compression effect is why time-based forecasting (when will the wallet run out?) is more useful than balance-based alerting (alert me when the balance hits $5,000). At 5% growth, a $5,000 balance threshold triggers at the right time one month, and three weeks too late the next quarter when the burn rate has grown.

Proactive Top-up Management#

The reactive scenario plays out the same way at most companies: the wallet hits zero, production breaks, someone files a ticket, the CSM calls the customer to apologize and explain, the customer’s finance team has to issue an emergency PO, and the top-up takes 5–10 business days to clear. Revenue is interrupted, trust is damaged, and the churn signal is already on the board.

The proactive scenario requires knowing the depletion date at least 30–45 days in advance. At that lead time, the CSM can initiate a renewal conversation framed as expansion planning (“your usage has grown 40% since you funded the wallet, so let’s make sure the next wallet covers your projected usage for the next six months”) rather than an emergency refill. The customer’s procurement team has time to issue a PO without an expedite request.

What makes proactive management operationally feasible:

  • Time-based thresholds, not balance-based. A $5,000 balance might be 3 weeks of runway in month 2 and 2 weeks of runway in month 8. An alert set to fire when projected depletion is 45 days away accounts for growth; a balance threshold does not.

  • Auto top-up for high-velocity customers. Enterprise customers with large, fast-growing wallets often prefer a contractual auto top-up: when the balance falls below a defined threshold, an agreed top-up amount is charged automatically. This eliminates the procurement lag entirely. The calculator’s “Auto Top-up Threshold” and “Top-up Amount” inputs model this scenario: you can see how many automatic top-ups a customer will trigger over 12 months and what the cash flow profile looks like.

  • Portfolio visibility. With 30 or 40 wallet customers, the CSM team needs a single view sorted by days of runway, not a manual query across each customer’s account. The most urgent accounts (shortest runway) belong at the top of the weekly pipeline review.

Using This Calculator for Portfolio Forecasting#

The calculator is most immediately useful at the individual customer level: paste in a specific customer’s wallet balance and burn rate before a QBR, confirm the depletion timeline, and frame the top-up conversation around projected runway rather than a reactive request.

At the portfolio level, the “Projected Top-up Revenue (12 months)” output is the finance input. Sum this figure across your wallet customer base and you have a cash flow forecast for top-up events. This is distinct from recognized revenue: a top-up is a cash receipt that adds to the deferred revenue balance; recognition happens as usage continues to draw that balance down.

The growth rate input is the most important lever for sensitivity analysis. Try the same wallet balance and burn rate at 3%, 5%, and 10% monthly growth. The depletion dates will diverge significantly, and the differences are material for cash flow planning. A customer whose usage is growing quickly is also your highest-value customer; their next wallet will need to be larger, and the timing of that conversation determines whether it happens on your terms or theirs.

For customers on auto top-up, the “Top-ups in Next 12 Months” count tells you how many cash receipts to expect from that customer over the year. Multiply by the top-up amount to get the total inbound cash, then model how that cash converts to recognized revenue month by month as the usage continues. This is the input your finance team needs to build a reliable deferred revenue forecast.

Frequently Asked Questions#

What is a prepaid credit wallet in AI billing? A prepaid credit wallet is a fixed dollar balance a customer buys upfront. Usage is deducted from that balance at the agreed per-unit rate. When the balance reaches zero, usage is blocked until the customer adds more credit. The model is common in API-first AI products where enterprise buyers prefer a single PO to an open-ended usage commitment.

How is deferred revenue calculated for prepaid wallets? When the customer funds the wallet, the cash hits your balance sheet but the revenue is deferred: it is a liability until you deliver the service. Revenue is recognized each period as usage occurs and the balance is drawn down. If a customer has a $50,000 wallet and burns $8,000 in month one, you recognize $8,000 of revenue and carry $42,000 as deferred revenue on the balance sheet.

What is a good auto top-up threshold? The threshold should give the customer enough runway to process an internal budget approval before the wallet runs out. For most enterprise customers, 30–45 days of runway at their current burn rate is the target. With an $8,000 monthly burn growing at 5% per month, the threshold that triggers a top-up 30+ days before depletion is roughly $9,000–$10,000.

What happens to deferred revenue when a wallet expires unused? Wallet terms typically include an expiry clause. If a customer funds a $50,000 wallet but only burns $20,000 before the contract expires and they do not renew, the $30,000 unearned balance may be recognized as breakage revenue (if the probability of redemption is reliably low) or refunded. ASC 606 requires judgment on breakage recognition, and finance teams should document the basis for their estimate.

How does usage growth affect depletion forecasting? Even modest compounding growth creates meaningful forecast error when ignored. A 5% monthly growth rate means month 6 burn is 34% higher than month 1. Over a 6-month wallet, the simple-division forecast (balance divided by starting burn) underestimates actual depletion by 8–12%. At 10% monthly growth the gap is larger. Always model burn rate growth, not flat usage, when setting customer expectations and top-up thresholds.