IT budgets 2026: how to present the technology business case

Budgets get decided in October

Most European companies close their next-year budgets between October and December. For technology leaders, this means the 2026 IT business case is being presented right now. The quality of that document determines whether critical projects get funded or deferred another year.

The problem is rarely a lack of needs. It is how those needs are presented. A CTO who arrives at the board meeting with a list of technology projects and their costs, without connecting each line to business impact, loses before the conversation starts.

Benchmarks that provide context

Before presenting numbers, you need sector context. The CFO’s questions are predictable: are we spending too much or too little on IT? Are we aligned with the industry?

Reference data for 2025-2026 (sources: Gartner IT Key Metrics, IDC, Forrester):

• IT spend as % of revenue: global average 5.5%. Logistics: 3.5-4.5%. Banking: 7-10%. Retail: 2.5-4%. Construction: 1.5-3%. Professional services: 5-8%.
• Year-over-year IT spend growth: estimated average +8% for 2026. Generative AI is inflating the figure; without it, baseline growth is 4-5%.
• Typical distribution: 65-70% run (keep existing systems going), 20-25% grow (improve), 10-15% transform (innovate). Companies investing less than 10% in transformation are, in practice, accumulating technical debt.

These benchmarks are not prescriptions. A logistics firm at 3% IT spend is not necessarily underperforming; it depends on their automation level and strategic objectives. But they provide a reference frame that the board understands.

The prioritization framework

Not all IT projects compete in the same league. A useful framework for organizing the budget proposal classifies investments into four categories:

Mandatory (compliance/risk). Non-optional projects: security updates, regulatory compliance (NIS2, DORA, digital CSRD), end-of-life infrastructure renewal. These do not need ROI because the cost of not doing them is quantifiable and greater. Present them as risk management, not investment.

Maintenance (keep the lights on). Licenses, support, version upgrades, hardware refresh. This is the 65-70% of the budget everyone wishes they could shrink but that sustains operations. The argument is not ROI; it is operational continuity. The cost of a service interruption (downtime hours multiplied by cost per hour) justifies these line items.

Improvement (operational efficiency). Process automation, cloud migration, system integration, tooling upgrades. This is where measurable ROI lives. The challenge is quantifying it correctly.

Transformation (competitive advantage). New capabilities that change how the company competes: applied AI, digital products, new channels. ROI is more uncertain, but the opportunity cost of not investing can be existential in the medium term.

The budget proposal should present all four categories separately, with distinct arguments for each. Mixing a cybersecurity compliance line item with an experimental AI project in the same section guarantees that both will be questioned.

Building the business case the board approves

Speak the CFO’s language

The board does not approve “stack modernizations” or “technical debt reduction.” It approves investments that reduce costs, increase revenue, mitigate risk, or satisfy legal obligations.

Practical translation:

• “Migrate to Kubernetes” becomes “Reduce infrastructure costs by 30% (EUR 120K per year) and eliminate 14 hours of monthly manual deployment tasks.”
• “Implement observability” becomes “Reduce mean time to resolution from 4.2 hours to under 1 hour, avoiding X hours of annual downtime valued at EUR Y.”
• “Automate invoice processing” becomes “Eliminate 160 hours per month of manual work and reduce misclassification errors from 8% to 0.5%.”

Every project needs three numbers: total cost of ownership (3 years), quantified benefit (in euros, hours, or mitigated risk), and payback period.

Realistic payback periods

Boards distrust inflated ROI projections, and rightly so. An IT project promising 400% ROI in the first year is likely hiding costs or inflating benefits.

Realistic ranges by project type:

• Process automation: 6-18 month payback.
• Cloud migration: 18-36 months (the first year is often more expensive due to migration costs).
• Data/analytics platforms: 12-24 months for defined use cases, longer for generic capabilities.
• Applied AI: 9-24 months for concrete use cases (classification, extraction, routing). Much longer (or uncertain) for exploratory projects.

Honesty about payback builds credibility. Presenting a range (“we estimate payback of 12 to 18 months under these assumptions”) is more convincing than a magic number.

The cost of doing nothing

For infrastructure and compliance projects, the most powerful argument is not the ROI of the investment but the cost of inaction. Concrete examples:

• An end-of-life server without vendor support: the average cost of a security incident at a European SME is EUR 50,000-200,000 according to ENISA.
• Manual processes consuming 200 hours per month of skilled staff time: 200 hours at EUR 35 per hour equals EUR 84,000 per year in direct cost, not counting errors.
• Failing to comply with NIS2 or DORA before the deadline: fines of up to EUR 10 million or 2% of global turnover.

The cost of doing nothing is almost always greater than the cost of doing something. But it must be calculated explicitly so the board can see it.

Mistakes that sink valid proposals

We have seen dozens of technically sound IT budget proposals get rejected. The common errors:

Presenting a shopping list. “We need: new cloud platform (180K), BI tool (60K), network refresh (90K), security licenses (45K).” No narrative, no prioritization, no connection to company objectives. This is not a business case; it is a catalog.

Underestimating total cost. Including licenses but forgetting implementation, training, data migration, and ongoing support. An ERP that costs EUR 150K in licenses can cost EUR 400K total in the first year. The board that discovers hidden costs after approving the project loses confidence for the next budget cycle.

Failing to prioritize. If everything is priority one, nothing is priority one. The board needs to know what is lost if the budget is cut by 20%. Presenting three scenarios (minimum, recommended, optimal) with explicit impact of each cut enables an informed decision.

Ignoring the track record. If EUR 500K was approved last year for “digital transformation” and the results were vague, the board will be skeptical this year. Before asking for more, demonstrate that the previous investment worked: adoption metrics, validated savings, user satisfaction scores. There is no better argument for future investment than a solid execution history.

The proposal that works

An effective IT budget proposal follows a clear structure:

1. Context and alignment. Business objectives for 2026 and how technology supports them. Half a page at most.
2. Current state. Where we stand: key indicators of current IT operations (uptime, incidents, costs, internal satisfaction). One page.
3. Proposal by category. Mandatory, maintenance, improvement, transformation. Each project with cost, benefit, and payback. Two to three pages.
4. Scenarios. Minimum (mandatory plus maintenance only), recommended, and optimal. What is lost in each cut.
5. Execution roadmap. Quarterly calendar. What gets delivered and when.
6. Success metrics. How success will be measured. Concrete KPIs, not generic ones.

The complete document should not exceed 8-10 pages. If it needs more, the prioritization is insufficient.

The difference between an IT budget that gets approved and one that gets cut is rarely technical soundness. It is the clarity with which it connects technology to business outcomes, and the confidence that the presenting team inspires. Our consulting team can help you build the business case or conduct the technology diagnostic that underpins it.