After a review of the new collection, one shirt was left hanging in the office. Everything else had already been packed up and carried away, but this one was still there, complete with a paper tag, care labels, and a barcode. It looked like it belonged to the collection, yet no one nearby knew which style it was or who had brought it in.
I wanted to know where it came from. The tag had an EAN, so I did the obvious thing—at least the obvious thing for someone who works with data—and looked it up in our systems. If the shirt was really part of the collection, it had to have left a record somewhere. Inside fashion, the storefront is luxury and the daily work is still broken integrations; this was one of those days.
It hadn’t.
I checked the digits again. I tried adding a leading zero. I searched for it as both a string and a number. Then I checked active products, archived records, and the latest data loaded from SAP.
Still nothing.
At that point, mild curiosity turned into a small investigation. The shirt was hanging in the office of a fashion company, looked like a piece from the new collection, and had perfectly normal retail labeling. If it was ours, some trace of it should have existed in at least one system.
The problem was the assumption behind my search. I was treating the EAN as if it were the shirt’s one true number—a permanent identifier that could lead me through the entire company.
Fashion products do not work that way.
A product picks up new identities at almost every stage of its life. Some last for years. Others change with the season, market, platform, warehouse, or sales channel.
To find one shirt, I first had to understand how many different objects were hiding behind the word product.
The first ID exists before the shirt does
A fashion product usually begins not as a physical item, but as a development record.
A designer or product developer creates a style in a product lifecycle management system such as Centric PLM, PTC FlexPLM, or another platform used to manage product development.
An integration extract might look something like this:
STYLE_OID STYLE_NO SEASON_CODE BRAND_CODE CATEGORY_CODE STATUS
847291 SH-04218 FW27 BRAND_A SHIRTS APPROVEDAt this point, the shirt may not physically exist. There may be no inventory, no sales history, no barcode, and not even a finalized size range.
But it already has two identifiers.
STYLEOID is an internal system key for the PLM object. STYLENO is the business-facing style number used by people working with the collection.
They are not interchangeable.
The business number may follow brand, season, or category conventions. In some organizations, it can be changed. The internal object ID is usually more stable, but it only means something inside that particular PLM environment.
The product already has two numbers before anyone has manufactured a single shirt.
Then colors are added:
COLORWAY_OID STYLE_OID COLOR_CODE SUPPLIER_COLOR_CODE STATUS
920114 847291 BLK 900 APPROVED
920115 847291 IVR 102 APPROVED
920116 847291 BLU 417 CANCELEDNow STYLE_OID is no longer enough to identify a specific variation.
The black and ivory shirts belong to the same style, but they are different colorways. Each receives its own COLORWAY_OID.
Once the size range is created, another level appears:
SKU_OID COLORWAY_OID SIZE_CODE SIZE_SCALE ACTIVE_FLAG
7710011 920114 XS US_WOMENS Y
7710012 920114 S US_WOMENS Y
7710013 920114 M US_WOMENS Y
7710014 920114 L US_WOMENS YOne shirt design now has an internal style ID, a business style number, separate colorway IDs, and separate IDs for each color-and-size combination.
This is not random duplication. Each identifier exists because the previous one describes a different level of the product.
STYLE_OID answers: Which design is this?
COLORWAY_OID answers: Which design and which color?
SKU_OID answers: Which color and which size?
You can call all three of them product, but that only hides the difference in the column names. The difference still exists in the data.
SAP gives the product a new identity
Once the collection is approved, the product moves into ERP.
In SAP, it becomes a material and receives a MATNR.
A mapping extract might look like this:
PLM_STYLE_OID PLM_COLORWAY_OID PLM_SKU_OID SAP_MATNR
847291 920114 7710011 000000000018472931
847291 920114 7710012 000000000018472932
847291 920114 7710013 000000000018472933
847291 920114 7710014 000000000018472934Why create MATNR if PLMSKUOID already exists?
Because PLM and SAP manage different lives of the same product.
PLM manages product development: design, fabric, color decisions, samples, size ranges, approvals, and revisions.
SAP manages operational reality: purchasing, inventory, deliveries, sales, costing, and financial transactions. Follow one coat through the rest of that stack—sourcing, QMS, PIM, WMS, OMS—and the split stops looking like a quirk of two databases.
A SAP material may need to remain active long after the original PLM record has been changed, archived, or carried into another season.
PLMSKUOID identifies a development object.
MATNR identifies an operational material.
The relationship is not always one-to-one, either.
One company may create a separate material for every size:
PLM_SKU_OID SIZE_CODE SAP_MATNR
7710011 XS 18472931
7710012 S 18472932
7710013 M 18472933
7710014 L 18472934Another may create different materials for the European and US markets:
PLM_SKU_OID MARKET_CODE SAP_MATNR
7710013 EU 18472933
7710013 US 28472933A new material may also be created when the same design is carried into a new season:
BASE_STYLE_OID SEASON_CODE SAP_MATNR
847291 FW27 18472933
847291 FW28 19488106To a designer, it may still be the same basic black shirt.
To SAP, these are separate operational objects with their own documents, inventory, status, and history.
One SAP material does not fit into one SAP table
Even inside SAP, the product does not live in a single row.
Core material data is distributed across multiple tables, each describing the material in a different context.
At the general material level, it appears in MARA:
MANDT MATNR MTART MATKL MEINS SPART
100 000000000018472933 FERT 00003120 EA 10Here, MATNR is the main material identifier.
But the product description is stored separately in MAKT:
MANDT MATNR SPRAS MAKTX
100 000000000018472933 E WOMENS SHIRT BLACK M
100 000000000018472933 D DAMENHEMD SCHWARZ MThe same MATNR has multiple rows because the description depends on language.
Plant-level data appears in MARC:
MANDT MATNR WERKS DISMM DISPO BESKZ MMSTA
100 000000000018472933 NL01 PD 101 F
100 000000000018472933 US01 PD 205 F
100 000000000018472933 DE01 ND 101 F 01At this level, MATNR alone no longer identifies a row. The actual key includes the material and the plant.
Sales data lives in MVKE:
MANDT MATNR VKORG VTWEG PRODH VMSTA DWERK
100 000000000018472933 1000 10 001001002003004
100 000000000018472933 1000 20 001001002003004
100 000000000018472933 2000 10 001001002003004 01 US01Here, the material exists in the context of a sales organization and distribution channel.
The same MATNR can be active for retail, blocked for wholesale, and configured differently for e-commerce.
It is still one SAP material, but it already has several operational versions.
The EAN is not the master ID
I started with the EAN because it was physically printed on the tag.
That made it feel authoritative. If a number could be scanned at a warehouse or register, surely it had to point directly to the product.
But a barcode is not necessarily the product’s master identity.
Additional EANs or GTINs may appear in SAP like this:
MANDT MATNR MEINH EAN11 EANTP HPEAN
100 000000000018472933 EA 8710000000011 HE X
100 000000000018472933 CS 8710000000097 HEOne material can have multiple barcodes—for example, one for an individual unit and another for a case.
The number may depend on the market, packaging level, or unit of measure. An old EAN may remain in history after a new one has been introduced. A sample may receive a barcode before it has been fully integrated into the company’s primary systems.
More importantly, the EAN appears relatively late in the product lifecycle.
At the style, colorway, or early sample stage, it may not exist at all.
A barcode is good at answering: What is this particular system scanning right now?
It is not always good at answering: Which original product design does this physical item belong to?
The missing EAN did not prove that the shirt was not ours. It could have existed only in a supplier system. It could have belonged to a sample, another market, or a record that had not yet made it through the integration pipeline.
So the investigation continued.
The warehouse creates its own item
When a material reaches a warehouse management system, the WMS may preserve the SAP material number and still generate its own identifier.
ITEM_ID OWNER_CODE FACILITY_CODE SAP_CLIENT SAP_MATNR UOM ACTIVE_FLAG
ITM394521 EU01 WH-NL-01 100 18472933 EA YWhy create ITEM_ID when MATNR already exists?
Because a WMS may serve multiple ERP systems, inventory owners, legal entities, and fulfillment operations.
A MATNR may only be unique within a particular SAP client. The same number arriving from two different ERP environments does not necessarily identify the same product.
The warehouse also has its own concerns: owner, facility, unit of measure, lot handling, serialization, storage rules, and fulfillment logic.
The WMS is not simply copying the SAP identifier. It is creating a warehouse identity for the product.
By now, the shirt may have a STYLEOID, STYLENO, COLORWAYOID, SKUOID, MATNR, one or more EANs, and an ITEM_ID.
And we still have not reached the online store.
E-commerce changes what “product” means again
In e-commerce, several SAP materials often need to be grouped back into one customer-facing product page.
A commerce extract might look like this:
PRODUCT_ID VARIANT_ID SAP_MATNR COLOR_CODE SIZE_CODE ONLINE_STATUS
P48291 V994519 18472931 BLK XS ACTIVE
P48291 V994520 18472932 BLK S ACTIVE
P48291 V994521 18472933 BLK M ACTIVE
P48291 V994522 18472934 BLK L ACTIVEHere, PRODUCTID identifies the overall product page. VARIANTID identifies a specific color-and-size option.
The direction has reversed.
PLM started with one style and split it into colorways and SKUs. SAP turned those SKUs into operational materials. E-commerce groups several of those materials back together under one PRODUCT_ID so a shopper sees one page with a size selector.
One commerce product can represent several SAP materials:
1 PRODUCT_ID
→ N VARIANT_ID
→ N SAP MATNR
Searching by PRODUCT_ID alone would not necessarily identify the shirt on the hanger. The ID may be too broad because it covers every size and sometimes more than one color.
A marketplace identifies the listing, not the shirt
Independent brands feel this pressure even earlier: small fashion systems still have to keep product data, channels, and stock coherent without an enterprise master-data team.
Once the product is published to a marketplace, another set of IDs appears:
MARKETPLACE SELLER_SKU LISTING_ID OFFER_ID ECOM_VARIANT_ID STATUS
ZALANDO SH04218-BLK-M ZL881273 OF712004 V994521 ACTIVE
AMAZON SH04218-BLK-M B0D31X82K7 A2F99104 V994521 ACTIVEA LISTING_ID does not necessarily identify the product in the same way PLM or SAP does.
It may identify a publication in a particular channel’s catalog. An OFFERID may represent one seller’s commercial offer. A SELLERSKU may be created by the brand or integration platform solely for exchanging data with that marketplace.
One commerce variant can have multiple listings and offers.
Delete a listing and create it again, and the same physical SKU may receive a new LISTING_ID.
Not every ID represents a durable product identity. Some represent a temporary state of the product in a specific sales channel.
The data warehouse creates an ID for the record itself
When product data reaches the analytical warehouse, it receives another key: PRODUCT_KEY.
A dimension might contain rows like these:
PRODUCT_KEY SAP_MATNR PLM_SKU_OID ECOM_VARIANT_ID PRODUCT_CLASS VALID_FROM VALID_TO IS_CURRENT
4189201 18472933 7710013 V994521 SHIRTS 2026-08-01 2027-01-14 N
5028417 18472933 7710013 V994521 WOVEN_TOPS 2027-01-15 NULL YThe source identifiers are identical in both rows.
The PRODUCT_KEY is not.
That is because the warehouse is identifying not only the product, but a historical version of the analytical record.
If the category, division, reporting hierarchy, or merchandising group changes, a Slowly Changing Dimension Type 2 process may close the old row and create a new one.
One MATNR can therefore receive multiple PRODUCT_KEY values over time:
SAP MATNR
→ N historical PRODUCT_KEY
The key is useful for connecting facts to the correct historical version of the product dimension.
But it is not a universal product ID. PLM, SAP, the warehouse, and the online store know nothing about it.
Rebuild the dimension, and the surrogate keys may even change. Sending PRODUCT_KEY back into operational systems as a business identifier would be a particularly creative way to cause problems.
The warehouse does not eliminate the existing IDs.
It adds another one.
Trying to assemble the shirt again
By this point, the shirt could exist in the data as a style, colorway, SKU, SAP material, barcode, warehouse item, commerce variant, and marketplace listing.
The issue was not that any of those identifiers were irrational. Each made perfect sense inside the system that created it.
The difficulty appeared when someone tried to follow the chain backward.
Start with the EAN and find the MATNR. Use the MATNR to locate the PLM SKU. From the SKU, move back to the colorway and style. Then check the warehouse, the online store, the marketplace, and the product’s history.
To make this possible, companies build mapping tables, reference models, and canonical product layers that connect source identifiers.
Sometimes the result looks almost reassuring:
CANONICAL_PRODUCT_ID SOURCE_SYSTEM IDENTIFIER_TYPE IDENTIFIER_VALUE
CP007710013 PLM STYLE_OID 847291
CP007710013 PLM SKU_OID 7710013
CP007710013 SAP MATNR 18472933
CP007710013 SAP EAN 8710000000011
CP007710013 WMS ITEM_ID ITM394521
CP007710013 ECOM VARIANT_ID V994521Now all the identifiers appear to point back to one object.
But achieving that required creating CANONICALPRODUCTID—another number that did not exist before.
It does not replace MATNR, because SAP still operates with its own materials. It does not replace STYLE_OID, because PLM still manages the design. It does not replace the EAN printed on the tag or the variant ID used by the website.
This creates a very typical data architecture outcome: to make sense of ten product identifiers, the company creates an eleventh.
Even then, one question remains.
What exactly does the canonical ID represent? One style? One color? One size? Every seasonal version of the same design?
Reassembling a product is often harder than breaking it apart.
Now AI gets to be confused too
Until recently, an engineer or analyst had to reconstruct the path between STYLEOID, MATNR, EAN, and PRODUCTKEY.
Now companies increasingly hand that work to AI agents. The agents search for products, generate SQL, and answer questions about sales, inventory, and assortment.
From the agent’s perspective, the data can look deceptively simple.
Several tables contain columns with product in the name. There are identifiers, descriptions, and relationships between them. The agent can generate a technically valid query, execute it successfully, and return the wrong answer with complete confidence.
“How many shirts do we have?” could mean the number of styles in PLM, color-and-size SKUs in SAP, active product pages in e-commerce, or live marketplace listings.
A person will usually ask what the speaker means.
An AI agent is more likely to select one available interpretation and continue as if the ambiguity never existed.
For a question about designs, count styles. For a question about sellable options, count SKUs. For a question about marketplace presence, count listings. All three answers can be correct, even when the numbers are completely different.
That means the old mappings now need another layer of explanation: what each object actually represents and when a particular identifier should be used.
AI does not remove ambiguity from the product model. If the underlying systems do not distinguish clearly between a style, SKU, material, and listing, the agent will simply reproduce the confusion faster—and with better formatting. A day without those assistants makes the same point from the other direction: the work does not vanish when the interface does.
Product identities also change over time
Even a correct relationship between two identifiers does not have to last forever.
A product may receive a new business style number. A different SAP material may be created for another market. The EAN may change after repackaging. A warehouse item may be replaced during a WMS migration. An e-commerce variant may be recreated after the catalog is rebuilt. A marketplace listing may disappear and return under a new ID.
The mapping therefore needs its own history:
SOURCE_SYSTEM IDENTIFIER_TYPE IDENTIFIER_VALUE CANONICAL_PRODUCT_ID VALID_FROM VALID_TO
SAP MATNR 18472933 CP007710013 2026-05-02 NULL
SAP EAN 8710000000011 CP007710013 2026-05-05 2027-02-28
SAP EAN 8710000004415 CP007710013 2027-03-01 NULLKeep only the current identifier, and historical facts may suddenly start resolving to the new one.
Keep only the old identifier, and current integrations may stop finding the product.
Product identity is not a static lookup table.
It is a historical model.
How the investigation ended
By this point, I had several convincing theories for why the EAN on the shirt did not exist in our systems.
Maybe it was a sample that had not reached SAP.
Maybe the supplier had created the barcode and the mapping had failed to load.
Maybe the shirt was intended for another market.
Maybe the material already existed under a replacement barcode.
Maybe it was a carryover style with a new seasonal identity.
I checked PLM extracts, SAP materials, archived EANs, WMS items, and the latest e-commerce data. I found several similar products, but none matched completely. One had a similar color. Another had the same fabric composition. A third had an almost identical description.
By then, I was so deep into the systems that I had failed to do what any normal person would have done first: read every label inside the shirt.
One of them carried the name of a different brand.
The shirt had nothing to do with [REDACTED].
Someone had simply left it in the office after a meeting or fitting.
Several hours of searching did not identify the product. They did, however, explain why identifying a product can take several hours in the first place.
A modern fashion product does not receive one permanent number that follows it from sketch to sale. It becomes a style, colorway, SKU, material, barcode, warehouse item, commerce variant, marketplace listing, and historical analytical record.
Each system creates a new ID because each system is identifying its own version of the object.
The problem is not that one shirt has ten different numbers. The problem begins when the data platform cannot explain what each number means, where it is unique, when it was valid, and how it relates to the others.
But sometimes there is a much simpler reason a product cannot be found anywhere in your systems.
Sometimes it just isn’t your product.
