How to Forecast SaaS Renewal Costs and Avoid Software Budget Surprises
There’s something rather impressive about a software subscription that nobody remembers approving, nobody seems particularly enthusiastic about using, and everybody assumes someone else is managing.
It renews anyway.
And there it is, sitting on the credit card statement or in accounts payable, behaving like a perfectly legitimate business expense. Which, contractually speaking, it may well be.
I’ve always found this interesting about software budgets. We can spend weeks debating a new $15,000 purchase, complete with presentations, approvals, and perhaps a committee if we’re feeling ambitious. Meanwhile, a $48,000 subscription from three years ago can renew with considerably less ceremony.
The problem isn’t necessarily that the software is bad. It may be essential. The problem is that the business made a purchasing decision years ago and has somehow turned it into a permanent assumption.
If I’m building a SaaS renewal forecast, I want to know more than what we spent last year. I want to know what we’re committed to, what we actually need, when we can change it, and what the decision will do to both expenses and cash.
Those are not always the same numbers.
How to Forecast SaaS Renewal Costs
A useful SaaS renewal forecast starts with the contracts, not last year’s software expense.
For each subscription, I would collect the current annual or monthly price, number of licenses, renewal date, cancellation or change-notice deadline, payment terms, expected price changes, and the person responsible for deciding whether to renew.
Then I’d add actual usage, anticipated headcount changes, and any expected implementation or switching costs.
The basic annualized cost calculation for a per-seat subscription is:
Forecast annual subscription cost = Forecast license count × Forecast monthly price per license × 12
That works for a straightforward subscription priced monthly for a full year. It doesn’t automatically work for partial-year renewals, prepaid annual contracts, usage-based charges, tiered pricing, minimum commitments, or contracts with midyear price changes.
And that’s why I wouldn’t stop there.
I would build three related views: the contractual commitment, the expected expense by month, and the expected cash payments by date.
The first tells me what the business may be obligated to spend. The second helps me forecast the income statement. The third tells me when the money leaves the bank.
A budget that gets the annual total right but the cash timing wrong can still create a fairly unpleasant Tuesday.
The $48,000 Subscription That Became a $62,400 Decision
Let’s use a hypothetical U.S. business with 100 licenses for a cloud-based platform.
The company currently pays $40 per user per month.
Its annual cost is:
100 licenses × $40 × 12 = $48,000
The contract renews on January 1. The vendor proposes an 8% increase, and the business expects to need 20 additional licenses because of planned hiring.
Nothing particularly dramatic so far.
Except the renewed annual cost becomes:
120 licenses × $43.20 × 12 = $62,208
That’s an increase of $14,208, or 29.6%, over the existing $48,000 annual cost.
The vendor increased its price by 8%.
Our forecasted spending increased by 29.6%.
Both numbers are correct. They answer different questions.
Here’s the calculation:
| Cost driver | Current contract | Proposed renewal |
|---|---|---|
| Licenses | 100 | 120 |
| Monthly price per license | $40.00 | $43.20 |
| Monthly subscription cost | $4,000 | $5,184 |
| Annualized cost | $48,000 | $62,208 |
| Increase from current annual cost | — | $14,208 |
I would separate the increase into two pieces.
The 8% price increase on the original 100 licenses adds $3,840 annually.
The additional 20 licenses at the new $43.20 rate add $10,368.
Together, that’s $14,208.
Why separate them? Because we have two different decisions to make.
We can negotiate the vendor’s price. We can also question whether we need 120 licenses.
And those discussions should not be confused with each other.
The License Count Is Where I Would Start Asking Questions
Let’s say the company has 100 paid licenses, but only 76 people have used the software during the past 90 days.
I wouldn’t immediately cancel the other 24.
Some may belong to seasonal employees. Others may be needed for quarterly processes, occasional approvals, or administrative functions that don’t produce frequent logins.
Usage data is evidence, not a verdict.
But I would ask who owns those licenses, why they’re assigned, and whether they’re expected to be used again.
Then I’d ask about the 20 new licenses.
Are they tied to approved hires with actual start dates? Or did someone take the headcount growth percentage from the annual plan and apply it to every software application?
Because that’s a wonderfully efficient way to forecast spending nobody has demonstrated a need for.
As a mom, I appreciate the optimism of buying supplies for every possible activity a child might take up this year. I also appreciate discovering six months later that we’ve apparently opened a small, privately funded sporting-goods store.
Software licensing can work much the same way.
I want the licenses associated with people, roles, or genuine operating requirements. Not merely a percentage.
What Happens When We Forecast the Licenses We Actually Expect to Use?
Suppose we review the company’s usage and hiring plans.
We determine that 12 existing licenses can be removed without disrupting operations. Of the 20 planned additions, only 12 are supported by approved hiring dates and expected access requirements.
That gives us:
100 − 12 + 12 = 100 forecast licenses
At the proposed new price of $43.20, the annualized renewal cost becomes:
100 × $43.20 × 12 = $51,840
Compare that with the original proposed renewal of $62,208.
The difference is $10,368 annually.
That’s a meaningful amount of money to recover through a conversation about who actually needs access.
And we haven’t negotiated a single dollar off the vendor’s proposed price.
I would be careful about calling the entire $10,368 a realized saving, though. It’s a reduction from a proposed future spending scenario, not a reduction from the existing $48,000 contract. Against current annual spending, the revised renewal is still $3,840 higher.
This distinction matters when management reports savings.
Avoiding a proposed increase is valuable. It just isn’t the same as reducing what the business currently spends.
A SaaS Renewal Forecast Needs More Than One Number
For the example above, I’d present at least three scenarios.
| Renewal scenario | Licenses | Monthly price | Annualized cost | Change vs. current |
|---|---|---|---|---|
| Current contract | 100 | $40.00 | $48,000 | — |
| Proposed expansion and 8% price increase | 120 | $43.20 | $62,208 | +$14,208 |
| Rightsized licenses, 8% price increase | 100 | $43.20 | $51,840 | +$3,840 |
| Rightsized licenses, negotiated 3% increase | 100 | $41.20 | $49,440 | +$1,440 |
The fourth row adds a possible negotiated outcome, not a promise that the vendor will accept it.
What interests me is how the options change the conversation.
Instead of asking Finance why the software budget is increasing by almost 30%, we can ask whether the additional licenses are justified, whether the price increase is reasonable, and which outcome we should plan around.
That’s a more useful meeting.
And it has the added benefit of not beginning with someone asking why the spreadsheet doesn’t match the invoice.
The Renewal Date Is Not Always the Important Deadline
Now let’s introduce a complication that deserves considerably more attention than it usually receives.
Our hypothetical subscription renews on January 1.
The agreement requires 60 days’ written notice to cancel or change the committed license count.
That means management may need to act in early November, subject to the contract’s exact notice language and deadline calculation.
If the company doesn’t review the renewal until December, the financial forecast may still be accurate.
Unfortunately, the opportunity to change the commitment may already have passed.
I would put two dates into the renewal calendar: the renewal date and the last date on which the business can exercise its contractual options.
Then I’d assign an owner and an internal decision deadline early enough to allow for usage analysis, security review, negotiation, and approvals.
The actual notice requirement comes from the signed agreement. It isn’t always 30, 60, or 90 days, and the rules for changing seat counts can differ from the rules for cancelling the whole contract.
I wouldn’t guess.
A calendar reminder that says “Software renews January 1” is useful.
A reminder that says “Decide by October 15 whether we want to be committed for another year” is considerably more useful.
The first reminds us that something will happen.
The second gives us a chance to influence it.
Annual Software Expense and Cash Payments May Tell Different Stories
Here’s another reason I don’t like forecasting subscriptions by copying last year’s expense and adding a percentage.
Suppose the company chooses the rightsized, negotiated option at $49,440 for a 12-month service period beginning January 1.
If the company pays the entire amount upfront on January 1, the cash forecast shows a $49,440 payment in January.
Assuming the payment qualifies as a prepaid service cost and the benefit is received evenly over the 12-month period, the illustrative expense forecast recognizes:
$49,440 ÷ 12 = $4,120 per month
Those are very different patterns.
| Month | Illustrative subscription expense | Illustrative cash payment |
|---|---|---|
| January | $4,120 | $49,440 |
| February | $4,120 | $0 |
| March | $4,120 | $0 |
| April–December combined | $37,080 | $0 |
| Full year | $49,440 | $49,440 |
This simplified example assumes the payment is made in January, the service benefit is received evenly, and no other fees or accounting complications apply. Actual recognition depends on the contract and applicable accounting policy.
Now imagine the business is also paying annual insurance premiums, making a large equipment deposit, and funding a seasonal inventory build in January.
The income statement might show an entirely manageable monthly software expense.
The bank account may have a more colorful opinion.
This is where I’d connect the renewal schedule to the company’s working capital forecasting and cash forecasting processes.
And if the vendor offers monthly payments instead of annual prepayment, I’d compare the full cost of each option. A discount for paying annually may be attractive, but only if the liquidity tradeoff makes sense.
How I Would Build a SaaS Renewal Forecast in Excel
I wouldn’t start by buying a subscription-management platform to manage the subscription-management problem.
Not yet, anyway.
For a business with a manageable number of contracts, a well-designed Excel file may be sufficient. The important part is that somebody owns it and updates it.
I’d begin with a contract register containing the following fields:
| Field | Why I need it |
|---|---|
| Vendor and product | Identify the actual service |
| Business owner | Identify who can justify the need |
| Current license count | Establish the contracted quantity |
| Active or justified licenses | Challenge the quantity |
| Current price | Establish the cost baseline |
| Renewal price or uplift assumption | Forecast the new rate |
| Contract renewal date | Identify when the new term begins |
| Notice deadline | Identify when a decision must be made |
| Billing frequency | Forecast cash timing |
| Contract term | Identify the period of commitment |
| Planned hiring or reductions | Support future license needs |
| Decision status | Renew, reduce, negotiate, replace, or cancel |
| Expense and cash forecast | Show the financial effect |
For a simple per-seat contract, the key Excel formulas could be:
Annualized current cost
=Current_Seats*Current_Monthly_Price*12
Annualized proposed renewal cost
=Forecast_Seats*Current_Monthly_Price*(1+Uplift_Rate)*12
Annualized cost increase
=Proposed_Annual_Cost-Current_Annual_Cost
Notice deadline
=Renewal_Date-Notice_Days
That last formula is a useful reminder, not a substitute for reading the contract. Calendar-day versus business-day provisions, delivery requirements, and specific notice language can change the legally effective deadline.
I would also build monthly columns for expense and cash, rather than assuming annualized cost equals expense recognized during the calendar year.
A contract renewing in July affects only part of that year’s expense forecast at the new rate. A contract billed upfront in July may create a much larger cash movement in that month.
For the broader model, Sarah’s existing guide to operating expense forecasting explains why different costs deserve different forecasting methods.
Software contracts are a particularly good example.
Don’t Put Every Subscription in the Same Decision Bucket
Not every software contract should be approached as an expense to eliminate.
Some systems are essential to operations. Some contain years of business data. Some support regulatory or contractual requirements. Others may save substantial employee time even when their direct financial return is difficult to measure.
I’d group renewals according to the decision they require.
Keep and validate: The system is necessary, the licenses are justified, and the cost is reasonable. Confirm the renewal terms and move on.
Reduce or renegotiate: The business needs the system, but the number of licenses, service tier, or proposed price deserves another look.
Replace: An alternative may provide comparable or better value, but we need to understand implementation, migration, training, security, and disruption costs.
Cancel: The service no longer provides enough value to justify its cost, and the business can exit under the applicable contract terms.
That last qualification is important.
A subscription can be unnecessary and still be contractually committed.
I wouldn’t put savings into the forecast until I understood when the business can actually stop paying.
The Cheapest Renewal Isn’t Always the Best Financial Decision
Let’s say the business is considering replacing a $60,000 annual platform with a competing product costing $42,000 per year.
On the surface, that looks like an $18,000 annual saving.
Lovely.
Now let’s add the costs that don’t appear on the vendor’s pricing page.
The replacement requires $22,000 of implementation and data migration work. Internal employees will spend an estimated 200 hours on the transition, at an illustrative loaded cost of $60 per hour.
That’s another $12,000 of internal labor value.
The first-year comparison becomes:
| Item | Amount |
|---|---|
| Annual cost of existing platform | $60,000 |
| Annual cost of replacement | $42,000 |
| Annual recurring difference | $18,000 |
| One-time implementation and migration | $22,000 |
| Estimated internal transition labor | $12,000 |
| Total first-year replacement cost | $76,000 |
| First-year difference vs. keeping existing platform | $16,000 higher |
The $76,000 is a simplified economic-cost comparison. Internal labor may not represent additional cash spending if existing employees perform the work; it still consumes capacity that could have been used elsewhere.
Assuming recurring annual savings of $18,000 continue and there are no further switching costs, the simple payback on the $34,000 transition investment is:
$34,000 ÷ $18,000 = 1.89 years, or approximately 23 months.
That’s before considering contract overlap, termination fees, training disruption, different functionality, future price changes, or the time value of money.
The replacement might still be a good decision. A two-year payback could be entirely reasonable, particularly if the new platform solves problems the existing one cannot.
But I wouldn’t approve the switch simply because $42,000 is less than $60,000.
My calculator is capable of that comparison without supervision.
I’d like Finance to contribute something more.
For larger technology investments, I’d use the same disciplined thinking I discuss in building an AI business case for Finance: distinguish promised benefits from measurable ones and include the full cost of making the change.
Forecast the Contract You Have, Then Model the Contract You Want
One of the most useful distinctions I can make in a renewal forecast is between the committed or expected baseline and the proposed savings scenario.
Suppose management believes we can reduce our subscription from 120 licenses to 100.
That’s a reasonable planning scenario.
But if the signed agreement requires 120 licenses for another year, I wouldn’t simply forecast 100 because we’ve decided that would be nicer.
I’d keep the contractual baseline visible and show the reduction as an action-dependent scenario until the vendor accepts the change or the agreement permits it.
The same applies to negotiated price reductions, contract cancellations, and vendor replacements.
A potential saving is not a committed saving.
And an approved initiative is not the same thing as a completed contractual change.
This is especially important when a CFO is presenting expected savings to leadership or a board. We need to know which improvements are already secured, which depend on negotiations, and which are still ideas.
I like ideas.
I just prefer not to deposit them into the bank account before they’ve become real.
What I’d Review Every Month
Once the renewal forecast is built, I wouldn’t turn it into a giant reporting ritual.
I’d want a short monthly review focused on the decisions that are still available.
Which contracts have notice deadlines approaching? Which subscriptions are materially underused? Which proposed increases exceed our assumptions? Which planned hires actually require additional access? And which savings have moved from possible to contractually confirmed?
I’d also reconcile the contract register to actual spending.
Software purchased on employee cards, new usage-based charges, unrecorded renewals, and changes in billing terms can all make a beautifully maintained contract register incomplete.
If a subscription appears in actual spending but not the forecast, somebody should investigate.
If a contract is in the forecast but no longer appears in spending, that deserves a question too.
The point isn’t to create another dashboard full of colored circles. I have nothing against colored circles. I just like them better when they lead to a decision.
For more on making management information useful, see how to make management reports actionable.
When a Spreadsheet Stops Being Enough
A simple renewal register works well when the business has a relatively small number of contracts, clear owners, and reasonably straightforward pricing.
It becomes harder when subscriptions are purchased across multiple departments, business entities, credit cards, and procurement systems.
Usage-based billing adds another layer. So do multi-year agreements, currency exposure, minimum spending commitments, bundled products, and contracts that renew on different dates.
At that point, I’d want the contract data, accounting records, usage information, and financial forecast connected through a controlled process.
That doesn’t automatically mean buying another platform.
Sometimes it means improving purchasing approvals, establishing contract ownership, cleaning up vendor records, or building a reliable connection between systems the company already uses.
The objective is visibility and control, not collecting software tools like Beanie Babies in 1997.
Although, unlike some software subscriptions, at least the Beanie Babies didn’t automatically renew.
The Renewal Decision I’d Want on My Desk
Before approving a significant software renewal, I’d want a concise answer to five questions.
- What are we contractually committed to, and when can we change it?
- What do we actually use, and what will we need during the next contract period?
- What will the renewal cost under realistic pricing and license scenarios?
- What are the expense, cash, and switching-cost implications?
- Who is accountable for the decision before the notice deadline?
If those questions have credible answers, we can decide whether to renew, renegotiate, reduce, replace, or cancel.
If they don’t, I wouldn’t feel especially reassured by a software budget that happens to equal last year’s spending plus 5%.
That isn’t necessarily a forecast. It may simply be a subscription to our own assumptions.
I don’t think every software renewal needs an elaborate business case. A $20 monthly tool that solves a genuine problem probably doesn’t deserve a board presentation.
But when a company has substantial recurring software commitments, the cumulative cost of unexamined renewals can become a real financial issue.
If your finance team is struggling to connect contracts, software spending, and the forecast, my FP&A Function & Finance Systems services are a relevant place to explore improving the process.
I’d much rather help a business make the renewal decision while it still has options than explain afterward why the invoice arrived exactly as the contract said it would.
The vendor, after all, remembered the date.
Talk With Sarah About Your Finance Process









Leave a Reply
Want to join the discussion?Feel free to contribute!