The Least Exciting Sentence in Every AI Finance Meeting: 'Where Does This Number Actually Come From'

Nobody gets excited talking about data lineage. It’s the least glamorous phrase in finance transformation, right up there with “master data governance,” and it’s usually the thing that gets deprioritized in favor of the part everyone actually wants to talk about—which model, which agent, which vendor.

I’ve now watched enough AI pilots stall to be pretty confident about the actual pattern: the model is almost never the reason it stalls. The reason is almost always that nobody could answer, with confidence, “where does this number actually come from, and does it mean the same thing in the system the AI is reading from as it does in the report a human signs off on.”

What this looks like in practice

A natural-language BI tool gets asked “what was revenue by region last quarter.” It returns a confident, well-formatted answer. The answer is wrong—not because the model hallucinated, but because “region” is defined one way in the sales system and a different way in the finance consolidation, and nobody had documented that the two didn’t match. The tool did exactly what it was asked. The question itself was ambiguous in a way a human analyst would have caught by instinct (“wait, which region definition do you mean”) and the tool didn’t, because it had no reason to know there were two.

This happens constantly, and it’s almost never framed as a data lineage problem in the postmortem—it gets framed as “the AI got it wrong,” which lets the actual root cause quietly survive to cause the next incident.

Why this is worse with AI than it was before

Before, if a report used the wrong region definition, it usually showed up somewhere obviously wrong—a total that didn’t tie, a chart that looked off. Slow, manual processes had friction built in that occasionally caught these mismatches by accident. A fluent AI-generated answer doesn’t have that friction. It reads exactly as confident and clean whether the underlying definition was right or wrong, which means the errors that used to get caught by process friction now sail through, dressed in better prose than the mistake deserves.

The unglamorous fix, which is the only fix

There isn’t a shortcut here. The organizations that get real value from AI tooling on top of their data are the ones that did the boring work first: a documented, current data dictionary for the metrics that actually get used in decisions, an explicit mapping of where each metric is defined and whether the definitions agree across systems, and an owner for each metric who’s accountable when it drifts.

If I had to pick one thing to fix before spending another dollar on an AI tool layered on top of your data, it’s this. Not because it’s exciting—it’s the opposite of exciting—but because every downstream tool, whether it’s a natural-language BI layer, an anomaly detector, or an agent drafting commentary, inherits whatever ambiguity already exists in your metric definitions, and makes that ambiguity sound more confident than it deserves to.

The teams I’ve seen actually succeed with AI in finance didn’t have better models. They had done the unglamorous metric-definition work months before anyone mentioned AI at all, and the tooling just showed up to a foundation that was already solid. The teams that struggle usually bought the tool first and are now discovering the foundation problem in production, in front of a business partner who’s asking why the number doesn’t match last month’s deck.