AI Supply Chain Integration: ERP Data Readiness Assessment Checklist

Most AI supply chain deployments that fail in the first six months share a common root cause: the ERP data feeding the model was never actually ready. Not "imperfect" — genuinely unready. Duplicate vendor records, transaction timestamps that don't reflect physical events, item master fields populated with placeholder values, and order history that mixes fulfilled and cancelled lines without a reliable status flag.

This checklist is designed for the period before you select a vendor or sign a contract — the point where your team needs an honest picture of what the ERP can actually support. It covers four assessment stages: data structure and schema, data quality and completeness, integration architecture, and deployment readiness. Each stage has a go/no-go gate. If you can't pass a gate, the right answer is remediation, not acceleration.

Why ERP Data Readiness Determines AI Deployment Outcomes

AI supply chain tools — whether demand forecasting, replenishment optimization, or supplier risk scoring — are fundamentally data transformation engines. The model quality ceiling is set by the input data floor. A gradient boosting model trained on two years of SAP sales order history will produce accurate forecasts only if that history correctly represents actual demand. If it includes cancelled orders, internal transfers coded as sales, or backdated entries from period-end adjustments, the model learns the wrong patterns.

ERP systems accumulate data quality debt over years of configuration changes, mergers, manual overrides, and workarounds. That debt is invisible in day-to-day operations — the ERP still produces invoices and purchase orders — but it surfaces immediately when an AI layer tries to build a coherent, consistent training dataset across multiple modules.

Stage 1: Data Structure and Schema Assessment

Before evaluating data quality, confirm that the structural prerequisites exist. AI supply chain tools require specific data objects to be present, populated, and consistently keyed across modules. This stage is binary — either the data structures exist or they don't.

Item Master Integrity

• Every active SKU has a single, stable material/item number that has not changed over the target history window (typically 24–36 months for demand planning).
• Item master records include unit-of-measure fields that are consistently populated and match the UOM used in transaction tables (sales orders, purchase orders, inventory movements).
• Product hierarchy fields (category, subcategory, product family) are populated for at least 90% of active SKUs and use a controlled vocabulary — not free-text entries.
• Discontinued or superseded items are flagged with a status code, not just absent from recent transactions. The AI model needs to distinguish "no demand" from "item retired."
• If the ERP spans multiple plants or distribution centers, item numbers are consistent across organizational units, or a cross-reference table exists and is maintained.

Transaction Table Structure

• Sales order history includes: order date, requested delivery date, confirmed delivery date, shipped date, item number, quantity ordered, quantity shipped, and order status. All six date fields must be present — not just order date.
• Inventory movement tables distinguish between demand-driven outflows (sales, transfers to customers) and non-demand outflows (write-offs, quality holds, internal transfers). This distinction is non-negotiable for demand sensing.
• Purchase order history includes supplier ID, item number, order date, promised delivery date, actual receipt date, and quantity received. Promised vs. actual receipt date is required for lead time modeling.
• Each transaction record is keyed to a location (plant, warehouse, DC) that maps to a node in your network model.

Master Data Cross-Module Consistency

AI supply chain tools typically pull from multiple ERP modules simultaneously — SD (Sales), MM (Materials Management), PP (Production Planning), FI (Finance). The item numbers, customer numbers, and vendor numbers used in each module must resolve to the same master records. In practice, many ERP environments have accumulated inconsistencies: a vendor coded differently in MM and AP, a customer with multiple account numbers that aren't linked, or a plant code that changed during a system migration.

• Confirm that vendor master records in procurement (MM/SRM) and accounts payable (FI-AP) share a common vendor ID or have a documented mapping table.
• Confirm that customer master records in sales (SD) and accounts receivable (FI-AR) are consistent. Duplicate customer accounts for the same trading partner are a common source of demand history fragmentation.
• If the ERP is SAP, run transaction MM60 or equivalent to identify materials with inconsistent plant-level data. In Oracle, run the item validation report across operating units.

Stage 2: Data Quality and Completeness Assessment

Structure tells you what exists. Quality tells you whether what exists is usable. This stage requires running actual queries against production data — not reviewing documentation or asking the ERP administrator.

Demand History Quality

Inventory and Replenishment Data Quality

• On-hand inventory snapshots are taken at a consistent point in time (end of day, end of week) and stored with a timestamp. Intraday snapshots without timestamps make it impossible to reconstruct inventory positions for historical model training.
• Safety stock parameters currently stored in the ERP (reorder points, min/max levels) are documented with the date they were last updated. Parameters that haven't been reviewed in 18+ months are a signal that the ERP is operating on stale planning logic — which the AI will need to override, not inherit.
• Goods receipt records include actual receipt date and quantity received. If the ERP only stores the purchase order delivery date (not the actual GR date), lead time modeling will be based on planned rather than actual lead times — a significant accuracy gap.
• Cycle count and physical inventory adjustment records are stored with reason codes. Unexplained adjustments exceeding 2% of inventory value per quarter suggest a systemic counting or receiving process problem that will propagate into AI inventory recommendations.

Supplier and Procurement Data Quality

• Supplier performance data (on-time delivery rate, fill rate, quality rejection rate) is stored at the purchase order line level, not just summarized in a scorecard. AI supplier risk models need line-level history to detect deterioration patterns.
• Lead time actuals are available for at least 18 months per supplier-item combination. If lead times are only stored as static parameters in the vendor master, the AI cannot model lead time variability — only the mean.
• Spend data is coded to a consistent commodity or category hierarchy. Uncategorized spend (often 15–30% in organizations that haven't done a spend analysis project) limits the scope of any procurement AI application.

Stage 3: Integration Architecture Assessment

Even with clean, complete data, the integration layer between the ERP and the AI platform can introduce latency, transformation errors, and synchronization failures that degrade model performance in production. This stage assesses whether your current integration infrastructure can support the data exchange patterns AI supply chain tools require.

Data Extraction Capability

• The ERP supports scheduled bulk extracts (full or delta) to a staging area or data lake without requiring custom ABAP development or Oracle custom views for each AI vendor. Relying on vendor-specific extractors that require ERP customization creates a long-term maintenance dependency.
• Delta extraction (changed records only, not full table dumps) is available for high-volume transaction tables. Full table extraction of a 10M-row sales order history table nightly is often not feasible in production windows.
• The ERP team can document the exact table names, field mappings, and business rules that govern each extract. If this documentation doesn't exist, the integration project will spend 4–8 weeks reverse-engineering it.

Write-Back Architecture

Most AI supply chain tools don't just read from the ERP — they write recommendations back. Demand forecasts update planning tables. Replenishment recommendations generate purchase requisitions. Supplier risk scores update vendor master flags. The write-back path is where integration projects most often underestimate complexity.

• Confirm that the ERP has a supported API or BAPi (SAP) / open interface (Oracle) for each write-back object the AI tool will update. Unsupported write-backs via direct table inserts are a compliance and upgrade risk.
• Define the approval workflow for AI-generated write-backs before integration design begins. Does a demand forecast update require planner approval before it updates the planning table? Does a replenishment recommendation require a buyer to release the purchase requisition? These workflow decisions affect the integration architecture.
• Test write-back in a non-production ERP environment before go-live. Write-back errors that corrupt planning master data are significantly harder to remediate than read errors.

Middleware and Integration Platform Readiness

Stage 4: Organizational and Governance Readiness

Data and integration readiness are necessary conditions, not sufficient ones. The organizational prerequisites — ownership, accountability, and change process — determine whether a technically sound integration stays sound over time.

• A named data owner exists for each ERP master data domain (item master, vendor master, customer master) and has authority to approve changes. Without a named owner, data quality remediation has no accountable party.
• There is a documented process for handling ERP configuration changes (new plant codes, UOM changes, chart of accounts restructuring) that includes a notification step to the AI platform team. ERP changes that silently break the integration are the most common source of post-go-live model degradation.
• The planning team has been involved in the data readiness assessment — not just IT. Planners know which demand history periods are contaminated by unusual events, which supplier lead times are systematically understated, and which product categories have unreliable inventory records. That contextual knowledge is not in the data.
• A model monitoring process is defined before go-live: who reviews forecast accuracy metrics, at what frequency, and what triggers a retraining or parameter review. AI models degrade when the data distribution shifts — and ERP data distributions shift regularly.

Go / No-Go Decision Framework

Use the following gate criteria to determine deployment readiness at each stage. A "conditional pass" means remediation is underway with a defined completion date and owner — not that the issue has been noted and deferred indefinitely.

ERP-Specific Considerations

The assessment steps above apply across ERP platforms, but each major ERP has specific data structures and known problem areas that affect AI integration.

SAP ECC and S/4HANA

• The distinction between statistical forecasting (APO/IBP) and operational planning (MRP) in SAP creates two separate data domains. Confirm which one the AI tool will replace or augment — and whether the integration touches both.
• SAP movement type codes (261, 311, 551, etc.) in the material document table (MSEG) must be mapped to demand vs. non-demand categories before the data is usable for AI training. This mapping is organization-specific and typically requires 2–4 weeks of analysis.
• S/4HANA customers on the Universal Journal (ACDOCA) have a different data extraction path than ECC customers. Confirm which table structure your AI vendor's connector targets.

Oracle EBS and Oracle Cloud SCM

• Oracle EBS organizations running across multiple operating units often have item numbers that are not shared across operating units. The multi-org architecture requires explicit cross-reference mapping before AI tools can build a unified demand history.
• Oracle Cloud SCM customers using the Demand Management module should confirm whether the AI tool will replace Oracle DM or run alongside it — the write-back paths differ significantly.
• Oracle's REST API for Cloud SCM is the preferred extraction path for SaaS AI vendors. Confirm API access is enabled and that the required data objects (sales orders, inventory transactions, purchase orders) are exposed via the API, not just available in the UI.

Microsoft Dynamics 365 Supply Chain Management

• D365 SCM customers using Dataverse as their integration layer have a more standardized extraction path than those relying on direct database access. Confirm whether your environment uses Dataverse or a custom data warehouse.
• D365's built-in demand forecasting (Azure Machine Learning-based) creates a potential conflict with third-party AI demand planning tools. Define clearly whether the third-party tool replaces D365 demand forecasting or supplements it — and which forecast drives MRP.

What This Assessment Does Not Cover

The assessment should be completed by a team that includes at minimum: an ERP functional lead (who understands the business meaning of data fields), a data or BI engineer (who can run the actual queries), and a supply chain planning lead (who can validate whether the data reflects real operational behavior). Doing it with only IT involvement produces a technically accurate but operationally incomplete picture.

Plan for 4–6 weeks to complete a thorough assessment across all four stages for a single ERP instance. Multi-instance environments (e.g., separate ERP instances by region or business unit) multiply that timeline proportionally. The time spent here is not overhead — it is the work that determines whether the deployment succeeds.