Credit pricing is everywhere now - every other AI product launches with credits - but most credit systems are designed by copying a competitor's pricing page rather than the model that creates value. 

We've designed dozens of them, and the framing we like to use is this: a credit system is usage-based pricing paid up front, a deliberate hybrid that takes the best of a license and the best of pay-as-you-go.

Credit systems add complexity - but they create predictability for you and your customer. And complexity can be good.

‍- Ulrik Lehrskov-Schmidt, The Pricing Roadmap

Get the structure right - what a credit represents, how roll-over and expiry work, how you price and recognise the revenue - and credits become one of the most powerful models in B2B SaaS. Get it wrong and you create either a balance-sheet liability or a pricing page nobody understands.

What is a credit system?

There are four pricing modalities: flat fees, licenses (pay for the right to use, whether or not you use it), usage-based pricing (use first, pay after), and credits - a hybrid of the last two. 

A credit system places a currency between the product and the customer's consumption of it: the business sells credits, and the customer spends them on the product.

The mechanics run in a loop:

1. The customer starts a subscription and pays up front for a set number of credits - 10, 50, or 50,000.
2. Over the period - month, quarter, or year - they spend credits as they use the product.
3. Whatever they don't spend rolls over to the next period, so the balance never drops to zero.
4. At the new period, they pay for and receive another batch, and the loop repeats.

Because the purchase recurs and is contracted to a specific number, the revenue is genuinely recurring. It qualifies as ARR, and we've had credit systems recognised as subscription revenue under both GAAP and IFRS. 

That's the underrated power of the model - it makes usage-based revenue behave like a subscription.

One underused move is that credits don't only buy usage. They can activate licenses inside the product too. 

In one cybersecurity rollout we worked on, a customer bought credits and used them to enrol 10,000 employees into a recurring security programme at roughly 10 credits (~$10) each. 

Credits become a single currency that spans most of the pricing architecture - which is why many companies are now rolling licenses and usage into one credit economy.

‍

Why credit systems work

A well-designed credit system takes the fear away. Start low, ramp into real usage, roll over what you don't spend, never lose what you bought. The customer can commit up front without feeling at risk and from there the benefits compound:

Shorter sales cycles. With no downside to committing, customers say yes faster and start smaller.

Recurring, predictable revenue. Variable, seasonal, or bursty usage gets converted into a contracted, recurring commitment

A deposit effect that lifts consumption. Once customers have bought credits, the money feels "already there to spend" - like cash set aside for a holiday - so they use more.

Built-in retention. Credits are forfeited if the customer churns, which makes renewal conversations easier and ties customers to the business across quiet periods.

A cross-sell currency. One credit balance can be spent across the whole portfolio, so expansion becomes "spend more of what you already have" rather than a fresh purchase.

Roll-over and expiry: the trust mechanics

The throughline: roll-over plus a fair, FIFO, two-year expiry is what lets the customer commit money up front and still feel completely safe. That feeling is the entire point of the model.

This is the fine print that decides whether customers trust the model or feel trapped by it. Here are the general rules you can follow to make your credit system a success:

Forfeited on churn. Credits are lost if the customer leaves. Stated plainly in the contract up front, this is a legitimate retention mechanism. But it has to be transparent - never a surprise.

Unused credits roll over. At the end of a period, whatever the customer hasn't spent carries into the next one. The whole model exists to let customers commit money up front without feeling at risk - so the terms must never read as a gotcha. The promise is simple: we won't charge you more than you use, we won't punish you for misestimating, and you'll never lose what you paid for inside the term.

No payback, no transfer. Credits aren't refundable in cash, can't be withdrawn, and generally can't be handed to someone else. They're spent or they expire.

Credits expire - and they must. If credits never expire, the business carries an unlimited-term liability. In theory a customer could come back in 25 years and demand the usage. Our rule of thumb is two years - long enough that virtually every customer can use the volume they bought, and short enough that the CFO and legal team can live with the liability. It's also the window that sits cleanly within both GAAP and IFRS revenue recognition.

First-in-first-out. Always spend the oldest credits first. This minimises expiry - a customer would need to use less than half their expected volume before any credits were at risk - and it's visibly fair.

How to design a credit system

We frame the design as 12 necessary questions, with a blunt rule: if you haven't answered all of them, you don't have a credit system yet - just the outline of one. The first few define what a credit is (what it represents, what it can buy, what it costs); the rest cover communication, terms, and revenue recognition. Six of the calls tend to decide whether the system works in practice.

The no-penalty, one-framework discipline is what keeps a credit system out of commercial debt. Anything more elaborate - overlapping bundles, penalty tiers, opaque conversion rules - and the model starts creating the anxiety it was meant to remove.

Credits also sit alongside fair usage and usage caps on any plan where consumption can run past the paid volume - the two mechanisms cover different failure modes and belong in the same commercial model.

When credits work and when they don't

Credits work best when usage is variable, seasonal, or bursty and the business wants to stabilise revenue.

They fit when value maps neatly to a dollar, and when the business has multiple products a single credit currency can span. They're increasingly the default for AI products, where consumption is unpredictable and a credit layer abstracts the raw token cost.

Credits fail when the system gets too clever - overlapping multi-purchase schemes customers can't reason about - or when the terms feel like a trap: aggressive expiry, overage penalties, or opaque conversion from credit to outcome.

The clarity that makes credits sell starts to erode once complexity crosses a certain point. And the fix is discipline, not more mechanics: clean 1:1 pricing, fair roll-over, a transparent dashboard, and a two-year FIFO expiry.

A note on direction: credits are spreading fast, partly because customers now understand them. Credit economies are increasingly absorbing the rest of companies' pricing architecture - licenses and usage alike rolled into one currency.

Used with discipline, that consolidation is a feature. Used carelessly, it's how you end up with the complexity customers rebel against.