Let AI own the language, never the number.
The false choice
Most writing about AI in finance offers a developer two doors:
automate the finance function, or hold the technology at arm’s length until it’s proven safe.
Both doors assume the value sits in the tool. It doesn’t. The value sits in the person who knows which assumption won’t survive a credit committee, which forecast is quietly wrong because it can’t see next quarter’s grid connection slipping, and which covenant figure carries legal consequences if it’s off by a rounding error. AI holds none of that knowledge. A skilled finance operator does — and that operator, running AI in the loop, produces senior-grade output faster and across more of the finance function than they ever could alone.
That’s the real move. Not replacement, not resistance — amplification. And it comes with one working rule, simple enough to carry into every finance task you run:
let AI own the language, never the number.
The lean developer’s real constraint
A developer with a growing pipeline has an awkward finance problem. The work is institutional in nature — lender-ready project models, information memoranda that withstand diligence, board packs that stand up to a sophisticated investor, covenant reporting a bank will hold you to.
The volume rarely justifies the FP&A department a utility runs. You need the quality of a senior finance function without its headcount.
Put precisely, the constraint isn’t headcount at all. It’s senior bandwidth. One capable finance person can only be in one place, and the highest-value work — the model, the capital-allocation call, the lender negotiation — is exactly the work that can’t be rushed or handed to someone junior. So it queues. The IM waits because the model needs attention. The variance analysis runs thin because the reforecast is due. The board narrative gets written at midnight.
This is the constraint AI actually relieves — not by replacing the senior person, but by stripping out of their day everything that was never the reason you needed a senior person. The reconciliation that ate a morning. The first draft of the commentary. The sixty-page offtake contract that had to be read before one assumption could be set. Clear those, and the same practitioner spends their hours where judgement is the product. That’s the whole argument for augmentation. The rest of this piece is what it looks like in practice.
Where AI earns its place
One principle sits underneath every genuinely useful application of AI in FP&A, and it’s worth stating before the list:
AI earns its place wherever language is the input and a human owns the output.
Text in, structured sense out — that is what large language models are built to do, and every strong use case below fits the pattern.
Turning documents into inputs. A developer’s assumptions live buried in prose: power purchase agreements, grid connection offers, CfD and capacity auction terms, O&M contracts, planning conditions, regulatory consultations. Pulling the financially relevant terms out of a long offtake contract, or compressing a NESO consultation into “here’s what changes for our revenue stack,” is precisely what AI does well — and it applies equally to a PV offtake, a wind CfD, or a storage capacity-market position. The practitioner still checks every extracted term against source. But the distance between “here’s a sixty-page contract” and “here are the six terms that touch the model” collapses from a morning to minutes.
Drafting the narrative on numbers you already own. Variance commentary, board-pack narrative, IM prose, investor updates. Finance people write slowly, and writing is a large share of the job. The discipline is direction of travel: the numbers come from the practitioner’s validated model; AI drafts only the words around them. Low risk, because the figures are already right. High leverage, because a slow task becomes a fast one. The analysis is the human’s — AI just gets it onto the page quicker.
Reconciliation and anomaly-flagging at scale. Not “AI does the reconciliation.” AI as a tireless second pass that flags breaks, outliers, and figures that don’t tie — across ledgers, model versions, data sources. It surfaces candidates; the practitioner adjudicates. The downside is bounded, because a missed flag gets caught by the human’s own review anyway.
Interrogating a model you built and own. This one matters most to any lender reading over your shoulder, so it deserves careful wording. AI is genuinely useful reviewing a model — explaining an inherited circularity, pointing at where a formula could break, checking whether a block of logic does what its label claims, proposing stresses to run. Review works precisely because it requires the AI to own nothing. The practitioner built the model and answers for every cell of it; AI is a second pair of eyes, never the builder. That keeps you firmly on the right side of the auditability line while capturing a real benefit.
Sparring before you build. What sensitivities would a credit committee want on a merchant PV case? What’s missing from this wind downside? AI widens the option set; the practitioner filters it through what an actual lender will ask. Useful — and honest about who does the filtering.
Notice the common shape.
-> Language goes in.
-> A human-owned decision comes out.
The moment that inverts — the moment a number becomes the output AI owns — you’ve crossed into the territory the next section is about.
Where the human is the enhancement
The reason a developer needs a skilled operator rather than a subscription is not that AI is dangerous in the abstract. It’s that
AI produces one specific kind of error, and catching it is the skill you’re actually buying.
The error is structural, not occasional. A language model generates the most plausible continuation of whatever it was given. When the subject is numeric — a solar degradation rate, a wind P50 yield, a storage capture rate — it produces a figure that is well-formatted, confident, and plausible, with nothing attached to say whether it’s grounded or invented. There is no wobble in the output. A fabricated capture rate sits in the sentence with the same authority as a sourced one. A wrong degradation curve looks exactly like a right one.
FP&A is unusually exposed to this failure mode, for three compounding reasons.
1) Its outputs are numeric, so errors propagate rather than sit still.
2) Those numbers are consequential downstream — an assumption flows into a model, into an IM, into a financing decision. And
3) the work is audited: a plausible-but-wrong figure is something a lender’s technical adviser, a model auditor, or eventually a court will test.
The failure is dangerous precisely because it looks right for long enough to reach a document that matters.
That is why the judgement layer can’t be automated — and why the human in the loop is the enhancement, not a tax on it.
The model itself. An investment-grade project model is a bespoke artefact a third party must be able to audit — FAST-standard structure, debt sculpting resolved cleanly, every assumption traceable. AI can help review it. It cannot own it. The model’s integrity is the practitioner’s, and it is exactly what a lender relies on when they lend.
The assumptions. Every material input — capture rate, degradation, resource, availability, capex benchmark — must trace to a defensible source and survive challenge. This is the highest-hallucination-risk task in the entire function. The skill on offer isn’t having once been burned by a bad number; it’s knowing, structurally, that this is where the exposure always lives, and never letting an unverifiable output become a model input.
The forecast that knows things the data doesn’t. A good reforecast encodes what hasn’t happened yet — the slipping grid connection, the delayed CfD round, the auction that moved. AI extrapolates from the past. The practitioner holds next quarter.
The covenant figure and the capital call. A covenant calculation carries legal teeth; a wrong number can trip a default. The decision about which project in a multi-technology pipeline gets scarce development capital shapes the firm’s future. Neither is a place for a plausible output. Both require a named human answerable for the result.
The pattern holds in every case. Where the output is a number someone will be held to, the human leads and AI assists — and the practitioner’s value is knowing exactly where AI’s output can’t be trusted, and fixing it before it reaches a page a lender reads.
The dividing line, drawn precisely
Set the two previous sections side by side and the line between them isn’t arbitrary. It tracks two variables.
Standardisation. The more routine and repeatable the task — extraction, reconciliation, first-draft text — the more AI can carry it, because the pattern is well-worn and the human can verify the result quickly.
Accountability. The more consequence attaches to the output — a covenant certificate, a model a bank underwrites, an assumption behind a financing decision — the more the human must lead, because someone has to be answerable to a board, a lender, or a court, and a model cannot be.
Plot the whole finance function on those two axes and it sorts itself.
High-standardisation, low-accountability work falls where AI does most of the lifting.
High-accountability, bespoke work — the model, the assumptions, the capital call — falls where the human leads and AI is at most a second pair of eyes. The operating instruction that drops out of the grid:
delegate the floor, own the ceiling.
What this means for your finance function
The practical conclusion is not “hire an FP&A team,” and it is not “buy the tools and manage it yourself.” Neither solves the constraint. The team you can’t justify at your stage. The tools without judgement give you faster access to plausible-but-wrong numbers — which is worse than slow ones.
What resolves it is senior finance judgement that already works this way: a practitioner who uses AI to clear the floor and reserves their hours for the ceiling. That’s how a lean developer gets institutional-grade FP&A across the whole function — models, IMs, forecasts, board and lender reporting, capital analysis — without institutional cost. The output is senior.
The overhead is not.
One more point belongs here, because a lender will expect you to have thought about it: confidentiality. A term sheet, a draft IM, a lender’s covenant package — none of it belongs in a consumer AI tool that may retain or train on what it’s given. There is a hard distinction between enterprise-grade tooling with proper data controls and the free version in a browser tab, and a serious operator works only in the former when client-confidential material is involved. The subject deserves its own piece. The short version: discipline about where the data goes is part of the judgement you’re buying, not separate from it.
You’re not buying software
The question a developer faces was never “should we use AI in finance.” Everyone will; the tools are the easy part.
The real question is how to get senior finance judgement at the scale a growing pipeline demands
— judgement that knows which number won’t survive diligence, which forecast is blind to a known event, which assumption can’t rest on an unverifiable output.
The answer is a practitioner who runs AI in the loop and stays accountable for every figure that leaves the room. AI can draft the language all day. It cannot answer for the number — and in lender-facing finance, answering for the number is the entire product.
Let AI own the language. Never let it own the number.
That single discipline separates a finance function a bank will underwrite from one that merely looks like one.
Advance Klimate Solutions advises developers, PE-backed platforms, and institutional lenders on renewable energy project finance, financial modelling, and portfolio-company finance across the UK, Europe, and CEE.
In addition we support renewable energy platforms with interim FP&A function.
www.advaklim.com
Leave a Reply