Product and item
The thing you sell or consume, and its variants, packs and equivalents across sites and systems.
01 Why it matters
What depends on getting this right
Margin, availability, price variance and standardisation are all per item. When each site carries its own code for the same thing, none of those comparisons exist — which is the single most common finding in a multi-site group.
02 Where it lives
Every system holds a different version
None of these is wrong. Each was built for a purpose and records the part of the entity that purpose needed, which is exactly why resolution is required rather than optional.
| System | What it holds of this entity |
|---|---|
| ERP material or article master | the commercial and financial definition, cost and price |
| PLM | the engineering specification and revision history |
| WMS | the physical handling unit, which is often not the selling unit |
| POS or e-commerce | the selling item, with local buttons and variants |
| Procurement | the supplier part number, which differs from yours |
03 Match keys
What actually matches, and what only looks like it does
| Key | How well it works |
|---|---|
| GTIN, EAN or UPC | Excellent where it exists, absent for services and internal items. |
| Manufacturer part number | Strong for engineered goods, inconsistent in formatting. |
| Normalised description plus attributes | The fallback, and the reason attribute extraction matters so much here. |
| Supplier part number plus supplier | Resolves purchased items when internal codes diverge. |
04 Survivorship
When two records disagree, which value wins
Survivorship is a business decision, not a technical default. These rules should be agreed with the people who own the data and then applied consistently, because changing them later restates history.
Specification from PLM, commercial attributes from ERP
Each system is authoritative for a different half of the record.
Unit of measure conversions must be explicit
Cases, pallets and eaches cannot be survived; they must be converted with a stated factor.
Retain local codes as aliases
Otherwise historical transactions stop matching the standardised item.
Status wins conservatively
A blocked or obsolete flag from any authoritative source should survive over active.
05 The cost of not doing it
What stays broken while it is unresolved
Four prices for one item
Sites cannot compare or negotiate, and procurement leverage is invisible.
Category reporting silently incomplete
Local items outside the master drop out of category totals without any error.
Stock duplicated across the estate
The same part held under three codes at three sites reads as three different shortages.
Recipe and BOM costing wrong
If the consumed item is not the mastered item, theoretical cost never matches actual.
06 Metrics that divide by it
The numbers this entity carries
07 Questions
Frequently asked
Where should the item master live?
In one governed place that publishes to the systems that need it, with local codes retained as aliases. Trying to make every system adopt one code natively is what makes these programmes fail.
How do we handle equivalents and substitutes?
As an explicit relationship rather than a merge. Two items that can substitute are not the same item, and merging them destroys the ability to analyse the substitution.
See the duplicates in your own data
We will resolve one entity on your systems, live, and show what the duplicates are costing.