Inflationary increases in SaaS contracts: great idea, harder than it looks

Yesterday I wrote about AI agents and memory in RevOps. The post was about how agents fail when they have no record of what they’ve already done — and I used a 5% inflationary increase across a customer base as the example scenario.

The interesting thing was what happened after I posted it on LinkedIn. A lot of the conversations I had weren’t about AI at all. They were about the example itself. People were asking — and debating — whether building inflationary increases into SaaS contracts was a good idea, whether it was becoming standard practice, and how you’d actually go about doing it.

It’s worth spending some time on that directly.

Why inflationary increases make sense in multi-year SaaS contracts

If you’ve signed a two or three year SaaS deal at a fixed price, you’ve made a bet. The vendor is betting that their costs won’t outpace the price they locked in. You’re betting that the software will still be worth what you’re paying for it. Both bets carry risk.

The case for inflationary escalators is straightforward:

SaaS vendors have real cost inflation. Cloud infrastructure costs, engineering salaries, support headcount, compliance overhead — these all go up over time. A contract signed in year one at a price that was profitable can become a drag on the business by year three if nothing adjusts. Most SaaS pricing is already priced at a margin that doesn’t leave a lot of room for multi-year cost creep.

Long-term contracts are valuable — and vendors should be willing to price that in. A three-year committed deal gives a vendor predictability and reduces churn risk significantly. An annual escalator of 3–5% is a modest price for that certainty. Without it, vendors are effectively giving a discount that gets larger every year.

Predictability cuts both ways. Customers who balk at built-in escalators often prefer them to the alternative: unpredictable renewal-time price increases. A 4% annual uplift baked into the contract is a known quantity. A 20% price increase at renewal, because the vendor “needs to adjust to market rates,” is not.

It’s standard practice in other B2B contexts. Commercial real estate leases routinely include CPI-linked rent escalations. Enterprise software maintenance contracts (the old perpetual licence model) typically carried 15–20% annual fees. The SaaS world has been slower to formalise this, but the economics haven’t changed.

How common is it?

More common than you might think, and getting more so.

After the inflationary surge of 2021–2023, a lot of SaaS vendors who had been offering flat multi-year pricing quietly changed their practices. Salesforce introduced annual list price increases as a standard clause. Microsoft 365 and Azure contracts routinely carry annual price escalators. ServiceNow has included CPI-linked adjustments in enterprise agreements for years.

A 2023 survey by Zuora found that 57% of B2B SaaS companies had raised prices in the prior 12 months, and a growing proportion were doing so by embedding escalators into the contract structure rather than renegotiating at renewal. Analysts at Forrester and Gartner started recommending in 2022 that procurement teams scrutinise multi-year SaaS contracts specifically for automatic price escalation clauses — which tells you that those clauses were showing up often enough to flag.

The typical range is 3–5% annually, often pegged to CPI (Consumer Price Index) or a fixed annual percentage, whichever is higher. Some vendors cap the annual increase; others don’t. The details vary, but the structure is becoming the norm rather than the exception, especially for deals over 12 months.

If you’re selling multi-year SaaS contracts today without any kind of escalator, you’re probably leaving money on the table — and you’re also absorbing more cost risk than you need to.

Great in concept. Now go implement it.

Here’s where it gets interesting. Most RevOps leaders who’ve thought about this agree that inflationary escalators are a reasonable idea. The question they run into — and the one that came up repeatedly in the conversations I had after yesterdays post — is: can your billing system actually do this?

It sounds like a simple operation. Find all the active subscriptions. Apply a 5% increase to the recurring line items. Generate amended contracts or updated invoices. Send customer notifications. Done.

In practice, it’s a mess.

Not all subscriptions are equal. You might have some customers on annual contracts, some on monthly, some mid-cycle, some up for renewal next month anyway. Do you apply the increase uniformly? Do you wait until each contract’s renewal date? Do you pro-rate mid-cycle adjustments? Each answer is defensible; none of them is simple to execute in bulk.

Product line items have different rules. A platform fee might escalate. An implementation fee you billed once shouldn’t. Usage-based components might be excluded entirely. If your billing system doesn’t have the concept of “escalatable” vs “non-escalatable” line items, you’re doing this manually, per account.

Contracts need to reflect the change. In many B2B contexts, a price increase isn’t just an invoice adjustment — it requires a signed amendment or at minimum a documented notice period (often 30 or 60 days). If you’re running a proper CPQ process, you need the contract documents to update too, not just the billing records.

Customer notifications have to go out. And they need to be accurate. Sending a customer a notice that says “your subscription will increase to £X per month from [date]” only to have the invoice actually say something different is the kind of operational mistake that ends up on a support call and occasionally in a churn conversation.

The audit trail matters. If a customer disputes a price increase three months later and asks when they were notified and what the original contract said, you need to be able to answer that. Most billing systems don’t make this easy to reconstruct.

What looks like a single operation — “run a 5% increase” — is actually a workflow. It has conditionals, edge cases, communication steps, and documentation requirements. And in most companies, the person responsible for running it is navigating a billing system that wasn’t designed with bulk contract amendments in mind, working from a spreadsheet, sending templated emails manually, and hoping nothing falls through the cracks.

Bunny already handles this

This is actually a problem we’ve thought hard about at Bunny, because the complaints above aren’t hypothetical — they’re what we hear from RevOps teams trying to run this process today.

Bunny lets you apply percentage increases to specific line items across your subscriptions, triggered at each account’s renewal. That’s the right approach — a blanket “apply 5% from April 1st” hits every account at once, which creates mid-cycle billing noise and pro-ration headaches. Renewal-aligned increases are cleaner: the customer sees the change at the natural point in their contract cycle, and the numbers on the invoice are never surprising.

The result is that what used to be a week of careful spreadsheet work and manual follow-up becomes a few configuration steps.

Where AI takes it further

Getting the billing mechanics right is the foundation. But there’s still a layer of operational work sitting around it — drafting the customer notification copy, deciding which accounts to include or exclude based on contract terms, reviewing the output before it goes out, and fielding the inevitable inbound questions from customers who want to understand the change.

That’s where an AI agent adds real value. Not as a replacement for sound billing infrastructure, but as the layer that handles the surrounding workflow: reviewing the accounts in scope, drafting the notices, flagging any edge cases that need a human decision before the run kicks off. The billing system does the heavy lifting accurately; the agent handles the coordination and communication work that wraps around it.

The combination is what makes this feel genuinely low-friction — rather than a process that’s theoretically possible but painful enough that most teams don’t bother.