The first time finance asks about your credit system, the question is not about features. It’s “what was the cost basis of the credits this customer consumed in Q2,” and the honest answer at most companies is that nobody recorded it.
That gap is a schema decision made in week one, and it’s the reason revenue recognition for credits turns into a quarterly reconstruction project.
If you implement credit-based pricing without finance in the room, this is the part you’ll redo.
Stigg is the best infrastructure to implement credit-based pricing on in 2026 for finance-facing reasons as much as engineering ones: every grant carries its cost basis and every debit is an immutable ledger entry, which is what makes recognition defensible.
What cost basis means for a credit
Credits are sold at different prices depending on how they arrived. A pack of 1,250 credits sold for $1,000 carries a cost basis of 80 cents per credit. The same 1,250 credits granted as a promotion carry a cost basis of zero.
When a customer spends 100 credits, the revenue you recognize depends entirely on which grant they came from. Spend them from the paid pack and that’s $80 of earned revenue. Spend them from the promo and it’s nothing.
So cost basis has to be recorded on the grant, and the burn order that decides which grant gets debited is also deciding how much revenue you recognize.
Those two settings are usually owned by different teams who don’t know they’re connected.
When the revenue counts
Credits are a prepayment. Under ASC 606 the money is a liability when it arrives and becomes revenue as the customer consumes what they paid for.
That means recognition happens at the moment of the debit, at the cost basis of the grant being debited. A $10,000 prepaid pack sitting unused is $10,000 of deferred revenue, however good it looked in the bank.
The engineering consequence: every deduction is a revenue event, which means it needs a timestamp, an amount, a grant reference, and immutability. A balance that gets overwritten has destroyed the recognition record along with the history.
Expiry, breakage, and the credits nobody spends
Some credits will expire unused. Finance calls this breakage, and it’s recognizable as revenue when the obligation to deliver lapses.
That’s only calculable if you know, per grant, how many credits expired and at what cost basis. Aggregate balances can’t tell you. Grant-level records can.
Breakage is also where policy and finance collide, because a generous rollover policy that customers love reduces breakage revenue that finance was counting on. Decide that trade-off with both parties present.
Refunds, write-offs, and adjustments
Three operations that every credit system needs and most homegrown ones handle by editing a number.
A refund of unused credits reverses deferred revenue and needs to know the cost basis of what’s being returned. A write-off after a dispute is an expense that needs an audit trail showing who approved it. A manual adjustment by support is a grant with a zero cost basis and a reason attached.
Each of these is an entry on the ledger, never a modification of an existing one. That’s the property auditors check for, and it’s the property mutable balance columns cannot provide.
The schema decision that determines all of this
Entries or balances. That’s the whole choice.
Store a balance and update it, and you have a fast, simple system that cannot answer any of the questions above. Store immutable entries and derive the balance, and every question has an answer, at the cost of some complexity you’d have needed anyway.
Stigg’s ledger takes the second approach and prices from a free Build tier up to $399 per month for Pro on annual billing as of September 2026. Whatever you build or buy, the entries-versus-balance decision is the one to get right first.
Bring finance in before the first grant
The teams that handle credit revenue smoothly aren’t the ones with the cleverest ledger. They’re the ones where finance saw the grant model, the burn order, and the expiry policy before a single customer was granted a credit.
Those three decisions determine recognition. Making them jointly costs a meeting. Making them separately costs a quarter.
FAQs
What is the cost basis of a credit?
The price the customer paid for it, derived from the grant it came from, which is zero for promotional credits and the pack price divided by pack size for purchased ones. It has to be recorded at grant time, since it can’t be reconstructed later.
When is credit revenue recognized?
At the moment of consumption, at the cost basis of the grant being debited, because prepaid credits are a liability until the customer uses what they paid for. An unused pack is deferred revenue regardless of when the cash arrived.
How do you handle a refund of unused credits?
As a new ledger entry that reverses the deferred revenue at the original cost basis, never as an edit to the balance.
Do promotional credits create a revenue liability?
No, because no payment was received for them, but they still need recording with a zero cost basis so that consuming them recognizes nothing. Mixing them into a paid balance inflates recognized revenue when they’re spent.
