Which Product Facts Belong at Model, Variant and SKU Level?

Is a model number the same as a SKU?

No. A model number and a SKU can point to the same sellable configuration in one business, but they do different jobs and are not universal synonyms. A manufacturer model number usually identifies a model or design defined by the manufacturer. A SKU is usually an internal stock or commerce identifier used by a business to manage a sellable record.

What each term identifies:

What matters isn't whether two systems happen to reuse the same string but what object the identifier refers to and at what scope that object exists.

That matters for a Digital Product Passport. Under ESPR, the applicable product-specific rules can specify whether passport data refers to a model, batch or item. An ecommerce or retailer SKU does not decide that legal granularity. Keep the relationships explicit, then map the identifiers between systems rather than assuming SKU = model = GTIN = DPP identity.

For integration, use How to Map Product IDs Across ERP, PIM, Ecommerce and a DPP. For regulatory granularity, use Model, Batch or Item Level for a Textile Passport and the applicable product-category requirements.

Why product facts need a scope

A product business can hold hundreds of facts about what it sells:

• brand
• model or style name
• material composition
• size
• colour
• weight
• barcode
• country of manufacture
• supplier
• packaging
• price
• certification
• environmental figures
• care information.

Those facts are not all true at the same level.

A style name may describe an entire range of sellable configurations. A colour is normally specific to one branch of that range. A barcode may identify a particular trade item. A factory may apply to one production run. A serial number may belong to one physical unit.

If these levels are ignored, two common failures appear.

Duplication: the same shared fact is copied into every SKU and then drifts.

False inheritance: a higher-level value is assumed to apply to every child even when one child is different.

So a useful product model needs a scope for each important fact.

The levels in practical business language

These labels are useful, but they are not a global taxonomy.

Product family or range

A broad commercial grouping.

A range may collect related products under one proposition, collection or family name. It can be useful for merchandising and navigation but may be too broad to own detailed technical facts.

Model or style

A model or style usually represents the core product design or specification that several sellable configurations share.

For an apparel example, one shirt style might share:

• style name
• core design
• general care method
• base construction.

Whether composition also belongs here depends on whether every variant shares it.

Variant

A variant is a meaningful configuration of a product.

Common variation dimensions include:

• size
• colour
• material
• finish
• pack size
• market configuration.

Shopify, for example, treats combinations of option values such as size and colour as variants. That is documented Shopify system behaviour, not a universal industry law.

SKU

A stock keeping unit is normally an internal code used to identify and manage stock or a sellable configuration.

An SKU often maps one-to-one to a variant, but it does not have to define a separate semantic layer in the product model.

Shopify explicitly distinguishes SKUs from barcodes and describes SKUs as internal inventory codes. Its documentation recommends unique SKUs for product variants. Other businesses may use a different commercial convention.

So:

Variant describes a configuration. SKU usually identifies a commercial or inventory record for a configuration.

They may align. They are not synonyms.

Batch or lot

A batch or lot groups physical production output for traceability.

It can carry facts such as:

• production date
• manufacturing plant
• raw-material lot
• supplier lot
• inspection result
• temporary process condition.

GS1 defines its batch/lot identifier as information a manufacturer considers relevant for traceability and explicitly notes that batch/lot is not part of the unique identification of the trade item itself.

Individual item

An item-level record belongs to one physical unit.

Typical examples include:

• serial number
• item-specific repair history
• item condition
• warranty event
• individual lifecycle state.

Not every product category needs item-level data.

Fact scope matters more than labels

Two businesses can describe the same physical reality with different software language.

Business A may have:

style -> colour/size variant -> SKU

Business B may have:

model -> SKU

Business C may have:

product family -> model -> option combination -> material code -> warehouse SKU

The names differ. The core governance test does not:

What is the smallest group of products for which this value remains true without exception?

That is the fact's truth scope.

Inheritance

Inheritance lets a lower-level record use a fact maintained at a higher level.

Suppose every version of a shirt shares:

• brand = North Harbour
• care = machine wash 30°C
• core fabric = 100% cotton.

Instead of repeating those values across 24 size/colour SKUs, the model can own them and the variants can inherit them.

That reduces maintenance and drift, but inheritance is only safe when the fact is truly shared.

Inherit because the fact is common, not because copying it is convenient.

If one variant is different, the model needs either a lower-level value or a controlled override.

Overrides

An override is a lower-level value that intentionally replaces an inherited higher-level value.

Example:

Model composition: 100% cotton

Stretch variant composition: 98% cotton / 2% elastane

The stretch variant should not silently inherit the model's composition.

Another example:

Model manufacturing country: Portugal

Batch 2026-09-A: Turkey

If the manufacturing location changed only for that run, the lower truth scope is the batch.

An override needs governance. At minimum, a business should know:

• which higher-level value is being overridden
• the lower scope
• why the exception exists
• evidence supporting it
• when it became effective.

Practical product fact matrix

This is an example framework, not a mandatory placement standard.

Identifiers and levels

Identifiers tell you what record or object you are referring to. They do not remove the need to understand fact scope.

Internal model ID

An internal identifier for the model or style record.

SKU

An internal commercial or stock identifier. A SKU is not automatically a GTIN, UPI or regulatory identifier.

GTIN

A GS1 Global Trade Item Number identifies a trade item in the GS1 system.

A GTIN can map to a sellable product configuration, but GTIN assignment follows GS1 trade-item rules, not an organisation's arbitrary data hierarchy.

Batch or lot identifier

A traceability identifier for a production grouping. GS1 explicitly distinguishes this from the unique identity of the trade item.

Serial or item identifier

An identifier that distinguishes an individual physical unit where item-level identification is required or useful.

Regulatory identifier

A law or regulatory system may require its own identifier or may allow an existing recognised identifier. That question must be checked against the specific regime.

For Digital Product Passports, use the separate Digital Product Passport Identifiers resource for the regulatory identifier question. Do not infer that a commercial SKU is automatically a DPP unique product identifier.

Scope and source are separate questions

Knowing where a fact is true does not tell you where it came from.

A composition fact may be variant-level but supported by:

• supplier declaration
• approved technical specification
• laboratory test.

A weight may be SKU-level but maintained in:

• ERP
• PIM
• product development system
• controlled measurement process.

So product-data architecture needs two separate controls:

1. fact scope
2. fact authority and evidence

The next question: Which System Should Own Each Product Fact?

Common modelling mistakes

Putting everything at SKU level

This avoids inheritance decisions but creates duplication, maintenance cost and drift.

Putting everything at model level

This is tidy until one colour, size, supplier or production run differs.

Treating variants as universally defined

A variant is a useful concept, but ecommerce, ERP and manufacturing systems do not all implement it in the same way.

Treating the SKU as the product

An SKU is usually a business identifier. It does not by itself tell you whether the underlying truth is model, variant, batch or item-level.

Copying inherited values instead of inheriting them

Copied values look correct on day one and become inconsistent later.

Allowing overrides with no evidence

An override should represent a real lower-level exception, not an unexplained manual edit.

Mixing identity and traceability

A supplier lot, production batch and serial number answer different questions from a model ID or GTIN.

How to decide where a new fact belongs

1. Define the fact precisely

Do not start with a vague label such as "weight".

Ask:

• net product weight?
• packaged shipping weight?
• measured item weight?
• declared regulatory weight?

Different facts can have different scopes.

2. Find the first level at which exceptions appear

If all variants share the value, model-level may work.

If one variant differs, move the fact down to variant scope.

If variation only appears by production run, batch may be the right scope.

If every physical unit can differ, item-level may be needed.

3. Check whether the lower level is commercially distinct

If the change creates a different sellable configuration, the business may need a separate variant or SKU.

That is a commercial decision and may also interact with identifier standards.

4. Check evidence scope

The source document must support the same scope as the fact.

A certificate covering one factory and one model should not be used as evidence for every product in a range.

5. Define inheritance and override rules

State which lower records inherit, when they may override and what evidence an override needs.

Choosing software to maintain those relationships? Test shared facts and genuine variant differences in a DPP software pilot. The demonstration should show both inheritance and the exceptions, not just a tidy product list.

Those five questions are easier to answer against real data than in the abstract, and you can test what your existing record can already answer before deciding where a new fact belongs.

Worked example: one shirt style

Consider the Harbour Oxford Shirt.

Model/style

Shared across the range:

• model name: Harbour Oxford Shirt
• brand: North Harbour
• base construction: long-sleeve Oxford shirt
• standard care instruction: machine wash 30°C.

Variants

The style is sold in:

• navy
• white
• green

and sizes:

• S
• M
• L
• XL.

The business treats every colour/size combination as a sellable variant.

SKUs

Each sellable combination has an internal SKU, for example:

HOS-NVY-M

The SKU identifies the stock record. It does not make every fact SKU-level.

Composition exception

Navy and white are:

100% cotton

Green is:

98% cotton / 2% elastane

Composition cannot safely remain as one universal model-level fact unless the green variant has an explicit override.

Manufacturing batch

Most production is made in Portugal.

A specific replenishment run is produced in Turkey.

If that change applies only to the run rather than all future green shirts, the manufacturing-country fact belongs to that batch or another lower production scope.

Item state

One returned navy medium shirt is repaired and resold.

Its repair history belongs to that physical item, not to every navy medium shirt.

The model has not changed. The item's lifecycle state has.

Read back with its evidence, the example sorts into a handful of values. Each sits at the scope where it's true and needs evidence that covers that same scope:

• Brand, base construction and care: model level. Held once and inherited by all 12 colour and size variants, supported by the style's own specification.
• Composition, navy and white: 100% cotton at variant level, supported by fabric evidence that names those colours.
• Composition, green: 98% cotton / 2% elastane as a variant override, supported by its own fabric evidence rather than the cotton one.
• Country of manufacture, replenishment run: Turkey, held on that batch only and supported by the run's production record.
• Repair history: one navy medium item.

The saving comes from the first line. Those facts are answered once and their evidence travels with them, while the green shirt and the Turkish run keep their own values. ActivateDigital keeps each value to the model, variant or batch its evidence covers, so a shared answer isn't stretched past what its evidence supports.

Direct questions

What is the difference between model, variant and SKU?

A model or style usually describes a shared core product. A variant is a meaningful configuration of that product. An SKU is usually an internal commercial or inventory identifier for a sellable configuration. The exact terminology varies by organisation and system.

Is colour a variant?

Often, yes, when colour creates a meaningful sellable configuration. It is not a universal rule. The useful question is whether colour changes the product configuration your systems and customers need to distinguish.

Is size a variant or SKU?

Size is an attribute. A size value can help define a variant. The sellable size configuration may then have an SKU.

Should composition live at SKU level?

Only if that is the right truth scope. If every SKU under a style shares the composition, maintaining it once at model level may be better. If one variant differs, use lower-level ownership or an override.

Can one fact apply to every variant?

Yes. That's when inheritance is useful.

Is GTIN the same as SKU?

No. A SKU is typically an internal stock code. A GTIN is a GS1 trade-item identifier governed by GS1 rules.

What happens when one variant differs from the model?

Give that variant its own value and keep the evidence for the difference. Don't let the model value quietly replace a genuine exception.

Should batch information live in the PIM?

That depends on the architecture and use case. Batch information needs a governed home and traceable relationship to the product, but it does not universally have to be mastered in the PIM.

Another language is not another product

Do not create another product record merely because the same SKU is sold in another language. See the DPP country and language decision.

Next question

Once the fact scope is right, the next decision is:

Which System Should Own Each Product Fact?

Sources and evidence basis

Industry standards / conventions

• GS1 GTIN Management Standard, Release 1.1, September 2023
• GS1 General Specifications, current repository version 26.0.0
• Schema.org ProductGroup, which represents a group of products varying by defined properties and allows shared properties to sit on the group

Documented system behaviour

• Shopify Help Centre, Variants
• Shopify Help Centre, Using SKUs to manage your inventory

Related Knowledge

• Digital Product Passport Granularity: Model, Batch or Item?
• Digital Product Passport Identifiers
• Is Your Product Data Ready for a DPP?
• Passport Evidence: How We Know, and What a Blank Means

The placement rules in this article are our own recommendations, not a universal product-data standard.