August is when a lot of companies start assembling next year’s budget, and the AI section is usually the part written with the least evidence, because it is treated as a forecast rather than as a continuation of what already happened this year.
That is backwards for any company that ran even one project in the last twelve months. You have real numbers now. Use them.
Short answer: next year’s AI budget section should be built from this year’s fully loaded actuals, not fresh estimates. What worked gets funded to expand. What stalled gets a decision, not a repeat request. What is new gets sized using the real cost data you now have instead of a vendor’s projection.
Why this year’s data changes the exercise
A first-year AI budget is necessarily a guess, built from vendor claims and industry averages. A second-year budget does not have to be. If you tracked fully loaded cost and measured return properly, you have your own numbers, from your own operation, which are more reliable than anything a vendor will hand you.
What to pull together before writing anything
The fully loaded actual spend on every AI project this year, including build and ownership hours, not just subscriptions. The measured return where a baseline exists. And a status on each roadmap item: shipped and working, shipped and unclear, stalled, or never started.
Structuring the budget section
| Category | What goes here | How it is sized |
|---|---|---|
| Proven and expanding | Projects with measured return this year | Scaled based on actual cost per unit of value |
| New candidates | Next items from the ranked use case list | Estimated using this year’s real build costs |
| Under review | Projects with unclear return | Held flat pending a measurement fix, not expanded |
| Cut | Stalled projects with no active owner | Removed, freeing budget for the first two categories |
This structure does something a single lump-sum AI line item never can. It shows finance exactly where the request is grounded in evidence and where it is still forecast, which is precisely the distinction a CFO is trying to make anyway.
What to do about stalled projects specifically
Do not simply request the same budget again with the same vague hope attached. Either name what changed that will fix the stall, with a specific owner and date, or cut it. A repeated request without a changed plan is the fastest way to lose credibility for the rest of the AI budget.
Sizing new candidates realistically
Use this year’s actual build hours per project as your baseline for estimating next year’s new items, adjusted for complexity. This produces a far more defensible number than a vendor quote, because it reflects what building actually costs inside your specific organization.
What this does for the approval conversation
A budget section built this way answers the questions a CFO would otherwise have to ask, before they ask them. It reads as a continuation of a disciplined process rather than a fresh request for trust, which is a very different conversation to walk into.
FAQ
What if we did not track fully loaded costs this year?
Reconstruct as much as you can now, and commit to tracking it properly starting in Q1. The gap itself is worth naming honestly in the budget document.
Should stalled projects always be cut?
Not automatically, but they need a specific, credible reason to continue rather than an assumption that momentum will return.
How much of the budget should go to new candidates versus proven projects?
Weight toward proven projects until your organization has a track record of several successful builds, then increase appetite for new candidates.
Who should own writing this section?
Whoever owns the AI roadmap, with real numbers supplied by each project’s operational owner.
What is the biggest mistake in this exercise?
Writing next year’s request the same way as last year’s, as an estimate, when actual data now exists to build from instead.
Where to go next: Pull this year’s fully loaded actuals together this month, before the budget cycle forces a rushed version in November.
