The Four Layers Every AI Finance Stack Needs

Most AI-for-finance demos are two layers deep. They connect to a data source, and they let a model retrieve and talk about what it found. The demo looks clean. Then someone asks for last quarter’s gross margin by region, the model returns a confident number, and the controller pulls it apart in four minutes because it doesn’t tie to anything in the ledger.

The missing pieces sit in the middle. A trustworthy AI finance stack has four distinct layers, not two: connection, reconciliation, deterministic calculation, and retrieval. The two everyone skips are the two that decide whether a number is defensible. Skipping them is the structural reason most of these demos die in the room where someone has to sign.

Layer one: connection

This is the layer everyone builds first, because it’s the layer with a satisfying API. You wire into QuickBooks, Xero, NetSuite, Sage, an SAP or Oracle instance, a warehouse, or you take in uploaded statements and exports. Data flows. A model can see it.

Connection is necessary and it is genuinely hard at the edges. Permissions, rate limits, schema drift, the fact that “revenue” in one system is three different fields in another. But solving connection well solves exactly one problem: access. It tells you nothing about whether the numbers agree with each other, and it does nothing to stop a model from doing arithmetic it has no business doing.

The trap is that connection feels like the whole job. You can hand a language model an authenticated pipe to the GL and watch it answer questions in plain English. It demos beautifully. It is also the precise setup that produces numbers that don’t tie out, because the next two layers are doing nothing.

Layer two: reconciliation

Here is where most stacks have a hole. Raw financial data is not a financial model. It’s a pile of facts from systems that were never designed to agree with each other. The subledger doesn’t match the GL by a few thousand. Intercompany entries are booked on both sides with different timing. One entity reports in a different currency, on a different close calendar, with a different chart of accounts. Three exports of “the same” number disagree, and all three are technically correct from where they came from.

Reconciliation is the work of turning that pile into one model that ties out to the ledger. A single source of truth, in the literal sense: figures that reconcile to each other and trace back to the system they came from. This is unglamorous, deterministic, rules-driven work. It is also the layer that decides whether anything built on top is trustworthy, because every calculation and every retrieved figure inherits the integrity of the model underneath it.

Skip reconciliation and you are asking an AI to reason over contradictions. It will. It will pick one of the conflicting numbers, or silently blend them, and present the result with the same fluent confidence it gives to a correct answer. The model has no mechanism to know the inputs disagreed. That’s not a prompt you can fix. It’s a layer you didn’t build.

Layer three: deterministic calculation

This is the layer that gets argued about, so let me be blunt about the mechanism. Language models do not compute. They predict the most plausible next token, and a plausible-looking number is not a correct one. Recent mechanistic research is fairly direct on this: models can generate arithmetic and fail to validate it, and the errors are reproducible rather than random noise. There’s even work isolating the internal circuits responsible for confident wrong financial answers. The takeaway for anyone building in this space is unambiguous. The model can decide what to calculate. It must not be the thing that does the calculating.

So the calculation has to happen somewhere else, in a deterministic engine. Margins, ratios, growth rates, consolidations, allocations, currency conversion at the right rate on the right date, period-over-period math. These run as code against the reconciled model, not as text generated by a transformer. Same inputs, same answer, every time. That property matters for a reason that has nothing to do with elegance: a controller can re-run it. An auditor can re-run it. Nondeterministic output, where the same question yields a slightly different figure on Tuesday, fails basic audit and compliance expectations on its face.

A useful test for any AI finance tool: ask it the same numeric question three times, in slightly different words. If the figures drift, the arithmetic is living inside the model, and you have a layer-three problem dressed up as a feature.

This is the part of the architecture we think about most at Rexfin, because it’s the part the market keeps trying to skip. Connecting a model to your ERP and letting it answer “feels” finished. The math still comes out wrong, because the model is still the calculator.

Layer four: retrieval

Retrieval is the layer that gets the spotlight, and it deserves a real role, just not the one demos give it. Done right, retrieval is what lets a person ask a question in plain language, pull the right figures out of the reconciled model, run a what-if scenario, and get back an answer where every number traces to its source. The model’s job here is genuine and valuable: understand intent, fetch the correct figures, frame the result, explain it.

What retrieval is not is a substitute for the layers beneath it. Retrieval-augmented generation earned its reputation by grounding answers in real documents, and for “what does this clause say,” that’s enough. Finance is arithmetic that has to tie out. Pointing a model at the exact GL line is necessary and still leaves it free to compute the wrong margin from a correct number. Retrieval grounds where the figure came from. It does not make the math right. That’s why connection-plus-retrieval, the two-layer demo, hits a ceiling and stays there.

When retrieval sits on top of a reconciled model and a deterministic engine, the picture changes. The figures it returns already tie out. The calculations already replay. The model is composing an answer from trustworthy parts instead of manufacturing one. The insight traces to source because the source was real before the model ever saw it.

Why the middle gets skipped, and what it costs

The two missing layers are missing for a boring reason: they’re the hard, unglamorous engineering, and they don’t demo. Connection has an API. Retrieval has a chat box. Reconciliation and deterministic calculation are quiet infrastructure that only announces itself when it’s absent, and by then you’re explaining to a CFO why the AI’s number disagrees with the close.

I’ll concede the obvious limit. None of this makes AI omniscient about your business. The reconciled model is only as good as the source systems feeding it, garbage in still applies, and judgment calls about adjustments still belong to your team. What the four-layer separation buys you is narrower and more important: when the AI gives you a number, it’s a number you can defend. It ties to the ledger, the math replays identically, and the trail runs back to source.

That’s the whole bar for finance. Not “impressive in a demo.” Defensible in the room where someone signs.

If you want to see what a stack looks like when the middle two layers are actually built, the reliable financial-modeling layer for AI pillar lays out the full picture, and MCP for finance is not enough digs into why connecting an LLM to your ERP still gets the math wrong. When you’d rather watch it run against real numbers than read about it, book a demo and bring a question your last tool got wrong.