Product Variant
A product variant is a specific, sellable version of a base item that differs from other variants of the same product only in certain attributes such as size, colour or material. Each variant has its own article number, its own stock and often its own price.
A product variant is a specific, sellable version of a superordinate base item that differs from the other variants of the same product only in one or more defined attributes – for example size, colour, material or quantity. The "Basic" T-shirt, for instance, exists as the variant "Red / M", "Red / L" or "Blue / S". All of these versions logically belong to the same product, yet each one is its own uniquely identifiable article with its own article number, its own stock and, as a rule, its own barcode label.
Variants solve a practical problem in retail: customers perceive a product as a single unit and only choose the matching version at the point of purchase. Ordering, warehousing and accounting, on the other hand, have to track each individual version separately, because stock, availability and sometimes price differ per variant. The product variant is therefore the bridge between a marketing-friendly product presentation and precise, logistically reliable article management in the ERP system.
At a glance
- Sellable version of a base item, distinguished by attributes such as size, colour or material
- Each variant has its own SKU/article number, its own stock and often its own GTIN/EAN
- The base item (parent product) bundles shared data; the variants (children) carry the differing attributes
- Central to fashion, food, tech and any retail with size/colour dimensions
- Foundation for accurate stock management, shop selection fields and cross-channel availability
How a product variant is structured
Technically, the variant concept is based on a parent-child relationship. A base item – also called the parent article, master or configurator – bundles all the details that are identical for every version: product name, description, brand, product group and often the tax rate as well. Under this base item hang the individual variants, each of which carries only the differing attribute values and the variant-specific data such as stock, price and barcode.
The attributes by which variants differ are managed as dimensions or attributes. A clothing article typically has the dimensions "size" and "colour"; the combination of all attribute values yields the specific variant. Two dimensions with several values each quickly produce a large number of variants – four sizes times five colours already result in 20 individual articles, all of which have to be planned separately.
Attributes, dimensions and the variant matrix
Many ERP and shop systems generate variants via a so-called variant matrix: you define the dimensions and their possible values, and the system automatically builds all valid combinations from them. Not every combination has to actually exist – some size-colour combinations are never produced and can be deactivated in the matrix. This produces exactly the assortment that is genuinely available, in a controlled way.
A dedicated SKU and GTIN per variant
Each variant needs a unique article number or SKU, because only then can stock, ordering and shipping be assigned to the correct version. In retail, each variant additionally gets its own GTIN/EAN: the barcode on the label does not identify the product in general, but the individual sellable unit – that is, exactly "Red / M" and not just "T-shirt Basic".
Why product variants matter
Without a clean variant concept, every version would have to be created as a fully independent article – with redundantly maintained descriptions, images and product groups. This is error-prone and barely manageable in terms of assortment maintenance effort. Variants, by contrast, cleanly separate the shared product data, which is maintained only once, from the few differing attributes per version. A change to the product description takes effect immediately across all variants.
For sales, variants are the prerequisite for displaying a single product page with selection fields for size and colour in the online shop, instead of listing dozens of separate products. At the same time, stock management stays exact: if "Red / M" is sold out while "Red / L" is still available, the system has to provide exactly this information across all channels. Variants therefore combine an attractive customer view with precise, accounting-grade article logic.
Product variants in the ERP system
In the ERP system, the variant is the actual stock article: at its level, receipts and issues are posted, stock is managed, reorder points are monitored and purchase proposals are generated. The base item, by contrast, mainly serves to bundle and present. An order, a delivery note or an invoice always references the specific variant, because only it is physically tangible and deliverable.
The variant structure is closely interlinked with the article master. Shared attributes sit on the parent article, variant-specific fields – stock, price deviations, weight, barcode – on the children. In the combination of ERP and shop, a PIM often takes over the maintenance-intensive marketing data and media, while the ERP retains commercial and logistical authority over variants, stock and prices. Via an API, variants together with their availabilities are distributed to shop systems and marketplaces, so that the selection fields online correspond exactly to the deliverable combinations.
In procurement, the variant concept has a direct impact: material planning and purchasing work at variant level, because replenishment for "Red / M" has to be calculated independently of "Blue / L". Analyses, in turn, can be run both per variant and aggregated across the base item – for example to identify which size or colour of a product sells best.
Distinction: variant, bill of materials and bundle
The product variant is easily confused with other product structures that the ERP treats differently. What matters for the distinction is whether it concerns the same goods in a slight modification or a composition of several independent articles.
Variant vs. bill of materials
A variant is one and the same product in a different version – red instead of blue, M instead of L. A bill of materials, by contrast, describes which individual components an article is assembled or manufactured from. A set consisting of a shirt, trousers and a belt is not a variant, but a bundle made up of several articles with its own bill of materials. Variants share a base item; bill-of-materials positions are independent articles.
Variant vs. independent article
Not every product change justifies a variant. As a rule of thumb: only when customers perceive the versions as the same product in a different choice and the shared data is largely identical does a variant make sense. If two products differ significantly in function, target group or description, they should be created as independent articles – even if they look similar on the outside.
Challenges and DACH specifics
The biggest practical risk of variants is combinatorial explosion: anyone who combines many dimensions with many values quickly creates thousands of individual articles, all of which need to be planned, imaged and maintained. A well-thought-out variant model limits the dimensions to the purchase-relevant minimum and deactivates combinations that are not produced. Equally important is a consistent numbering logic that makes the affiliation of variants to the base item recognisable without jeopardising the uniqueness of the SKU.
In DACH retail, concrete requirements are added. For sales via brick-and-mortar retail and via marketplaces, each variant needs its own GTIN; marketplaces such as Amazon require variant-precise labelling. Price information is subject to the Price Indication Ordinance (Preisangabenverordnung) – for food and many other goods, the unit price per unit of measure must be shown, which makes variant-specific fill quantities relevant. Because variant-related prices and stock feed into tax-relevant documents, changes should be traceably documented in the spirit of the GoBD. In a data migration, the correct transfer of the parent-child structure is regularly tricky, because the old and new systems model variants differently.
Example
Example: a fashion retailer bundles 24 individual articles into one product
A mid-sized fashion retailer sells a basic T-shirt in four sizes (S, M, L, XL) and six colours. Created as individual, mutually independent articles, this would amount to 24 separate records, each with its own description, its own images and its own product group – in the shop, 24 individual product pages that no one recognises as belonging together.
With a variant model, the retailer instead creates a base item "T-shirt Basic" with the dimensions size and colour. From this, the ERP generates the 24 combinations via the variant matrix, each with its own SKU, its own GTIN and its own stock. In the online shop, a single product page appears with two selection fields; if "Black / M" is sold out, exactly this combination is greyed out while the rest remains orderable. Purchasing replenishes per variant, and the analysis shows that size M and the colour black sell best – the basis for the next reorder.
Frequently asked questions
Related services
Questions about Product Variant in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.