Real IT budget planning 2027 software and AI spend cannot be a single line item, and this is the month to fix that if yours still is, not because the number needs to grow, but because a single line item hides three different kinds of spend with three different risk profiles, and November is too late to unpick them.
Why September, not November
Enterprise budget planning guidance consistently points to a 6–9 month lead time before a fiscal year starts. For a 2027 budget, that puts the real planning window in September 2026. By November, most organisations have already made their allocation decisions and are defending a number, not building one. If you are reading this in September, you are on time. If you are reading it in November, the honest advice is to move fast rather than move perfectly.
The four lines a software budget actually needs
Most software budgets collapse everything into "development." That hides the part that actually breaks planning: these four categories behave completely differently and deserve to be planned separately.
| Line | What it covers | Planning approach |
|---|---|---|
| New build | Net-new features and systems | Scoped project by project, the traditional budgeting unit |
| Maintenance & support | Keeping what already exists running | A percentage of build cost, planned annually, not a one-off |
| AI integration | Model/API costs, prompt and eval maintenance, monitoring | A recurring operating cost, closer to a utility bill than a project |
| Compliance | Regulatory obligations tied to specific dates | Deadline-driven, not proportional to anything else |
Build-vs-maintain: the ratio everyone forgets
The number most teams anchor a new-build budget to is the build cost itself, and then stop. A widely cited industry planning ratio puts annual maintenance at roughly 15–20% of the original build cost: support, bug fixes, small enhancements, keeping dependencies current. That is a planning ratio, not a guarantee: a system with real technical debt or an unusually high rate of change will run above it, and a stable, well-built system can run below it. What matters for budgeting purposes is that the line exists at all. A build budget with no corresponding maintenance line is a budget for year one only.
The AI-integration line item
AI features do not behave like a one-time build cost, and budgeting them as one is the most common mistake we see in 2027 planning conversations already. Once a feature is live, you are paying for it continuously: model or API usage that scales with actual traffic, ongoing prompt and evaluation maintenance as the underlying model or your product changes, and monitoring for the kind of silent quality drift that a traditional feature simply doesn't have. Budget it the way you would budget a SaaS subscription that scales with usage, not the way you'd budget a one-time build.
The compliance line that lands specifically in 2027
Here is the detail nobody's 2027 planning template has yet: the 2026 Digital Omnibus deferred the EU AI Act's high-risk obligations for standalone Annex III systems to 2 December 2027, inside the fiscal year most organisations are budgeting for right now. If any system you run performs high-risk functions under Annex III (certain employment, credit, or safety decisions, for example), conformity assessment and registration work needs budget and lead time well before that date, not a scramble in Q4 2027. We cover what actually moved and what didn't in the EU AI Act's transparency rules here if you need the fuller regulatory picture; Annex III's high-risk regime is the deferred sibling to that post's Article 50 obligations, and it is the one that now lands inside next year's budget.
A worked line-item worksheet
For each system or initiative, budget four numbers, not one:
- Build cost: the scoped project cost, as usual.
- Year-one maintenance: 15–20% of build cost as a planning starting point, adjusted for known technical debt or change rate.
- AI operating cost: projected monthly model/API spend × 12, plus an allowance for prompt and eval maintenance.
- Compliance cost, if applicable: scoped separately, against the actual deadline that applies to your system, not a generic "AI Act line."
Sum those four per initiative, not one blended guess per department. It is more work up front and it is the version that survives a Q3 review without a surprise.
Getting a real number instead of a guess
A worksheet gets you a planning range. It does not replace someone who has actually scoped work like yours recently telling you where your specific number is likely to land. If budget season is the reason you're reading this, that is exactly the conversation worth having now rather than in November. A 45-minute scoping session gets you a defensible number for the line item, not a guess dressed up as one. For the fuller build-cost picture behind line one of the worksheet, see what custom software actually costs in 2026, and for how we structure the engagement itself, see how we work. When the budget line is approved and you go out to vendors, our software development RFP template is what turns the planning range into quotes you can compare side by side.
Common questions
A widely cited industry rule of thumb is roughly 15-20% of the original build cost, per year, for ongoing maintenance and support. Treat that as a starting planning ratio, not a quote. Actual maintenance load depends heavily on how much the system changes after launch and how much technical debt shipped with it.
Two things worth a line item of their own: ongoing AI model/API costs as a recurring operating expense rather than a one-time build cost, and, for anyone running a high-risk AI system under Annex III of the EU AI Act, compliance work ahead of the 2 December 2027 deadline that the 2026 Digital Omnibus deferred into this exact budget year.
Planning guidance across the industry converges on 6-9 months of lead time for enterprise software budgets, which puts the real planning window in September 2026, not November, by which point most allocation decisions are already made.
Its own line, for the same reason maintenance gets its own line. Folding it into general software spend is how it gets forgotten or under-scoped. Ongoing model costs, prompt/eval maintenance and monitoring behave more like a recurring service cost than a one-time build cost.