The 6-Dimension Data Quality Checklist for Supply Chain AI

A data quality checklist for supply chain AI has to answer a narrower question than most checklists do: can this specific data support the decision the model is about to influence? The familiar six dimensions—accuracy, completeness, consistency, timeliness, validity, and uniqueness—are useful shared language, and IBM describes them as core ways to evaluate whether data is fit for purpose.[1] But “fit for purpose” changes quickly in supply chain work. A supplier address used for risk scoring, a BOM used for production planning, and an inventory balance used for replenishment cannot be audited with the same level of tolerance.

That matters before the pilot starts. McKinsey has reported that only 53% of supply chain leaders rate their master data quality as adequate, which leaves many AI teams building on a foundation they already know is weak.[2] BARC research, as covered by Bigeye, found that data quality rose from 19% to 44% as the top reported obstacle to AI project success between 2024 and 2025.[3] Qlik reported in 2025 that 81% of companies still struggle with AI data quality.[4] Those numbers do not say every supply chain AI pilot will fail. They do say the audit belongs before model training, not after the first disappointing forecast run.

Start With Domains, Not a Generic Score

A single “data quality score” hides the failures that usually damage supply chain AI. The same defect may be harmless in one use case and fatal in another. A missing supplier tax ID may not affect a demand forecast, but it can break supplier consolidation or risk screening. A stale inventory balance may be survivable in monthly reporting and unacceptable in inventory optimization.

Use the table as a routing device. It tells the analyst where to look and tells the data engineer what to profile. The checklist that follows is not meant to certify enterprise governance maturity. It is meant to decide whether a supply chain AI data set is trainable, remediable within the pilot window, or too compromised to proceed.

The Six-Dimension Checklist

Accuracy: Does the Record Match the Operational Reality?

Accuracy is the dimension most likely to be waved through because a field is populated and looks reasonable. For supply chain AI, the question is stricter: does the data match the thing people are actually buying, building, moving, or counting?

• Validation questions: Does the BOM in the system match the current product configuration? Does the supplier address match the location that ships or invoices? Does the inventory balance reconcile to recent cycle counts? Do PO prices match active contract terms?
• Profiling techniques: compare BOM components against engineering or manufacturing release records; sample supplier addresses against tax, procurement, or carrier records; reconcile inventory balances against the latest count events; compare PO line prices against contract tables.
• Pass logic: pass only when the audited fields match the authoritative operational source for the use case. A record can be accurate enough for spend reporting and still fail for supplier risk scoring if the address points to headquarters instead of the manufacturing site.
• Fail logic: fail when the field is plausible but unverified, when the source of truth is unclear, or when exceptions cluster around high-volume SKUs, critical suppliers, regulated materials, or constrained lanes.

Accuracy checks should not start with every field in the ERP. Start with the fields the model will treat as signals. In a supplier risk model, the manufacturing location, parent-child supplier relationship, category, and payment or delivery history matter more than a general contact field. In inventory optimization, the model needs a trustworthy relationship between SKU, site, quantity, unit of measure, replenishment rule, and recent movement.

Completeness: Are the Required Signals Present Often Enough to Train On?

Completeness is not the same as having many columns. A demand forecasting model can tolerate missing fields that never enter the feature set. It cannot learn much from historical demand records that are missing order dates, ship dates, canceled-order flags, or product hierarchy fields needed for aggregation.

• Validation questions: Are lead-time fields populated for purchased items? Are supplier tax IDs and parent-company links present where supplier consolidation matters? Are carrier service levels defined? Are historical demand records complete across the period the model will use?
• Profiling techniques: calculate null and blank rates by field, product family, plant, supplier, and time period; separate required AI features from nice-to-have attributes; identify whether missingness is random or concentrated in certain business units, acquired systems, or older periods.
• Pass logic: pass when required fields are populated across the scope the model will train and infer on, and when missing values have an agreed treatment that does not distort the decision.
• Fail logic: fail when missing values remove entire suppliers, lanes, plants, product families, or time periods from the usable training set, even if the overall null rate looks acceptable.

The field-level null rate is only the first cut. A 5% missing rate sounds small until every missing record belongs to a new product family, a recently acquired facility, or a strategic supplier segment. Completeness has to be profiled by the operating slices the model will be expected to serve.

Consistency: Do the Same Things Keep the Same Meaning Across Systems?

Consistency is where supply chain AI inherits years of system history. A part number can mean one thing in the legacy ERP, another in the warehouse system, and a third after an acquisition. Units of measure can quietly shift from eaches to cases. Customer codes may reconcile in finance but not in order management. A model will not negotiate these differences; it will learn them.

• Validation questions: Does the SKU or part-number format match across ERP, WMS, TMS, planning, and analytics layers? Are units of measure standardized or reliably converted? Do plant, supplier, customer, and carrier codes reconcile across systems? Are product hierarchies aligned between planning and finance?
• Profiling techniques: run cross-system joins on key identifiers; calculate unmatched records by source; profile unit-of-measure conversions; compare product and location hierarchies; check whether the same identifier maps to multiple descriptions or the same description maps to multiple identifiers.
• Pass logic: pass when identifiers, units, and hierarchies map consistently enough that model inputs describe the same operational object across sources.
• Fail logic: fail when joins drop important records, when conversion rules are incomplete, or when the same SKU, supplier, or location changes meaning depending on the source system.

This is one of the checks that should happen before feature engineering. If the training table has already collapsed three systems into one view, inconsistency may be harder to see. Ask for the join fallout: which records failed to match, which were force-mapped, and which were excluded.

Timeliness: Is the Data Fresh Enough for the Decision Window?

Timeliness is not a generic preference for real-time data. The right freshness depends on the decision. A monthly demand planning model and a same-day routing model do not need the same update cadence. The audit question is whether the data arrives before the decision is made.

• Validation questions: Is inventory based on last night’s cycle count, a current WMS balance, or a number carried forward from a quarterly reconciliation? Are carrier ETAs updated before dispatch decisions? Are supplier lead-time changes reflected before the planning run? Are demand signals loaded at the cadence the forecast requires?
• Profiling techniques: measure source-to-target latency; compare event timestamps with load timestamps; identify batch windows; profile late-arriving records by source and site; measure how often records arrive after the business decision they are supposed to support.
• Pass logic: pass when the data refresh cadence is faster than the model’s decision cycle and late records do not materially affect the target use case.
• Fail logic: fail when the model will routinely train or infer from data that was true after the decision point, or when stale records drive recommendations for fast-moving items, constrained inventory, or active shipments.

Timeliness also has a training-data trap: historical snapshots are often overwritten. If the team trains on today’s corrected view of what inventory was last month, the model may see information planners did not have at the time. For use cases tied to daily decisions, keep the timestamp discipline visible.

Validity: Do Values Obey the Rules of the Business?

Validity checks whether a value is allowed, not whether it is true. A date can be in the right format and still fall outside a reasonable operating window. A carrier service level can be populated and still not exist in the carrier contract. An address can contain a ZIP code and still mismatch the city and state.

• Validation questions: Do order, receipt, and ship dates fall in expected ranges? Do PO amounts align with contract thresholds and approval rules? Do ZIP codes match city and state combinations? Are units of measure, carrier services, and supplier statuses drawn from approved values?
• Profiling techniques: run domain checks, range checks, referential integrity checks, address validation, contract-threshold checks, and allowed-value checks against active master and contract tables.
• Pass logic: pass when invalid values are rare, explainable, and excluded or corrected before training and inference.
• Fail logic: fail when invalid values cluster in the exact fields that constrain the model, such as service levels for routing, lead-time values for planning, or addresses for lane optimization.

Validity rules should come from current operating rules, not from whatever values happen to appear in the database. If an inactive supplier status appears in open purchase orders, the model should not be left to infer whether that is a valid exception or a broken process.

Uniqueness: Is One Real-World Entity Represented Once?

Uniqueness is where supplier risk scores, spend analytics, and customer-service models often get quietly distorted. If the same supplier exists three times, each record may look low-risk, low-spend, or low-volume on its own. If material masters were merged after an acquisition without a reliable crosswalk, the model may split one item’s history or combine two items that should stay separate.

• Validation questions: Are supplier records deduplicated across legal names, trade names, addresses, and tax IDs? Are customer records linked to a single golden ID? Are material masters merged with clear lineage? Are duplicate purchase orders, receipts, or shipment events removed from the training set?
• Profiling techniques: run fuzzy matching on supplier and customer names; compare addresses, tax IDs, bank details, and parent-company links; identify many-to-one and one-to-many material mappings; detect duplicate transactions by business keys and timestamps.
• Pass logic: pass when each supplier, customer, material, location, and transaction has a stable identifier at the grain required by the model.
• Fail logic: fail when duplicate or merged identities change the target variable, dilute risk indicators, inflate transaction counts, or prevent spend, demand, or performance history from rolling up correctly.

Golden IDs are not a cosmetic cleanup task. They decide what history belongs together. For AI use cases that score entities—suppliers, customers, carriers, lanes, materials—uniqueness can be the difference between a useful signal and a fragmented one.

Weight the Checklist by the AI Decision

The checklist should not be scored flat. A routing model, a supplier risk model, and a demand forecast do not punish the same defects in the same way. Before assigning pass, remediate, or pause, weight each dimension according to the model’s decision.

Demand Forecasting: Missing and Late Data Hurt Before the Model Starts

For demand forecasting, the first audit should look at whether the model has enough usable history at the right grain. That usually means order or shipment history tied to product, customer, location, and time. If canceled orders, stockouts, substitutions, or product transitions are not captured, the model may treat constrained demand as true demand.

Timeliness matters because forecasts are produced on a planning cadence. A weekly forecast that receives demand updates after the planning run is not using “recent demand” in the operational sense. Completeness matters because gaps are rarely evenly distributed. New channels, acquired brands, seasonal products, and discontinued SKUs often create the missing-history pockets that a simple aggregate completeness score will smooth away.

Supplier Risk Scoring: Entity Resolution Comes First

Supplier risk scoring should not begin with a model until the team knows which supplier is being scored. Accuracy and uniqueness carry the weight here. A supplier’s plant location, legal entity, parent relationship, category, delivery record, and quality history may sit in different systems. If those records do not resolve to the right entity, the score can look precise while pointing at the wrong risk.

This is where duplicate supplier masters become more than an administrative nuisance. They split spend, dilute late-delivery patterns, and make risk attributes look less severe than they are. If the supplier master has not been deduplicated, the risk model may reward the cleanest record rather than the safest supplier.

Inventory Optimization: Codes, Units, and Counts Have to Agree

Inventory optimization is unforgiving because the recommendation turns into a quantity: buy, move, hold, expedite, or release. Consistency and accuracy therefore carry more weight than a broad data quality average. If one system stores an item in cases and another stores it in eaches, or if two SKU codes refer to the same material, the model can produce a mathematically clean answer for an operationally wrong quantity.

The audit should trace the chain from item master to on-hand balance to recent movement to replenishment rule. The important question is not whether each table is populated. It is whether the same item, at the same site, in the same unit of measure, with the same lead-time assumption, can be followed through the systems the model will use.

Logistics Routing: Freshness and Valid Values Are Operating Constraints

For logistics routing, timeliness and validity are not polish. They are constraints. A shipment status that updates after dispatch, an address that fails validation, or a carrier service level that does not map to a real option can make a route recommendation unusable even if the optimization logic is sound.

The audit should compare the data refresh cycle with the routing decision cycle. It should also validate addresses, service codes, location identifiers, delivery windows, and lane constraints before training. Routing models can still be useful with imperfect data, but not when the defects sit in the fields that define where a shipment can go and when it can arrive.

Turn the Audit Into a Pre-Training Decision

After profiling, avoid turning the checklist into a long issue register with no decision. The output should place each data domain into one of three states: proceed, remediate, or pause.

This is also where source quality matters in the business case. A TraxTech blog states that 70% of AI projects fail due to data quality issues and that companies investing in data infrastructure first achieve 3x better AI ROI than those that rush into algorithms, but that ROI figure is vendor-published rather than independent research.[5] Gartner has separately warned that lack of AI-ready data puts AI projects at risk.[6] The practical conclusion is narrower and stronger than any single statistic: if the critical data domains fail the weighted checklist, model training is not the next responsible step.

Teams that need the broader failure pattern can pair this checklist with why supply chain AI projects fail when implementation starts before data readiness. Teams building the implementation plan itself can use this audit as the data-readiness gate inside a phased roadmap, rather than treating cleanup as an after-hours task for analysts once the pilot date is already public.

The checklist will not create data ownership, fix master-data workflows, or monitor drift after deployment. It is the step before those steps: a focused test of whether the data set in front of the team can support the supply chain AI decision being promised. If the answer is no, the cleanest implementation move is to say so before the model is trained.

References

1. What Are Data Quality Dimensions? — IBM
2. Prioritize Master Data Quality to Enable Your Supply Chain Strategy — McKinsey via Gartner
3. The Data Quality Crisis Killing AI Projects — Bigeye
4. Data Quality is Not Being Prioritized on AI Projects — Qlik, 2025
5. Why Supply Chain AI Projects Fail: The $100M Data Quality Problem — TraxTech
6. Lack of AI-Ready Data Puts AI Projects at Risk — Gartner, February 2025