Product master data

What product master data is

Product master data is every attribute of an item that holds permanently and does not depend on the individual sale. It covers the identifier, the name, dimensions, weight, material, manufacturer, tax rate, base price and customs tariff number. That separates it from movement data such as stock, orders and revenue, which change daily.

The separation matters in practice. An error in the master record affects every transaction that touches that item: every invoice, every shipment, every customs declaration and every report. An error in a single order affects only that order.

Which fields belong

• Identification: Internal item number, manufacturer number, GTIN, plus the link to category and supplier.
• Logistics: Weight, dimensions, packaging unit, shelf life, hazardous goods labelling.
• Commercial: Purchase price, tax rate, customs tariff number, country of origin.
• Content: Title, description, images, properties used for filters, plus information required by product safety rules.
• Variant: The options by which the item differs in size, colour, length or version.

Why maintenance is underestimated

Master data is invisible as long as it is correct. That is why it rarely gets planned as a work area of its own, and that is exactly where the typical consequences come from. Without weight, shipping is calculated wrongly and the shop pays the difference. Without a customs tariff number, the shipment sits at the border. Without maintained variant options, the customer finds no matching size and the filter shows values with no hits.

A second reason is duplication. The same attributes often live in the ERP, in the shop, on the marketplace and in the price comparison feed, each slightly different. If the source is not defined, the same information is maintained several times and still ends up wrong.

How maintenance gets organised

The first step is a single leading source. All attributes are held in one place and distributed from there, not captured anew in every system. The second step is a set of mandatory fields. For your own purposes it must be clear which fields are required before publication and which may be added later. The third step is a check before publication that detects empty mandatory fields and obvious contradictions.

A change log is useful as well, showing who changed which field and when. Without it, tracking down the cause of a wrong invoice takes longer than the correction itself. Experience shows maintenance succeeds when it is kept small: few mandatory fields, one source, one check. A complete data model without enforcement stays on paper.