Manufacturer SKU

Because the vendor issues it, the manufacturer SKU is the one identifier that appears identically on their document and in your catalog, assuming it was stored when the product was created. Matching on it is exact rather than fuzzy, which is why any decent receiving process tries it first.

It fails in three predictable ways. The field is often left empty at product creation, so there is nothing to match against. Vendors reformat it between seasons, adding or dropping a season code. And some vendors populate it with something that is not a per-product identifier at all.

Worth checking rather than assuming: some catalogs carry a brand name in the manufacturer SKU field for every product from that brand. When that happens the field is not an identifier, it is a label, and matching on it will cheerfully unify every product the brand makes into one match. A field that returns hundreds of rows for a single lookup is telling you it holds a category, not a SKU.

These answer different questions. The manufacturer SKU answers what the vendor calls this. Your custom SKU answers what you call it. Keeping both, and keeping them distinct, is what lets a document reconcile against your catalog without either side having to adopt the other's naming.

Collapsing them into one field is a common shortcut and a costly one. If you overwrite the manufacturer SKU with your own convention, every future document from that vendor loses its strongest match signal and falls back to comparing product names, which is fuzzy and fails on exactly the styles that matter most. Storing both costs one field and preserves the only exact identifier the vendor will ever give you.