IT budgeting for small business: how to plan technology spend for the year

Most small business IT budgets are built the same way. Someone in finance opens last year’s general ledger, filters for anything that looks like technology, adds a few percent for inflation, and drops the total into next year’s plan. If a big project is already agreed, it gets bolted on as a separate line. The whole exercise takes about two hours and produces a number that is wrong in a specific and predictable way: it funds the environment you had last year, not the one the business is about to need.

That approach survives because it usually does not fail loudly. It fails quietly, in the third quarter, when a server reaches end of support that nobody tracked, or a cyber insurance renewal demands a control you have not bought, or a licensing price increase lands that was announced nine months earlier. At that point the money is committed elsewhere, the request goes to leadership as an emergency, and the business pays retail for something it could have planned for at a discount. The budget did not really exist. It was a forecast of the past.

This article is about the process rather than the number. It covers how to run an annual technology budget cycle: when to start, what to gather, how to structure the budget so it survives scrutiny, how to present it to people who do not want a technical briefing, what to do when it gets cut, and how to track it through the year so the December version and the June reality are still recognisably related. If what you need is the number itself, how much should a small business spend on IT covers benchmarks by industry, the six standard line items, and the hidden costs that distort them. That article answers how much. This one answers how.

Short answer

An annual IT budget should be built from your IT roadmap, not from last year’s invoices, and the cycle should start roughly 90 days before your fiscal year begins. Work through it in seven steps: pull the prioritized initiatives off the roadmap, establish the recurring baseline from a complete renewal register, price the planned projects at total cost rather than sticker price, split the result into run, grow, and transform spend, decide what is capital and what is operating expense, add a contingency that is defined rather than decorative, then package the whole thing into a one page summary that leads with business outcomes. Present it as an option set with the consequences of not funding each item stated plainly, never as a single take it or leave it number. Then review it quarterly against actuals and reforecast formally at the midpoint. The budget that gets approved is rarely the most detailed one. It is the one whose owner can answer what happens if we do not do this.

The annual IT budget cycle at a glance

Question	Short version
When does it start?	About 90 days before the fiscal year, so October for a January start.
What is the input?	The IT roadmap, the renewal register, and last year’s actuals.
Who builds it?	IT or your provider drafts it. Leadership owns and approves it.
How is it structured?	Run, grow, and transform, split further into capital and operating expense.
How much contingency?	Five to ten percent, defined by what it is for, not left as a slush line.
How long should the document be?	One page for leadership. The detail lives underneath it.
What gets presented?	Three to four numbers, an option set, and the risk of not funding each.
How often is it reviewed?	Quarterly against actuals, with a formal reforecast at the midpoint.
What is a good variance?	Within about ten percent for the year, excluding genuine incidents.
What is the most common failure?	Building it from invoices instead of from a plan.

Why most small business IT budgets fail before they are written

There are three failure patterns and almost every unusable IT budget is one of them.

It was assembled from invoices. Accounting data tells you what you spent. It does not tell you what you deferred, what you underfunded, or what you are about to be forced to buy. A budget built purely from the ledger encodes every one of last year’s mistakes into next year’s plan, and it systematically underfunds anything that was skipped, which is usually the least visible and most important work: backup testing, patching capacity, security tooling, hardware refresh.

It was built by IT alone. A budget written entirely by technical staff or a technical provider tends to be a shopping list with justifications attached. It is accurate and it is unpersuasive, because it answers the question what do we want to buy rather than the question leadership is actually asking, which is what happens to the business if we do not. Budgets fail in the approval meeting far more often than they fail in the spreadsheet.

It is a single number with no structure. IT: 340,000 dollars. There is nothing in that line to negotiate with. When margins tighten, an unstructured number gets cut by a percentage, and a percentage cut applied to an unstructured budget always lands on whatever is easiest to stop paying, which is almost never the thing that should have been stopped. Structure is what lets you cut deliberately instead of arbitrarily.

The fix for all three is the same. The budget is the financial expression of a plan that already exists. If the plan does not exist, you are not budgeting, you are estimating.

The budget season calendar

For a business whose fiscal year starts in January, the cycle looks like this. Shift every row by the same offset if your year starts elsewhere. The point is not the specific months. It is that a budget needs about a quarter of lead time, and that the work is sequential.

Timing	What happens	Who is involved
September	Refresh the current state inventory. Confirm asset ages, end of support dates, user counts, and actual license consumption.	IT or provider
Early October	Annual roadmap rebuild. Confirm business goals for the coming year, re-prioritize initiatives, drop what is no longer relevant.	Leadership and provider
Mid October	Build the renewal register. Every contract, subscription, and support agreement with its date, cost, term, and notice period.	IT and finance
Late October	Price the roadmap initiatives at total cost. Get real quotes for anything above a material threshold.	Provider and vendors
Early November	Assemble the draft budget. Run, grow, transform. Capital and operating expense separated. Contingency defined.	IT and finance
Mid November	Internal review. Pressure test against a downside revenue case. Prepare the option set.	Finance and leadership
Late November	Present to leadership or the board. Decisions made, not deferred.	Everyone
December	Revise, approve, and communicate. Anything deferred is recorded as accepted risk with a named owner.	Leadership
January	Budget goes live. Renewal dates and project start dates loaded into a shared calendar.	IT and finance
Quarterly	Review actuals against plan. Reforecast formally at the midpoint.	Finance and provider

The single most common scheduling mistake is starting in late November. At that point there is no time to get real quotes, so the numbers become estimates, and estimates are what get challenged first in the approval meeting. The second most common is treating the roadmap rebuild and the budget build as one session. They are different activities with different participants and they produce a better result when they are a fortnight apart, because leadership needs time between deciding what matters and deciding what to pay for.

Step 1: Start from the roadmap, not from last year’s invoices

The budget is downstream of the roadmap. That ordering is the whole difference between a plan and a projection, and it is worth being concrete about what it means in practice.

The roadmap has already decided which initiatives matter, in what order, and why. It has already made the sequencing calls, which is where most of the money is saved or wasted. What the budget does is attach a defensible number to each of those decisions and spread them across four quarters in a way the business can actually absorb. If you find yourself deciding during the budget build whether the file server migration should happen before or after the identity project, stop. That is a roadmap question, and answering it inside a spreadsheet with only finance in the room is how businesses end up paying to do the same work twice.

If you do not have a roadmap, the practical path is not to skip it. It is to build a compressed one first. Two working sessions is usually enough for a first pass at small business scale: one to establish business goals and obligations for the coming year, one to inventory what you have and identify the gaps. A network assessment is often the cheapest way to produce the inventory half of that, and it has the useful property of being an independent view rather than an internal one.

What comes out of this step is a list of funded candidates. Not a budget yet. A list of things the business has already agreed it wants to do, each with a rough size and a target quarter.

Step 2: Establish the recurring baseline

Before anything new gets priced, you need to know what next year costs if the business does absolutely nothing differently. Most small businesses get this number wrong, and they get it wrong in the same direction: too low, because subscriptions accumulate quietly and nobody holds the full list.

Build a renewal register. It is a single table, it belongs to finance rather than to IT, and every row captures the same fields.

Field	Why it matters
Vendor and product	Obvious, but many businesses have two rows that turn out to be the same product bought twice.
Annual cost	The comparable figure. Convert monthly billing to annual so like sits beside like.
Renewal date	Drives the calendar. Also tells you which quarter absorbs the cost.
Notice period	The date you actually have to decide by, which is earlier than the renewal date.
Licensed count versus used count	The single largest source of recoverable spend at most businesses.
Internal owner	Someone who can answer whether it is still needed. Not IT by default.
Business justification	One sentence. If nobody can write it, that is the finding.
Auto renew status	Determines whether inaction is a decision.

Two things reliably fall out of this exercise the first time it is done. The first is licensing you are paying for and not using, which for most businesses is somewhere between five and twenty percent of the software line, concentrated in seats for departed staff and tools bought for a project that ended. Reducing Microsoft 365 costs without losing features covers the most common instance of this. The second is spend that never appears in the IT budget at all because it sits on a departmental card: design tools, scheduling apps, AI subscriptions, storage accounts. It is real spend on real business systems and it belongs in the picture even if it stays in a departmental cost centre.

The baseline also has to account for price increases rather than assuming flat renewal. Assuming last year’s price for a subscription renewing next year has been a losing bet for several years running. Where you have a contracted rate, use it. Where you do not, budgeting a modest increase and being pleasantly surprised is a better failure mode than the reverse.

Step 3: Price the projects at total cost, not sticker price

A quote is not a budget line. The quote is the first year licence or the hardware cost, and for most technology projects that is somewhere between half and three quarters of what the project actually consumes. The items that get missed are consistent enough to be checked against a list.

Cost component	Frequently missed because
Implementation and professional services	Often quoted separately, or assumed to be included when it is not.
Data migration	Scoped by volume, and the volume is usually underestimated.
Parallel running	Old and new systems both cost money during a cutover period.
Internal staff time	Real cost even though it never appears on an invoice.
Training and change management	Cut first, then blamed later for poor adoption.
Year two recurring	The subscription that starts in Q3 costs four times as much next year.
Integration work	Two systems that both do their job and do not talk to each other.
Decommissioning the old thing	Contract exit, data extraction, disposal, sometimes an early termination fee.

The year two effect deserves particular attention because it is the one that quietly breaks the following year’s budget. A tool that goes live in October costs three months of subscription this year and twelve next year. If several projects land late in the year, next year’s baseline is materially higher before a single new initiative is added, and the business experiences that as IT spend growing without anything visible being bought.

For anything above a threshold you set yourself, get a real quote rather than an estimate. Where a real quote is genuinely unavailable at this stage, label the line as an estimate with a confidence range instead of presenting a false precision. Leadership handles a stated range far better than it handles a number that turns out to have been a guess.

Step 4: Split the budget into run, grow, and transform

This is the structural move that changes how a budget gets discussed, and it costs nothing to adopt.

Category	What it covers	Typical share
Run	Keeping the current environment operating: support, licensing, connectivity, security tooling, backup, patching, hardware replacement in cycle.	60 to 75 percent
Grow	Extending what exists to serve more people or more work: additional seats, capacity, an office, a system that scales with headcount.	15 to 25 percent
Transform	Changing how the business works: a platform migration, a new line of business system, an automation programme, a compliance build.	10 to 20 percent

The shares are reference points, not targets. The value is in the conversation the split produces. A business spending ninety percent on run has no capacity to change anything and will be overtaken by competitors who do. A business proposing forty percent on transform is planning more simultaneous change than a small team can absorb, and the usual outcome is that everything runs late. Neither of those observations is available from a single total, and both are obvious the moment the split is on the page.

The split also makes cuts survivable, which is the point at which most budgets actually get decided. When leadership asks for fifteen percent off, an unstructured budget forces an arbitrary reduction. A structured one lets you answer precisely: transform can absorb it by deferring one initiative to next year, at a stated cost in delay and risk, and here is what that means. That is a negotiation. The other version is a haircut.

Step 5: Separate capital from operating expense

Finance cares about this distinction more than IT usually expects, and understanding why makes the approval conversation shorter.

Capital expenditure buys an asset that is depreciated over several years. It hits cash immediately but the profit and loss statement gradually. Operating expenditure is consumed in the period. It hits the profit and loss statement immediately. The same technology can land in either category depending on how it is acquired, and the choice is a legitimate business lever rather than an accounting technicality. Buying twenty laptops outright is capital. Leasing them, or taking them as a service, converts that into a predictable operating cost with no large single hit. Which is better depends on the business’s cash position, its borrowing situation, and how it prefers its numbers to look, and those are finance’s decisions to make. Your job is to present the option, not to pre-empt it.

Two things follow from this that are worth building into how the budget is presented. First, the approval path is often different. Capital frequently needs board sign off above a threshold while operating expense sits within management authority, which means the capital items need more lead time and better documentation. Second, the long term drift is one way: cloud services, subscription licensing, device as a service, and managed services all convert capital into operating expense. That is usually a good outcome for a small business because it smooths cash and removes refresh cliffs, but it means the operating expense line grows year over year even when total cost is flat or falling. Say so explicitly in the presentation, or you will be asked why IT running costs keep rising and the honest answer will sound like an excuse.

Consult your accountant on the specific treatment of any material item. The categorisation rules vary by jurisdiction and by the structure of the purchase, and getting it wrong is a tidy way to turn a good decision into a bad one.

Step 6: Build contingency that survives contact with reality

Every IT budget needs contingency and most of them have a line called contingency that does no work, because it is a single round number with no stated purpose. The first time something goes wrong, it gets spent, and the second time there is nothing left.

Define it by what it is for. In practice there are two distinct pools and they behave differently.

Incident and failure reserve. For unplanned events: a hardware failure outside refresh cycle, an incident requiring outside help, an emergency replacement. This is genuinely unpredictable, it should be sized against your actual exposure rather than a rule of thumb, and it should be released back or carried forward rather than spent down at year end because it was there. Sizing it is easier once you know what an incident actually costs, and how much a data breach costs a small business is a useful starting point for the upper end of that range.

Price and scope variance. For known unknowns: a renewal that comes in higher than budgeted, a project that runs ten percent over, a licensing model change. This is much more predictable and is often better handled as a modest uplift inside each line than as a central pot, because a central pot invites the first person to reach it to take all of it.

Five to ten percent of total spend across both is the range most small businesses land in. Regulated businesses and those with aging infrastructure sit at the top of it. What matters more than the percentage is that the rules are agreed in advance: who authorizes a draw, what it may be used for, and what happens to the balance at year end. Contingency without rules is not contingency. It is the first place a cut lands, because nobody can defend a number that has no stated purpose.

Step 7: Package it for people who do not want a technical briefing

The budget document has two layers and they are for different readers. Underneath there is the detail: every line, every renewal, every quote. That layer exists to answer questions, not to be read. On top there is one page, and that page is what gets discussed and approved.

The one page carries four things and nothing else.

The total, split three ways. Run, grow, and transform, with last year’s actuals beside them for comparison. Three numbers, not thirty.

The change and its cause. Whatever the movement is against last year, name the two or three drivers in plain terms. Headcount growth, a licensing increase, a compliance obligation, one major project. Unexplained movement invites suspicion regardless of its size.

The initiative table. One row per proposed initiative, in priority order, with the same four columns each time.

Initiative	Cost	What it delivers	If we do not fund it
Server refresh and migration	Capital, quoted	Removes the last on premise single point of failure before the lease ends	Hardware is out of support in August. Emergency replacement at retail, plus an unplanned outage risk we cannot quantify.
Endpoint detection and response	Operating, annual	Continuous monitoring and response across all devices	Renewal of the cyber insurance policy in June is at risk. The policy requires it.
Multi factor authentication rollout	Low, mostly internal time	Closes the most exploited entry point across all accounts	The single highest likelihood incident scenario stays open at effectively no cost to close it.
Phone system replacement	Operating, annual	Removes an unsupported platform and a manual call handling process	Nothing breaks this year. It gets more expensive to move later.

That last column is the one that changes the outcome of the meeting, and it is the one most technical budgets leave out. It is also where honesty pays. If the answer to what happens if we do not is nothing much this year, write that. A budget where every single line is presented as urgent teaches leadership that none of them are.

The recommendation. Not a menu. A recommended option with a stated rationale, plus a reduced option and what it costs the business in delay and risk. Presenting exactly one number with no alternatives is what forces leadership to invent their own reduction, and their reduction will be worse than yours because it will be based on which words looked least important.

Presenting the budget to non-technical leadership

The failure mode of a technical budget presentation is that it is accurate, complete, and unpersuasive. A handful of rules fix most of it.

Lead with the business, not the technology. Open with what the business intends to do next year and what technology has to be true for that to happen. The spend follows from that. Opening with a product name loses the room in the first sentence.

Translate every item into money, time, or risk. Those are the three currencies leadership operates in. End of support becomes no security patches after this date and an insurance exposure. Latency becomes staff hours lost per week. A version upgrade becomes a compliance requirement with a deadline attached.

Bring the downtime number. If a full day of downtime costs the business a figure you can defend, most arguments about redundancy, backup, and continuity spend resolve in one sentence. If nobody has ever calculated it, calculating it is worth more than anything else in this list.

Answer the question that is actually being asked. When a CFO asks why IT costs keep going up, the question is usually not accusatory. It is a request for a structure they can reason about. Run, grow, and transform is that structure.

Do not oversell. Presenting everything as critical is the fastest way to lose the credibility you need for the item that genuinely is. Rank honestly and defend the ranking.

Bring the comparison, not just the cost. The cost of a managed services agreement is only meaningful beside its alternatives. How much managed IT services cost and how MSPs are paid both help frame that conversation, particularly where leadership is comparing an outsourced arrangement against hiring internally.

If the audience is a board rather than an owner, expect the security portion to get the most attention and prepare it separately. A board wants current posture, the top three risks, what closing them costs, and what has changed since the last review. It does not want a tool inventory.

When the budget gets cut

It usually is, at least partially. Handling that well matters more than the initial ask, and there is a defensible order.

Defer transform first, because deferral is the only cut that does not create risk, only delay. Then reduce grow, accepting that capacity gets tighter. Then look hard at run, and look at it for duplication and unused licensing rather than for capability. That order should be the recommendation you arrive with, before it is requested.

Some things should not be cut, and the reason is not that they are technically important. It is that cutting them transfers a large risk onto the business in exchange for a small saving.

• Backup, and specifically backup testing. An untested backup is a line item that buys nothing.
• Patching capacity, including the labour to actually do it rather than just the tooling.
• Anything your cyber insurance policy requires as a condition of cover. Removing a required control can invalidate a claim, which converts a small saving into an uncapped exposure.
• Anything with a compliance deadline attached to it.
• Hardware already past end of support, where the deferral is not saving money but accruing it.

When something does get deferred, record it. A one line entry naming what was deferred, what the exposure is, who accepted it, and when it will be revisited. This is not a paper trail for its own sake. It is what turns next year’s budget conversation into a continuation rather than a fresh argument, and it is what stops a deferred item from silently becoming a permanent gap. A recurring quarterly business review with your provider is the natural place for that list to live.

Tracking and reforecasting through the year

An approved budget that nobody looks at again until next October is a document, not a control. Three habits keep it real.

Quarterly variance review. Actuals against plan, by category. Small variances are noise. What you are looking for is a category drifting in one direction consistently, which usually means the baseline was wrong rather than that spending is out of control.

A formal midpoint reforecast. At the halfway mark, rebuild the second half projection using what you now know: real renewal prices, actual project costs, changes to headcount. The reforecast is not an admission that the budget was wrong. It is the difference between finding out in July and finding out in December.

Renewal and end of support dates in a shared calendar. Every renewal notice period and every end of support date, visible to both IT and finance, with a reminder ahead of the decision date rather than the renewal date. This single habit prevents the most common form of unplanned IT spend, which is not a disaster. It is a deadline that arrived without warning. When to replace business network equipment covers how to set those dates for infrastructure that does not announce its own retirement.

A worked example

A 40 person professional services firm, January fiscal year, currently with a managed services provider and no formal budget process. Here is what the first proper cycle looked like.

Month	What happened	Outcome
September	Inventory refresh. Found two servers past end of support, 11 laptops over four years old, and a backup appliance out of warranty.	Three items that were going to be emergencies became planned line items.
Early October	Roadmap session with the two owners. Business goal was a second office in the second half of the year.	Reordered the plan. Identity and file access work moved ahead of the phone system.
Mid October	Renewal register built for the first time. 31 subscriptions found, 9 of which nobody could justify.	Recovered a mid four figure annual sum, immediately reallocated to security tooling.
Late October	Quotes obtained for the server migration and the laptop refresh.	Migration came in 30 percent above the initial estimate once data migration was scoped properly.
November	Draft built. Run 68 percent, grow 19 percent, transform 13 percent. Contingency at 7 percent with written rules.	Structure made the second office cost visible as its own decision rather than a surprise.
Late November	Presented to the owners. Recommended option plus a reduced option.	Phone system deferred to the following year and recorded as accepted risk. Everything else approved.
March	Q1 review. Licensing tracking slightly under, project spend on plan.	No action.
June	Midpoint reforecast. Second office confirmed for September, one quarter later than planned.	Moved spend between quarters rather than requesting more.
September	Second office opened. Costs within the grow allocation.	No emergency request all year, for the first time in the firm’s history.

The recovered licensing spend roughly paid for the security tooling that had been deferred for two years running. That is a common pattern rather than a lucky one, and it is the strongest practical argument for building the renewal register even if nothing else in this process gets adopted.

Common mistakes

Building the budget from the ledger. It encodes last year’s deferrals as next year’s plan.

Starting too late. A budget assembled in three weeks is built on estimates, and estimates are what get challenged first.

Presenting one number with no structure. It invites a percentage cut, and a percentage cut lands on whatever is easiest to stop paying rather than whatever matters least.

Leaving out year two recurring costs. A subscription that starts in October costs four times as much next year, and next year’s budget gets blamed for it.

Treating contingency as a round number. Undefined contingency gets spent on the first thing that goes wrong and is the first line to be cut when it has no stated purpose.

Ignoring internal time. Staff hours spent on a migration are real cost. Excluding them makes projects look cheaper than they are and makes the team look slower than it is.

Assuming flat renewal pricing. Budgeting last year’s price for next year’s subscription has been a losing bet for several years running.

Marking everything as critical. It teaches leadership that nothing is, and it costs you the argument on the item that genuinely matters.

Budgeting flat against a growth year. Twenty percent more headcount is more than twenty percent more IT, because new people need devices, licences, security tooling, and onboarding time.

Never reforecasting. A budget nobody revisits until year end is a record of what you once believed, not a control on what you are spending.

How this fits the rest of your IT

The budget sits directly beneath the IT roadmap and directly above every project plan. The roadmap decides what the business is going to do and in what order. The budget decides how it gets paid for and in which quarter. Built in that order, they agree with each other. Built independently, which is the usual pattern, they diverge by about the second quarter and the roadmap quietly becomes aspirational.

For the numbers themselves, how much a small business should spend on IT covers benchmarks as a percentage of revenue by industry, the six standard line items, and the hidden costs that make an apparently reasonable budget insufficient. It is the companion piece to this one and the natural next read if your open question is whether your total is in the right range at all.

Above both sits the vCIO role, which is the function that owns this cycle when a business is too small for a full time CIO and too complex to keep making these calls ad hoc. Alongside it, managed IT services make the largest single line in most small business IT budgets predictable, which is a substantial part of why businesses move to that model in the first place. If you have internal IT staff already, co-managed IT covers how the budget ownership usually divides between an internal lead and an outside provider.

Two adjacent areas commonly distort a budget that is otherwise sound. Cloud spend drifts upward without anyone deciding that it should, and cloud cost management covers how to bring it back under control. And if you are evaluating whether your current provider should be the one helping you build this at all, what to ask before you sign with an MSP covers how to tell a provider who does real planning from one who lists it on a web page.

What is next in this series

The next article covers aligning IT strategy with business goals: why technology decisions made in isolation from the business plan produce waste and friction, the questions worth asking before any investment is approved, how to run a technology review alongside annual business planning, and the misaligned spending patterns that show up most often at small business scale. Budgeting well is a process discipline. Making sure the process is pointed at the right things is a strategy discipline, and the second one is what makes the first one worth doing.

How Sequentur can help

Sequentur builds annual technology budgets with our clients as a standing part of managed IT and vCIO engagements, for small and medium-sized businesses across the 15 to 250 employee range including regulated industries such as healthcare, legal, financial services, and defense contractors. In practice that means a current state inventory with real costs and end of support dates attached, a renewal register we maintain rather than rebuild every year, quoted scope and cost for the initiatives on your roadmap, a budget structured so it can be presented to an owner, a CFO, or a board without translation, and a quarterly review where variance gets discussed while there is still time to act on it.

If next year’s technology budget is currently last year’s number with a percentage added, schedule a call and we will walk through what a structured cycle would look like for your business. If the conclusion is that your spend is already in the right range and the only thing missing is the process around it, we will tell you that, and the process is the cheaper half to fix.