The Item Master Problem: Why Every Manufacturing Merger Loses a Month Before Anyone Notices
Two manufacturers merge. The ERP consolidation plan is built, the timelines are set, and the first major delay arrives before a single line of migration code runs. The item master contains forty thousand records from each company, and they describe the same physical parts in completely different ways. Nobody budgeted three months for that. Almost nobody does.
The item master creates more migration issues than any other data set in an ERP consolidation. That sentence appears, nearly verbatim, in most serious ERP migration guides. It appears there because it keeps being true, merger after merger, industry after industry, and the teams who read it still underestimate it because the problem looks like a data cleaning task until it is not. By the time it stops looking like a data cleaning task, three weeks have disappeared and the go-live date is theoretical.
The item master problem in a manufacturing merger is not that both companies have bad data. Often they each have good data, maintained diligently inside their own systems. The problem is that two independently maintained, internally consistent item masters describe the same physical world in different languages. A M8 x 1.25 x 20mm hex cap screw in legacy A's system is a Fastener, Hex Cap, M8-1.25, 20mm, Zinc in legacy B's. They are the same part. Neither record is wrong. And when the consolidated system needs to know how many of them you have across both plants, it cannot answer the question.
Why This Is Always Underestimated
There are three reasons the item master problem lands late in almost every merger integration plan, and they compound each other.
The first is that the problem is invisible at the level where the integration is planned. Executives see two ERP systems that need to become one. The item master is an implementation detail. Nobody puts "reconcile forty thousand part records" in a board-level integration slide because it does not fit in a box on a slide. By the time the implementation team gets close enough to see it, the timeline is already set.
The second reason is that the volume is genuinely surprising. Five to fifteen percent duplicate rates sound manageable. At forty thousand records, five percent is two thousand items that need a human decision about which record wins, what to do with open purchase orders that reference the losing record, and how to handle the inventory positions that sit under each one. Two thousand decisions, each with downstream consequences. That is not a data cleaning task. That is a project.
The migration does not clean the data. An ERP data migration transfers whatever already exists. Duplicate customers, inconsistent item records, outdated bills of material, inaccurate inventory balances: these all move into the new system along with everything else. The assumption that migration is also a cleanup event is one of the most expensive assumptions in manufacturing ERP work.
The third reason is that item master remediation is a business decision, not an IT task. IT can identify the duplicates. IT can surface the mismatches. IT cannot decide which part number is canonical, which open purchase orders get re-pointed, which vendor is preferred for the consolidated category, or whether the two product lines that share a component are going to continue sharing it after the merger. Those decisions belong to operations, procurement, and engineering. And those teams are already consumed by the merger in a dozen other ways.
What Actually Breaks When Item Masters Conflict
The effects are not abstract. They show up in specific operational failures within the first ninety days after go-live, which is also the period when the integration team has already partially disbanded and nobody wants to hear that the data was wrong.
When duplicate part records survive into the consolidated system, inventory is split between them. Legacy A's stock of the M8 screw sits under one record; legacy B's stock sits under another. The purchasing system sees a shortage under one record and triggers a replenishment order. The warehouse has enough stock. It just lives under a different number.
This pattern inflates apparent inventory levels in aggregate while creating operational shortages at the line level. The plant manager sees the discrepancy in the count. The system shows no shortage. The line stops anyway. Finding the root cause takes longer than it should because it requires tracing a physical part back through two separate item records in a system that was supposed to be consolidated.
Bills of materials from both legacy entities reference their own part numbers. After consolidation, a product from legacy A's line that shared a component with a legacy B product may now have a BOM that references a part number that no longer exists, was merged into a different number, or points at a record with an incorrect unit of measure inherited from the other system.
BOM errors of this kind are not immediately visible. They surface when a production order is placed. The first indication is often a material reservation that fails, or a picking list that requests a quantity in the wrong unit. By then, the product is scheduled and the line is waiting.
The Classification Problem Nobody Talks About
Part numbering conflicts get most of the attention. The classification problem is harder and less discussed.
Classification taxonomies are the structure that makes the item master useful for procurement, spend analysis, and inventory management. One acquired company uses eCl@ss. Another uses UNSPSC. A third uses an internally developed category hierarchy that nobody outside the company has ever seen. Without harmonization, spend analysis and sourcing across the combined entity are effectively impossible, because you cannot aggregate spend by category when the categories mean different things in each legacy system.
The MRO problem is the classification problem at its most acute. Maintenance, repair, and operations items are the category where duplicate records accumulate fastest and cause the most operational disruption when missed. An undetected duplicate MRO record means two purchase orders for the same item going to two suppliers, two receiving events for parts that are physically the same thing, and inventory that is impossible to rationalize without a manual audit. In a merger of two manufacturing plants with a combined MRO catalog of twenty thousand items, this is not an edge case. It is the baseline condition before any harmonization work happens.
The practical challenge with classification harmonization is that it requires subject-matter expertise in procurement, engineering, and operations working together on the same problem, at the same time, during a period when all three functions are occupied with merger integration in other dimensions. The people who know what a part is used for, who buys it, and which suppliers are qualified to provide it are not typically the people running the ERP migration. Getting them into the same room and keeping them there long enough to make four thousand classification decisions is an organizational problem that no software tool resolves on its own.
The Sequence That Reduces the Damage
The item master problem cannot be fully avoided in a manufacturing merger. Two independently maintained systems will always have divergence. The question is how much of the remediation happens before go-live and how much happens after, and the cost ratio between those two is roughly four to one in favor of doing it before.
Extract and profile before the migration plan is written
Pull a full export of both item masters in the first two weeks after close. Run a basic profile: record count by category, completeness rates by field, duplication rate using fuzzy matching on description and manufacturer part number. This profile is the factual basis for a realistic timeline. Without it, the timeline is fiction.
Assign business-side ownership by domain, not by system
Finance owns the chart of accounts and vendor masters. Operations owns material masters. Engineering owns BOMs and specifications. Procurement owns MRO and supplier records. These are business decisions that require business owners. Assigning the work to IT ensures that the decisions that require operational judgment will wait until IT escalates them, which adds weeks to every cycle.
Clean each source file individually before merging
Merging two dirty datasets into one large dirty dataset compounds the matching problem. Deduplicate and standardize each legacy system's export independently before running any cross-system matching. A cleaned file from legacy A matched against a cleaned file from legacy B produces reliable results. Two uncleaned files matched against each other produce noise.
Resolve open transactions before the item number decision
For every item record with a deduplication decision, check open purchase orders, open production orders, and inventory positions that reference it. The decision about which record wins is not just a master data decision. It determines which transactions need to be re-pointed and at what cost. That cost has to be visible before the decision is made.
Establish a governance process before go-live
The item master will continue to drift after go-live because both legacy teams will continue creating records using the conventions they learned before the merger. A governance process that catches new records at creation, validates against the canonical taxonomy, and routes exceptions to a named owner is the difference between a one-time cleanup and a sustained data quality posture.
Where AI Fits in Item Master Reconciliation
AI-assisted matching is genuinely useful for item master deduplication, with a realistic scope. The problem it solves well is identification: finding records that describe the same physical part under different descriptions, manufacturer part numbers, and internal codes. Matching algorithms that compare across multiple fields simultaneously and score similarity against a database of original manufacturer data can surface duplicates that manual review would miss, particularly in large MRO catalogs where the description field is inconsistent and the manufacturer part number is sometimes missing.
The problem AI does not solve is the decision that comes after identification. Which record is canonical? What happens to the open orders? Which supplier is preferred? Those are operational and commercial decisions that require the people who understand the business. AI identification accelerates the front end of the process. It does not compress the back end.
| Task | AI Can Do | Requires Human Decision |
|---|---|---|
| Duplicate identification | Match records across description, MPN, category, and unit of measure simultaneously | Confirm match when similarity score is below threshold; resolve ambiguous cases |
| Classification mapping | Suggest mapping from legacy taxonomy to canonical taxonomy based on description | Validate suggested mapping; resolve items that span categories |
| Obsolescence flagging | Flag records with no transactions in 24+ months and no open orders | Decide whether to retire, archive, or keep each flagged record |
| BOM impact analysis | Identify all BOMs that reference a given item number | Decide which BOMs to update, which to hold, and in what sequence |
| Supplier consolidation | Identify items with multiple qualified suppliers across both legacy entities | Decide which supplier is preferred in the consolidated sourcing strategy |
Starting an ERP Consolidation in Manufacturing?
GrayCyan works with manufacturing operations teams on item master remediation sequencing, data governance design, and the ERP integration decisions that determine whether a merger consolidation holds together at the operational level.
Talk to GrayCyan