Field notes
20% of what? The rollover cap that quietly changes invoices
"Up to 20% of unused credits roll over" reads like one rule. It's two, and on an ordinary contract the gap between them is twelve times the overage.
About these field notes. They draw on public discussions with RevOps, billing and NetSuite practitioners in October 2026, in which several people described how their teams run usage true-ups today. We paraphrase and don't name anyone. The worked examples are illustrations we built to show the mechanics, not any company's real figures.
What practitioners told us
When we asked RevOps and billing people how they run capped rollover, the arithmetic was never the hard part. The cap was. One person running rollover on Stripe with scheduled jobs and a small database table singled out a cap set as a percentage of the commitment, rather than of what's left over, as "the annoying part": the year-end number only comes out right if someone watches it every month. A NetSuite practitioner, unprompted, said a custom record beats a spreadsheet precisely because of capped rollover.
Both point at the same thing. A cap needs a base, and contracts often don't say which one.
Two readings of one sentence
- Cap on the commit: at most 20% of the period's included credits can roll. On a 10,000-credit month, that's up to 2,000, however much is left.
- Cap on the unused balance: at most 20% of what's left can roll. If 4,000 are left, 800 roll.
The second reading always rolls less, so the customer hits overage sooner. Which one is "right" is a contract question, not a maths one. What matters is that it's decided once, written down, and applied the same way every month.
One contract, one year, two readings
10,000 credits a month, overage at $1.20 a credit, up to 20% rolls over, and rolled credits expire after one month. Usage swings between quieter and busier months, as it does for most API products.
| Month | Usage | Rolled cap on commit | Overage cap on commit | Rolled cap on unused | Overage cap on unused |
|---|---|---|---|---|---|
| Jan | 6,000 | 2,000 | 0 | 800 | 0 |
| Feb | 11,500 | 500 | 0 | 0 | 700 |
| Mar | 7,000 | 2,000 | 0 | 600 | 0 |
| Apr | 12,000 | 0 | 0 | 0 | 1,400 |
| May | 8,000 | 2,000 | 0 | 400 | 0 |
| Jun | 10,500 | 1,500 | 0 | 0 | 100 |
| Jul | 6,500 | 2,000 | 0 | 700 | 0 |
| Aug | 12,500 | 0 | 500 | 0 | 1,800 |
| Sep | 9,000 | 1,000 | 0 | 200 | 0 |
| Oct | 11,000 | 0 | 0 | 0 | 800 |
| Nov | 7,500 | 2,000 | 0 | 500 | 0 |
| Dec | 12,000 | 0 | 0 | 0 | 1,500 |
| Year | 113,500 | 500 → $600 | 6,300 → $7,560 |
Same customer, same usage: $600 of overage for the year under one reading, $7,560 under the other.
Computed with our drawdown engine. Each month draws rolled credits first, then included credits, then overage.
Why spreadsheets drift on this
- The cap's base hides in a formula. One cell references the commit, another the remainder, and nobody notices until a customer queries an invoice.
- Rolled credits need their own expiry. A single "rollover balance" column can't tell you which credits lapse this month, so expiry gets applied late or not at all.
- It changes when the plan changes. After an upgrade or downgrade, is the cap based on the old commit or the new one? See amendments.
What to do
- Decide the base for every contract with a cap, and record it next to the clause reference.
- Track rolled credits as separate lots, each with its own expiry date, not as one running balance.
- State the drawdown order: rolled credits before included ones is the usual choice, because it uses the credits that expire first.
- Check last quarter by recomputing a few contracts under the base you've chosen. The true-up calculator handles capped, expiring rollover for one contract at a time.
For the wider picture, see our review of 64 pricing pages: of the six that offer rollover publicly, one states a cap.
Not sure which reading your invoices use?
Send us a few redacted contracts and the usage behind them. We'll recompute each period and show where the cap was applied differently. Free, within 48 hours of complete files.