Usage-Based Pricing Infrastructure: Credits, Drawdown, and Revenue
By Formance Staff
Product
Embedded Finance
Ledger
Loading article content
Loading table of contents
Loading author
_FORMANCE STUDIO/
Build the ledger in Formance Studio
Open Formance Studio and load the AI usage billing template. It scaffolds the five accounts, the Numscript burn and refund transactions, and the query templates shown above. It then validates the schema against a live ledger transaction before you ship a line of production code.
A retried webhook subtracts from a customer's balance twice, but the payment processor's total does not match the sum of open credit balances. The auditor then asks which usage events moved which dollars out of the liability account, but no one from the engineering or financial teams can answer.
The IMF's April 2026 note on agentic AI and payments flags the tension between probabilistic AI behavior and the deterministic requirements of payment infrastructures. Without a connection between the two, it's difficult to establish a consistent flow of expenditure and usage.
Usage-based billing infrastructure for AI credits keeps probabilistic AI behavior and the deterministic payment structures in sync. It tracks prepaid balances as customers spend them on inference and keeps the customer's wallet aligned with usage billing revenue on the finance side.
This guide covers why AI products converge on credits, and the ledger pattern that keeps wallets and revenue in sync.
Why AI products converge on credits for usage-based billing
AI products use prepaid credits for predictable cash on day one, flexible consumption for variable inference spend, and psychological pricing that mirrors mobile, cloud, and gift card models. These dynamics make credit-based pricing the default shape of AI monetization.
Predictable cash on day one
Predictable cash arrives on day one because prepaid credit purchases settle before the service is delivered, so working capital and the forecast improve immediately.
The cash received is booked as an asset, and the service the vendor still owes is booked as a deferred revenue balance until the credit is spent.
Consumption flexibility for variable inference
Consumption flexibility matters because inference spend rarely follows a straight line. Prepaid credits absorb weekly usage swings inside a single balance, so a heavy inference week does not trigger a contract amendment.
Without prepaid funds or credits, fixed forecasts break under real usage, and finance ends up renegotiating whenever usage runs above or below the original commit.
Psychological pricing that mirrors mobile and cloud credit models
Psychological pricing works because a visible, depleting credit balance gives customers a sense of control that an open-ended usage bill never does. It mirrors mobile data plans, cloud credits, and gift cards, which customers already trust as budget-safe units.
Product familiarity turns a variable-cost inference call into a draw against a known pool rather than an open-ended charge customers can't predict until the invoice arrives.
All three models give the customer the same signal: a finite bucket the user watches deplete without being billed at month-end.
The accounting reality of usage-based credits that nobody explains
Prepaid credits are a liability until the service is delivered, and most billing stacks store this as a single number, which is why the accounting breaks the moment an auditor asks for history. Refunds reverse that liability, burns earn it, expirations close it out, and promo grants stay tagged separately from it.
Prepaid credits are a contract liability until service transfers
Prepaid credits are a liability from the moment payment lands until the service is delivered. Each time the service is delivered, a posting moves value between accounts.
A single number in a database column cannot keep that history. It cannot tell you which event moved which amount, cannot be reversed cleanly, and it cannot prove the closing balance.
Refunds reverse the liability, but they don't delete it
A refund is an inverse of a transaction. A refund liability is measured and reported separately from the liability it came from, because it represents the customer's conditional right to money back. It is not an obligation to deliver a service.
That separation has to show up in the posting logic. A refund moves value out of the customer's available balance account into a distinct pending refund account, and does not reverse the original deposit.
Only when the refund actually settles, once cash leaves the business, does a second posting move that value. The two postings, the two timestamps, and the chart of accounts must show a refund was requested before it shows one was paid.
Revenue is earned as credits burn
Payment receipt moves value into the customer's available balance account, and each metered burn moves value from the available account into a usage revenue account.
Both movements are postings, not database updates, so the history the auditor needs is there by default. For inference-priced products, this burn logic is what makes token accounting work at the unit-economics level.
Breakage postings preserve the expiration audit trail
When credits expire, the remaining balance moves through the account finance chose for its breakage policy, rather than quietly disappearing.
The policy can either track how customers use their credits as they go, or wait until it is clear the remaining credits will never be used.
Promo grants need distinct treatment from paid credits
Promo credits carry no cash, so they are tagged separately to keep them out of the paid-credit liability.
Formance's Assets Coloring separates promo units from paid units without creating a new asset type, and it automatically spends promo credits before paid ones.
How balance drift occurs across metering, billing SaaS, and revenue spreadsheets
Balance drift happens because metering code, billing SaaS, and revenue spreadsheets each hold their own version of the same number, with no event-level posting tying them together. The same customer usage produces three different totals depending on which one you query.
Metering code drift between the inference path and billing system
Metering lives in application code, and when the code sends usage events only once a week, unit conversions and field names fall out of sync with the billing system.
When metering breaks, customers can get billed for far more than they actually used, and it often takes hours for anyone to catch it.
Customer-facing wallet drift in billing SaaS and database columns
The customer-facing wallet is usually a cached number in a billing SaaS or a database column updated by metering webhooks, and it can change shape under the customer without notice.
In 2025, Cursor replaced its Pro plan's fixed 500 fast responses per month with a $20 credit pool billed at application programming interface (API) rates, then issued a public apology on July 4, 2025.
When a wallet-drift occurs under the customer without a stable ledger definition, trust breaks before the invoice even arrives.
Revenue roll-forward drift in the controller's monthly spreadsheet
Revenue drift starts in the controller's monthly spreadsheet. It pulls totals from the billing SaaS and the payment processor, while the enterprise resource planning (ERP) system supplies the accounting records.
The result is three balances with three ways to query them, and no posting that ties them together at the event level.
The ledger pattern: wallet and revenue derive from the same double-entry log
Usage-based billing infrastructure works when the wallet the customer sees and the revenue finance reports derive from the same double-entry log, and each burn recognizes its own revenue atomically. A single log as the system of record keeps prepaid AI credits, drawdown, and revenue recognition in sync across product and finance.
The pattern rests on five accounts that hold the balances, an idempotent burn posting, and append-only handling for expiry, refund, and correction.
Five accounts and five states
A prepaid AI credit wallet uses five accounts, plus a bank account for payment receipts and refunds. A credit moves through five states, each defined by the posting that moves it:
1Available: payment moves from the bank account into available.
2Reserved: a hold moves from available into reserved while a request is in flight.
3Consumed: the metered amount moves from available (or reserved) into the usage revenue account.
4Expired: any remaining balance moves out of available under finance's breakage policy into the breakage revenue account.
5Refunded: the unused amount moves from available back to the bank account, with a linked posting pointing to the original purchase. Partial refunds only reverse the unused portion, so the already-spent portion stays recognized in the period it was delivered.
Every number the wallet displays is a read across these five accounts.
One burn posting per metering window
Each closed metering window produces one posting from available to the usage revenue account, keyed by an idempotency key tied to the meter batch ID.
The transaction is written in Numscript, Formance's purpose-built language for describing financial transactions. It shows a move of $12,400.00 from Acme's usage against their prepaid balance:
A second delivery with the same batch ID writes no new posting, and reusing the same ID with different amounts is rejected.
Duplicate-safe postings need this check enforced at write time. Storing the ID in metadata alone is not enough.
Corrections append and should never mutate
Expiry, refund, and correction events each write a new posting instead of changing an old one.
Expiry moves the remaining balance from available into breakage revenue, keyed on the purchase ID. For refunds, a new transaction writes from available back to the bank account, with metadata pointing to the original receipt.
Corrections take the form of a reversing posting plus a correct one, and both stay in history. Idempotency on the purchase ID means a scheduler firing an expiry job twice still produces one posting.
What to look for in usage-based billing infrastructure?
Four properties determine whether credit-based pricing SaaS infrastructure holds up in an audit for Accounting Standards Codification (ASC) 606: event-time burning, sufficient-balance checks, separate revenue accounts by type, and append-only history.
1. Event-time burning with bi-temporal timestamps for late-arriving data
Each burn uses the metered event timestamp, so the deferred revenue usage billing roll-forward reflects when the service was delivered, while the batch job timestamp stays separate.
Bi-temporality pairs the event's business time with the ledger's write time and protects against late-arriving data.
A cutoff query for September 30 returns what the ledger knew at close, and a settlement file arriving October 3 for a September event posts with a September effective date. It creates this query without rewriting what the ledger already showed on September 30.
Before a burn writes, the ledger checks that the account has enough balance, so the transaction either succeeds in full or fails cleanly.
Without this check, a partial drawdown can leave the wallet negative or the revenue account short, and neither state is reversible without a manual correction.
The $12,400 Acme burn above depends on that check. The ledger evaluates the balance and writes the posting in a single atomic transaction, so no partial state can leak to the wallet or the revenue account.
3. Separate revenue accounts by type: paid usage, breakage, and promo recognition
Paid usage and breakage go into separate revenue accounts, and promo consumption is tracked separately, so promo never inflates the paid-credit liability or the revenue roll-forward.
The deferred revenue roll-forward becomes a query over usage and breakage account movements between two cutoffs. Your ledger recognition is derived from those events, with the credit subledger feeding the summarized entries.
Recognition derived from controlled metering postings reduces manual-adjustment risk and preserves an event-level audit trail. However, it does not eliminate classification errors, upstream metering errors, or management override.
4. Append-only history proves the liability identity at any cutoff
Append-only history proves, at any point in time, that the money owed equals the money on the books. That identity check exists because ASC 606-10-45-2, as FASB defines it, treats a prepaid credit as an unearned liability until the service is delivered, so the ledger must prove the liability.
The sum of all source@customers:credits:available and @customers:credits:reserved balances equals settled prepayments minus recognized usage, breakage, and refunds.
A difference above tolerance opens an exception posting. Manual balance edits are blocked, so the exception posting becomes part of the history the auditor reads.
Formance is SOC 2 Type II and ISO 27001 certified, so the audit trail the Ledger produces meets the controls SaaS auditors already know how to check.
