Most retailers don't create the product data they sell with. Suppliers send it. Then buyers, category managers, warehouse teams and e-commerce editors change it in their own systems. Retail master data management keeps one governed version of that data and distributes it to every system that needs it. MDM software is the tool that holds the rules and runs the integrations.
The sections below cover what MDM software does in practice, how retail requirements differ from the generic MDM model, what AI does today in retail data work, and how four solutions fit different situations.
Key Takeaways
- Retail MDM differs from generic MDM mainly at intake. Most product attributes originate with suppliers, so validation has to happen when data arrives, before it spreads into ERP and warehouse systems.
- Data drifts at every handoff. In a 2020 GS1 Australia pilot covering about 250 grocery SKUs, values diverged more the more systems they passed through.
- A retail product is a family of records: variants, packaging levels, location-specific ranging and channel-specific content.
- AI saves time on extraction, classification, and matching. Its output belongs in a review queue before it reaches the golden record.
- The tools on the market start from different problems. Choose the one built around the place where your data breaks first.
What MDM Software Does In Practice
Master data is the reference data that transactions point to. An order line points to a product. A delivery points to a supplier and a distribution center. Transactions happen by the second, while master data changes by the week, and each change has to reach every system that copied the old value.
MDM software sits between the systems that create data and the systems that use it. It collects records from ERP, supplier portals, spreadsheets, and data feeds into a staging area. It matches records that describe the same real item, such as two supplier submissions with the same GTIN. Survivorship rules then decide which source wins for each field: the supplier owns net content and allergens, the category team owns the retail name and category. The result is the golden record. Validation rules and approval workflows control every later change, version history keeps the audit trail, and outbound integrations push approved values to ERP, POS, WMS, the online shop and marketplaces.
Retail teams often blur MDM, PIM and ERP. ERP holds the operational item record for ordering, invoicing, and stock. PIM manages channel content such as long descriptions, images, SEO fields and translations. MDM governs the core attributes both depend on and settles conflicts between sources. Many mid-sized retailers run PIM and MDM on one platform, and that works if the platform supports matching, survivorship and field-level ownership. A PIM that only stores and publishes content cannot settle a conflict between two systems.
A practical test: when two systems disagree about a product's case weight, the tool that decides the correct value and updates the other system is your MDM, whatever its label says.
Why Retail Needs Are Different
A manufacturer creates its own material master. A bank opens its own customer accounts. A retailer receives most product attributes from suppliers and then adds its own layer on top: prices, assortments, categories, store ranging and channel content.
Most Product Data Starts Outside The Company
Supplier data arrives through GDSN data pools, supplier portals, EDI catalogs, spreadsheets, and PDF spec sheets. Each route has its own error profile. Spreadsheets carry typos and unit mix-ups. GDSN data is structured, but it only reflects what the supplier entered, sometimes an estimate made before production started.
A 2020 data review pilot by the Australian Food and Grocery Council's Trading Partner Forum and GS1 Australia measured how far supplier data drifts as it moves between systems. The pilot followed about 250 grocery SKUs through four systems: the supplier's ERP, the GS1 National Product Catalogue, the retailer's ERP and, for a subset, the retailer's warehouse management system. The participating retailers were Woolworths, Coles and Metcash.
The first comparison stayed entirely in the supplier's hands. Suppliers maintain both their ERP record and their catalogue entry. Even so, at zero tolerance, 32% of SKUs differed in at least one carton dimension and 44% differed in carton weight. With a 5% tolerance, the figures dropped to 18% for dimensions and 14% for weight.
The follow-up review traced the supplier-side mismatches to human error. Some suppliers confused a carton's width with its depth. Others mistyped values or had different people enter data into each system at different times. About one SKU in seven appeared to have its dimensions transposed.
Variance grew with every system the data passed through. Retailer distribution centers remeasured cartons and stored their own values in their WMS, so two DCs of the same retailer could hold different dimensions for one item.
The data dates from 2020 and covers one market and one product category. Treat the percentages as an indication for your own catalog rather than a benchmark. The mechanism applies anywhere: every system that lets someone re-enter or remeasure a value creates a second version of it.
In the 2020 pilot, 32% of SKUs showed a carton dimension mismatch between the supplier's ERP and the same supplier's GS1 catalogue entry, at zero tolerance. No retailer had touched the data yet.
For retail master data management, that translates into concrete software requirements:
- Validation at intake.
Supplier submissions are checked against category-specific rules before they reach the item master: mandatory attributes, unit-of-measure normalization, and plausibility checks such as comparing case weight against units per case multiplied by unit weight. - A feedback loop to the supplier.
Rejected values go back to the supplier with a reason. When a buyer fixes data silently, the supplier's next update overwrites the fix. - Field-level source tracking.
When a DC remeasures a case, the measured value is stored as a separate source with its own timestamp, and the conflict goes to a data steward. The AFGC report recommends relaying DC changes through the central data team to the supplier so every system stays aligned.
Supplier Intake In Practice
Our customers turn to us when supplier data has already split into several versions of the same product.
Nahdi Medical Company is Saudi Arabia's largest pharmacy-led retailer, with over 1,150 pharmacies across Saudi Arabia and the UAE. Before the project, vendors and internal teams shared product onboarding without clear roles or visibility, and the legacy PIM kept duplicate product versions for different regions. We implemented AtroPIM, the product module of the AtroCore platform. Vendors now upload Excel feeds that import directly into the system, and role-based workflows define who creates, reviews, approves, and enriches each record. Only verified and approved data syncs to the Adobe Commerce storefront. One record per product serves both the English and the Arabic site, with translation memory and a glossary keeping Arabic terminology consistent.
First Stop Ayme, a tire and car service chain with nearly 500 centers in France and the Benelux, came to us with nearly a million SKUs from multiple suppliers. The data arrived in different formats, often with conflicting details. The implementation automated the imports from each source and applies brand and category rules as data arrives. Completeness checks and dashboards show data quality per brand and category, and scheduled exports deliver channel-specific datasets to partners.
The same platform also runs on the other side of the exchange. Manufacturers that deliver to several chains use it to keep one item master and generate each retailer's format from it, so a correction happens once instead of in every retailer portal.
For retailers, the practical step is to publish data requirements in a form suppliers can check before submission: mandatory attributes per category, units of measure, allowed values, and image specifications. A supplier that validates against your rules in its own system sends fewer records into your rejection loop.
One Product Is Many Records
In retail, a product is a family of records.
Fashion and footwear multiply each style by colors and sizes. A shirt in 5 colors and 6 sizes is 30 sellable items, each with its own GTIN and stock, and often its own image. MDM software has to support inheritance, with shared attributes on the style and overrides on the variant. Without inheritance, a change to fabric composition means editing 30 records by hand and missing two of them.
Packaging adds a second axis. The consumer unit, inner pack, case, and pallet each carry dimensions and weight, and often their own GTIN. Stores plan shelves from consumer-unit data. Distribution centers plan slotting, picking, and pallet building from case data, and the AFGC report notes that automated DCs use carton dimensions for robotic picking and carton weight as a checkpoint for the robotics. A wrong case dimension stays invisible online and stops a pallet in the DC.
Two practical rules follow. Model each packaging level as its own linked record with its own validations, instead of adding extra fields to the consumer unit. And define the unit for every quantity field. The AFGC review found suppliers recording Ti (units per pallet layer) in consumer units while retailer ERPs expected cases per layer.
The Location Dimension
Locations are a full master data domain in retail: stores, distribution centers, dark stores, pickup points. Each carries attributes such as format, sales area, opening hours, region, and fulfillment options. Many product attributes are only true per location, such as whether an item is ranged in a store cluster or which regional label language applies. A chain ranging 20,000 items across 300 stores has 6 million product-location combinations.
Most of those combinations belong in merchandising and replenishment systems. MDM should own the location master and the definitions behind the combinations: store clusters, ranging rules, regional product variants, and label languages. Daily store-level values stay in the operational systems.
Hierarchies With Different Owners
One product sits in several hierarchies at once. The merchandising hierarchy drives buying and reporting. The web navigation tree drives findability and changes with campaigns. GS1's Global Product Classification serves data exchange with suppliers. Each marketplace has its own category tree. Different teams own each hierarchy, and each changes on its own schedule.
The MDM has to hold these as separate classifications linked to one golden record, with attribute requirements per category. A wireless headphones category needs battery life and Bluetooth version. A yogurt category needs allergens and storage temperature. When category managers can add a required attribute themselves, new categories go live without an IT ticket.
Compliance Data Has To Reach The Product Page
Retail regulation applies at the point of sale, and online listings count. Since 13 December 2024, the EU General Product Safety Regulation requires online offers to show the manufacturer's name and postal and electronic address, details that identify the product, and any warnings or safety information. For food sold online, EU Regulation 1169/2011 requires most mandatory food information, allergens included, to be available before the purchase is completed.
The retailer publishes these fields. The supplier owns them. So MDM needs to record which supplier submission each compliance value came from and when it was approved.
Customer Data At Consumer Scale
Customer MDM in retail handles millions of consumers, guest checkouts, loyalty cards, changed email addresses, and households sharing one account. There is no shared identifier like a VAT number in B2B, so matching depends on probabilistic rules. Consent status under GDPR has to stay in sync with every system that uses the profile. Many retailers keep customer data in a CDP or loyalty platform and focus MDM on products, suppliers and locations. That split holds as long as customer IDs and consent flow both ways.
What Stays Out Of MDM
Live prices, promotions, markdowns, and stock levels change too often for MDM approval workflows. Keep reference values such as recommended retail price and VAT class in MDM, and leave the rest to pricing and inventory systems.
Where AI Helps In Retail Master Data
Most retail AI projects consume product data: on-site search, recommendations, shopping assistants, and marketplace feeds. They fail quietly when attributes are missing or wrong. A Gartner survey of data management leaders found that 63% of organizations either lack the right data management practices for AI or are unsure whether they have them. Gartner also predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data.
Gartner's Roxane Edjlali: "If the data has issues, then the data is not ready for AI."
Inside MDM, AI handles a specific set of jobs well enough to use in production:
- Attribute extraction. Models pull values such as net content, material, voltage, or care instructions from supplier PDFs, images, and free-text descriptions into structured fields. Informatica's Product 360, for example, uses its CLAIRE engine to extract brand names from product descriptions.
- Classification. A model proposes the category or GPC brick for a new item based on its title and attributes.
- Duplicate matching. Machine-learning models score likely duplicates, such as one item submitted by two distributors under different internal codes.
- Drafting and translation. Models write first drafts of descriptions and translations from approved structured attributes.
AI does not measure cartons. Physical attributes need a scale and a tape measure, and the AFGC report recommends a data verification step for new products and imported lines. Generated descriptions carry their own risk because fluent text can still be wrong. A draft that calls a water-resistant jacket "waterproof" reads well and produces returns.
In projects we implemented, AI output lands in staging and never goes straight into the golden record. Each suggested value links to the document it came from, and a data steward accepts or rejects suggestions in bulk. The acceptance rate per attribute then shows where the model is reliable enough for lighter review.
Vendors now package these jobs as agents. Stibo Systems announced AgentWorkx in September 2026, a framework for building and governing AI agents that work inside its STEP platform under the platform's existing roles and permissions. For any agent feature, check which fields it can change and who approves its changes.
Retail Master Data Management Solutions
The four solutions below start from different problems. That matters more in practice than feature checklists, because every vendor lists matching and workflows.
Stibo Systems
Stibo Systems is headquartered in Aarhus, Denmark, and belongs to the foundation-owned Stibo Software Group. Its STEP platform is a multidomain MDM covering products, suppliers, customers, and locations in one data model. Retail is a core market for the company. Its NRF exhibitor profile names Walmart and Marks & Spencer among the retailers using the platform, and it ships with predefined retail data models and governance workflows. In 2026, Stibo added an MCP server and the AgentWorkx agent framework, both running under STEP's access controls. It fits large retailers that need product, supplier, and location data governed together, with many approval steps and teams. The trade-off is the size of the effort. Programs of this scale usually run with an implementation partner, and the workflows only pay off with a dedicated data governance team behind them.
Informatica
Salesforce completed its acquisition of Informatica in November 2025, so Informatica's MDM now sits inside a CRM vendor's data strategy. The MDM runs on the Intelligent Data Management Cloud (IDMC) as domain applications: Product 360, Supplier 360, Customer 360, and Reference 360. A retail industry extension adds a prebuilt data model that spans those domains, and the CLAIRE AI engine supports match tuning and enrichment. It fits retailers that already use Informatica for integration and data quality, or that run Salesforce for commerce and service and want master data close to it. Pricing depends on which domain applications you license, so costs grow with each domain you master. Retailers outside the Salesforce stack should ask how the roadmap treats non-Salesforce target systems before signing a multi-year contract.
Syndigo
Syndigo, based in Chicago, comes from the content exchange side of retail. It absorbed the MDM vendor Riversand and, in September 2025, acquired 1WorldSync, which combined two GDSN data pools and added the PowerReviews ratings platform. The combined network reaches more than 3,500 retailers and over 18,000 customers. For a retailer, the main value is vendor onboarding. Many brands already publish to Syndigo, so new item content can arrive validated against the retailer's requirements instead of through spreadsheets. It fits retailers and brands whose biggest problem is the volume of supplier content and syndication to channels. The trade-off is focus. Its center of gravity is product content exchange, so retailers with complex location, ranging, or customer mastering needs should test those domains with their own data before deciding.
AtroCore
AtroCore, developed by the German company AtroCore GmbH, is an open-source MDM and data platform under the MIT license, with AtroPIM as its product module. It can be self-hosted. Administrators configure entities, attributes, hierarchies, staging pipelines, matching rules, and per-field survivorship in the interface without code, so a new category or marketplace export is a configuration task. Native connectors cover systems such as SAP, Microsoft Dynamics, Salesforce, and Shopify, and paid modules add AI integration and extended data quality automation. It fits mid-sized retailers and retail chains whose assortment and channels change often and who want control over hosting and license costs, like the two chains described earlier. The trade-off is ecosystem size. The community and partner network are smaller than those of the enterprise suites, and AtroCore does not operate a supplier content network or GDSN data pool, so retailers relying on brand-submitted content connect to one.
How To Test A Retail MDM Before You Buy
Bring your worst supplier file to the demo. Ask the vendor to load and map it, then show which records fail and why. How the tool reports errors back to a supplier matters more than how a clean golden record looks.
Then test a change that crosses systems. A DC remeasures a case and enters a new height. Watch whether the MDM keeps both values, flags the conflict, notifies the owner, and pushes the decision to ERP and WMS once someone approves it.
Build one style with 30 variants and four packaging levels, then change a shared attribute. Count the clicks.
List the last ten data model changes your team asked for, such as a new attribute for a category or a new marketplace export. Ask the vendor which of them are configuration and which are development work. Development work turns every future change into a project with its own budget and its own queue.
Measure a baseline before the project starts. Useful numbers are the days from supplier submission to sellable item, the rejection rate per supplier, the number of items where ERP and WMS disagree on case dimensions or weight, and the share of items missing mandatory compliance fields. Without these numbers, nobody can show later that the project worked.