Use case
A credit ledger is not a spreadsheet of remaining units
Definition
A credit ledger is the financial system of record for prepaid credits: grants, burns, expiry, refunds, rate changes, and the journal entries those events require. It answers how many credits remain and what that is in revenue from the same history. Lucius ingests credit events from your product; the product stays the operational wallet; Lucius produces deferred revenue, recognised revenue, breakage, and unbilled usage as deterministic outputs.
See a credit ledger workflow
We'll take one real customer balance — purchase, burns, a price change, an expiry — and show the journal entries.
The problem
- Most companies have a product wallet and a finance spreadsheet. Neither is a ledger.
- When the unit price changes, old grants and new grants get mixed. Revenue is wrong in a way nobody notices until audit.
- Negative balances, rollovers, and expiry rules are treated as edge cases. In AI and usage businesses they are the business.
How Lucius solves it
- Lucius ingests credit events from your product (API, webhook, CSV). Your product stays the operational wallet. Lucius produces the accounting.
- Each purchase is a grant with a frozen rate and optional expiry. Burns deplete FIFO. The same events always replay to the same books.
- Deferred revenue, recognised revenue, breakage, and unbilled usage are outputs of the ledger — not a monthly model.
Workflow
- 1
Connect credit events
Purchases, burns, expiry, refunds, opening balances. Idempotent. Append-only.
- 2
Issue grants
Each top-up freezes its own conversion rate and expiry.
- 3
Burn FIFO
Consumption hits the oldest active grant first, so attribution and expiry stay deterministic.
- 4
Post the accounting
Every event has a debit and a credit. Corrections never overwrite history.
- 5
Read remaining units and remaining dollars
Two balances, both true, because they measure different things.
Example data flow
| From | To | What happens |
|---|---|---|
| Purchase event | Grant | Units, dollars, rate, and expiry are frozen on the grant. |
| Burn event | Grant depletion + revenue | FIFO burn releases deferred revenue at the original grant rate. |
| Expiry event | Breakage | Unused units on that grant close; the liability ends. |
| Negative burn | Unbilled revenue | Over-consumption is a contract asset until the next top-up. |
Frequently asked questions
What is credit ledger software?
Credit ledger software treats prepaid credits as financial state, not as a wallet UI plus a finance spreadsheet. It records grants, burns, expiry, refunds, and rate changes as events, and produces the journal entries those events require, so remaining units, remaining dollars, and the GL do not have to be reconciled by hand.
Does Lucius replace our in-product credit balance?
No. Your product remains the source of operational balances. Lucius is the accounting system that consumes credit events (API, webhook, or CSV) and outputs the correct financial treatment: deferred revenue, recognised revenue, breakage, and unbilled usage. The same events always replay to the same books.
Why not just recognise revenue when credits are sold?
Because you still owe the customer the unused units. Selling credits is a liability until they are consumed or expire. Recognising the cash as revenue on day one misstates both the P&L and the obligation, and it gets worse the first time the unit price changes across grants.
Can this sit next to Stripe and QuickBooks?
Yes. Land-and-expand is the usual path: Stripe collects, your product burns, Lucius accounts, and the existing GL can remain during rollout. Full-stack replacement is the other path once credit events, invoices, and reporting already share one maintained state.
See a credit ledger workflow
We'll take one real customer balance — purchase, burns, a price change, an expiry — and show the journal entries.
See a credit ledger workflowOr explore the stateful ledger — Lucius's financial system of record.