A software budget is the planned ceiling for everything the business expects to pay for tools, platforms and subscriptions across the coming year. Building it from last year's total plus a percentage produces a number nobody can defend. Building it from this year's register, line by line, produces a plan the team can explain, challenge and actually hold. This guide shows how to plan next year's software budget from the register you already keep.
Key Points
- A software budget built line by line can be explained and defended.
- The renewals map is the skeleton: every line at its renewal price.
- Growth allowance belongs to named plans, not to a general percentage.
- A written cut list keeps reduction decisions ahead of pressure.
- The budget stays useful only when reviews compare it with the register.
Start From The Register, Not From Last Year's Total
Last year's total mixes together lines that were cancelled, lines that arrived mid year and prices that have already changed. Carrying it forward with a percentage copies every one of those errors into next year's plan. The register, by contrast, knows exactly which lines will exist on the first day of the new year and what each one costs.
Our renewal calendar guide shows how to build the view of dates this map depends on. Begin with the lines that survive into the new year at their current prices. That figure is the honest baseline: not a target, not a wish, but the cost of standing still. Every later adjustment to the software budget is then a visible decision added to or removed from that baseline, which is what makes the final number defensible in a budget meeting.
Build The Renewals Map For The Year
Lay every renewal in the coming year on one map: the service, its date, its current annual value and the price expected at renewal under its contract terms. Some lines carry agreed steps. Some contracts allow seat corrections. Some renewals are simply undecided, and the map should mark them that way rather than assuming they roll over unchanged.
The renewals map is the skeleton of the budget because it shows when money decisions fall due. Heavy renewal months deserve negotiation time booked ahead. Quiet months absorb the planned additions. Renewals keeps these dates with the deadlines in front of them, in the order the decisions will actually arrive.
Price The Lines You Already Know Will Change
Some changes are already certain before the year starts. A contract step agreed in writing. A tier the team has outgrown and formally decided to leave. A service bought for a project that ends in spring, whose cancellation is already recorded. Enter each known change at its expected price from its expected date.
| Budget Layer | What It Holds | How It Is Priced |
|---|---|---|
| Surviving Lines | Lines Continuing Into The New Year | Current Prices From The Register |
| Known Changes | Agreed Steps And Recorded Endings | Contract Terms And Decisions |
| Growth Allowance | Seats And Tools For Named Plans | Owner Estimates With Dates |
| Cut List | Lines Chosen For Reduction | Savings Counted From Their Dates |
Pricing known changes separately keeps the budget honest in both directions. It stops the plan pretending that agreed increases will not happen, and it stops cancelled lines quietly funding new purchases twice. The reader can see the baseline, the settled changes and the judgement calls as three distinct layers.
Give Growth A Name, A Number And A Date
Growth is real, and a software budget that forbids it simply gets bypassed. Teams will hire, projects will start and tools will need more seats. The planning task is not to deny growth but to make it specific: which team grows, by how many seats, on which tools, starting when, owned by whom.
Enter each growth item as its own line with an owner and a start date, priced from the actual plans it will use. Vague allowances pooled into one percentage line invite spending to fill them. Named lines invite review: when the hire slips, the line slips visibly with it. Our spend forecasting guide uses these same named items as its assumption layer each quarter.
Write The Cut List Before You Need It
Every register carries lines the business suspects but has not decided about: the duplicate tool, the oversized tier, the service one project used. Write them into the budget as a named cut list, each with its decision date at renewal and the saving counted only from that date, not from January. The list also names who decides each item, so a renewal never arrives with its decision still homeless.
A written cut list changes budget pressure completely. When the year demands savings, the business executes decisions it already made calmly instead of hunting in a panic. When the year goes well, the list still gets reviewed at each renewal, because a line earns its removal from the list with evidence, not with a good quarter.
Set The Ceiling And The Review Rhythm Together
The budget total that emerges from these layers is the ceiling: baseline, plus known changes, plus named growth, minus the cut list as its dates land. Present it to whoever approves budgets in that layered form. Approvers trust a number whose construction they can inspect, and they challenge the right layer instead of the whole plan.
Agree the review rhythm at the same meeting. Quarterly, the register is compared with the budget layers: which lines drifted, which growth items landed, which cut decisions came due. The guide to creating a business budget covers the wider company budget this software plan sits inside, including how category ceilings are set and held.
Keep One Owner For The Software Budget
A budget owned by everyone is revised by no one. Name one owner for the software budget, usually the person who runs the register reviews. The owner maintains the layers during the year: moving settled renewals into the baseline, adding approved growth, marking cut decisions as executed or deferred with reasons.
Ownership does not mean the owner approves every purchase. Approvals still run through the normal request route. It means one person can always answer the question of how the year is tracking against the plan, from live figures rather than from a spreadsheet rebuilt for the occasion. When the owner changes, the layers hand over like the register does, with the year's decisions and reasons intact. Our quarterly spend review guide gives that owner the meeting format for the comparison.
Separate Running Costs From Change Costs
A healthy software budget distinguishes the cost of standing still from the cost of changing. Running costs are the surviving lines doing this year's work. Change costs are the projects: the migration, the new platform rollout, the consolidation that costs money this year to save it next year. Mixing the two hides both, and the run rate gets blamed for the projects it carries.
Present change costs as their own layer with end dates. A migration that finishes in June should stop appearing in forecasts after June, and its promised effect on running costs should be visible as a known change when it lands. This separation also protects change from panic cuts, because the room can see exactly which future saving a cut would cancel. Readers of the budget learn to ask two questions instead of one: what does standing still cost, and what is change buying us?
Protect A Small Contingency Without Hiding It
Some software spending genuinely cannot be foreseen in November: a tool a new client requires, a price change outside contract protection, a replacement for a service that fails. A small, explicit contingency line serves the budget better than pretending otherwise, provided it is governed: named as contingency, drawn only through the normal request route, and reported on whenever it is used.
The discipline is in the reporting. Contingency spent silently becomes a general allowance, and general allowances become expectations. Contingency reported quarterly, item by item, usually shrinks year by year, because the review keeps discovering that most surprises were foreseeable lines that planning simply missed, and the planning improves.
Close The Year By Explaining Every Layer
The budget's final service is the year end explanation. Compare each layer with what actually happened: surviving lines against their baseline, known changes against their contract outcomes, growth lines against the plans they funded, the cut list against the decisions executed. Every difference gets one sentence of cause, written by the budget owner while the year is still remembered.
That explanation is next year's planning document. It shows which owners estimate well, which suppliers' steps keep surprising, and which categories nobody can forecast yet. A business that writes it three years running owns a planning memory that no new spreadsheet can imitate, and its software budgets get calmer every single year.
Final Verdict
A software budget earns its authority from its construction: surviving lines from the register, known changes at contract prices, growth as named lines with owners and dates, and a written cut list that turns pressure into execution. Built that way, the ceiling can be defended line by line and reviewed quarterly without rebuilding it. Our article on business budgeting mistakes shows the failure modes this method avoids.
Ready to plan from the register instead of from last year's total? Spends Control keeps the lines, renewal dates and contract terms the budget is built from in one workspace.
Frequently Asked Questions
What Is A Software Budget?
A software budget is the planned ceiling for everything a business expects to pay for tools, platforms and subscriptions across a year. Built properly, it is layered: surviving register lines at current prices, known changes at contract prices, named growth items, and a written cut list with decision dates.
How Do You Build A Software Budget From A Register?
Start with the lines that continue into the new year at current prices. Add the renewals map with agreed price steps and recorded endings. Add growth only as named lines with owners and start dates. Finish with a cut list whose savings count from their renewal dates, then set the ceiling.
Should A Software Budget Include A Growth Percentage?
A general percentage invites spending to fill it and hides which plans the money serves. Named growth lines work better: the team, the seats, the tool and the start date, priced from real plans. When a named plan slips or cancels, its budget line moves visibly with it.
When Should The Cut List Be Written?
Before the year starts, calmly, from the register lines the business already suspects: duplicates, oversized tiers and project tools nearing their end. Each item gets a decision date at its renewal. Writing the list under pressure produces panic cuts; writing it early produces executed decisions.
How Often Should A Software Budget Be Reviewed?
Quarterly, against the register. The review moves settled renewals into the baseline, checks which growth items landed, and confirms which cut decisions came due. Monthly checks suit the largest lines, but the full layered comparison four times a year keeps the budget a live plan rather than an annual artefact. The owner keeps the layers current between reviews, so the quarterly comparison stays a reading rather than a rebuild.
