Your ERP Now Has AI: What Your Vendor Won't Tell You Before You Turn It On

AI modules in ERPs promise automation and predictions. But if your data isn't in shape, the AI amplifies the mess — it doesn't fix it. What to check before you activate.

Your ERP vendor just announced that the new version includes artificial intelligence. Demand forecasting, automated purchase recommendations, real-time anomaly detection. The button is already in the menu. You just need to turn it on.

Before you do, there’s a question no vendor will ask you: what shape is the data your ERP has been accumulating for years?

What the AI pitch promises — and what it assumes

AI modules for ERPs are real and can work. Demand forecasting that learns your business seasonality, detection of suppliers with recurring delay patterns, stock-level recommendations per location — all of that exists and delivers value when the right conditions are in place.

The problem is what the vendor assumes without saying it: that your data is reliable.

Your ERP’s AI doesn’t have access to external industry benchmarks. It works with what you fed it over the years: manual entries, partial migrations, fields filled in “just to get past the validation,” duplicates no one cleaned up because the system worked fine without it.

When a model processes that kind of data, it doesn’t fix it. It uses it. With the same statistical confidence it would apply to clean, well-governed data.

What actually happens

We worked with an organization that activated their ERP’s demand prediction module after six months of configuration work. The project had executive sponsorship, a dedicated team, and a results presentation ready for the board.

Within weeks of going live, the model’s numbers started diverging on the highest-turnover product categories — exactly where accurate predictions mattered most.

No one could explain why. The model had been validated. The configuration was correct according to the vendor.

When we looked at the product master, we found that 34% of active items had an incorrect or blank category. This wasn’t a recent mistake — it was years of fast data entry and fields that the operational system ignored because it didn’t need them to process orders.

The operational system ignored them. The AI model didn’t. It used product category as a segmentation variable for demand estimation. With a third of items miscategorized, predictions by category were essentially noise wearing the costume of a number.

The fix wasn’t changing the model. It was cleaning the product master and adding validation rules to the entry flow. Two weeks of work. After that, the module performed as the vendor had promised.

The underlying issue: ERPs weren’t designed to be sources of truth

An ERP was designed to operate: process orders, issue invoices, manage inventory, record transactions. It does that well. But in doing so, it accumulates data of variable quality that no one audited systematically, because it wasn’t necessary for operations.

When you want to run analytics or AI on top of that data, the cracks show up.

The most common issues we find:

Customer master with duplicates. The same client under three name variations, two different tax IDs, one outdated address. When the model tries to segment by purchase behavior, it mixes three distinct entities as if they were one.

Products uncategorized or miscategorized. Categories were defined at the original implementation. No one revisited them as the catalog evolved.

Critical fields empty or filled with default values. “N/A,” “0,” ”-” — values that technically fill the field but carry no analytical meaning. The model treats them as valid information.

History with gaps. Partial migrations that didn’t bring over all historical periods. The model trains on a time series with holes it doesn’t know it has.

Records that were never properly closed. Purchase orders open since three years ago, “active” customers who last bought in 2022, deactivated suppliers still live in the system.

When does ERP AI actually work well?

We’re not saying AI modules in ERPs don’t work. We’re saying they work well under specific conditions.

Condition	Why it matters
Clean, current master data	The model needs consistent categories and entities to segment correctly
Complete, continuous history	Time series with gaps produce unstable predictions
No junk values in critical fields	”N/A” as data is worse than missing data — it misleads the model
Active validation rules on data entry	Without rules, quality degrades over time regardless of the initial cleanup
Team that understands what the model consumes	If the operational team doesn’t know what feeds the predictions, they’ll keep entering data the wrong way

If your organization has these conditions, the ERP’s AI module will probably work well from day one.

If not, activating it will produce outputs the team will dismiss within weeks — and the internal conclusion will be “AI doesn’t work for our business,” when the reality is that the AI did exactly what it was supposed to do with the data it was given.

What to do before activating

The preparatory work isn’t glamorous and doesn’t show well in a board presentation. But it determines whether the project works or not.

1. Audit the customer and product master data

How many duplicates exist. How many records have critical fields blank. How many items have incorrect or inconsistent categories. This audit can be done in hours with the right tooling — the output is a concrete number, not an estimate.

2. Define which fields the model actually consumes

Before cleaning, you need to know what the model uses. There’s no point cleaning fields the AI module won’t touch. The vendor should be able to tell you which variables feed the model — if they can’t, that’s a warning sign.

3. Focused cleanup on the fields that matter

You don’t need to clean the entire ERP. You need to clean what the model will use. In most cases, that’s 5–8 critical fields per entity. The work is manageable when it’s properly scoped.

4. Forward-looking validation rules

Cleanup fixes the past. Validation rules on data entry prevent the problem from returning. Without this step, you’re back to the same starting point in six months.

5. A validation period before using outputs for real decisions

The model needs time to stabilize on clean data. Run it in parallel for 4–6 weeks, compare its outputs to reality, adjust. Only then start making operational decisions based on its recommendations.

When this prep work doesn’t apply

If your organization is implementing the ERP from scratch — migrating from spreadsheets or an unstructured legacy system — the right moment for this work is during implementation, not after. Cleaning data before migration costs a fraction of what it costs once the system is live with dirty data.

If you already have the ERP running but aren’t considering AI modules, the cost-benefit of a data audit depends on how many issues you’re seeing in your current reports. If the numbers reconcile and the team trusts the data, it’s probably not urgent. If there are frequent discrepancies or the team has developed a habit of “checking the system against their own spreadsheet,” there’s a data quality problem worth addressing regardless of AI.

Something you can do this week

Without hiring anyone or launching a formal project: ask someone on the team to pull the first 1,000 records from the customer master and count how many have the same name with minor variations, how many have an empty or generic “category” field, and how many haven’t had any activity in the last 24 months.

That number will give you a fairly accurate picture of your data state. Below 5%, your data is probably ready to support AI. Above 15%, you have preparatory work to do before activating any module.

No six-month project required to find out. Just an hour and honesty about what you find.

---

You might also like: Your Company Doesn’t Have an AI Problem. It Has a Data Problem.