AI for FP&A: your ERP's semantic layer doesn't cover your forecast

I’ve heard a version of this argument, and it’s a good one up to a point.

It goes like this. The LLM is the consumption layer, because people want to ask questions in chat instead of learning another tool. The hard part is the semantic layer, the governed definitions that make “revenue” mean the same thing every time. That semantic layer can sit anywhere, including in MCP servers built on top of the ERP. If you already have that, a separate data platform for finance looks like overhead.

I agree with the first two points. The LLM is where people will consume this. And the semantic layer is the hard part. Anyone can point an AI model at your data.

The argument breaks on the forecast.

The ERP only knows what happened

An ERP holds transactions: invoices, journal entries, purchase orders, payroll. A semantic layer built on the ERP gives you well-governed actuals, and that’s worth having. It doesn’t give you the budget, the forecast, or the scenarios, because at most companies those don’t live in the ERP. They live in spreadsheets, or a planning tool, and a lot of the time in both.

In my experience, when you ask a finance team where the current forecast lives, the honest answer is a set of Excel files. Budgets and forecasts in ungoverned spreadsheets get called a gap, and then the conversation moves on.

That gap is most of the problem.

What finance actually asks

Most finance questions are comparisons. How did we do against budget. What changed between last month’s forecast and this one. What’s driving the miss in a department. Where do we land for the year.

Every one of those needs forward-looking data next to actuals, at the same grain, with the same definitions. An agent that only sees governed actuals can answer “what did we spend.” It can’t answer much of what a CFO asks after that.

Why forecast data is harder than actuals

Actuals have a lot of structure built in. The books close, accounts are defined, and the numbers stop moving. Forecast data has almost none of that by default.

None of that comes from the ERP. It’s work on the planning side, and the planning side is where the ungoverned spreadsheets are.

How we handle it

At OVG we structure forecast data the same way as actuals, in the same governed layer, so comparing them is a query instead of a reconciliation project. Inputs can still start in Excel, because that’s where finance works and it isn’t going anywhere. What changes is that each file gets validated and loaded into the same model as the actuals, with versions tracked.

Most of these pieces are repeatable patterns. Versioning, a shared grain, validated loads from Excel, a change log. They shouldn’t be rebuilt from scratch at every company, and a team that treats them as a fresh custom build each time is going to feel the overhead the skeptics are worried about.

Once forecast data sits in the same governed layer as actuals, the model on top matters less. Whichever model wins next year, you point it at the same layer.

Questions to ask before you decide the ERP layer is enough

If most of the answers are “a spreadsheet” or “no,” the ERP-side semantic layer is still worth building. It covers the actuals half of what finance needs.

More writing