Why the OLAP Cube Is the Wrong Foundation for Finance AI

The multidimensional cube is the quiet workhorse under classic corporate performance management. TM1 (now Planning Analytics), Jedox, Board, and the Hyperblock-style engines all rest on the same idea: model the business as intersecting dimensions (account by entity by period by scenario by product) and let a user pivot through billions of cells in the time it takes to click. For thirty years that was the right trade. When a planner needs revenue by region by month, sliced four different ways in a meeting, a cube answers instantly where a relational query would crawl.

So when teams bolt an AI assistant onto their EPM stack, the cube seems like the obvious place to point it. It is already the “single number.” It is already fast. The problem is what the cube quietly threw away to get that speed. A cube stores answers, not the reasoning behind them. And an AI that reasons over stored answers inherits every aggregation and mapping decision that was baked in long before the question was asked, with no way to walk back to the transaction that would prove or disprove it.

A cube stores conclusions, not evidence

The defining move of OLAP is pre-aggregation. Raw transactions get rolled up along dimension hierarchies (thousands of GL postings collapse into one “EMEA / Q2 / Net Revenue” cell) because pre-computing those rollups is exactly what makes the pivot instant. That rollup is a one-way street. Once postings are summed into a cell, the cell has no memory of which postings it came from. It is a conclusion with the evidence discarded.

This is fine, even ideal, for the job cubes were built to do. Nobody browsing a variance report wants to drag ten million journal lines around. But it means the cube is structurally the wrong shape for the question AI in finance actually has to survive: “where did this number come from?” The honest answer a cube can give is “the sum of the cells beneath it,” which is another set of conclusions, not evidence. You can drill down a hierarchy until you hit the lowest stored level, and then you stop. Below that level, in the ledger, is where the audit trail lives, and the cube has no pointer to it.

The mapping is invisible, and the AI can’t see it either

Getting data into a cube is not a copy. It is a translation. A load process maps source accounts to cube accounts, applies sign flips, currency conversion, intercompany eliminations, and allocation rules, then writes the result into cells. Every one of those transforms is a modeling decision, and most of them live in load scripts, TurboIntegrator processes, or rule files that the cube itself does not expose as data.

An AI querying the cube sees the output of that translation with none of the translation attached. Ask it why marketing spend jumped and it will faithfully report the cell. It cannot tell you that the jump is real versus an allocation basis someone changed last quarter, because that fact was never in the cube: it was in the process that fed it. This is the same failure the spreadsheet as the wrong foundation runs into, arriving by a different road. The grid hides the difference between a ledger figure and a typed-over one; the cube hides the difference between a raw figure and a transformed one. In both cases the model reads a confident number with the provenance stripped off.

”Trace this figure” dead-ends at a cell

Put the two problems together and you get the core defect for AI. A retrieval-grounded assistant is only as trustworthy as the source it can cite. When the source is a cube, the best citation available is a coordinate: a cell address inside a set of dimensions.

Question a CFO asks	What the cube can return	What’s missing
What is Q2 net revenue for EMEA?	The cell value, instantly	Nothing; this is the cube’s strength
Which deals make up that figure?	The child cells one level down	The transactions; drill stops at the lowest stored level
Why did it move vs. forecast?	Two cells and their difference	The driver; the delta is arithmetic, not explanation
Prove this ties to the ledger	A rollup total	The mapping and the source postings that would prove it

That last row is the whole game. A cell coordinate is not a citation an auditor accepts. It says “this is where the number sits in the model,” not “this is where the number came from in reality.” The trace dead-ends at a cell, and an AI answer that dead-ends at a cell is a claim, not a defensible fact. This is why connecting a language model straight to an EPM cube (the promise behind a lot of “AI-native planning”) improves the interface without touching the trust problem. The retrieval is grounded in a source that itself cannot be traced back.

Fast is not the same as founded

None of this makes cubes bad technology. They are genuinely excellent at aggregation performance, at sparse storage, at letting a human explore a large model interactively. If your only requirement is fast slice-and-dice over numbers someone already trusts, a cube is hard to beat, and tools like Board and Jedox are good at exactly that.

The mistake is treating “fast to query” as if it implied “safe for AI to reason over and cite.” Those are different properties. A cube optimizes retrieval speed by pre-committing to a set of aggregations and mappings; AI trustworthiness requires the opposite: the ability to decompose any figure back down to source on demand, including facts the cube deliberately compressed away. You cannot get lineage back out of a structure that was designed to discard it for speed. A drill-through path bolted on afterward reaches the ledger only for the specific cells someone wired up in advance; it is not general lineage, and the AI cannot assume it exists.

What a citable foundation looks like

The fix mirrors the spreadsheet case: move the source of truth beneath the query layer, into a model where every figure keeps its link to the transaction that produced it. Rexfin builds that model by connecting to where the numbers actually live (the accounting system, the bank, the warehouse, or uploaded statements) and reconciling them into one model that ties out to the ledger. The transforms that a cube buries in load scripts (mappings, eliminations, allocations) become part of the model’s recorded lineage instead of an invisible preprocessing step. This is the same discipline behind proper financial consolidation: the model has to know how it was assembled, not just what it concluded.

Aggregation still happens: you still want revenue by region by month instantly. The difference is that each aggregate holds a pointer down to the postings and the rules beneath it, and a deterministic engine, not the model’s own arithmetic, does the math. So when the AI answers, it retrieves from the reconciled model and can return the figure with its trace attached: the rule, the source rows, the path an auditor would walk. The cube gives you a coordinate. A reconciled model gives you a citation.

The takeaway

The OLAP cube earned its place by being fast at slice-and-dice, and it should keep that place. But it earned that speed by storing conclusions and discarding the evidence, and an AI can only cite what its source retains. Point a model at a cube and “trace this figure” ends at a cell: a location, not a source. The teams getting defensible answers out of finance AI aren’t querying a faster cube; they put a reconciled model underneath, so every figure ties back to the ledger and the AI can answer and show its work.

For the full picture, start with the pillar on the reliable financial-modeling layer for AI. To see it trace your own numbers back to source, book a demo.