Use case
Your customer wired $500k for credits. What do you owe them tomorrow?
Definition
Prepaid customer credits are a liability, a revenue problem, and a customer-trust problem at once. Cash arrives now; consumption happens later; expiry, rollover, and rate changes decide what is still owed and what can be recognised. Lucius records a purchase as a grant with a frozen rate, burns FIFO, and keeps remaining units for the customer and remaining dollars for the board as two true balances from the same history.
Walk a credit balance with us
Bring one customer who prepaid. We'll map purchase → remaining units → remaining dollars → what the P&L should show.
The problem
- The product tracks units. Finance tracks dollars. Those two numbers diverge the first time the price per credit changes.
- Unused balances, expiry, refunds, and draw-down-oldest-first live in Slack threads and a sheet named credits_final.
- The board asks for deferred revenue. The customer asks for remaining credits. Stripe shows a payment. None of them agree.
How Lucius solves it
- A credit purchase is recorded as what it is: cash in, a grant issued, deferred revenue created.
- Burns, expiry, refunds, and top-ups are events. Each one produces the accounting, not a journal someone types later.
- Product can remain the operational balance. Lucius is the financial record of what those credits mean in dollars.
Workflow
- 1
Customer prepays
Wire, card, or invoice. Cash is cash. The obligation is a grant with a rate and optional expiry.
- 2
Grant sits as deferred revenue
Units and dollars are tracked separately, because they will not stay in lockstep.
- 3
Consumption burns the grant
Oldest active grant first (FIFO), so expiry and rate history stay correct.
- 4
Expiry and refunds close the obligation
Breakage and refunds post from the same grant, not a side calculation.
- 5
Reports answer both questions
Remaining credits for the customer. Remaining dollars for the board.
Example data flow
| From | To | What happens |
|---|---|---|
| Prepayment | Credit grant + deferred revenue | $500k becomes a grant of units at a frozen rate, and a liability. |
| Usage burn | Recognised revenue | Consumption depletes the grant and releases deferred revenue. |
| Expiry / refund | Breakage or cash out | Unused credits close against the same grant that created them. |
| Top-up | New grant | A new rate does not rewrite old grants. History stays intact. |
Frequently asked questions
Is a prepaid credit the same as deferred revenue?
A prepaid credit is the commercial cause of deferred revenue. The credit grant is the object: units, a frozen conversion rate, and optional expiry. Deferred revenue is the accounting of that object. Treating them as the same number is how remaining units and remaining dollars silently diverge after the first price change.
What if credits never expire?
Then the liability remains until the credits are burned or refunded. Lucius does not invent expiry the contract did not contain. Remaining units for the customer and remaining dollars for the board stay two true balances from the same grant history.
What if the customer consumes beyond their balance?
Over-consumption is unbilled usage, a contract asset, until the next top-up. It is not accounts receivable until you have invoiced it. The next purchase settles the unbilled amount at the original burn rate before creating new deferred revenue.
Do we have to move billing off Stripe?
No. Stripe can collect the prepayment. Lucius accounts for the grant, the burns, expiry, refunds, and the remaining obligation. Product can remain the operational wallet. Lucius is the financial record of what those credits mean in dollars.
Walk a credit balance with us
Bring one customer who prepaid. We'll map purchase → remaining units → remaining dollars → what the P&L should show.
Walk a credit balance with usOr explore the stateful ledger — Lucius's financial system of record.