AI can now generate surprisingly complete financial models. Give a sufficiently detailed prompt and a modern AI system can produce assumptions, schedules, formulas, scenario structures, and summary outputs in a fraction of the time that a traditional modelling workflow might require. That changes the bottleneck.
The difficult part is no longer only building the spreadsheet. It is establishing whether the generated model actually represents the business logic that the modeller intended. This distinction matters because a financial model can be mathematically consistent and still be wrong. A formula can calculate exactly what it was written to calculate while implementing the wrong assumption, applying the wrong timing convention, referencing the wrong cell, or interpreting a business instruction incorrectly.
That is why human-in-the-loop validation should be treated as part of the architecture of an AI-assisted financial modelling system rather than as a final visual inspection before someone opens the workbook. Recent guidance and research point in the same direction. ICAEW's 2026 discussion of AI-generated financial models recommends treating AI output as a draft that requires close human review, while PwC describes human-led validation as important for checking completeness, accuracy, reliability, business alignment, and source quality.
Generation and validation are different problems
A useful way to design these systems is to separate model generation from model validation.
The generation process might take natural-language requirements, source documents, assumptions, or structured inputs and convert them into a financial model. The resulting workbook or structured model can then be passed through deterministic calculations and automated validation before a human reviewer examines the remaining issues.
Conceptually, the workflow looks like this:
Source data and requirements
↓
AI model generation
↓
Deterministic calculation
↓
Automated validation
↓
Exception review
↓
Human validation
↓
Approved model
The important point is that the system does not ask the same component to generate the model and then declare its own output correct.
The AI system can propose the model structure and logic, but independent checks should establish whether the resulting model satisfies predefined requirements. The human reviewer then deals with questions that cannot be resolved reliably through mechanical checks alone. This separation becomes especially important when the model contains assumptions about timing, business rules, accounting treatment, project phases, or scenario interpretation.
A model can be internally consistent and still be wrong
Consider a simplified development model with land cost, construction cost, development period, revenue, operating expenses, financing, and an exit value. Suppose the AI generates all the formulas correctly from a syntactic perspective. Every cell contains a valid formula, there are no broken references, and the workbook recalculates without errors.
That does not establish that the model is correct. Imagine the project is supposed to generate operating revenue only after completion, but the generated model begins recognizing revenue during construction. The formulas may still be perfectly valid. The spreadsheet may balance. The summary page may display plausible-looking numbers.
The error is semantic rather than syntactic. The same problem can occur when an AI system interprets a cost assumption incorrectly, uses a different definition of area than the source data, applies an assumption to the wrong period, or changes the dependency between two schedules.
This is one reason human review remains important. A human reviewer can ask whether the model represents the intended scenario rather than merely whether the spreadsheet executes successfully.
Validation should happen at several levels
A robust validation process should not rely on a single test. The first level is structural validation. This checks whether the generated model contains the expected components and whether those components are connected in a sensible way. Required assumptions should be present, expected schedules should exist, output sections should be populated, and unexpected hard-coded values or missing dependencies should be flagged.
The second level is formula validation. Here the system checks whether formulas exist where they should, whether formulas are consistent across periods, whether references are valid, and whether unexpected changes appear in repeated calculation structures. Checks for broken references, circular references, inconsistent ranges, and formulas replaced by hard-coded values can often be automated.
The third level is numerical validation. Instead of asking whether an output "looks reasonable," the system tests known relationships within the model. For example, if total revenue is defined as the sum of periodic revenue, that relationship can be tested directly. If total project cost is defined as the sum of several cost categories, the reconciliation can be performed independently of the AI that generated the workbook.
The fourth level is semantic validation, and this is where human judgement becomes particularly important. The reviewer needs to establish whether the assumptions and calculations correspond to the intended business scenario. Automated tests can tell you that a formula works. They cannot always tell you that it is the right formula for the question being asked.
Deterministic checks are particularly valuable
Financial modelling contains many relationships that do not need probabilistic judgement.
If a model specifies that:
Total Cost = Land Cost + Construction Cost + Other Costs
the validation system can calculate both sides independently and compare them.
If:
Cash Balance[t] =
Cash Balance[t-1]
- Cash Inflows[t]
- Cash Outflows[t]
the system can test that relationship for every relevant period.
If a revenue schedule is driven by units and price:
Revenue[t] = Units[t] × Price[t]
The validation process can independently recalculate the expected result. These tests are valuable because they establish explicit pass/fail conditions. The validation result does not depend on another language-model response saying that the number "appears reasonable."
For financial models, this distinction is important. Where a calculation has a clearly defined mathematical relationship, the validation system should use that relationship as the reference rather than asking another probabilistic model to judge the answer.
Recent work on financial AI validation makes a similar argument: benchmark performance alone is not sufficient evidence for a production financial AI system, because the complete system also includes data, retrieval, generation, tool use, orchestration, monitoring, and human escalation.
Provenance should travel with the assumption
Another important part of validation is provenance. When an AI-generated model contains an assumption such as a construction cost, occupancy rate, price, interest rate, or development period, the reviewer should be able to understand where that value originated.
For example, instead of simply storing:
Construction Cost = 125
a model could maintain metadata such as:
Value: 125
Unit: USD / sq ft
Source: User-provided assumption
Status: Confirmed
The exact implementation will vary between systems, but the principle is straightforward: important assumptions should be traceable. This becomes more important when AI systems transform information before placing it into a model. If an input has been extracted from a document, inferred from context, converted between units, or derived from another assumption, the validation process should make that transformation visible.
The OECD's 2026 work on AI in finance similarly emphasizes traceability, validation, monitoring, and retention of model instances so that problematic behaviour can be investigated later rather than disappearing when a system is updated.
Do not use AI as the only validator
One of the easiest mistakes to make is to build a workflow that looks like this:
AI generates model
↓
AI reviews model
↓
Model approved
A second AI pass can certainly be useful. It can identify missing sections, obvious inconsistencies, unusual formulas, or potential errors. But it should not be the sole approval mechanism.
If the same underlying reasoning process can introduce an error, asking a similar system to validate the output does not provide the same level of independence as an external deterministic check or human review.
A stronger architecture separates responsibilities:
┌─────────────────┐
│ AI generation │
└────────┬────────┘
↓
┌─────────────────┐
│ Calculations │
│ and rules │
└────────┬────────┘
↓
┌─────────────────┐
│ Automated │
│ validation │
└────────┬────────┘
↓
┌─────────────────┐
│ Human review │
└────────┬────────┘
↓
Approval state
This does not eliminate AI-generated errors. It creates multiple opportunities for those errors to be detected.
Human review should focus on exceptions
Human-in-the-loop does not mean that a modeller should manually inspect every cell in every generated workbook. That would remove much of the efficiency gained from automation. A better design is to automate the repeatable checks and send exceptions to a human reviewer.
A validation report might therefore look like:
Structural checks: PASS
Formula checks: PASS
Reconciliation checks: PASS
Missing assumptions: 2
Unexpected formula changes: 1
Timing interpretation: REVIEW REQUIRED
Source provenance: 1 item unresolved
The reviewer can then concentrate on the areas where judgement is actually required.
This is a more practical division of labour. Computers are well suited to repeating deterministic tests across thousands of cells and periods. Humans are better positioned to resolve ambiguous requirements, interpret business context, and challenge assumptions. PwC similarly recommends tailoring the level of human review to the complexity and risk of the use case, with more rigorous validation for higher-stakes financial outputs.
Test the model by changing its assumptions
Validation should not stop with the base case. A useful model should respond coherently when important assumptions change. Suppose construction cost increases by 10%. The model should show the corresponding effect on total development cost and any downstream cash-flow metrics that depend on it.
Suppose the development period changes. Timing-sensitive costs and revenues should move accordingly. Suppose an input is set to zero. If that input is genuinely part of the calculation chain, the relevant outputs should respond. These tests can expose broken dependencies that may not be visible when reviewing the base case alone.
The purpose is not to determine whether a particular scenario is commercially attractive. The purpose is to verify that the model behaves according to its defined logic when its inputs change.
Define the approval state explicitly
Another useful design decision is to make model status explicit. A generated model should not automatically become an approved model.
A simple state machine could be:
GENERATED
↓
AUTOMATED VALIDATION
↓
┌───────────────┐
│ │
PASS FAIL
│ │
↓ ↓
HUMAN REVIEW REPAIR
│ │
├── APPROVED ───┘
│
└── CHANGES REQUIRED
This creates an audit trail around the model itself. It also prevents a common operational problem: treating an AI-generated artifact as if it has already passed the organization's review process simply because it exists and produces numbers.
The role of the human is changing
Human-in-the-loop validation does not necessarily mean that AI has failed to automate financial modelling. It means that the nature of the human role changes.
Instead of spending most of the time manually constructing repetitive formulas, a modeller may spend more time defining assumptions, establishing validation rules, reviewing exceptions, testing model behaviour, and challenging the interpretation of the generated model.
That shift is consistent with recent industry research. The Financial Modeling Institute's 2026 survey of 63 financial-modelling professionals across 26 countries found that none of the respondents said they would be confident relying on an AI-generated financial model for a high-stakes business decision without independent human review.
The implication is not that AI-generated modelling has no value. It is that generation and approval should be treated as different stages of the workflow.
A practical validation framework
For an AI-assisted financial modelling system, a useful validation framework can therefore combine five elements.
First, validate structure. Confirm that the model contains the expected inputs, schedules, calculations, and outputs.
Second, validate formulas and relationships. Check references, repeated formulas, reconciliations, dependencies, and other deterministic relationships independently of the generation process.
Third, validate provenance. Make important assumptions traceable to their source and record transformations where relevant.
Fourth, test behaviour. Change important assumptions and confirm that the model responds according to its defined logic rather than merely producing a plausible base case.
Fifth, require human approval for unresolved semantic questions. The reviewer should be able to challenge assumptions, interpretation, timing, and other aspects that automated checks cannot reliably resolve. This produces a more useful definition of validation than simply checking whether a spreadsheet opens without errors.
The goal is controlled automation
The strongest argument for human-in-the-loop validation is not that humans are always better than AI or that AI should never be trusted. The practical argument is that different parts of a financial modelling workflow have different verification requirements.
AI can be useful for generating structures, translating requirements into model components, drafting formulas, and accelerating repetitive work. Deterministic systems can test calculations and reconciliations. Provenance mechanisms can make assumptions traceable. Automated validation can identify exceptions. Human reviewers can resolve ambiguity and determine whether the model represents the intended business logic.
The result is a workflow in which the model does not become trusted merely because an AI system generated it. It becomes reviewable because its assumptions can be traced, its calculations can be tested, its behaviour can be challenged, and its unresolved questions can be presented to a human before approval. For financial modelling, that distinction is fundamental.
Generation produces a model. Validation produces evidence about the model. Human review determines whether that evidence is sufficient for the intended use.
Top comments (0)