The honest read on financial modeling AI in 2026 is that it has gotten good at a specific, useful thing. In recent evaluations, capable models such as Claude and a handful of dedicated finance tools can build a fully integrated three-statement model meaningfully better than a general assistant. The balance sheet ties, the cash flow rolls, the schedules link. That is real progress.
It is also where people draw the wrong conclusion. A model that assembles a coherent three-statement model has not made the judgement calls underneath it. It picked a revenue growth path, a working-capital cycle, a tax rate, and it did so from whatever it could infer. Some of those choices will be defensible. Some will be wrong in ways that only an analyst who knows the business will catch.
So the design question is not whether to use an analyst copilot. It is how to keep a human in the loop without turning that human into a rubber stamp.
Where the copilot does the work
The copilot is at its best on the parts of modeling that are mechanical and time-consuming. This is where the human-in-the-loop arrangement actually pays off, because it gives the analyst back the hours that data assembly used to eat.
- First-draft models. Standing up the three-statement skeleton, wiring the links, building the supporting schedules. A draft in an hour beats a blank workbook on a Monday.
- Pulling and formatting data. Filings extraction, history from the warehouse, the tedious work of getting numbers into a consistent shape with the periods lined up.
- Drafting commentary. A first pass at the narrative around the numbers, which the analyst then rewrites rather than starts from nothing.
None of this removes the analyst. It moves them up the chain, from typing to thinking, which is the only version of this that is worth paying for.
Where the human stays
Some things do not move. The analyst owns the assumptions, full stop. A copilot can propose a growth rate; it cannot be accountable for it. The same goes for sign-off and for anything that ends up in front of a client or a board. If a number is going into a board pack, a person with a name attached has to stand behind it.
This is not caution for its own sake. A three-statement model that ties perfectly can still be built on an assumption that nobody would defend out loud. The output looks finished, which makes a bad assumption harder to spot, not easier. The analyst’s job is exactly the part the copilot cannot do: deciding whether the story the numbers tell is the right one.
Design the output to make review fast
The way to keep the human genuinely in the loop, rather than nominally in it, is to build outputs that show their working. Review should be quick because the model is legible, not because the analyst stopped looking.
A few things we hold to when designing these systems:
- Every assumption is surfaced as an editable input, not buried in a formula, so the analyst can see and change what drives the model.
- The copilot states its sources. A pulled figure carries its lineage back to the filing or feed it came from, so a value can be checked rather than trusted.
- Outputs flag where the model inferred rather than knew. An assumption the copilot guessed at should look different from one the analyst confirmed.
Get this right and review takes minutes on the parts that are sound and concentrates attention on the few that are not. Get it wrong and you have built a system that is fast to produce and slow to trust, which is worse than the manual process it replaced.
The value of an analyst copilot is augmenting judgement and cutting data-assembly time. It is not the analyst, and the moment a project starts treating it as one, the output stops being something anyone can sign.