Building the AI Control Stack for Financial Data: A Reference Architecture

A controller asks the AI assistant for free cash flow last quarter. It answers in two seconds, confident, formatted, sourced-looking. The number is wrong by 4%. Nobody catches it because there is nothing to catch it with. The model retrieved a figure, did some arithmetic in its head, and printed the result. No second pair of eyes, no recompute, no log.

That is the gap most “AI for finance” deployments ship with. The model is fine. The architecture around it is missing. When the question is whether a CFO can put an AI-generated number in front of an audit committee, the answer depends almost entirely on what sits between the language model and the ledger.

This is a reference architecture for that middle. Think of it as five control layers, each catching a different failure, stacked so that a number cannot reach a human without passing through all of them.

Why a single model is not a control

Start with the uncomfortable benchmark data. On financial spreadsheet tasks, the strongest 2026 models top out around 82% accuracy: roughly one error every six questions. On harder multi-step financial reasoning, even frontier models sit in the high 80s to low 90s, and they fall apart on temporal reasoning and scenario work, which is exactly what finance is made of. No standalone language model gets to error rates low enough for unsupervised production use. That is not a prompt problem you can engineer away. It is a property of how these systems generate text.

So the design goal is not a better model. It is to make the model’s weakest capability (doing math reliably) irrelevant, and to surround its strongest capability (reading and explaining) with checks. Each layer below does one job.

Layer 1: Data quality at the boundary

Garbage in is still the dominant cause of wrong answers, and it is the least glamorous to fix. Before anything reaches the model, the inputs have to be reconciled, not just present. That means figures pulled from QuickBooks, Xero, NetSuite, Sage, an SAP or Oracle instance, a warehouse, or an uploaded PDF statement all resolve into one model that ties out to the general ledger. Mapped accounts, consistent periods, eliminated intercompany, a documented chart.

The control here is the reconciliation itself: a tie-out check that fails loudly when the assembled model does not match the source ledger to the cent. If layer 1 does not pass, nothing downstream runs. A clean calculation on dirty inputs is just a confident wrong answer. This reconciled foundation is the part most teams skip, and it is the reason their demos collapse the moment real data shows up, a point we make in detail in why a spreadsheet is the wrong foundation for AI finance.

Layer 2: Deterministic calculation

This is the load-bearing layer. The language model never computes free cash flow, never inverts a ratio, never decides whether a change is absolute or percentage. It identifies what the user is asking for and which figures are involved, then calls a deterministic engine that runs the actual formula against the reconciled model.

Same inputs, same output, every time. A controller can prove the result the way they would prove a spreadsheet cell: trace it to the operands, check the formula, recompute. The arithmetic lives in code with a fixed definition, not in a probability distribution over tokens. This is the single change that takes you from “usually right” to “right and provable,” and it is why deterministic and replayable calculation has become the expectation auditors bring to AI outputs.

Layer 3: Output auditing

Even with clean inputs and deterministic math, you want a check between the engine’s result and the user. Output auditing is a set of rules that runs on every answer before it is shown: does the figure fall inside a sane range, does the balance sheet balance, does the sign make sense for a cash outflow, does this quarter’s revenue sit within a plausible band of trailing quarters?

These are not AI judgments. They are the same sanity checks a sharp analyst runs reflexively, encoded as deterministic assertions. When one fails, the answer is held and flagged rather than shipped. Regulators increasingly expect exactly this kind of behavioral validation (testing what the system outputs rather than only inspecting the model) because with a vendor LLM the weights are not yours to inspect anyway. We cover that constraint in output-based validation for vendor LLMs.

Layer 4: Access control

Who is allowed to ask, and what are they allowed to see? An AI interface that flattens permissions is a data breach with a chat box. The control layer has to enforce the same entity, period, and field-level restrictions that the underlying systems do, and it has to attribute every query to a real human identity, not a shared service account that makes the audit trail useless.

This matters more with AI than with a static report, because the interface invites open-ended questions. Someone in a regional team asking a broad question should not get group-level numbers back because the model was helpful. Access control sits in the path of the query, not bolted on after.

Layer 5: Immutable logging

The last layer records everything the other four did, in a form that cannot be quietly edited. For each answer: who asked, what was asked, which source data and version fed the calculation, which formula ran, what the output auditing checks returned, and what figure was returned. Append-only, timestamped, retained.

This is what turns a number into a defensible number. Months later, when a board member questions a figure or an auditor asks for support, you replay the entry and reproduce the exact result from the exact inputs. The log is also where regulatory expectations are quietly converging: the 2026 model-risk frameworks that replaced SR 11-7 lean hard on traceability and reproducibility, and the EU AI Act’s logging requirements point the same direction.

How the layers fail well together

The point of stacking is defense in depth. A bad source value gets caught at layer 1. A reasoning slip never happens because layer 2 removed reasoning from the math. An out-of-band result gets held at layer 3. A user seeing data they should not gets stopped at layer 4. And if anything still goes wrong, layer 5 lets you find out precisely what and when.

Be honest about the limits. This architecture does not make the language model accurate; it makes the model’s inaccuracy non-fatal. It does not eliminate the need for human review on consequential figures; it makes that review fast and grounded instead of a leap of faith. And it adds latency and engineering cost: the deterministic engine, the reconciliation, the logging are real work. The trade is that the output is one a controller will actually sign.

There is a tempting shortcut worth naming: connect an LLM to your ERP through a protocol like MCP and call it done. That gives the model governed access to live data, which is layer 4-ish, but it leaves the model doing fragile arithmetic on raw GL fields with no reconciliation and no deterministic compute. Retrieval is not the hard part. The middle layers are.

The takeaway

If you remember one thing: the model is the least important component in a trustworthy AI finance system. The value is in the reconciled foundation beneath it and the controls around it. Build those five layers and AI can retrieve, explain, and model scenarios all day, with every number traceable to source. Skip them and you have a fast way to generate confident errors.

Rexfin is the layer that does this work: one reconciled model, a deterministic calculation engine, and immutable logging, with the LLM kept on reasoning and retrieval where it is strong. If you want to see a figure traced from a board-deck answer back to the ledger entry that produced it, book a demo.