Most "AI for finance" demos look the same. A chat box appears. Someone types "why did opex go up in March?" A confident paragraph comes back. The room nods.
The demo works because the data behind it was prepared for the demo. The hard part of AI for finance has nothing to do with the model. It's everything underneath the chat box.
What's actually under the hood
For an AI assistant to answer a real variance question, it has to know what your accounts mean, how your hierarchy rolls up, which entities consolidate into which, what counts as headcount and what counts as contractor cost, how your fiscal calendar lines up against your reporting calendar, and which of last month's numbers were actuals versus mid-close estimates.
None of that lives in the LLM. It lives in your data layer. If the data layer is wrong, stale, or generic, the model will produce a fluent answer that is also wrong. Confidently. Which is worse than no answer at all.
A wrong-but-fluent answer in finance isn't a hallucination problem. It's a data architecture problem dressed up as one.
The number of facts an LLM knows about your business.
Until you build the data layer that gives it some. Everything you see in a polished AI-for-finance demo is the data layer doing the work, not the model.
What I learned shipping AI at scale
Before Novaplan I spent years on the BI side and then on AI infrastructure at Fortune-scale, including co-founding an agentic-AI platform from zero. The pattern that surfaces in every serious deployment is the same: the teams that ship AI that holds up under real use are the teams that treated the data layer as the actual product. The model is the easy part. The model gets better every six months whether you do anything or not. The data layer doesn't.
The teams that skipped the data work and bolted an LLM onto an ERP export ended up with demos. The teams that did the data work ended up with something operators trusted on Monday morning.
What we did differently
Novaplan is built BI-first under the hood. The data model is the spine. Your GL, your hierarchy, your headcount, your actuals-versus-plan history are modeled the way a serious analytics team would model them, with versioning, lineage, and reproducibility. The AI layer sits on top of that, not in place of it.
Practically, that means when you ask Novaplan why a number moved, the answer cites the specific accounts, the specific entries, and the specific drivers it used to get there. You can click through to the underlying rows. If something is wrong, you can see why. That's not a UX choice. It's the only honest way to ship AI for finance.
What this means for your team
If you're evaluating an FP&A platform with an "AI assistant" attached, the question worth asking isn't how impressive the chat looks. It's: what is the data layer this assistant is reading from, and who configured it for your business?
If the answer is "our generic semantic layer plus a template that approximates your GL," you have a demo. If the answer is "your actual model, configured by the people who built the platform, with lineage to your source systems," you have something operators can rely on. That's the bar we hold ourselves to, and it's the bar I'd hold any serious vendor in this category to.