Category
Credit ledger: prepaid credits that actually tie to the books
Ryan Gralia
Founder, Lucius
A credit ledger is the accounting system for prepaid credits: purchases, grants, consumption, expiry, refunds, and negative balances, posted as deterministic journal entries. The product system remains the source of truth for unit balances. Finance needs the dollar effect of those events on deferred revenue, recognised revenue, breakage, cash, and what the company still owes customers. The diagnostic is whether product balances, the GL, and cash all tie. Lucius ingests credit events and maintains that financial treatment on a stateful ledger for AI and usage companies that sell credits.
Typical credit events are top-up, grant, burn, expiry, refund, and negative-balance consumption. A purchase creates deferred revenue; consumption recognises revenue against the grant; unused credits that expire become breakage; consumption beyond the balance creates unbilled revenue until the next top-up. Lucius does not operate the in-product wallet. It accounts for the events that wallet already produced, so customer liability, revenue, and cash can be reconciled.
Does product, customer balances, GL, and cash all tie?
A customer wires $500k for AI credits. Tomorrow, four systems each have an answer: the product wallet, the customer portal, the general ledger, and the bank. If they do not reconcile, finance is guessing what you still owe.
That is not a bookkeeping hygiene problem. It is missing architecture. Credits are a financial object with a lifecycle, not a memo on a Stripe charge.
Credit event lifecycle
Top-up -> Grant -> Burn -> Expiry / refund / negative balance -> Cash and GL
- Top-up: cash or processor settlement creates a grant and deferred revenue.
- Grant: units, dollar rate, and optional expiry stay attributable.
- Burn: consumption recognises revenue against the grant (FIFO when rates or expiries differ).
- Expiry: unused dollars become breakage, not silent leftover deferred revenue.
- Negative balance: usage past zero is unbilled revenue until the next top-up, not fake AR.
Where Lucius fits
Lucius is the accounting system for credit events, on the same stateful ledger that runs contract-to-cash and bank reconciliation. Product remains the wallet. Stripe remains the processor. The ledger is where those facts become deferred revenue, recognised revenue, breakage, and cash.
Related: usage-based billing accounting when you invoice consumption instead of (or as well as) selling a prepaid pool, and the stateful ledger for the architecture underneath.
When Lucius is right (and when it isn't)
Lucius is a strong fit when
- You sell prepaid credits, tokens, or usage pools that customers draw down.
- Product, billing, and the GL currently disagree on what you owe customers.
- You need breakage, FIFO grants, or negative-balance treatment that Stripe cannot model.
- You're an AI, API, or infrastructure company where credits are the commercial object.
A simpler tool may suffice when
- You only sell seats or flat subscriptions with no prepaid balance.
- Credits are a marketing coupon with no material deferred revenue.
- You need Lucius to operate the in-product wallet rather than account for it.
- You're pre-revenue and a lightweight ledger covers you for now.
Frequently asked questions
What is a credit ledger?
A credit ledger is the accounting system for prepaid credits. It records purchases, grants, consumption, expiry, refunds, and negative balances as journal entries. The product wallet still owns unit balances. The credit ledger owns the dollar treatment: deferred revenue on top-up, recognised revenue on burn, breakage on expiry, and unbilled revenue when a customer consumes past zero. Lucius ingests those events onto a stateful ledger so finance can see what the company owes customers without reconstructing it from Stripe, the product database, and a spreadsheet.
Does your product, customer balances, GL and cash all tie?
That is the diagnostic. Product knows units. The customer dashboard shows a remaining balance. The GL shows deferred revenue. Cash sits in the bank or processor. If those four numbers cannot be reconciled, you do not have a credit ledger. You have four systems that happen to mention credits. Lucius is built so credit events post once and those views stay aligned, with append-only corrections when something is wrong.
Does Lucius replace the product credit wallet?
No. The customer's product system remains the source of truth for credit units. Lucius consumes events from that system (API, webhook, CSV, or sync) and produces the financial treatment. We do not mint credits, price tokens inside the product, or operate the end-customer wallet. We account for what already happened so deferred revenue, breakage, and cash application are auditable.
How are prepaid credits recognised?
A purchase creates deferred revenue for the dollar amount collected. Consumption recognises revenue against the grant that is depleted (typically FIFO so expiry and rate changes stay attributable). Unused credits that expire become breakage. If a customer burns past zero, revenue is recognised against unbilled revenue until the next top-up settles that balance. Time-based recognition of a prepaid pool without consumption data is a different, weaker model.
See how Lucius accounts for prepaid credits.
Share how credits, billing, and the GL run today. We'll say whether a credit ledger on Lucius is a fit.