Energy & UtilitiesLeadership Insights & Strategy

Budgeting AI in a renewables capital programme: the energy and utilities CFO view

AI capital budgeting in renewables is the finance discipline of classifying, funding and evidencing artificial-intelligence spend inside a utility capital programme. It turns on one split: which AI costs are capitalised into the rate base and earn a regulated return, and which are expensed as period costs the moment they are incurred.

Energy & Utilities · Leadership Insights & Strategy

Atomic Loops EngineeringIndustrial AI practiceReviewed by Atomic Loops Solutions ArchitecturePublished 14 August 202657 min read

Key takeaways

The single most consequential decision in a regulated utility's AI budget is the capex/opex split, because only capitalised, used-and-useful assets enter the rate base and earn the allowed return. The same £1m of AI spend is either an asset earning a regulated return for a decade or a period cost that depresses this year's earnings.
Cloud consumption, foundation-model API spend and research-phase model work are almost always period costs. Embedded control systems, instrumentation, sensors and the integration labour that brings a physical asset into service are the components with a genuine capitalisation argument — and they are what a rate-base case is built from.
AI business cases fail hurdle rates because the benefit is stated as accuracy. A hurdle rate accepts megawatt-hours, avoided curtailment, imbalance charges, O&M cost per MW and outage duration. It does not accept a percentage-point improvement in forecast error, because that number has no place to land in a cash-flow model.
An AI programme's uncertainty profile is nothing like a construction project's, so the same gate structure misprices both. Renewables construction gates release large tranches against declining technical risk; AI gates should release small tranches against demonstrated benefit, with the largest gate after the first metered result rather than before it.
Benefits realisation is what survives an audit, and it has to be designed before go-live. A baseline pulled from metered plant data, a named control group of sites or turbines, an attribution method agreed with internal audit, and a benefit register owned by FP&A rather than by the AI team — those four artefacts are the difference between a claimed benefit and a booked one.

Abbreviations used on this page

Capex: Capital expenditure — spend recognised as an asset and depreciated over its life
Opex: Operating expenditure — spend charged to the period in which it is incurred
Rate base: The value of prudent, used-and-useful assets on which a regulator allows a return
RAB: Regulated asset base — the European term for the rate base
WACC: Weighted average cost of capital, the basis of most utility hurdle rates
LCOE: Levelised cost of energy — lifetime cost per MWh generated
IRR: Internal rate of return
NPV: Net present value
FID: Final investment decision — the gate at which a project's capital is committed
FP&A: Financial planning and analysis
O&M: Operations and maintenance, usually quoted per MW per year
USoA: Uniform System of Accounts — the prescribed account structure US utilities book to

What AI capital budgeting in renewables is — and the one split it turns on

A definition, the capex/opex split that decides whether AI spend enters the rate base, and the path a single AI cost takes from invoice to recovery.

AI capital budgeting in renewables is the finance discipline of classifying, funding and evidencing artificial-intelligence spend inside a utility's capital programme. It is not a technology governance activity and it is not a strategy exercise. It resolves to four decisions a CFO signs: how each AI cost line is classified, how funding is released against it, what return it is appraised at, and how the benefit is proved after the fact.

Everything on this page turns on one split. Cloud consumption, foundation-model API spend and research-phase model development are, under most frameworks, period costs — expensed as incurred. Embedded control systems, sensors and instrumentation, and the integration labour that brings a physical asset into service, are components with a genuine capitalisation argument. In a regulated utility that distinction is not presentational. Capitalised, used-and-useful assets enter the rate base and earn the allowed return; expensed costs do not. The same spend is either an asset earning a regulated return for a decade or a charge against this year's earnings.

The frameworks that decide it are published and stable. Under IFRS the relevant tests sit in IAS 38 on intangible assets (opens in a new tab) and IAS 16 on property, plant and equipment (opens in a new tab), and the IFRS Interpretations Committee has addressed configuration and customisation costs in cloud arrangements directly — see the March 2021 IFRIC Update (opens in a new tab). For US regulated utilities the account structure that a regulator reads is the FERC Uniform System of Accounts at 18 CFR Part 101 (opens in a new tab). Neither this page nor any page is a substitute for your own technical accounting and tax advice: treatment is framework-specific, jurisdiction-specific and fact-specific, and the ledger below is a starting position to be tested, not a conclusion to be applied.

The path an AI cost takes from invoice to recovery

Where an AI cost ends up is decided very early, usually by omission. The top lane is what happens when no classification test is applied: the cost is absorbed, nothing is capitalised, and the benefit is never evidenced. The middle lane is a disciplined finance process. The bottom lane is what a regulated business needs on top of that to reach the rate base.

Data & feeds
Where value leaks
Human in the loop
System-of-record action

The process, in words

In the unbudgeted lane, an AI invoice arrives with no classification test applied. It is absorbed into a shared IT operating subscription, no asset is recognised, nothing is depreciated or recovered, and no benefit baseline was ever set — so at the next budget round the line has no defence and is cut. This is where the value leaks, and it leaks silently.
In the disciplined lane, the cost line is raised tagged to a project, an asset and a use case; a written classification test decides capex or opex; funding is released in tranches against evidence with a kill criterion at each gate; and a benefit baseline is pulled from metered data before go-live, feeding a benefit register that FP&A owns and reconciles every period.
In the regulated lane, capitalised components face a further question — rate base, regulatory asset or period cost — and must then be in service and demonstrably used and useful before they earn the allowed return. The prudence file assembles the cost support, the decision record and the benefit evidence into something a regulator or auditor can reconstruct years later.

Step-by-step insights

The invoice with no test — how the default becomes opex: Nothing in a finance system forces a capitalisation question; the question has to be asked. Capitalisation requires an affirmative argument, supporting evidence and a willing reviewer, while expensing requires none of those things. So in the absence of a written rule the ledger drifts one way, and it drifts consistently. The costs that suffer most are precisely the ones with the strongest capitalisation case — controller upgrades, sensors, commissioning labour — because they arrive bundled with genuinely expensable cloud and licence spend and get swept along with it. The fix is not a new policy document; it is a default treatment written beside every cost line, so the question is answered before anyone has to ask it.
Tagging at the point the cost line is raised: Retrospective tagging is expensive and unreliable, and it is the reason a stage-1 finance function cannot total its own AI spend. Attribution has to happen when the purchase order or the cloud resource is created: project, benefiting asset, use case, proposed treatment. In a renewables portfolio the benefiting asset matters more than it does in most industries, because a model trained centrally may benefit fifteen sites with different ownership structures, different PPAs and different regulatory regimes. A shared model with an untagged cost base cannot be allocated to those sites, and an unallocated cost cannot be recovered from any of them.
The classification test, and why it is per cost line rather than per programme: The most common and most costly error is treating an AI programme as a single classifiable thing. A single programme routinely contains research-phase work that must be expensed, development-phase work that may qualify for capitalisation once the recognition criteria are met, hardware that is unambiguously plant, integration labour that follows the asset it commissions, and consumption spend that is a period cost by nature. Applying one treatment to the bundle guarantees that some of it is wrong, and it is the bundle rather than any individual judgement that draws audit adjustments and regulatory disallowance.
Gate release, and why the tranche profile inverts: Renewables construction gates release large tranches early, because technical uncertainty falls steeply through consent, procurement and FID. An AI programme has modest technical risk and very high benefit risk, and benefit risk does not fall until something has run against live plant for long enough to see a season. Releasing the largest tranche before that point is buying the least certain thing at the highest price. Inverting the profile — small tranches to the metered result, the large one after — changes the committee's maximum regret by an order of magnitude without changing the total programme cost at all.
The baseline that has to exist before go-live: A benefit baseline pulled after go-live inherits the intervention's own effects and can never cleanly attribute them. In a renewables portfolio the confound is severe: wind resource, irradiance, curtailment regimes, market prices and outage schedules all move independently of anything the model does, and any of them can swamp the effect being measured. The workable answer is the same one used for any operational change — a pre-agreed baseline window drawn from metered data plus a held-back control group of comparable sites, turbines or feeders. It costs a little forgone benefit and it is the only thing that turns a claim into a number an auditor will accept.
Rate base, regulatory asset, or neither: For a regulated business the capitalisation question has a second half that unregulated developers never face. A capitalised asset enters the rate base only if it is in service and used and useful, and the return it then earns is the regulator's allowed return, not the company's hurdle rate. Some jurisdictions additionally permit a regulatory asset — deferral of a cost that would otherwise be expensed, for recovery over a later period — and whether AI-related spend qualifies is a live, fact-specific question that belongs with your regulatory counsel before the spend is committed, not after. The one universally bad answer is to decide the recovery treatment retrospectively, because that is the pattern reviewers are trained to look for.

The five rungs in detail

For each rung: what it looks like inside a finance function, the diagnostic signals an FP&A lead can check in an afternoon, the anti-pattern that traps teams there, and what leaving costs.

Each rung below is written for a finance practitioner rather than a buyer. The hallmarks describe conditions you can observe in a ledger and a capital plan, the diagnostic signals are checks you can run against your own systems this week, and the anti-pattern is the specific mistake most often made trying to leave that rung.

Attributable cash benefit released against budgeting maturity

The curve is not linear and the inflection is not where most finance functions expect it. Almost no attributable cash is released through rungs 1 and 2, because nothing is being measured against a baseline; the inflection is at rung 3, when funding starts being released against evidence and a baseline exists to evidence it against. This is why a programme can be technically successful for two years and financially unprovable.

Attributable cash benefit released by stage

Stage 1 · Unbudgeted — 21% of operators. AI spend is real but has no line of its own — it is absorbed into IT operating budgets, project contingency or a vendor's day rate.
Stage 2 · Line-itemed — 38% of operators. AI spend has visible lines in the budget, but classification is argued case by case and the treatment depends on who prepares the paper.
Stage 3 · Stage-gated — 26% of operators. AI spend is released through gates matched to an AI programme's uncertainty profile rather than a construction schedule, with each gate priced.
Stage 4 · Rate-base aligned — 11% of operators. Capitalised AI components are in service, in the rate base, and supported by a prudence file a regulator or auditor can reconstruct.
Stage 5 · Portfolio-optimised — 4% of operators. AI capital is allocated across the whole portfolio on risk-adjusted marginal return, and realised benefits are audited into the P&L.

Curve shape: logistic, plotted from the stage data above. Distribution: Shape consistent with IEA analysis of energy-sector digitalisation.

Select a rung

Every rung's full detail is in the page source — the selector only changes which panel is visible, so nothing here depends on JavaScript to exist.

Stage 1

Unbudgeted

21% of operators sit here

AI spend is real but has no line of its own — it is absorbed into IT operating budgets, project contingency or a vendor's day rate.

Stage 1 is not the absence of AI spend. In almost every generation and network business at this stage the spend is already material — it is simply invisible to the capital plan. A developer's analytics licence rides inside an EPC contract. A forecasting pilot is funded from a project's contingency. A team's model experiments land on a shared cloud subscription owned by IT. Each is individually defensible; the sum is a portfolio of costs the CFO cannot total, classify or defend.

The tell is arithmetic. Ask FP&A for last year's total AI spend and watch what happens. At stage 1 the answer requires a manual trawl of vendor ledgers, cloud invoices and project cost reports, takes more than a day, and comes back with a range rather than a number. Two analysts asked the same question will produce two different totals for defensible reasons, because there is no agreed boundary for what counts.

This stage is expensive in a way that does not show up as expense. Because nothing is classified, nothing is capitalised, so spend that would legitimately have entered the rate base and earned a return is instead expensed in the year it is incurred. In a regulated business that is a permanent, unrecoverable transfer of value away from shareholders — and it happens quietly, invoice by invoice, with no decision ever taken.

In practice

The cloud bill discovered at year end

A renewables operator running roughly 2 GW of wind and solar found, during a year-end true-up, that inference and data-egress charges for three separate forecasting pilots had been billed to one shared cloud subscription owned by central IT. The total was a mid-six-figure annual run rate. None of it had been budgeted as AI, none of it had been tested for capitalisation, and none of the three teams knew what the other two were spending.

What it looks like

No line in the approved capital plan carries AI as its purpose
Cloud and model consumption sit inside a shared subscription nobody reconciles by use case
AI costs surface as unplanned variances in the IT or O&M ledger
No AI cost has ever been tested against a capitalisation criterion

Diagnostic signals you can check this week

Ask FP&A to produce total AI spend for the last financial year. If it takes more than a day, or comes back as a range, you are here
Search the approved capital plan for a single line whose asset class or WBS description names AI, machine learning or advanced analytics
Ask who owns the cloud subscription the models run on and whether it is tagged by use case, project and cost centre
Ask the technical accounting lead when an AI cost was last assessed against your capitalisation policy. If the answer is never, that is the stage

Anti-pattern · Announcing a central AI budget before the classification rules exist

The instinctive fix is to create a ring-fenced AI fund — a number on a slide, owned centrally, spent by application. It feels like control and it defers the actual work. Money released from an unclassified pot is classified retrospectively, which is exactly the condition auditors and regulators treat as weakest. Write the classification rules first, on one page, and let them govern spend that is already flowing. The pot can wait; the ledger cannot.

What holds you here

Nobody can total AI spend, so nobody can classify it — and unclassified spend defaults to opex by omission.

Highest-leverage next move

Build the AI cost inventory: every vendor, cloud subscription, licence and internal labour charge, tagged to a cost centre, a project and a proposed treatment.

Cost of leaving

Effort: 1 quarter
Team: One FP&A analyst and the technical accounting lead, part-time
Risk: Low — the work is disclosure and tagging, not new spend
To next stage: 3–6 months

If this is you, the next step is

A two-week exercise: find every AI cost line, tag it, and total it by treatment.

Get your AI spend counted

Stage 2

Line-itemed

38% of operators sit here

AI spend has visible lines in the budget, but classification is argued case by case and the treatment depends on who prepares the paper.

Stage 2 is where most utility finance functions actually are, and it looks like progress because the numbers finally exist. AI has lines. The lines have owners. The variance report explains them. What is still missing is a rule: the treatment of a given cost depends on which project it landed in and which accountant reviewed it, so two structurally identical costs — a LiDAR retrofit on a wind site and a LiDAR retrofit on the next one — can be booked differently in the same year.

The consequence is not chaotic accounting; it is a systematic bias toward opex. Capitalisation requires an affirmative argument, evidence and a willing reviewer. Expensing requires nothing. When the rule is ambiguous, the path of least resistance is a period cost, and the AI components that genuinely belong in an asset's cost — the controller upgrade, the sensor, the commissioning labour — get swept into operating budgets alongside the cloud bill. The rate base never sees them.

There is a second cost that shows up in the investment committee rather than the ledger. Without a classification rule, the finance function cannot tell an AI proposal what shape a fundable case looks like, so proposals arrive shaped by engineering: accuracy, coverage, model architecture. They are then rejected or deferred not because the value is absent but because nobody translated it. Teams learn that AI cases do not get funded, and the next proposal is smaller and vaguer.

In practice

Two identical retrofits, two different ledgers

A utility retrofitted nacelle-mounted LiDAR and an upgraded turbine controller across two wind farms in the same financial year, in both cases to feed a power-curve optimisation model. On the first site the work was bundled into a capital repowering package and capitalised. On the second it was procured as an O&M improvement and expensed. Same hardware, same purpose, same year, two treatments — and no written rule that either accountant had broken.

What it looks like

AI appears as identifiable lines in the operating and capital budgets
Capitalisation decisions are made per project, with no written policy specific to AI
Cloud spend is tagged by use case but still charged wholly to opex
Business cases are approved on strategic rationale rather than on modelled cash

Diagnostic signals you can check this week

Take two structurally similar AI-related cost lines from different projects and compare how each was treated
Ask whether your capitalisation policy contains any AI-specific guidance at all, or only generic software and plant wording
Check whether research-phase and development-phase model work are distinguished anywhere in the ledger
Read the last three AI business cases that reached the investment committee and count how many state a benefit in cash

Anti-pattern · Writing a policy that only an accountant can apply

The obvious remedy is a technical accounting memo. Most are unusable at the point of decision because they restate the standard rather than the cases. What a project engineer needs on a Tuesday is a one-page ledger of cost lines — sensor, controller, licence, integration labour, cloud consumption, training — with a default treatment beside each and a named person to call for the exceptions. Write the ledger first and derive the memo from it, not the other way round.

What holds you here

There is no written, cost-line-level rule, so treatment varies by preparer and drifts toward opex by default.

Highest-leverage next move

Write the classification ledger — every AI cost line, its default treatment, the test that decides it, and the evidence that supports it.

Cost of leaving

Effort: 1–2 quarters
Team: Technical accounting lead, FP&A manager, one engineering lead who knows the cost lines
Risk: Low to medium — restating prior-year treatments may need audit discussion
To next stage: 6–9 months

If this is you, the next step is

We map your actual AI cost lines onto your capitalisation policy and asset classes.

Build your classification ledger

Stage 3

Stage-gated

26% of operators sit here

AI spend is released through gates matched to an AI programme's uncertainty profile rather than a construction schedule, with each gate priced.

Stage 3 is the first stage at which the funding model fits the thing being funded. A renewables construction project has a declining risk profile: uncertainty is highest at feasibility and collapses through consent, procurement and FID, which is why construction gates release large tranches early and small ones late. An AI programme has the opposite shape. Technical risk is modest and benefit risk is enormous, and benefit risk does not fall until something has run against live plant data for a season.

So the gate structure inverts. Small tranches fund the data work and the offline result. A slightly larger tranche funds the shadow run against live plant. The largest tranche — the one that pays for fleet rollout, instrumentation and integration — is released only after a metered benefit has been observed on a real site against a real baseline. Finance functions that reach this stage stop asking 'is this a good idea?' at a single committee and start asking 'what would we need to see to release the next tranche?', which is a question engineers can actually answer.

The visible change is in the shape of the paper. At stage 2 an AI proposal is one document asking for one number. At stage 3 it is a gate schedule: what each tranche buys, what evidence releases the next one, what the kill criterion is, and what the spend to date will have been if it is killed. That last figure — the maximum regret at each gate — is what makes an investment committee comfortable funding something whose benefit is genuinely uncertain.

In practice

The curtailment model that was funded four times

An operator funding a curtailment-forecasting model split it into four tranches: a data-readiness tranche against the historian and meter data; an offline backtest tranche measured in MWh recovered against actual dispatch instructions; a shadow-run tranche on two sites for one full season; and only then the fleet tranche covering instrumentation, control integration and rollout across the portfolio. Three of the four were small. The committee's exposure at any point before the metered result was a fraction of the headline programme cost.

What it looks like

A published gate structure releases AI funding in tranches against evidence
The largest tranche is released after the first metered benefit, not before it
Each gate has a named financial owner and a stated kill criterion
Business cases arrive in cash units — MWh, £/MWh, O&M per MW, avoided charges

Diagnostic signals you can check this week

Ask to see the gate schedule for the last AI investment approved. If there is a single approval and a single number, you are not here yet
Check whether any AI funding tranche has a written kill criterion that has ever been exercised
Ask what the maximum regret is at each gate — the cumulative spend if the programme stops there
Look at where the largest tranche sits relative to the first metered benefit. Before it is a stage-2 pattern wearing stage-3 clothing

Anti-pattern · Reusing the construction gate model unchanged

The capital governance framework already exists and applying it to AI looks like discipline. It misprices the risk in both directions: it demands FID-grade certainty before any money moves, which kills work whose whole purpose is to reduce uncertainty, and it then releases the entire remaining budget at a single point, which is precisely when benefit risk is still highest. Keep the governance, invert the tranche profile, and be explicit that you have done so.

What holds you here

The classification is sound and the gates work, but capitalised AI components are not yet assembled into a case a regulator would accept.

Highest-leverage next move

Build the prudence file: for every capitalised AI component, the in-service date, the used-and-useful argument, the cost support and the benefit evidence.

Cost of leaving

Effort: 2–3 quarters
Team: FP&A manager, capital governance owner, an engineering lead per gated programme
Risk: Medium — the gate structure must be agreed with capital governance, not bolted beside it
To next stage: 9–15 months

If this is you, the next step is

Four gates, priced, with the evidence that releases each one.

Design your AI gate structure

Stage 4

Rate-base aligned

11% of operators sit here

Capitalised AI components are in service, in the rate base, and supported by a prudence file a regulator or auditor can reconstruct.

Stage 4 is where classification stops being an internal accounting matter and becomes an external one. A capitalised AI component in a regulated business must survive three questions: is it an asset, is it used and useful, and was the spend prudent. The first is answered by the standard, the second by the in-service evidence, and the third by the record of how the decision was made — which is exactly what the gate structure from stage 3 produces as a by-product.

The practical work is unglamorous and it is mostly documentation. In-service dates for control and instrumentation assets. Cost support that ties capitalised labour to timesheets and to a defensible allocation basis. A description of the component in the vocabulary of the account structure the regulator reads — plant accounts, general plant, intangible — rather than the vocabulary of the vendor's product page. Operators that skip this arrive at a rate case with a technically sound asset and no way to evidence it, and the disallowance risk falls entirely on the shareholder.

The judgement that matters most at this stage is restraint. Not everything should be capitalised, and a finance function that pushes marginal costs into the rate base to flatter current earnings is buying a disallowance later at a worse exchange rate. The strongest position is a conservative, consistently applied ledger with a small number of confidently capitalised components and a clear, documented rationale for everything expensed. Regulators and auditors reward legibility far more than they reward aggression.

In practice

The asset that was real and unevidenced

A network operator capitalised the control-integration work for an AI-assisted switching optimisation across a distribution region. The asset was genuine — new edge controllers, commissioned, in service, demonstrably in use. But the capitalised labour was supported only by a fixed-price vendor invoice with no time detail and no split between the development work and the commissioning work. The component was defensible in substance and hard to evidence in form, which is the position no CFO wants to occupy in front of a regulator.

What it looks like

Capitalised AI components carry in-service dates and used-and-useful support
Cost support ties every capitalised amount to invoices, timesheets and commissioning records
The regulatory filing describes the AI component in the language of the account structure, not the vendor's
Recovery treatment — rate base, regulatory asset or period cost — is decided before spend, not after

Diagnostic signals you can check this week

Pick one capitalised AI amount and try to reconstruct it from invoices, timesheets and commissioning records in an afternoon
Check whether every capitalised AI component has a recorded in-service date and a used-and-useful description
Ask whether the recovery treatment was decided before the spend was committed or after the invoice arrived
Read the regulatory description of one AI component and check it uses the account structure's vocabulary rather than the vendor's

Anti-pattern · Capitalising the model because the hardware was capitalised

Once a controller retrofit is capitalised, it is tempting to sweep the model development, the data work and the first year of cloud consumption into the same asset on the grounds that they were all part of the same programme. That bundle is the single most common source of disallowance and audit adjustment, because it mixes components with genuinely different tests. Split the programme into its cost lines and let each one meet its own test, even when that means a less flattering capitalisation ratio.

What holds you here

Individual cases are defensible, but AI capital is still allocated project by project rather than across the portfolio on marginal return.

Highest-leverage next move

Move the allocation decision up a level: rank AI investments across the whole renewables and network portfolio on risk-adjusted return per pound, not within each project.

Cost of leaving

Effort: 3–4 quarters
Team: Regulatory accounting lead, FP&A, project controls, external audit liaison
Risk: Higher — the constraint is now external review and the evidence standard is not yours to set
To next stage: 12–24 months

If this is you, the next step is

We reconstruct one capitalised AI component the way a reviewer would.

Stress-test a prudence file

Stage 5

Portfolio-optimised

4% of operators sit here

AI capital is allocated across the whole portfolio on risk-adjusted marginal return, and realised benefits are audited into the P&L.

Stage 5 is narrower than it sounds and it is a finance capability rather than a technology one. It means that when £5m of discretionary capital is available, the question asked is which AI investment across wind, solar, storage, networks and customer operations returns most per pound at an acceptable risk — not which project sponsor argued best. That requires every candidate to be expressed in the same units, with comparable confidence intervals, which is only possible once the classification and benefit-measurement disciplines beneath it are solid.

The artefact that defines the stage is the benefit register: a live reconciliation between what each AI investment claimed and what has actually been booked, in the units the P&L uses. It is owned by FP&A rather than by the AI team, it is reviewed on the normal reporting cycle, and its variances feed back into the assumptions used to appraise the next round. Programmes with a register stop having the annual argument about whether AI delivers, because the answer is a number with a history.

Sustaining stage 5 is a discipline problem, and it is the stage most likely to regress. Market conditions move, so a curtailment benefit measured under one year's constraint regime overstates the next year's. Portfolios change shape through acquisition and disposal. The register's attribution methods need periodic re-validation, and the honest finance functions treat a benefit assumption the same way they treat a wind resource assumption — as something with a vintage, a source and an expiry.

In practice

The register that repriced the roadmap

An operator running a benefit register across eleven AI investments found after two years that the two largest claimed benefits — a customer-operations automation and a fleet-wide asset-health model — had realised roughly half of what was appraised, while a small imbalance-cost model on the trading desk had realised well above its case. The next planning round reallocated on that evidence rather than on advocacy, and the appraisal assumptions for the whole category were revised down. That reallocation is the stage-5 behaviour.

What it looks like

AI investments compete across the portfolio, not inside individual projects
A live benefit register reconciles claimed to booked benefit every period
Realised benefits feed the next planning round's assumptions automatically
Internal audit tests AI benefit claims on the same cycle as other capital claims

Diagnostic signals you can check this week

Ask whether AI investments are ranked against each other across the portfolio or approved inside their own project envelopes
Ask to see the benefit register and check whether variances have ever changed a subsequent appraisal assumption
Check whether internal audit has tested an AI benefit claim on its normal cycle
Ask what the vintage is on the assumptions behind the largest live AI benefit claim

Anti-pattern · Letting the register become a reporting exercise

Once the register exists there is a strong pull toward making it look good — restating baselines, extending attribution windows, quietly reclassifying an underperforming benefit as strategic. The register stops being an instrument and becomes a presentation, and the feedback loop that made it valuable is severed. Fix the attribution method and the baseline in writing before go-live, version them, and require a documented change control to move either.

What holds you here

The constraint is assumption drift — attribution methods and baselines silently stop describing the portfolio they were built for.

Highest-leverage next move

Treat every benefit assumption as a versioned artefact with a vintage, a source and a review date, under the same change control as a capital assumption.

Cost of leaving

Effort: Continuous
Team: FP&A ownership of the register, plus internal audit on the standing cycle
Risk: Concentrated — the risk is drift in attribution and stale assumptions, not overspend

If this is you, the next step is

We test the attribution method and the baseline against the metered data behind them.

Audit a live benefit register

Where utility finance functions actually sit today

The distribution across the ladder, and why the rung 2 to rung 3 step is the one most operators never take.

Most utility finance functions are at rung 2. AI spend has lines and owners; what it does not have is a rule. The distribution below is weighted toward that position: a large majority can now identify their AI cost lines, a minority release funding against evidence rather than against a calendar, and a small number have capitalised AI components sitting in a rate base with a prudence file behind them.

Illustrative distribution of utility finance functions across the five rungs

Illustrative distribution, synthesised from published research on energy-sector AI adoption and investment — not a measured survey. Rung 2 is both the mode and the plateau: the step from line-itemed to stage-gated requires a change to capital governance, which is a harder internal negotiation than any accounting judgement on this page.

Share of finance functions

21% — 1 · Unbudgeted
38% — 2 · Line-itemed (the plateau)
26% — 3 · Stage-gated
11% — 4 · Rate-base aligned
4% — 5 · Portfolio-optimised

Source: Illustrative distribution, anchored to IEA research on energy and AI

The reason the plateau sits at rung 2 is structural rather than technical. Moving to rung 3 does not require a new accounting judgement — it requires changing how the capital governance framework releases money, and that framework was built for construction projects and is defended by people whose job is to defend it. A classification ledger can be written by a finance team in a fortnight. A gate structure has to be negotiated with capital governance, and that negotiation is where most programmes stop.

The context matters for how an AI line is read in a capital plan. Global energy investment is running at record levels and the clean-energy share of it keeps rising — see the IEA's World Energy Investment series (opens in a new tab) — while the cost floor for new renewable generation continues to fall, as IRENA's Renewable Power Generation Costs (opens in a new tab) tracks each year. Both facts squeeze the same place. A renewables capital programme competing for capital at scale, against a falling LCOE benchmark, has very little tolerance for spend that cannot state its return in the same units as the rest of the plan. That is the environment an AI line has to survive, and it is why the translation work in the next sections is not a presentational nicety.

The cost classification ledger, line by line

The centrepiece of this page: every AI cost line in a renewables programme, its typical treatment, the test behind it, whether it can reach the rate base, and the evidence a reviewer asks for.

The classification ledger is a one-page table that gives every AI cost line a default treatment before anyone has to argue about it. It is the artefact that separates rung 2 from rung 3, and it is deliberately written at the level of the cost line rather than the programme, because a single AI programme contains costs whose correct treatments genuinely differ. Read it as a starting position to test with your own technical accounting and tax advisers under your own framework — not as a conclusion.

Cost line	Usual treatment	The test behind it	Rate base?	Evidence a reviewer asks for
Cloud compute, inference and data egress	Opex	Consumed as a service in the period; no controlled resource arises	No	Tagged invoices by use case, project and benefiting asset
Foundation-model API and token spend	Opex	Same as consumption: a service consumed, not an asset acquired	No	Usage reports reconciled to the appraised volume assumption
Research-phase model work	Opex	Recognition criteria for an internally generated intangible are not met	No	Project records distinguishing research from development phase
Development-phase model work	Case by case	Capitalisation only once every recognition criterion is met and evidenced	Sometimes	Timesheets, feasibility evidence, the date criteria were met
Third-party AI SaaS subscription	Opex	Right to receive a service over the term, not a controlled asset	No	Contract terms showing no transfer of control of software
Configuration and customisation of a cloud arrangement	Usually opex	Addressed directly by the IFRIC agenda decision on cloud arrangements	No	Supplier statements of work split by activity
Sensors, met masts, nacelle LiDAR, condition monitoring	Capex	Tangible plant with a determinable life, controlled by the entity	Yes	Asset register entry, serial numbers, in-service date
Turbine, inverter and plant controller upgrades	Capex	Enhancement to an existing asset's capability or life	Yes	Commissioning records and the enhancement rationale
Perpetual on-premise software licences	Capex	Control of the software passes to the entity	Usually	Licence terms, useful-life assessment, amortisation basis
Integration and commissioning labour on a capital asset	Capex	Directly attributable cost of bringing an asset to working condition	Yes	Timesheets, allocation basis, evidence of direct attribution
Training, change and adoption work	Opex	Not a directly attributable cost of the asset under either framework	No	Nothing beyond normal cost support — this row rarely disputes
Model validation, assurance and external audit	Opex	Ongoing operating cost of running the capability	No	Assurance reports, retained for the prudence file regardless

AI cost lines in a renewables capital programme, with the treatment most commonly reached under IFRS or a US regulated account structure. 'Rate base?' assumes a regulated utility; unregulated developers should read that column as 'depreciable asset?'. Treatment is framework-, jurisdiction- and fact-specific — test every row with your own advisers.

Three rows carry almost all the argument. Development-phase model work is the row that most often ends up in an audit adjustment, because the recognition criteria are met on a date and that date has to be evidenced rather than asserted. Integration and commissioning labour is the row that most often gets under-claimed: it is genuinely and directly attributable to a physical asset, it is frequently expensed by default, and the amounts are large. Configuration and customisation of a cloud arrangement is the row that surprises engineering teams the most, because the work feels like building an asset and the IFRIC agenda decision (opens in a new tab) points the other way in most fact patterns.

Which funding treatment fits which AI cost

Plot each AI cost line by how clearly it classifies and how firmly its benefit can be measured. Three quadrants have a straightforward answer. The fourth — capitalising spend whose benefit is only modelled — is where disallowance risk concentrates in a regulated business.

Fund from operating budget, prove monthly

Consumption and licence spend with a metered benefit
Reconcile actual usage against the appraised assumption
The easiest quadrant to defend and the easiest to stop

Capitalise and take to the rate base

Instrumentation, controllers, integration labour
Benefit metered against a held-back control group
The only quadrant where a rate-base case is genuinely strong

Stage-gate as innovation spend

Research-phase work and first-of-a-kind pilots
Smallest tranche, explicit kill criterion, short window
Expense it and say so — do not dress it as capital

The disallowance quadrant

Capitalised assets whose benefit is only modelled
Survives internal review, fails prudence review
Fix by metering the benefit before, not after, the filing

Benefit measurability — top: Metered against a baseline, bottom: Modelled only

Classification — left: Clearly a period cost, right: Clearly a capital asset

Tax and incentive interactions sit alongside the accounting classification and are decided separately from it. Capital allowances in the UK are claimed against qualifying plant and machinery under rules published by HMRC (opens in a new tab), and US clean-energy credits are administered by the IRS (opens in a new tab) with eligibility defined by asset type, placed-in-service timing and a set of statutory conditions that change with legislation. Two things are worth stating plainly and nothing more. First, an accounting capitalisation decision does not by itself determine tax treatment or credit eligibility — the tests are different and are applied to different definitions. Second, whether AI-related instrumentation attached to a qualifying energy asset shares that asset's incentive treatment is a fact-specific question that depends on how the equipment is integrated and on the statute in force, and it must be answered by your tax advisers before the spend is committed, not reconstructed afterwards.

Hurdle rates: why AI business cases fail financial review

A hurdle rate can only test cash. Here is how to translate an AI claim into megawatt-hours, avoided charges and O&M per MW — and what discount rate and asset life to use.

AI business cases fail hurdle rates because the benefit is stated as accuracy. A hurdle rate is a test applied to a cash-flow profile, and a percentage-point improvement in forecast error has no line in a cash-flow model — it is an input to something that produces cash, not the cash itself. The proposals that clear are not the ones with better models; they are the ones that carry the translation from model behaviour to cash all the way through, and show their working.

What the team says	What actually changes	The cash line it lands on	Unit for the case	Evidence needed
Day-ahead forecast error is down	Fewer imbalance volumes and better scheduling of committed output	Imbalance and cash-out charges	£ per MWh imbalanced, per month	Settlement data before and after, against a control portfolio
Curtailment prediction is more accurate	Output is redispatched or shifted ahead of a constraint	Revenue from generation not lost to curtailment	MWh recovered × captured price	Dispatch instructions and metered output vs control sites
Turbine fault detection improved	Interventions move from reactive to planned windows	O&M cost and lost production during unplanned outages	£ per MW per year, plus availability points	Work-order history and availability, control group of turbines
The power-curve model is better	Control set-points change and yield per unit of resource rises	Generation revenue at unchanged capital cost	Capacity factor points, then MWh × price	Metered production normalised for resource, vs control turbines
Inspection coverage is higher	Truck rolls and rope-access campaigns fall	Field O&M and contractor cost	£ per inspection avoided × volume	Contractor invoices and inspection schedules, before and after
Outage duration is shorter	Restoration and switching decisions are made faster	Lost revenue, and regulatory incentive or penalty	Customer-minutes lost, then the incentive rate	Outage management records against the incentive scheme's own metric
The trading desk gets better signals	Position-taking and hedging decisions shift	Gross margin on the traded position	£ per MWh traded, risk-adjusted	Desk P&L attribution with an explicit counterfactual

Translating an AI claim into a number a hurdle rate can test. The right-hand column is the part most often missing: without it the middle columns are an assertion, and an investment committee is correct to discount an assertion heavily.

The second failure is subtler and it is a discount-rate error. Applying a 25-year generation asset life to a model that will be retrained, re-scoped or replaced within three years overstates NPV badly, and it is the assumption most likely to be challenged. Applying a venture-style risk premium to an embedded controller upgrade with a fifteen-year physical life understates it just as badly. The workable convention is to appraise per component: hardware and integration at the host asset's life and the regulated or corporate cost of capital, model and platform work at a short life with an explicit premium for benefit uncertainty, and consumption spend as a recurring operating cost that never enters the capital appraisal at all.

Illustrative benefit stack for a 300 MW onshore wind portfolio

Illustrative modelled shares of a single AI benefit case, shown to make the shape of the argument concrete — not a measured result and not a forecast for any specific portfolio. The point is the ordering: in most renewables portfolios the largest addressable benefit sits in avoided curtailment and availability, while forecast-error improvements land mainly on imbalance charges and are usually smaller than teams expect.

Share of modelled annual benefit

34% of modelled annual benefit — Avoided curtailment (largest and most contested)
26% of modelled annual benefit — Availability and unplanned outage
17% of modelled annual benefit — Field O&M and inspection
13% of modelled annual benefit — Imbalance and cash-out
10% of modelled annual benefit — Yield and power-curve

Source: Illustrative benefit stack; cost and revenue structure anchored to IRENA renewable cost data

Appraise against the right counterfactual
The comparison is not 'AI versus nothing'. It is 'AI versus the next-best operational change with the same capital'. In a renewables portfolio that alternative is often a straightforward maintenance-schedule change or a contract renegotiation, and it can have a better risk-adjusted return. A case that survives that comparison is far more robust in committee than one that only beats doing nothing.
Model the downside explicitly
Benefit risk is the dominant risk in an AI case, so present the downside as a case rather than a sensitivity line. A proposal that still clears the hurdle at half the modelled benefit is a different object from one that needs the full number, and committees fund the first much more readily even when its central case is lower.
Separate the recurring cost from the capital
Cloud consumption and licence spend continue for the life of the capability, so they belong in the operating cost profile, not amortised into the capital case. Cases that bury a growing consumption line inside a capital number look attractive at approval and become an unpleasant surprise in year three, which is the single fastest way to lose an investment committee's trust in the category.
State the price basis and its vintage
A curtailment or imbalance benefit is priced against a market and a constraint regime that will change. Say which year's prices the case uses, where they came from — published market data or your own settled positions — and when the assumption should be revisited. EIA's electricity data (opens in a new tab) and its Annual Energy Outlook (opens in a new tab) are the usual public reference points in US filings.

What the financial argument looks like in public

Three publicly reported programmes, read for their finance lesson rather than their technology. None is an Atomic Loops engagement — each links to the organisation's own published material.

The clearest public evidence for the argument on this page is in how organisations chose to express what they had built. In each case below the notable thing is not the model — it is that the outcome was stated in a unit a finance function can use: the value of energy delivered, cost to serve, or a published work programme a regulator can hold the organisation to.

Three programmes read for their finance lesson

Outcomes as reported by the organisations themselves; we have not independently audited them, and figures should be verified against the linked source before reuse. The card images are illustrative scenes from our energy image library, not photographs of these organisations' sites or people, and no endorsement is implied.

Scene illustration: two engineers reviewing wind and solar generation forecast charts on control-room screens, with turbines visible outside

Google (DeepMind)Corporate wind portfolio · ~700 MW, central United States24

Challenge: Wind output is variable, and variable energy is worth less to a grid than energy that can be committed to a set delivery at a set time. The commercial problem was therefore not generation volume but the value realised per megawatt-hour generated.
Approach: Google and DeepMind applied machine-learning forecasting to roughly 700 megawatts of wind capacity, predicting output 36 hours ahead and using those predictions to make optimal hourly delivery commitments to the grid a day in advance.
Reported outcome: DeepMind reported that machine learning had boosted the value of that wind energy by roughly 20 per cent, relative to a baseline scenario of no time-based commitments to the grid.; What it shows about the curveThe benefit was stated as the value of energy delivered, not as forecast error. That is exactly the translation the hurdle-rate section above describes, and it is why the result is quotable in a capital paper at all. A finance function can discount a value-per-MWh claim; it cannot do anything with a percentage-point improvement in mean absolute error.

Google DeepMind — Machine learning can boost the value of wind energy (opens in a new tab)

Scene illustration: an energy company leadership team reviewing a platform and cost-to-serve dashboard, with wind turbines visible through the window

Octopus Energy (Kraken)Energy retail and flexibility platform · 9m+ customers, 26 countries25

Challenge: Operating on an incumbent third-party billing and operations platform constrained both the pace of product change and the cost of serving each customer, and every improvement had to be bought rather than built.
Approach: Octopus Energy adopted its own platform, Kraken, in 2016 and has since built customer, field and residential-flexibility products on it, running the platform as a sustained internal capability rather than a series of separately justified projects — and subsequently licensing it to other utilities.
Reported outcome: Kraken reports the partnership delivering up to 40% lower cost to serve, alongside industry-leading customer scores and support for more than nine million customers across 26 countries.; What it shows about the curveSustained platform funding produces a different financial object from repeated project funding. The cost line stops being an annually contested expense and becomes a capability with an asset profile and, in this case, a third-party revenue line. The finance lesson is about the funding model, not the technology: what is funded as a project is appraised, defended and cut as a project.

Kraken — Octopus Energy case study (opens in a new tab)

Scene illustration: a system operator planning team reviewing network and generation data on a large wall display, with wind turbines shown on screen

NESO (National Energy System Operator)Great Britain electricity system operator · regulated entity34

Challenge: A regulated system operator cannot fund a data and AI work programme by internal conviction. Spend has to be visible, justified and reviewable within the regulatory framework it operates under, and the commitments have to survive being read back by a regulator later.
Approach: NESO publishes a Digitalisation Strategy and Action Plan setting out its data and digital work programme, including the actions and commitments behind it, as a public document under the regulatory transparency expectations that apply to it.
Reported outcome: The June 2025 Digitalisation Strategy and Action Plan is published openly, so the organisation's data and AI commitments are on the public record and can be tracked against delivery.; What it shows about the curvePublishing the work programme is a funding-model discipline before it is a transparency one. A commitment written down in advance, in a document a regulator reads, forces the classification, the sequencing and the benefit statement to be settled before spend rather than reconstructed after it — which is precisely what the prudence file at rung 4 requires.

NESO — June 2025 Digitalisation Strategy and Action Plan (opens in a new tab)

Read together, the three make one point. The programmes whose numbers are quotable years later are the ones that expressed the outcome in a financial unit at the time: value per megawatt-hour, cost to serve, a published commitment. None of the three is quotable because of its model architecture, and none of them would be quotable at all if the benefit had been recorded as accuracy.

The funding model: gates matched to an AI uncertainty profile

Why the construction gate structure misprices AI in both directions, what the inverted tranche profile looks like, and which layer of the capital stack each gate buys.

An AI programme should be funded in the inverse tranche profile to a construction project, because its risk profile is inverted. A renewables construction project carries its uncertainty at the front — resource, consent, grid connection, procurement — and that uncertainty falls steeply toward FID, which is why the governance framework releases the large tranche once and early. An AI programme carries modest technical uncertainty and very high benefit uncertainty, and benefit uncertainty falls only after live running against real plant data.

Gate	Construction project	AI programme	What releases the next tranche
G0 — concept	Small: feasibility and resource assessment	Small: data readiness against the historian and meter data	Data exists, is complete enough, and is accessible without a new platform
G1 — definition	Medium: consent, grid, front-end engineering	Small: offline result measured in the benefit unit, not accuracy	The offline result clears the hurdle at half the modelled benefit
G2 — commitment	Largest: FID, EPC award, long-lead procurement	Medium: shadow run on two sites for a full season, control group held back	A metered benefit on live plant, attributable against the control
G3 — execution	Small: construction management and contingency	Largest: instrumentation, control integration and portfolio rollout	Realised benefit tracking to the case in the benefit register

The two gate profiles side by side. The total programme cost can be identical; what changes is the committee's maximum regret at each point and, therefore, what it takes to get the first tranche approved at all.

The practical consequence for a CFO is that the first tranche of an AI programme should be small enough to approve without a committee cycle, and the last should be large enough to require one. That is the opposite of how most capital governance frameworks behave, and it is why the negotiation with capital governance — not the accounting judgement — is the real work of reaching rung 3. State the inversion explicitly in the paper rather than quietly working around the framework, because the reason for it is defensible and the workaround is not.

The AI capital stack, and which gate buys each layer

Each layer is annotated with the rung at which a finance function typically has to classify it properly. The layers do not have a single treatment between them, which is precisely why programme-level classification fails: the stack contains plant, intangibles and pure consumption at the same time.

Field instrumentation
Stage 2+
- Met masts, nacelle LiDAR, irradiance sensorsTangible plant — capex, in the rate base once in service
- Condition monitoring and vibration sensorsTangible plant, usually attached to a host asset
- Metering and PMU upgradesPlant accounts; often the strongest rate-base component
→
Edge and control integration
Stage 3+
- Plant and turbine controller upgradesEnhancement to an existing asset — capex
- SCADA and historian integrationIntegration labour follows the asset it commissions
- Network segmentation and cyber controlsCapex where it is part of bringing the asset into service
→
Data platform
Stage 2+
- Time-series store and historian capacityLicence terms decide: perpetual capex, subscription opex
- Asset register and meter data alignmentUsually opex; the cost is people, not licences
- Data quality and lineage toolingOpex, and the cheapest insurance on the whole stack
→
Model layer
Stage 3+
- Research-phase workOpex — recognition criteria are not met by definition
- Development-phase workCase by case, and evidenced from a specific date
- Inference and consumptionOpex, recurring, and it belongs in the operating profile
→
Assurance and evidence
Stage 4+
- Model validation and independent reviewOpex, and non-negotiable in a regulated business
- Benefit registerOwned by FP&A, reconciled every reporting period
- Prudence fileCost support, in-service records and the decision record

Pipeline described

Field instrumentation (stage 2+) — Met masts, nacelle LiDAR, irradiance sensors: Tangible plant — capex, in the rate base once in service; Condition monitoring and vibration sensors: Tangible plant, usually attached to a host asset; Metering and PMU upgrades: Plant accounts; often the strongest rate-base component
Edge and control integration (stage 3+) — Plant and turbine controller upgrades: Enhancement to an existing asset — capex; SCADA and historian integration: Integration labour follows the asset it commissions; Network segmentation and cyber controls: Capex where it is part of bringing the asset into service
Data platform (stage 2+) — Time-series store and historian capacity: Licence terms decide: perpetual capex, subscription opex; Asset register and meter data alignment: Usually opex; the cost is people, not licences; Data quality and lineage tooling: Opex, and the cheapest insurance on the whole stack
Model layer (stage 3+) — Research-phase work: Opex — recognition criteria are not met by definition; Development-phase work: Case by case, and evidenced from a specific date; Inference and consumption: Opex, recurring, and it belongs in the operating profile
Assurance and evidence (stage 4+) — Model validation and independent review: Opex, and non-negotiable in a regulated business; Benefit register: Owned by FP&A, reconciled every reporting period; Prudence file: Cost support, in-service records and the decision record

Step-by-step insights

Field instrumentation — the layer with the cleanest capital case: Sensors, met masts, nacelle LiDAR and metering upgrades are tangible plant with determinable lives, attached to identifiable host assets, with serial numbers and commissioning dates. They are the least contested rows in the ledger and, in a regulated business, the components most likely to enter the rate base without argument. The mistake finance functions make here is not classification but sequencing: instrumentation is frequently bought in the first tranche, before there is any evidence a model can use it, which converts the cheapest gate into the most expensive one. Buy the instrumentation at G3, after the shadow run has shown what the model actually needs.
Edge and control integration — where the largest under-claim sits: Integration and commissioning labour that brings a controller upgrade into working condition is directly attributable cost of a capital asset under both major frameworks, and it is routinely expensed because it arrives as a professional-services invoice rather than as equipment. The amounts are material on a portfolio retrofit. Capturing it requires nothing more exotic than statements of work that split activity by cost line and timesheets that allocate labour to the asset, both of which are easy to require in a contract and nearly impossible to reconstruct after the fact.
Data platform — where licence structure decides everything: The same functional capability can be capex or opex depending entirely on how it was contracted. A perpetual on-premise licence with control passing to the entity looks like an asset; the same vendor's subscription does not. This is worth knowing at procurement rather than at year end, because the commercial teams negotiating the contract are usually optimising for headline price and flexibility and are entirely unaware that the structure they choose determines whether the spend can ever reach the rate base. A two-line note in the procurement brief is the cheapest intervention on this page.
Model layer — the research/development boundary is a date: Under IFRS, an internally generated intangible cannot be recognised from research-phase activity at all, and development-phase costs are only capitalised from the point every recognition criterion is met and can be demonstrated. That point is a date, and it has to be evidenced by project records at the time — not asserted in a memo written when the auditor asks. Programmes that expect to capitalise development work should be keeping the feasibility, intention, resource and benefit-measurement evidence contemporaneously from the start of the phase, because retrospective construction of that file is the single most common source of audit adjustment in this layer.
Assurance and evidence — an operating cost that protects a capital claim: Model validation, independent review and the benefit register are all period costs and none of them will ever enter a rate base. They are also what makes the capitalised layers defensible, which makes them the highest-leverage opex on the stack. A prudence review does not test whether a model was accurate; it tests whether the decision to spend was reasonable given what was known at the time, and whether the asset is in service and used and useful. Both of those are documentation questions, and documentation is cheap right up until the moment it does not exist.

A 90-day plan: getting one curtailment model through capital approval

The rung 2 to rung 3 step made concrete on one problem — avoided curtailment on a 300 MW onshore wind portfolio. Contains no model development.

Moving one rung takes about 90 days when it is scoped to a single cost line and a single benefit, and multiple years when it is scoped to a function. To make that concrete, the plan below runs the step on a specific and very common problem: a 300 MW onshore wind portfolio losing output to network constraints, where a curtailment-forecasting model already exists and has never been through a capital approval process. The quarter contains no model development at all — every day of it is classification, gating, benefit derivation and baseline design.

Rung 2 to rung 3 on one curtailment cost line, in one quarter

One portfolio, one benefit, one named financial owner. If a phase needs more than its window, narrow the scope — fewer sites, one constraint boundary — rather than extending the plan.

Days 1–20
Inventory and classify the cost line
List every cost the curtailment model consumes today: cloud and inference, the forecasting licence, internal engineering time, the historian capacity it uses. Tag each to the portfolio and to a use case. Run each through the classification ledger and mark the default treatment and the one or two rows that need a technical accounting decision. Name an FP&A owner — not an engineering owner — for the cost line.
A tagged AI cost line with a default treatment per row
Days 21–45
Derive the benefit in cash and set the baseline
Pull two years of curtailment volumes from dispatch instructions and metered output, by site and by constraint boundary. Price recovered MWh at the captured price for the relevant periods, stating the price vintage and its source. Design the control: hold back a comparable set of sites or turbines on the existing process. Agree the attribution method with internal audit before anything changes.
A benefit in MWh and £, with an agreed attribution method
Days 46–70
Build the gate schedule and take it to governance
Convert the programme into four tranches with the inverted profile: data readiness, offline result, shadow season, then rollout. Price each tranche, write the kill criterion for each, and state the maximum regret at each gate. Take the inversion to capital governance explicitly, with the risk-profile argument written down. Expect this to be the phase that slips.
An approved gate schedule with kill criteria and maximum regret
Days 71–90
Open the benefit register and run the first reconciliation
Create the register entry: appraised benefit, unit, baseline, control group, attribution method, price vintage, review date and named FP&A owner. Run the first monthly reconciliation of claimed against booked benefit even though the number will be small and noisy. The point of the first reconciliation is to prove the pipeline works before the number matters.
A live register entry and a working monthly reconciliation

The order matters

Classification before appraisal
Appraising a programme before classifying its cost lines produces a case whose capital and operating profile is wrong, and the correction always arrives late and unhelpfully. Twenty days of tagging changes the shape of the case more than any modelling refinement will.
Baseline before go-live
A baseline pulled after the model is running inherits the model's own effects and can never cleanly attribute them. In a renewables portfolio the confounds — resource, prices, constraint regimes, outage schedules — are large enough to swamp the effect entirely. Design the control group while there is still something to hold back.
Gate structure before the large tranche
The instrumentation and rollout tranche is where the money is, and it is the one that should be released last. Programmes that buy instrumentation first do so because it is procurable and visible, and they end up owning sensors whose data the eventual model does not need.
One cost line before the portfolio
The classification ledger, the gate schedule and the register are all reusable once they exist for one cost line. Building them for a whole function first encodes guesses; building them for one curtailment model and then generalising encodes what actually happened.

Benefits realisation that survives an audit

The four artefacts that turn a claimed benefit into a booked one — and the readiness checklist a reviewer will effectively be working through.

A benefit survives an audit when four artefacts exist and were created before go-live: a baseline drawn from metered data, a held-back control group, an attribution method agreed with internal audit, and a register entry owned by FP&A rather than by the team that built the model. Every one of those has to pre-date the intervention. There is no method for reconstructing them afterwards that a reviewer will accept, and this is the single most common reason a genuinely successful AI programme cannot prove it.

Field	What it holds	Source	Who owns it
Benefit type	Curtailment, availability, O&M, imbalance, yield or trading margin	The appraised case	FP&A
Unit	MWh, £/MWh, £ per MW per year, availability points, customer-minutes	The appraised case	FP&A
Baseline	The pre-intervention level, by site and period	Metered output, dispatch instructions, work orders, settlement data	FP&A, from operational systems
Control group	The sites, turbines or feeders held back from the change	Asset register, named explicitly at design time	Operations, agreed with FP&A
Attribution method	How the difference is assigned to the intervention	Agreed in writing with internal audit before go-live	Internal audit signs, FP&A maintains
Price basis and vintage	The prices used and the year they came from	Settled positions or published market data	Commercial, reviewed annually
Claimed vs booked	The appraised benefit and the realised benefit, per period	The register itself, reconciled monthly	FP&A
Review date	When the assumptions expire and must be re-validated	Set at creation, never open-ended	FP&A

The benefit register entry, field by field. This is what FP&A owns and what internal audit tests. Every field has a source system named, because a benefit whose source system cannot be named is an estimate.

The attribution method deserves more attention than it usually gets, because in a renewables portfolio the confounds are unusually strong. Wind resource, irradiance, constraint regimes, market prices and outage schedules all move independently of the model, and any of them can be larger than the effect being measured in a given month. A held-back control group of comparable sites or turbines is the only mechanism that handles all of those at once, and it costs a small amount of forgone benefit. Finance functions that treat that forgone benefit as waste end up with a portfolio of unprovable claims, which is a far more expensive position.

Prudence-review readiness checklist

Eight items. A reviewer will effectively be working through this list whether or not it exists on your side. Tick as you go — this list works without JavaScript.

Every AI cost line is tagged to a project, a benefiting asset and a use caseTagged at the point the cost line is raised, not reconstructed at year end.
A written classification ledger gives each cost line a default treatmentOne page, applicable by a project engineer without calling an accountant.
Research-phase and development-phase model work are distinguished in the recordWith the date the recognition criteria were met, evidenced contemporaneously.
Capitalised amounts tie to invoices, timesheets and a stated allocation basis
Every capitalised component has an in-service date and a used-and-useful description
Funding is released in tranches against evidence, with a written kill criterion
A pre-go-live baseline and a named control group exist for every claimed benefitDrawn from metered data and agreed with internal audit before the change.
The benefit register is owned by FP&A and reconciled every reporting periodClaimed against booked, with variances feeding the next appraisal round.

0 of 8 ticked

Nothing ticked — start with the inventory, not the policy

Zero ticks is an honest rung-1 position and it has a cheap first move. Do not commission a technical accounting memo. Spend two weeks producing the AI cost inventory: every vendor, subscription, licence and internal labour charge, tagged to a project and a use case. Every other item on this list needs that inventory to exist first, and most finance functions are surprised by the total.

Scope the cost inventory with us

Failure modes that unwind an AI capital case

Four regressions account for almost all of it, and none is an accounting error in the ordinary sense.

AI capital cases unwind for reasons that look procedural and are actually structural. In each of the four below the accounting was defensible at the time; what failed was the surrounding discipline — the evidence, the ownership, the assumption vintage or the classification boundary. All four are cheap to prevent and expensive to remedy, which is the usual signature of a governance gap rather than a technical one.

Likelihood: highImpact: high

The benefit was never baselined, so it cannot be booked

The model works, operations are happy, and the finance function cannot attribute a single pound to it because there is no pre-intervention baseline and no control group. The claim then gets discounted to zero at the next planning round, and the programme is defunded despite working. In renewables this bites hardest on curtailment and availability benefits, where the year-to-year variance from resource and constraint regimes is larger than the effect.

PreventionNo funding tranche is released without a named baseline, a named control group and an attribution method agreed with internal audit.

Likelihood: highImpact: high

The whole programme was classified as one thing

Hardware, integration labour, development-phase model work, research and cloud consumption are swept into a single treatment because they were one programme and one purchase order. Some portion of that bundle is necessarily wrong, and it is the bundle rather than any individual judgement that draws the audit adjustment or the regulatory disallowance.

PreventionClassify at cost-line level, in the ledger, and require statements of work to be split by activity at contract stage.

Likelihood: mediumImpact: medium

The consumption line grew and nobody re-forecast it

Cloud, inference and API spend scale with usage, and usage scales with success. A case approved on a year-one consumption assumption looks very different in year three when the capability is running across the portfolio. The overspend is discovered as a variance rather than a forecast, and it damages the credibility of the whole category rather than of the one programme.

PreventionForecast consumption against the rollout curve, not the pilot, and reconcile actual against appraised usage monthly.

Likelihood: mediumImpact: high

The benefit assumptions aged out silently

A curtailment benefit priced under one year's constraint regime and one year's captured prices keeps being reported after both have moved. The register looks healthy and is describing a market that no longer exists. This is the most common cause of regression from rung 5, and it is invisible until an external reviewer asks for the vintage.

PreventionEvery register entry carries a price vintage and a review date, under the same change control as a capital assumption.

Regulatory context is jurisdictional and it changes the mechanics rather than the principle. In the United States the relevant structures are the FERC Uniform System of Accounts (opens in a new tab) and state-level rate proceedings, with NARUC (opens in a new tab) as the standing forum for the commissions that run them and FERC itself (opens in a new tab) for federal jurisdiction. In Great Britain the equivalent question is how spend is treated within the price control, where Ofgem's RIIO framework (opens in a new tab) uses a totex approach that deliberately blunts the capex/opex incentive by allowing a proportion of total expenditure to be capitalised regardless of its accounting classification. The principle is identical everywhere: classify before you spend, evidence contemporaneously, and describe the component in the regulator's own vocabulary rather than the vendor's.

Glossary

Hover a term for its definition — or expand the map full screen. The full definitions are written out below.

Rate base: The value of a regulated utility's prudent, used-and-useful assets on which the regulator allows a return. Capitalised assets enter it once in service; expensed costs never do. Called the regulated asset base, or RAB, in most European regimes.
Allowed return: The rate of return a regulator permits a utility to earn on its rate base, set through a rate case or price control. It is distinct from the company's own hurdle rate, and it is what makes the capitalisation decision economically consequential rather than presentational.
Used and useful: The regulatory test that an asset is in service and actually serving customers before it earns a return. An AI component that is technically installed but not yet operationally relied upon usually fails this test, whatever the accounting position.
Prudence review: A regulator's assessment of whether spend was reasonable given what was known when it was committed. It tests the decision record, not the outcome — which is why a stage-gated funding history is the strongest defence available.
Regulatory asset: A cost that would ordinarily be expensed but which a regulator permits to be deferred and recovered over a later period. Whether AI-related spend qualifies is fact-specific and jurisdictional, and it must be settled with regulatory counsel before commitment.
Totex: Total expenditure — the combined capex and opex approach used in Ofgem's RIIO price controls, under which a set proportion of total spend is capitalised regardless of accounting classification, deliberately reducing the incentive to prefer capital solutions.
Hurdle rate: The minimum risk-adjusted return an investment must clear to be approved, usually anchored to the weighted average cost of capital. It tests a cash-flow profile, which is why benefits expressed as model accuracy cannot be assessed against it.
LCOE: Levelised cost of energy: the lifetime cost of a generation asset divided by the energy it produces, in cost per MWh. The benchmark an AI benefit in a renewables programme is ultimately measured against, since the goal is either more MWh or lower lifetime cost.
Capacity factor: Actual output over a period as a proportion of theoretical maximum output. AI benefits in generation usually appear here first — through avoided curtailment, higher availability or better power-curve control — before they appear as revenue.
Curtailment: Output a generator is instructed or forced to reduce, typically because of network constraints or negative prices. Recovered curtailment is one of the largest addressable AI benefits in a constrained renewables portfolio, and one of the hardest to attribute.
Benefit register: The live reconciliation between the benefit an investment claimed and the benefit actually booked, per period, in the units the P&L uses. Owned by FP&A rather than by the delivery team, and the defining artefact of the top rung of this ladder.
Maximum regret: The cumulative spend an organisation would have incurred if a programme is stopped at a given gate. Stating it per gate is what makes an investment committee comfortable funding an initiative whose benefit is genuinely uncertain.

Frequently asked questions

The questions utility CFOs and FP&A teams ask most often when an AI line first appears in a capital plan. None of the answers is accounting or tax advice — treatment is framework-, jurisdiction- and fact-specific.

Can AI spend be capitalised in a utility?

Parts of it, and the parts differ sharply. Sensors, instrumentation, controller upgrades and the integration labour that brings a physical asset into working condition generally have a straightforward capitalisation argument. Cloud consumption, foundation-model API spend, third-party SaaS subscriptions and research-phase model development are usually period costs. Development-phase model work sits between the two and is capitalised only from the point every recognition criterion under the applicable standard is met and evidenced contemporaneously. Classify at cost-line level rather than programme level, because a single AI programme routinely contains all of these categories at once.

Does capitalised AI spend enter the rate base?

Only if it is capitalised, in service, and used and useful, and only to the extent a regulator accepts the spend was prudent. Those are three separate tests and a component can pass the accounting one and fail the regulatory ones. In practice the components with the cleanest rate-base case are instrumentation, metering upgrades and control integration attached to identifiable host assets, because they have serial numbers, commissioning dates and an obvious operational purpose. Software and model components are harder, and the recovery treatment should be settled with regulatory counsel before the spend is committed rather than argued afterwards.

Why do AI business cases fail our hurdle rate?

Almost always because the benefit is stated in the wrong unit. A hurdle rate tests a cash-flow profile, so a benefit expressed as a percentage-point improvement in forecast accuracy has nothing to attach to. The fix is a translation the proposing team can do: identify what operationally changes because of the model, then the cash line that change lands on, then the unit — MWh recovered, £ per MW per year of O&M, avoided imbalance charges, availability points. State the derivation and the price vintage, and present a downside case at half the modelled benefit that still clears.

What discount rate and asset life should an AI business case use?

Set both per component rather than for the programme. Instrumentation and control integration take the host asset's remaining life and the regulated or corporate cost of capital, because that is what they physically are. Model and platform development take a short life — often three years or less, because retraining and re-scoping are certain — with an explicit risk premium for benefit uncertainty. Cloud consumption and subscriptions are recurring operating costs and should not be amortised into the capital appraisal at all. A single uniform assumption across the programme will overstate NPV badly in one direction or the other.

How should AI funding gates differ from construction gates?

They should be inverted. A renewables construction project carries its uncertainty at the front and resolves it toward FID, so the largest tranche is released early. An AI programme has modest technical risk and very high benefit risk, and benefit risk falls only after live running against real plant. So the tranches should be small through data readiness, offline result and a shadow season, with the largest released only after a metered benefit on live plant. State the inversion explicitly in the paper and give the risk-profile reason, rather than quietly working around the existing framework.

How do we prove an AI benefit to an auditor?

With four artefacts, all created before go-live: a baseline drawn from metered data rather than estimates, a held-back control group of comparable sites, turbines or feeders, an attribution method agreed in writing with internal audit, and a register entry owned by FP&A rather than the delivery team. Attribution designed after the fact inherits the intervention's own effects, and in a renewables portfolio the confounds from resource, prices and constraint regimes are usually larger than the effect being measured. Nothing reconstructed afterwards will satisfy a reviewer.

Where does cloud consumption sit — capex or opex?

Consumption is a period cost in essentially all fact patterns: compute, inference and data egress are services consumed in the period, not resources the entity controls. Configuration and customisation of a cloud arrangement is the more interesting question, and the IFRS Interpretations Committee addressed it directly, concluding that such costs are generally expensed unless a separate identifiable asset arises. The practical consequence for budgeting is that consumption belongs in the operating cost profile for the life of the capability, forecast against the rollout curve rather than the pilot, and reconciled monthly against the appraised usage assumption.

How do tax credits and capital allowances interact with AI spend?

Separately from the accounting classification, and the tests are different. UK capital allowances are claimed against qualifying plant and machinery under HMRC's rules; US clean-energy credits are administered by the IRS with eligibility defined by asset type, placed-in-service timing and statutory conditions that change with legislation. Whether AI-related instrumentation attached to a qualifying energy asset shares that asset's treatment depends on how it is integrated and on the statute in force. This is genuinely fact-specific and must be answered by your tax advisers before commitment — an accounting capitalisation decision does not by itself determine tax treatment or credit eligibility.

Does the RIIO totex approach change any of this in Great Britain?

It changes the incentive, not the discipline. Ofgem's RIIO price controls use a totex approach in which a set proportion of total expenditure is capitalised for regulatory purposes regardless of its accounting classification, deliberately removing the bias toward capital solutions that a pure capex-based framework creates. That reduces the financial consequence of the capex/opex judgement in the regulated entity, but it does not remove the need for classification, for evidenced cost support or for benefit attribution — those are still required for statutory accounts, for internal audit and for the price control's own reporting.

Should AI have its own budget line or sit inside project budgets?

A programme line with charges allocated back to benefiting assets, as an interim, and a portfolio allocation as the destination. AI buried inside individual project envelopes cannot be compared across projects, its shared components get paid for repeatedly, and its costs cannot be allocated to the assets that actually benefit — which matters when those assets have different ownership structures, PPAs and regulatory regimes. A wholly separate central line is the opposite failure: visible but disconnected from the project economics it is supposed to improve.

What is a realistic first-year AI budget for a renewables operator?

The question is better asked as maximum regret per gate than as an annual number. A first gate covering data readiness against the historian and meter data is small enough to approve without a committee cycle in most organisations. The offline result and a single shadow season on two sites are the next two, still modest. The material money — instrumentation, control integration and portfolio rollout — belongs in the final tranche, released only after a metered benefit. Framed that way, the first-year figure is a consequence of how far the evidence gets rather than a target set in advance.

Who should own the AI benefit register — finance or the AI team?

FP&A, without exception, with the delivery team as a data source. A benefit claim reported by the team whose continued funding depends on that claim is not evidence, however honest the team is, and internal audit will treat it that way. FP&A ownership also puts the reconciliation on the normal reporting cycle rather than on a project cadence, which is what makes variances feed back into the next appraisal round instead of being explained away at a programme review. The delivery team should still supply the operational data and the technical interpretation.

About the author

Atomic Loops Engineering

Industrial AI practice

Atomic Loops builds production AI systems for energy, utilities and infrastructure operators — generation forecasting, curtailment and dispatch optimisation, condition monitoring and asset-health models running against live plant and market data, integrated into the SCADA, historian and asset-management layer rather than delivered as dashboards. We scope work so it can be classified, gated and evidenced by a finance function.

· Production deployments across wind, solar, storage and network operations
· Capital-plan scoping done jointly with FP&A and technical accounting leads
· Benefit registers built from metered plant data, not self-reported estimates
· 18 cited sources on this page

Sources

Energy & Utilities industry practiceProduction AI systems Atomic Loops has built for generation, networks and energy retail operators.Leadership insights and strategy for energy & utilitiesThe sibling leadership pages in this cell — including taking an approved AI strategy round the estate once it is funded.AI readiness and transformation roadmap for energy & utilitiesThe sequencing work a funded capital plan turns into — what gets built first once the gates are agreed.

Find out what your AI spend actually is — then what it should be

We run the assessment with your FP&A and technical accounting leads, produce the classification ledger against your own cost lines and account structure, and leave you with a costed 90-day plan for your weakest dimension. You keep the ledger and the plan whether or not we build anything.

Book a budgeting review See our energy and utilities work

Published 14 August 2026 · Last updated 14 August 2026

Key takeaways

Abbreviations used on this page

Score your AI capital budgeting

What AI capital budgeting in renewables is — and the one split it turns on

The five rungs in detail

Unbudgeted

Line-itemed

Stage-gated

Rate-base aligned

Portfolio-optimised

Where utility finance functions actually sit today

The cost classification ledger, line by line

Hurdle rates: why AI business cases fail financial review

What the financial argument looks like in public

The funding model: gates matched to an AI uncertainty profile

Field instrumentation

Edge and control integration

Data platform

Model layer

Assurance and evidence

A 90-day plan: getting one curtailment model through capital approval

The order matters

Benefits realisation that survives an audit

Failure modes that unwind an AI capital case

The benefit was never baselined, so it cannot be booked

The whole programme was classified as one thing

The consumption line grew and nobody re-forecast it

The benefit assumptions aged out silently

Glossary

Frequently asked questions

Can AI spend be capitalised in a utility?

Does capitalised AI spend enter the rate base?

Why do AI business cases fail our hurdle rate?

What discount rate and asset life should an AI business case use?

How should AI funding gates differ from construction gates?

How do we prove an AI benefit to an auditor?

Where does cloud consumption sit — capex or opex?

How do tax credits and capital allowances interact with AI spend?

Does the RIIO totex approach change any of this in Great Britain?

Should AI have its own budget line or sit inside project budgets?

What is a realistic first-year AI budget for a renewables operator?

Who should own the AI benefit register — finance or the AI team?

About the author

Sources

Related reading

Find out what your AI spend actually is — then what it should be