Large language models are increasingly being used as interfaces to financial software. Instead of opening a spreadsheet and navigating through dozens of tabs, a user can describe a change in ordinary language and ask an AI system to identify the relevant assumption, run a scenario, compare two cases, or explain why an output changed. That interaction model is useful because financial models are often difficult to navigate even for experienced users, particularly when the underlying workbook contains many assumptions, formulas, dependencies, and scenario-specific adjustments.
The architectural problem begins when the language model is also made responsible for performing the financial calculation itself.
That may seem reasonable at first. The model understands the request, it has access to the relevant numbers, and modern LLMs can perform arithmetic. For a simple calculation, the distinction may not matter much. In a real financial model, however, the calculation is rarely an isolated operation. A single assumption can affect a long chain of formulas, and the correctness of the final result depends not only on arithmetic but also on which assumptions were selected, how they were interpreted, which dependencies were recalculated, and whether the resulting state is consistent with the model.
This is why a financial AI system should separate language reasoning from numerical execution.
The language model should be responsible for understanding the user's intent and translating that intent into a structured operation. A deterministic calculation layer should then validate the operation, execute the relevant formulas, and return structured results. The language model can come back into the process afterward to explain those results in terms that a human can understand.
That division of responsibility is not about pretending that LLMs cannot do mathematics. It is about giving each part of the system a job that can be tested and trusted independently.
The difficult part is usually not the arithmetic
Consider a request such as:
What happens to the project if construction costs increase by 8%?
The arithmetic implied by the question is straightforward. If the relevant construction cost is $10 million, an 8% increase produces $10.8 million.
The difficult part is determining what the user actually means by "construction costs" in the context of the model.
The workbook might contain total construction cost, construction cost per square metre, separate hard and soft costs, costs distributed across multiple development periods, or different cost assumptions for different scenarios. The model might also calculate financing costs from the timing and amount of construction expenditure. If the assumption changes, those financing costs may need to change as well. A scenario may need to be created instead of modifying the base case.
None of those questions can be answered by arithmetic alone. They are interpretation and model-structure questions.
Once the correct variable has been identified and the intended operation has been validated, however, there is little reason for the language model to calculate the resulting financial outputs itself. The application already has a place where those calculations can be performed deterministically.
This distinction becomes particularly important because recent evaluations of spreadsheet agents show that the hard part of real financial spreadsheet work is not simply generating an individual formula. End-to-end tasks involve multiple worksheets, dependencies, debugging, formatting, and selecting the correct cells or model components. SpreadsheetBench 2, for example, evaluates agents on realistic multi-sheet business workflows and reports substantial reliability gaps in current systems.
A financial agent should translate intent into an operation
A useful way to think about the LLM is as a translation layer.
The user speaks in terms of business intent:
Increase construction cost by 8% and show me the effect on the project.
The application needs something much more precise:
{
"operation": "scenario_change",
"target": "construction_cost",
"change_type": "relative",
"change": 0.08
}
This structured object should not immediately be treated as a valid instruction.
It is a proposed operation that needs to pass through validation.
The system can check whether construction_cost exists in the model, whether the operation supports a relative change, whether the percentage is expressed in the expected format, and whether the user is asking to create a scenario or modify an existing assumption. It can then pass the validated operation to the calculation layer.
This creates a useful separation:
Natural-language request
|
v
LLM interpretation
|
v
Structured operation
|
v
Validation
|
v
Deterministic calculation
|
v
Structured result
|
v
LLM explanation
The LLM therefore does not disappear from the workflow. It simply stops being the authority for the numerical result.
That distinction is important because it gives engineers something concrete to test. The interpretation step can be evaluated against expected structured operations, while the calculation engine can be tested independently using known inputs and outputs.
Structured output does not solve the reliability problem by itself
One of the easiest mistakes to make is assuming that structured output automatically makes an AI system reliable.
It does not. A model can return perfectly valid JSON that describes a completely inappropriate operation.
For example:
{
"operation": "set_assumption",
"target": "construction_cost",
"value": -5000000
}
The JSON is valid. The instruction may be nonsensical.
The application therefore needs to distinguish between syntactic validity and semantic validity.
Syntactic validation answers questions such as whether the required fields exist and whether their data types are correct. Semantic validation asks whether the operation makes sense in the context of the actual financial model.
That second layer might check whether the target variable exists, whether the unit is compatible with the variable, whether the value falls within an acceptable range, whether the requested operation is supported for the current scenario, and whether changing that assumption requires additional calculations to be performed.
This is also where authorization belongs. If an agent is allowed to change assumptions, the application should decide which operations the user is permitted to perform. The LLM should not determine its own authority simply because it has generated a plausible tool call.
Tool design matters more than giving the model more freedom
Agent frameworks often make it easy to expose a large collection of tools to a language model and allow the model to decide what to do next.
That flexibility is useful for some applications, but financial modelling generally benefits from narrower interfaces.
Imagine giving an agent a generic spreadsheet-editing function that allows it to select arbitrary cells, change their values, rewrite formulas, and modify formatting. The model may be capable of using such a tool, but every additional degree of freedom increases the number of ways in which an incorrect interpretation can become a damaging state change.
A better approach is to expose operations that correspond to meaningful financial-model actions.
For example:
get_assumption()
set_assumption()
create_scenario()
calculate_scenario()
compare_scenarios()
get_dependencies()
The difference is subtle but important.
With a generic spreadsheet tool, the model decides both what the user means and how that meaning should be implemented in the workbook.
With a domain-specific interface, the model decides what operation the user appears to be requesting, while the application determines how that operation is safely executed.
For example, the model might produce:
{
"function": "set_assumption",
"arguments": {
"scenario": "construction_cost_upside",
"target": "construction_cost_per_gfa",
"value": 1850,
"unit": "USD/m2"
}
}
The application can then resolve construction_cost_per_gfa, verify the unit, check whether the scenario exists, validate the value, and determine which downstream calculations must be recalculated.
The agent is still useful, but the financial model retains control of its own state.
Deterministic calculations are valuable because they can be tested
Moving arithmetic out of the LLM is not enough on its own. The calculation layer must also be engineered properly.
A deterministic function is valuable because its behaviour can be inspected and tested independently of the language model.
For example:
def development_margin(revenue, total_cost):
if revenue == 0:
raise ValueError("Revenue cannot be zero")
return (revenue - total_cost) / revenue
The important property here is not that the formula is sophisticated. It is that the function has a clearly defined contract.
Given the same valid inputs, the function should produce the same result. That allows ordinary software-testing techniques to be applied.
You can test expected values, invalid inputs, boundary conditions, and changes to the underlying calculation logic. You can also run regression tests against known model cases whenever the calculation engine changes. Scenario testing becomes especially useful.
If construction cost increases while all other assumptions remain unchanged, the system should produce a predictable direction of change in the relevant outputs. If the model contains financing costs that depend on construction expenditure, those dependencies should be explicitly represented and tested rather than relying on the language model to remember them.
The calculation engine should therefore be treated as software, not as a hidden extension of the prompt.
Spreadsheet automation makes the distinction even more important
The argument becomes stronger when the AI agent operates directly on spreadsheets.
A spreadsheet is not simply a two-dimensional database of values. It is a computational environment containing formulas, references, dependencies, named ranges, formatting conventions, multiple worksheets, and often business logic that is encoded indirectly through the workbook's structure.
That creates a much larger surface area for errors. Recent financial spreadsheet benchmarks reinforce this point. WorkstreamBench evaluates agents on end-to-end financial spreadsheet tasks and measures accuracy, formula quality, and format against professional standards. Its results indicate that even strong agents can degrade substantially as workflows move beyond relatively small chains of calculations.
BlueFin reaches a similar conclusion from another direction. Its benchmark contains challenging professional-finance spreadsheet tasks, and frontier models perform poorly on some of the dynamic-correctness requirements.
That does not mean spreadsheet agents are useless. It means that "the model can edit the spreadsheet" should not be confused with "the model can reliably maintain the financial logic of the spreadsheet." Those are different capabilities.
A robust architecture should therefore make the financial model's rules explicit wherever possible and use the LLM to navigate, interpret, and communicate rather than silently becoming the spreadsheet's calculation engine.
The number should carry its provenance
There is another reason to separate calculation from language generation: a financial output needs more context than its value.
Suppose an agent returns:
Development profit: $12.4 million
The number may be correct, but a professional user will often have a more important question:
Why is it $12.4 million?
A useful system should be able to trace that result back through the assumptions and calculations that produced it.
For example:
Development profit
|
+-- Revenue
| |
| +-- Area assumptions
| +-- Pricing assumptions
|
+-- Development costs
|
+-- Construction cost
+-- Professional fees
+-- Financing
The implementation does not need to expose this exact diagram to the user, but the underlying system should preserve enough information to reconstruct the dependency chain. That may include the model version, scenario, input values, units, calculation function, source references, and validation results.
The advantage is not merely auditability. It also makes debugging much easier.If the final result looks wrong, an engineer can determine whether the problem originated with the source assumption, the interpretation of the user's request, the dependency mapping, or the calculation itself.
Without provenance, all of those failures collapse into one generic problem: "the AI gave the wrong answer."
Evidence and assumptions should not be treated as the same thing
This becomes especially important when an AI system retrieves information from external sources.
Imagine an agent finds a market report containing a rental figure.
The retrieved figure is evidence.
It is not automatically a model assumption.
There is a chain of decisions between those two things. The system needs to know what the source actually said, which period it referred to, what geography it covered, what unit it used, and whether the figure is appropriate for the model being constructed.
Only after that assessment should the value become an explicit modelling assumption.
A useful representation might look like:
{
"evidence": {
"source": "market_report.pdf",
"page": 18,
"metric": "average_rent",
"period": "2026-Q2",
"value": 42
}
}
The model can then contain a separate assumption:
{
"assumption": {
"name": "monthly_rent",
"value": 42,
"unit": "currency/m2/month",
"source_reference": "market_report.pdf:p18"
}
}
The distinction allows someone reviewing the model to challenge either the evidence or the modelling decision without confusing the two.
This is one of the areas where AI systems can otherwise become difficult to audit. A generated answer may look authoritative even though the underlying number passed through several undocumented interpretation steps.
The LLM becomes more useful after the calculation
Once the calculation engine has produced a structured result, the language model can return to the workflow.
This is where it can provide substantial value without being responsible for the underlying arithmetic.
Suppose the calculation engine returns:
{
"scenario": "construction_cost_upside",
"construction_cost_change": 0.08,
"profit_change": -1200000,
"margin_change": -0.047
}
The LLM can explain what happened in context:
The 8% increase in construction cost reduces projected development profit by $1.2 million under this scenario. The model also shows a reduction in margin of approximately 4.7 percentage points. These changes reflect the assumptions and dependencies contained in the current model, so the scenario should be interpreted as a sensitivity to those assumptions rather than as an independent forecast.
The difference is important.
The LLM is not deciding that profit fell by $1.2 million.
The calculation engine has already established that result.
The LLM is translating the result into useful language.
That makes the generated explanation easier to review because every important numerical statement can be traced back to structured output.
A good financial agent should be replayable
A useful engineering test for an AI financial workflow is to ask whether another engineer could reproduce the calculation without asking the LLM to perform the reasoning again.
Suppose the system records:
{
"model_version": "2026.09",
"scenario": "construction_cost_upside",
"inputs": {
"construction_cost": 12500000,
"revenue": 18000000
},
"operations": [
{
"function": "apply_relative_change",
"target": "construction_cost",
"change": 0.08
},
{
"function": "development_profit",
"target": "profit"
}
]
}
Another process should be able to take the same model version, inputs, and operations and reproduce the result.
This property is useful for much more than formal auditing. It helps with debugging, regression testing, incident investigation, and model review.There is growing research specifically around reproducibility and determinism in tool-using financial agents, including work examining whether identical inputs can produce consistent trajectories and evidence-aligned decisions.
The broader engineering principle is straightforward: if a result matters, the system should retain enough information to reproduce how that result was obtained.
Human review becomes more meaningful when the architecture is explicit
"Human in the loop" is often presented as a solution to AI reliability problems, but simply putting a person at the end of an opaque workflow does not necessarily make the workflow safe.
A reviewer needs something meaningful to inspect.
A well-designed financial agent can expose a chain such as:
User request
↓
Interpreted operation
↓
Validated target
↓
Evidence / assumptions
↓
Deterministic calculation
↓
Changed outputs
↓
Generated explanation
The reviewer can then ask the right question at the right layer.
If the target variable is wrong, the interpretation needs attention.
If the source assumption is unsuitable, the evidence needs attention.
If the formula is wrong, the calculation engine needs attention.
If the calculation is correct but the narrative overstates what it proves, the explanation needs attention.
That is far more useful than asking someone to read a polished paragraph and decide whether it "looks right."
The architecture also limits the blast radius of an AI mistake
There is a practical reason to keep these boundaries separate. LLMs will make interpretation errors.
The objective should therefore not be to build a system that assumes the model will never make a mistake. The objective should be to make sure an interpretation error does not automatically become an uncontrolled financial-model mutation.
If the LLM proposes:
construction_cost_per_gfa = 1850 USD/m²
the application can reject it if the unit is incompatible, the variable does not exist, the value is outside an allowed range, or the requested scenario cannot be modified.
The model has made a mistake, but the system has contained it. This is a much more realistic approach to AI reliability than trying to eliminate every possible model error.
The practical rule
For financial modelling agents, the most useful rule is simple:
If a result must be reproducible from the same inputs, the LLM should not be responsible for producing the result.
That does not mean LLMs have no place in financial modelling.
They can be extremely useful for interpreting requests, extracting assumptions from documents, identifying ambiguity, selecting appropriate operations, summarising scenario changes, and explaining model outputs.
The calculation layer should remain responsible for arithmetic, formula execution, dependency propagation, validation, scenario calculation, and other operations where reproducibility matters.
The provenance layer should preserve enough information to explain where the inputs came from and how the outputs were produced.
The human reviewer should be able to inspect the chain rather than simply trusting the final prose.
Conclusion
The interesting engineering question is not whether a language model can calculate an eight-percent increase.
It can.
The harder question is what happens when that calculation becomes one step in a financial model containing hundreds of assumptions, thousands of formulas, cross-sheet dependencies, external evidence, and scenario logic. At that point, asking the LLM to perform everything in one conversational loop creates an unnecessary reliability problem.
A better architecture gives the language model responsibility for language and interpretation while giving deterministic software responsibility for numerical execution.
The LLM can translate the user's request into a structured operation. The application can validate that operation against the model. A deterministic calculation engine can execute the relevant formulas. The system can preserve provenance and return structured results. Finally, the LLM can explain those results in language that makes sense to the user.
The result is not an attempt to make the language model behave like a spreadsheet.
It is a system in which the language model acts as an intelligent interface to a financial model whose calculations remain explicit, testable, reproducible, and reviewable. For financial AI, that boundary is not a limitation. It is part of the architecture that makes the system useful.
Top comments (0)