Item master vs product master: one row, or one thing you sell?
Item master = the transactional item record. Product master = the commercial product record. Last reviewed August 2026.
The short answer
An item master is the ERP's list of transactable things: one row per item you buy, stock, pick and invoice, keyed on a part number and carrying cost, price, unit of measure, stock and status. A product master is the commercial view: one record per thing a buyer perceives as a product, which may span several item-master rows — pack sizes, colours, lengths, branch-specific part numbers — and which carries the attributes, media and copy needed to sell it. Confusing the two is the root cause of the most common catalog defect in distribution: the same product appearing five times online because it has five item-master rows, splitting reviews and search relevance, and making faceted navigation useless. In SAP terms the parallel is the material master and the product record; in NetSuite it is inventory items against the item group or matrix parent.
This one is not a software comparison but a modelling distinction — one that decides how your catalog behaves, and one usually made by accident, years before anyone notices.
The symptom is always the same: search results full of near-identical entries.
Item master vs Product master, line by line
| Item master | Product master | |
|---|---|---|
| Lives in | ERP or WMS | PIM, or the commerce platform's product model |
| Granularity | One row per transactable unit | One record per thing a buyer perceives as a product |
| Keyed on | Internal part number | Manufacturer part number, GTIN, or a model family |
| Holds | Cost, price, UOM, stock, vendor, lead time, tax, status | Attributes, specs, taxonomy, media, copy, variant relationships |
| Variants | Separate rows with no modelled relationship | Explicit parent-child structure with shared and differing attributes |
| Duplicates are | Normal — several rows can be one product legitimately | A defect — they split search relevance and reviews |
| Owned by | Operations, purchasing, finance | Merchandising and ecommerce |
Where they actually overlap
They describe the same physical goods and answer different questions, so the overlap is total in subject and near-zero in structure.
The failure is publishing the item master directly to the storefront. The fastest path to a live catalog, and it produces a specific, recognisable set of symptoms: the same product listed once per pack size, facets that return one result each, review counts split six ways, and a site search that ranks a case of 100 above the single unit for no discernible reason.
The fix is a grouping layer — a product record that references its item-master rows and carries the shared attributes, with the differing ones modelled as variant axes. Doing that requires deciding, per category, what makes two items the same product. That decision is merchandising's, and it is the part that cannot be automated away, though the matching that follows largely can.
Which one you need, by situation
- The same product appears several times in search results
- You are publishing the item master. Add a grouping layer.
- Reviews and ratings are split across near-identical listings
- Same cause. Consolidation will lift both conversion and rankings.
- Facets return one product each
- Variants are modelled as separate products rather than as axes.
- Purchasing and ecommerce disagree about what a SKU is
- They are both right. Write the two definitions down and stop arguing about the word.
- Migrating to a PIM
- Decide grouping rules before loading, or you will migrate the duplicates and rebuild later.
Do you need both?
Yes, always, and the relationship should be explicit: item-master rows are children of a product record, not competitors to it. The ERP keeps transacting on items; the storefront presents products.
The integration detail that matters most is which identifier joins them. Manufacturer part number plus brand is usually the most stable key across systems; internal part numbers are stable inside one ERP and worthless across a merger.
The job neither system does
Building the grouping layer means deciding which item rows are the same product, which is a matching problem across inconsistent descriptions, competing part-number conventions, and missing identifiers.
Much of what we do before any enrichment starts is exactly that: resolving items to products, recovering manufacturer part numbers and GTINs, and modelling the variant axes per category — because enriching a catalog that still has five records for one product just produces five enriched duplicates.
Frequently asked questions
Is a SKU an item or a product?
In practice SKU means the transactable unit — the item. Buyers use it loosely for the product. The ambiguity is exactly why the two terms above are worth keeping separate in internal documents.
What is the SAP equivalent?
The material master is the transactional record. Newer product-master and MDG-based product records sit above it for commercial and cross-system use — the same split under different names.
How does NetSuite model this?
Inventory items are the transactional rows; item groups, kits and matrix items provide grouping. Matrix items come closest to a product-with-variants model, and many implementations never adopt them, which is where duplicate listings come from.
Should the product master live in the PIM or the ERP?
The PIM, or the commerce platform if you have no PIM. ERPs model transactable items well and variant hierarchies badly, and adding that structure to an ERP is expensive change control for something that mainly serves merchandising.
How do we decide what counts as one product?
Per category, by buyer perception: if a buyer would expect to choose between them on one page, they are variants of one product. Length, colour and pack size are usually variants; a different rating, material or model number usually is not.