If your customer's credits go unused, that's on you

A lot of B2B SaaS companies are landing on credits to price their AI features. I don't love credits. When one credit pays for many actions that are worth different amounts, it is effectively a currency, and I don't think that is very useful, because it masks what each action is worth. Every SaaS company defines them differently, and buyers have a hard time forecasting them. It isn't a perfect model, and it is still the best option we have right now for pricing work that varies this much in cost and in value.

So I'm less interested in whether to use credits than in how to run them. Most of that argument comes down to one policy: what happens to the credits a customer buys and doesn't use.

Why I'd let credits expire

The common advice is to let unused credits roll over. I understand the appeal. A buyer who knows they won't lose what they paid for commits more easily, and the deal closes faster.

The cost shows up on your side. Prepaid credits are cash you have collected for work you haven't delivered yet, so they sit on your books as a liability until the customer uses them. Every period of rollover makes that balance bigger and your revenue recognition harder. At some point you are holding customers' money against future use, and that is closer to running a bank than a software company.

Expiry is also how most credit plans already work. As of October 2026, Anthropic's prepaid API credits expire one calendar year after they are issued and are non-refundable.¹ HubSpot's credits reset every month and unused credits don't roll over.² Salesforce's Flex Credits don't roll over into the next subscription term.³ GitHub Copilot's included credits don't carry over between months,⁴ and Figma's don't either.⁵ Clay is one exception. Its data credits roll over up to twice the monthly amount, and enterprise customers can carry up to 15% of the prior year's credits if they renew at an equal or higher commitment.⁶

I'd let credits expire. The price of a credit should match the value it delivers, and it is fine to discount that a little on the understanding that some credits will go unused, especially on monthly plans.

I wouldn't make rollover a policy, because it is a slippery slope. Where it happens, it should be decided case by case and kept short: a month, a quarter at most.

"A license by another name"

The usual objection is that credits which expire every period are a license by another name. That may be true, and I don't think it matters.

We price on value. What matters is whether the customer got the value they paid for, whatever the model is called. A balance that rolls into next year doesn't answer that. It moves the conversation to a later date.

Unused credits are the SaaS company's problem

I don't mean 5–10% left over in one month. I mean a pattern, where the customer leaves credits unused period after period. That is the point to ask why they aren't using them and why they aren't getting the value.

If you pre-sell a block of credits and the customer keeps not using them, I see two explanations. You sold them more than they needed, or you didn't get them to the point where they needed it. Both are on you.

Rollover lets everyone avoid that for another year. Expiry puts a date on it, which means you have to do something about it while the contract is still running.

Build right-sizing into the contract

Expiry is only fair if the commitment was the right size to begin with, and at signing neither side knows what usage will be. So I'd write the correction into the deal.

Keep the first 90 days open. The customer can adjust the commitment up or down while you both see real usage. After 90 days, it locks for the year. Ninety days is a guideline, because onboarding takes a different amount of time at every company. The principle is that the commitment is set on usage and not on a promise. A buyer can say they will use a lot to get a better rate, and the first 90 days show what they do. If customers can game the commitment that easily, it isn't a good metric.

Use what you know from your other customers. You have seen how accounts like this one grow. If, say, they are usually at 75% of their eventual usage by day 90, size the commitment from that.

Pool the credits. Credits belong to the whole organization and not to individual users, so a light month in one team is covered by a heavy month in another. GitHub does this with Copilot: 100 users share one pool of 190,000 credits and not 100 separate allowances.⁴ Figma's seat credits work the other way. They are per user, and only the credits a company buys on top are shared across the plan.⁵

Show the customer a forecast. Show them a projection of their usage and not only a balance, so they know whether they will run short or finish with credits to spare while there is still time to act. Most companies stop at alerts. HubSpot notifies admins at 75%, 85% and 90% of the limit.² Salesforce goes further and says its Digital Wallet will "forecast future consumption."⁷

Use the quarterly business review (QBR). If the customer is behind, the first job is to get them to full value. Getting customers to usage is the customer success team's job. If that isn't going to happen, right-size the account, even if it means reducing their credits. In some cases I'd extend the renewal date to make up for it, decided account by account.

Sell a credit pack before they run out. If the forecast shows a customer heading well past their commitment, raise it early and sell them a pack before renewal.

Keep the rate fixed

Credits only work when they are tied to something the customer values, that thing can be measured, and the buyer knows how many credits equal that value. I'd add a fourth condition: the rate doesn't change against the customer during the contract.

Most terms leave that open. HubSpot's documentation says "credit rates may change as features evolve."² Figma's says "Costs for each feature may change as models are optimized or new models become available."⁵ I understand why. The cost of running these models keeps moving. But if the SaaS company can change what a credit buys, the customer has made a commitment in a currency they don't control.

I'd fix the rates for the term, or let them move only in the customer's favor.

True forward at renewal

At renewal, look at what the customer used. If they finished within 10–15% of their commitment, I wouldn't bill the overage. Set next year's commitment at the level you expect them to grow to, lock it in, and move on.

If they went further over than that, bill it. It shouldn't surprise anyone, because the forecast flagged it months earlier and the credit pack was on the table.

I call this a true forward because it uses last year's usage to set next year's commitment, where a true-up sends a bill for last year.

What it costs you

Reducing a customer's credits in the middle of a contract costs you revenue this year. So does waiving a small overage. I'd take both, because the customer then renews on a number that matches what they use.

Key takeaways

• A pattern of unused prepaid credits means the SaaS company oversold or didn't get the customer to value.

• Let credits expire. Don't make rollover a policy; handle exceptions case by case and keep them short.

• Leave the commitment adjustable for the first 90 days, then lock it for the year.

• Pool credits across the organization, show a usage forecast, and use QBRs to get the customer to value or right-size the account.

• Fix what a credit buys for the length of the contract.

• At renewal, waive overage within 10–15% and set next year's commitment from real usage. Bill anything beyond that.

To close

Credits are a stopgap, and I expect something better to replace them. Some companies are already moving on. Devin Desktop, formerly Windsurf, replaced its credit system with daily and weekly usage quotas in March 2026.⁸ While we are using them, the test is the one we apply to any value metricValue MetricA value metric is the unit of measurement that determines how a customer is charged. It's the axis along which price scales — such as users, contacts, API calls, revenue managed, or storage.Read more →: the customer pays in proportion to the value they get. When credits go unused, that link is broken, and it is the SaaS company's job to repair it.

Sources

1. Anthropic, Credit Terms. Checked 11 October 2026.

2. HubSpot Knowledge Base, "Understand HubSpot Credits and billing." Updated 9 September 2026.

3. Salesforce, Agentforce pricing. Checked 11 October 2026.

4. GitHub Docs, "Usage-based billing for organizations and enterprises." Checked 11 October 2026.

5. Figma Help Center, AI credits. Rates as of 6 October 2026.

6. Clay, Pricing. Checked 11 October 2026.

7. Salesforce, Digital Wallet. Checked 11 October 2026.

8. Devin Desktop documentation, Quota. Checked 11 October 2026.