Skip to main content

Intelai

AI Will Not Fix Your ERP Forecast

Forecast accuracy is bounded by the chart of accounts and the close calendar, not by the model. Add AI to a broken model and you get faster wrong numbers.

By Amyn PorbanderwalaApril 1, 20255 min read

Contents
  1. The forecast is a data model problem
  2. Where AI actually helps
  3. The audit trail is the deliverable
  4. A pilot that can pass
  5. The model is the last thing to fix

A forecast is only as good as the definitions underneath it. If a part number means two different things in two systems, no model will reconcile them. It will learn the confusion and reproduce it with confidence.

That is the unglamorous core of AI in enterprise resource planning. The forecast is a data model problem wearing a statistics costume. Most of the failures blamed on models are failures of definition, timing, and ownership that were present long before anyone mentioned machine learning.

The forecast is a data model problem

Four things break a forecast before the algorithm runs.

Units of measure. A quantity is meaningless without its unit. A system that stores cases in one table and eaches in another will produce a number that is wrong by a factor of a hundred, and it will look plausible. The model learns the ratio and predicts it forward.

Effective dates. Organizations reorganize. Cost centers close, programs move, hierarchies change. A historical series that spans a reorganization is a series of two different things. If the model does not know where the break is, it will average across it.

Obligation versus expense. In federal accounting, the money is obligated when the contract is awarded and expensed when the work is performed. A forecast built on the wrong one of those is not inaccurate at the margin. It is measuring a different event.

Ownership. Every field has someone who is accountable for its meaning. In most ERP systems, that person is not identified. When two reports disagree, the argument is about the report, not the field.

None of these are fixed by a better model. All of them are fixed by a data owner, a definition, and a validation rule.

Where AI actually helps

The honest case for AI in ERP is narrower than the vendor deck and more useful.

Exception triage. A close cycle produces thousands of exceptions: unmatched receipts, duplicate invoices, accounts with abnormal balances. A model that ranks them by likelihood of being a real problem lets a small team work the top of the list first. The work is still human. The queue is better.

Reconciliation drafts. Matching a payment to an invoice, a receipt to a purchase order, or a labor record to a project is pattern work. A model can propose matches with a rationale and a confidence, and a person can accept or reject. The value is in the proposal, not the automation.

Query interfaces. Most ERP users cannot write the query they need. A natural-language interface that translates a question into a report, and shows the query it ran, removes a queue in the reporting team. Showing the query is the important part. Without it, the answer is unverifiable.

Narrative variance. Explaining why a number moved is a writing task that consumes analyst time. A model can draft the paragraph from the underlying transactions, and the analyst can correct it. The draft is a starting point, not a finding.

In each case, the model is doing triage or drafting. None of them require the model to be right about the number. They require it to be useful to the person who is.

The audit trail is the deliverable

An ERP forecast that cannot be reproduced is not a forecast. It is an opinion with a chart.

The auditor's question is not "is this number accurate." It is "show me how this number was produced, and show me who changed it." That question applies to an AI-generated forecast exactly as it applies to a manual one, and the AI version has more moving parts.

Three things have to be true before an AI forecast can survive that question.

The inputs are versioned. The data extract, the model version, the parameters, and the run date. If the extract is a query that changes daily, the forecast is not reproducible even a week later.

The transformation is visible. What the model did to the data, in enough detail that a reviewer can follow it. A pipeline that silently drops nulls or imputes values is making accounting decisions without telling anyone.

The override is recorded. When an analyst changes the forecast, the original, the change, and the reason are stored. Overrides are where the real forecast lives, and they are usually undocumented.

A pilot that can pass

Five requirements will separate a pilot that produces a number from a pilot that produces a capability.

  1. One forecast, one owner. Pick a forecast with a named owner and a decision attached to it. A pilot on a report nobody uses proves nothing.
  2. A frozen dataset. Take an extract, freeze it, and build against it. Reproducibility starts here.
  3. A baseline. Compare against the current method, on the same data, with the same metric. If the current method is a spreadsheet, that is the baseline.
  4. An error budget. State the accuracy the owner needs and the cost of being wrong. A forecast that is 5 percent off on a stable line is fine. The same error on a capital program is a reprogramming action.
  5. A review path. Name who checks the output, how often, and what they do when it looks wrong. The review is part of the system.

The model is the last thing to fix

AI in ERP is worth doing. The exception queue, the reconciliation draft, and the query interface are real improvements to real work, and they do not require a perfect data model to deliver value.

The forecast is different. It sits on top of every definition in the system, and it will inherit every ambiguity. Fix the units, the dates, the accounting basis, and the ownership first. Then the model has something to learn from.

Add AI to a broken data model and you get the same wrong number, faster, with a more confident explanation.