---
title: "GTIN+CPV: one stable GTIN, every realization visible"
description: When does a change need a new GTIN? Keep the GTIN stable and give every physical realization its own GS1 Consumer Product Variant (CPV) in the QR code. Rules, format and examples.
---

[Skip to content](https://support.syncforce.com/knowledge/gtin-cpv-consumer-product-variant#main-content)

[![Syncforce\_logo\_tagline](https://support.syncforce.com/hs-fs/hubfs/Syncforce_logo_tagline.webp?width=480&height=72&name=Syncforce_logo_tagline.webp)](https://www.syncforce.com/)

Open main navigation

Close main navigation

 Hello. How can we help you?

- There are no suggestions because the search field is empty.

1. [Home](https://support.syncforce.com/knowledge?hsLang=en)
2. [Industry & Regulatory Knowledge](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en)
3. [Product Identification & GTIN](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#product-identification-gtin)

# GTIN+CPV: one stable GTIN, every realization visible

## GTIN+CPV: Supply Chain Stability with eCommerce and Compliance Granularity

For fifteen years, supply chain teams and digital and compliance teams have argued about when a change deserves a new GTIN. Both sides are right, and the linear barcode forced the industry to choose one. The QR code removes that constraint. With **GTIN+CPV**, the GTIN stays stable for trade and logistics, and the GS1 Consumer Product Variant (CPV, Application Identifier 22) identifies each physical realization behind it: which product, in which packaging, from which source. Encoded in GS1 Digital Link as `/01/{GTIN}/22/V001R002`, it gives eCommerce, sustainability reporting and market surveillance the exact data of the pack in hand, without changing anything for systems that only read the GTIN.

 The problem: one number, three right answers

Anyone who manages product data in consumer goods knows these three requests. Often they come from the same retailer, in the same month.

- **Supply chain:** *Please do not change the GTIN when only the recipe or the packaging material changes. It creates unnecessary cost and disruption.*
- **QA and sustainability:** *Please assign a new GTIN whenever the formulation or packaging composition changes. We need it for sustainability tracking and accurate EPR reporting.*
- **Digital commerce:** *Please update the GTIN for every new pack design or label. The digital twin must match what the consumer receives.*

None of these comes from a badly run organisation. Each is right on its own terms.

**Supply chain is right** because a new GTIN is a commercial event, not a data edit. It triggers re-listing, new shelf and rack positions, phase-in and phase-out, new forecasts and a broken sales history. When the shopper buys the same thing, that cost buys nothing.

**Digital, sustainability and compliance are right** because the data must describe what is actually in the box. If the bottle in the warehouse holds 50% recycled content and the product page says 30%, the page is wrong. Under PPWR, EPR and the Digital Product Passport, that is not a customer experience problem. It is a reporting and compliance problem.

### Substantial for whom?

The GS1 GTIN Management Standard requires a new GTIN for a substantial change. The whole conflict lives in that one word. For a distribution centre, a change is substantial when the pallet pattern changes. For a compliance officer, it is substantial when the recyclability or the Declaration of Conformity changes. For an eCommerce manager, it is substantial when the pack looks different. Three thresholds, one number.

So every company ends up with one of two bad options:

1. **Keep the GTIN and one data set.** The record is overwritten or drifts from reality, and two different packs share one description.
2. **Change the GTIN for every relevant change.** GTINs multiply and the supply chain pays for it.

*Visual: the three retailer letters side by side.*

 Why now: the barcode changes and the rules arrive

The real constraint was never the rules. It was the barcode. A linear EAN or UPC carries one number, so the industry had to pick one answer. Two things are changing at the same time.

**The carrier.** GS1's *Sunrise 2027* prepares retail point of sale to scan 2D barcodes by the end of 2027. A QR code with GS1 Digital Link can carry the GTIN **and** qualifiers in one symbol. The linear barcode stays on pack next to it for now; as GS1 US puts it, this is a sunrise, not a sunset.

**The obligations.** A wave of EU regulation asks for data about the physical product, not the commercial listing:

| Regulation | What applies | Why it needs realization-level data |
| --- | --- | --- |
| PPWR (packaging) | Applies since 12 August 2026: Declaration of Conformity per packaging, identification on the packaging; harmonised material labels from August 2028 | Compliance belongs to the packaging as placed on the market. A new bottle is a new Packaging System. |
| EmpCo (green claims) | Applies since 27 September 2026 | A claim on pack must be true for the pack in hand. |
| EUDR (deforestation) | 30 December 2026 for large and medium companies, 30 June 2027 for micro and small | Origin can differ per supplier under one GTIN. |
| EU Battery Regulation | Battery passport from 18 February 2027 (EV, light means of transport, industrial above 2 kWh) | The passport belongs to the battery model, not to the retail pack. |
| ESPR (Digital Product Passport) | EU DPP registry live since 20 July 2026; delegated acts for steel, textiles and more follow, each with a transition period | The DPP is about the Product Model inside the Sales Unit. |

That is why we call **2027 the year of identifiers**: the year the QR code reaches the checkout, the first product passports become mandatory, and market surveillance authorities start checking packaging compliance in earnest.

Note: dates as of October 2026. Several of them have moved before; check the current status before planning on them.

### The foundation: Sales Unit = Product + Packaging

The GTIN has always been described as the unique identifier of a product. In regulated categories that is no longer true. A GTIN identifies a **Sales Unit**: a commercial proposition. Behind one GTIN can sit several physical realizations, and one product can sit in several GTINs.

The SyncForce Keystone Principle makes this explicit:

**Sales Unit = Product(s) + Packaging**

| Object | What it is | Identified by |
| --- | --- | --- |
| Sales Unit | What the customer buys and the retailer lists | GTIN |
| Product Model | The product that is consumed or used, with its own technical identity and life cycle | A product identifier accepted under the EU-DPP standards (EN 18219), for example `VTA-MPLA-PM-GU3ZSJP` |
| Packaging System | The complete packaging as placed on the market; the PPWR compliance object | A packaging identifier, for example `VTA-MPLA-PS-T46GD61T` |
| **Physical realization of the Sales Unit** | One specific combination of Product Model(s), Packaging System, artwork and source | **GTIN + CPV** |

A new CPV is needed when the realization changes:

- **A different product inside:** a reformulated recipe or a new material creates a new Product Model.
- **Different packaging around it:** a bottle with more recycled content is a new packaging component, so a new Packaging Master and a new Packaging System.
- **A different pack design or on-pack declaration:** what the shopper and the authority see has changed.
- **A different source,** where it changes what must be declared: origin, manufacturer, allergens.

The CPV does not copy any of that data. It **points** to the Product Model and the Packaging System it is made of. Product data lives on the product, packaging data on the packaging. This is the move from a golden record per GTIN, which breaks in regulated categories, to a graph of linked objects that each party can maintain where it belongs.

*Visual: the GTIN+CPV graph from the principles document (one GTIN, three CPVs, shared Product Models and Packaging Systems).*

 What GS1 already defines

Nothing in GTIN+CPV is new to GS1. The building blocks are ratified; only the way to fill and use them was missing.

- **AI (22), Consumer Product Variant.** In the GS1 General Specifications: 1 to 20 alphanumeric characters, assigned by the brand owner, for a variation that does **not** require a new GTIN. It must always appear together with the GTIN.
- **The GTIN Management Standard stays in charge.** It decides when a new GTIN is needed. CPV is only used below that line, never instead of it. GS1's own rules already recognise that a change within the specification defined for trading purposes needs no new GTIN.
- **GDSN support.** The GS1 implementation guideline *Consumer Product Variant in GDSN* (Release 1.1, November 2024) defines five attributes, including identification, reason code and start and end effective dates, and thirteen reason codes such as minor formulation change, packaging change with minor impact, artwork change and production in different locations.
- **Two kinds of CPV.** The same guideline distinguishes *transitional* CPVs (one replaces the other) from *concurrent* CPVs (they exist side by side, for example from different production facilities). Only the transitional behaviour is documented so far.
- **GS1 Digital Link.** AI 22 is a key qualifier of the GTIN, so `https://example.com/01/{GTIN}/22/{CPV}` is valid syntax today, in a fixed order before batch and serial.
- **AI (20) is different.** It is a product variant for internal use by the brand owner. AI (22) is the one meant for trading partners and consumers.

**What GS1 does not define is the content of the field.** Its examples are values like `123` or `126`. Left free, every company invents its own scheme, and a free-format field is not interoperability. That is the gap the V###R### convention fills.

### The V###R### convention

One field, two dimensions. `V004R003` reads as variant 4, in its third revision.

- **V = Variant: what is different at the same time.** Variants run in parallel under one GTIN, with the same commercial proposition. A second contract manufacturer, another country of origin, a promotional pack next to the standard pack, a colour in a mixed tray.
- **R = Revision: what changed over time.** Revisions replace each other within their variant. A reformulated recipe, a bottle with more recycled content, a redesigned label.

V is GS1's concurrent CPV; R is GS1's transitional CPV. The convention gives those two concepts a name and a syntax.

#### The rules in short

1. **Fixed format:** 8 characters, `V` plus 3 digits, `R` plus 3 digits, zero-padded. Human-readable, machine-sortable.
2. **Per GTIN:** the CPV is unique within its GTIN. GTIN+CPV is the key; a CPV never travels alone.
3. **Start at V001R001,** GS1's Primary Version.
4. **Parallel means a new V, replacing means a new R.** The behaviour decides, not the reason. The GS1 reason code records why the CPV was created.
5. **Never reused, never renumbered.** A retired variant stays retired, and history stays readable.
6. **One change set, one R.** Changes that reach the market together get one new revision.
7. **The brand owner of the GTIN keeps one register per GTIN,** even when allocation is delegated to a supplier.

#### When to change what

Ask three questions, always in this order:

1. **Does the GTIN Management Standard require a new GTIN?** Then it is a new GTIN, starting at `V001R001`. CPV never overrides GS1.
2. **Does the physical realization change?** If only the data is corrected or completed, it is a new data version of the same CPV, not a new CPV.
3. **Will the new realization run in parallel with an existing one?** Yes: next V. No: next R.

| Change | Result |
| --- | --- |
| Net content from 500 ml to 450 ml | New GTIN (GS1 rule) |
| Bottle from 30% to 50% recycled content, old bottle phased out | `V001R001` to `V001R002` |
| New label design and bio-based cap liner, same launch date | One new revision |
| A second contract manufacturer next to the first | New variant: `V002R001` |
| Supplier 4 changes its recipe | `V004R002` to `V004R003` |
| A typo in the ingredient list corrected in the data, pack unchanged | No new CPV |

Up the hierarchy, in the QR code, at the resolver

#### Up the hierarchy

A 6-pack or a case is a Sales Unit too: its own content (the child unit) plus its own packaging (tray, foil, case). When a child gets a new CPV, every level above it gets its next revision. **The GTINs stay the same at every level,** so shelf positions, rack positions and order lines do not move. A parent also gets a new revision when its own packaging changes, for example a shrink foil with more recycled content.

#### In the QR code (without and with batch/lot nr)

- https://prodigi.link/01/08765438765434/22/V001R002
- https://prodigi.link/01/08765438765434/22/V001R002/10/L26291

Point of sale and warehouse systems read `/01/` and work exactly as today. Systems that need the detail read `/22/`. The CPV changes only when the realization changes, which is when the artwork changes anyway, so it adds no separate print event. The linear barcode stays next to the QR code during the transition.

#### Promise and proof: CPV and batch

The CPV is the **promise**: what this realization is designed to be. The batch is the **proof**: what was actually produced and received. You need both, and neither replaces the other.

- **Time.** The CPV exists months before delivery, when content, claims and compliance files must already be right. A batch exists only from the first filling run.
- **Printing.** For most products the QR code is part of the artwork, printed in large volumes before filling. A batch number simply cannot be in it. In fresh products inline printing is common, and there the lot can follow the CPV: `/22/{CPV}/10/{lot}`.
- **Granularity.** The same product in the same packaging can run in daily batches. Every batch belongs to exactly one CPV.
- **Evidence.** The trigger is usually a component, such as a bottle with more recycled content. That revises the Packaging System, which tells you which facts to ask for. At sourcing, a lab report on an earlier or similar sample supports the promise: it describes the type, not your goods. At goods receipt, the proof comes per batch: production window inside the certificate validity, a transaction certificate linked to the delivery, and a sample test.

And the scan comes late: at the shelf, at home or at an inspection. By then the promise must have been published for months, and the proof must be findable for years. **Promise first, then proof.**

#### At the resolver

A resolver turns the code on pack into links. For GTIN+CPV it follows a few simple rules:

- **Every CPV has its own landing page,** showing the visuals and claims of the pack in hand.
- **The same link types exist at GTIN level and at CPV level;** only the targets differ per CPV.
- **An unknown CPV falls back to the GTIN page,** as GS1 Digital Link prescribes. Nothing breaks.
- **The GTIN page shows the current realization,** switched on its effective date, and its claims must be true for every realization still in circulation.
- **A CPV keeps resolving after it is phased out.** Packs live in homes and recycling streams long after they leave the shelf.

| Link type | Where it leads for this CPV |
| --- | --- |
| `gs1:defaultLink` | The landing page of this realization |
| `gs1:pip` | Product information for this realization |
| `gs1:dpp` | The Digital Product Passport (or eLabel view) of each Product Model inside |
| `imde:packagingInfo` | The Packaging System of this realization, with its Declaration of Conformity and composition |
| `gs1:sustainabilityInfo` | Recycling and sustainability information for this realization |

Two notes for regulated products. First, GS1 Application Identifiers and ISO/IEC Data Identifiers are never mixed in one URL: GTIN+CPV *links to* the Product Model and the Packaging System, it does not encode them. Second, reaching a Digital Product Passport through the Sales Unit is **indirect access**. Where a passport is registered on the Product Model, the product itself still needs a data carrier with its own identifier.

This is how GTIN+CPV prepares for federated, linked data, the direction the EU has chosen for the Digital Product Passport: each object is published once, by the party responsible for it, and the others link to it.

### Use it where you need it

GTIN+CPV is not a big-bang change. Each system and each partner chooses per data flow whether to use the CPV. A system that ignores it keeps working exactly as it does today.

| Flow | Without CPV | With CPV |
| --- | --- | --- |
| Checkout, ordering, invoicing | Runs on the GTIN | No change needed; a CPV never appears on an order line |
| Main distribution centre | Stores and ships per GTIN | Optional FIFO per realization during a changeover |
| eCommerce fulfilment | Picks per GTIN | Scans the CPV at inbound and knows which realization is in stock |
| Webshop | Switches images and claims on the effective date of the new realization | Shows the old pack until that stock is gone, then the new one |
| Retailer master data via GDSN | Overwrites the record per GTIN | Keeps a record per GTIN+CPV for reporting |
| EPR, PPWR and sustainability reporting | One composition per GTIN | What was actually placed on the market, per period: are we moving from A to better? |
| Consumer or market surveillance scan | The GTIN page | The page, the Declaration of Conformity and the product passport of exactly this pack |

**The safety net:** if a partner is not ready, a new data set for an existing GTIN simply overwrites the previous one, as today. Nothing stops; only the benefit of versioning waits until that partner's systems are ready.

### Three examples

#### Affligem Belgisch Wit 0.0: same beer, same GTIN, a new realization

![unnamed](https://support.syncforce.com/hs-fs/hubfs/unnamed.png?width=512&height=288&name=unnamed.png)

On the shelf, the old bottles and the new ones stand on the same spot. The new pack replaces the old one as the stock sells out. Three things changed: the label design, the cap liner (now from a bio-renewable source instead of crude oil) and the shrink foil of the 6-pack (34% more post-consumer recycled content). Two of these are material changes with direct EPR and PPWR consequences. Today neither is visible anywhere in the data, because the bottle and the 6-pack kept their GTINs.

With GTIN+CPV, both GTINs stay the same, so shelf, warehouse and ordering are untouched. The bottle moves from `V001R001` to `V001R002`, and so does the 6-pack. Each pack resolves to its own visuals and its own Packaging System, the webshop switches when the old stock is gone, and EPR reporting picks up the change from its effective date. *(Illustrative example.)*

#### Private-label Thai-style marinated prawns: seven sources, one GTIN

One product on one shelf position, with one rack position in the distribution centre. Behind it: seven contract manufacturers in seven countries, each with its own recipe and its own improvement cycle. Today that is one GTIN and one data record, and six of the seven realizations are invisible.

With GTIN+CPV, each source is a variant (`V001` to `V007`) and each recipe update is a revision within it. Source 4, running on its third recipe, is `V004R003`, encoded on pack as `https://prodigi.link/01/08765438765434/22/V004R003`. Origin, allergens, nutrition and packaging can differ per source and be published per source, without a single re-listing. *(Illustrative example.)*

#### Happy Socks: the product exists before the GTIN

A 3-pack and a 4-pack combine 12 products: 4 styles in 3 sizes. The socks are made in India, Turkey and China months before they are packed in Germany into a Sales Unit with a GTIN, and the same packaging is reused across many sock combinations.

![Sales Unit = Product + Packaging  in Fashion Happy Socks (2)](https://support.syncforce.com/hs-fs/hubfs/Sales%20Unit%20=%20Product%20+%20Packaging%20%20in%20Fashion%20Happy%20Socks%20(2).jpg?width=670&height=377&name=Sales%20Unit%20=%20Product%20+%20Packaging%20%20in%20Fashion%20Happy%20Socks%20(2).jpg)

This is why the product needs its own identifier: **it is produced before the GTIN is known,** and it ends up in more than one Sales Unit. The Product Model ID belongs to the sock, the Packaging System ID to the packaging, the GTIN to the pack. GTIN+CPV ties them together for each realization. For textiles, where the Digital Product Passport is expected to apply around 2029, this distinction decides what the passport is attached to.

#### How SyncForce will supports GTIN+CPV (Q1-2027)

SyncForce Circular PIM was built on the Keystone Principle: Sales Units, Product Models and Packaging Systems are separate objects in the Golden Hierarchy, linked rather than merged. GTIN+CPV is the natural next step on that foundation.

![](https://support.syncforce.com/hs-fs/hubfs/image-png-Oct-18-2026-01-17-53-4879-PM.png?width=670&height=257&name=image-png-Oct-18-2026-01-17-53-4879-PM.png)

- **Two clicks instead of a convention to memorise.** When you create a Sales Unit with a GTIN that already exists, SyncForce asks whether it is a new Variant or a new Revision of an existing Variant, and assigns the code.
- **One GTIN, many realizations.** Each GTIN+CPV has its own data, visuals, claims and dates, and links to its Product Model(s) and Packaging System.
- **The cascade is proposed for you.** A new CPV on a bottle proposes the next revision for the 6-pack and the case above it.
- **Digital Link and QR per CPV,** resolved through prodigi.link with a landing page per realization and the right link types.
- **Publication per partner,** with the CPV for those who use it and the GTIN-level record on the effective date for those who do not.

- [Industry & Regulatory Knowledge](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#main-content)

    - [Product Portfolio](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#product-portfolio)
    - [Packaging & PPWR](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#packaging-ppwr)
    - [EU Digital Product Passport - DPP](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#eu-digital-product-passport-dpp)
    - [GS1 & GDSN](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#gs1-gdsn)
    - [Food & Label Information](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#food-label-information)
    - [EPR & Sustainability Data](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#epr-sustainability-data)
    - [Product Identification & GTIN](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#product-identification-gtin)
    - [PIM & Data Architecture](https://support.syncforce.com/knowledge/industry-regulatory-knowledge?hsLang=en#pim-data-architecture)
- [Product Data Management](https://support.syncforce.com/knowledge/product-data-management?hsLang=en#main-content)

    - [Packaging Data Management](https://support.syncforce.com/knowledge/product-data-management?hsLang=en#packaging-data-management)
    - [Product data imports](https://support.syncforce.com/knowledge/product-data-management?hsLang=en#product-data-imports)
    - [PDM setup and config](https://support.syncforce.com/knowledge/product-data-management?hsLang=en#pdm-setup-and-config)
- [Digital Asset Management](https://support.syncforce.com/knowledge/digital-asset-management?hsLang=en#main-content)

    - [FileConvert](https://support.syncforce.com/knowledge/digital-asset-management?hsLang=en#fileconvert)
- [Project Portfolio Management](https://support.syncforce.com/knowledge/project-portfolio-management?hsLang=en#main-content)

    - [Team & Planning](https://support.syncforce.com/knowledge/project-portfolio-management?hsLang=en#team-planning)
    - [Proofing & Approval](https://support.syncforce.com/knowledge/project-portfolio-management?hsLang=en#proofing-approval)
    - [Budget & Spend Management](https://support.syncforce.com/knowledge/project-portfolio-management?hsLang=en#budget-spend-management)
    - [Resource Management](https://support.syncforce.com/knowledge/project-portfolio-management?hsLang=en#resource-management)
    - [To Do (task & actions)](https://support.syncforce.com/knowledge/project-portfolio-management?hsLang=en#to-do-task-actions)
    - [Project definition](https://support.syncforce.com/knowledge/project-portfolio-management?hsLang=en#project-definition)
- [Product Catalog](https://support.syncforce.com/knowledge/product-catalog?hsLang=en)
- [Media Library](https://support.syncforce.com/knowledge/media-library?hsLang=en)
- [Product Data Syndication](https://support.syncforce.com/knowledge/product-data-syndication?hsLang=en#main-content)

    - [GS1-GDSN](https://support.syncforce.com/knowledge/product-data-syndication?hsLang=en#gs1-gdsn)
    - [DataPorts](https://support.syncforce.com/knowledge/product-data-syndication?hsLang=en#dataports)
    - [PS in Foodservice](https://support.syncforce.com/knowledge/product-data-syndication?hsLang=en#ps-in-foodservice)
    - [REST API](https://support.syncforce.com/knowledge/product-data-syndication?hsLang=en#rest-api)
- [Document Automation](https://support.syncforce.com/knowledge/document-automation?hsLang=en)
- [Exports & reports](https://support.syncforce.com/knowledge/exports-reports?hsLang=en)
- [Business Network Management](https://support.syncforce.com/knowledge/business-network-management?hsLang=en#main-content)

    - [Single Sign-On](https://support.syncforce.com/knowledge/business-network-management?hsLang=en#single-sign-on)
- [Services & Support](https://support.syncforce.com/knowledge/services-support?hsLang=en)
- [Partner Support](https://support.syncforce.com/knowledge/partner-support?hsLang=en)
- [General setup](https://support.syncforce.com/knowledge/general-setup?hsLang=en)
- [Campaign management](https://support.syncforce.com/knowledge/campaign-management?hsLang=en)
- [General](https://support.syncforce.com/knowledge/general?hsLang=en)

[![Chill listening crop-3](https://support.syncforce.com/hs-fs/hubfs/SyncForce_plus_1024-2.png?width=105&height=24&name=SyncForce_plus_1024-2.png "Chill listening crop-3")](https://www.syncforce.com/)

Copyright © 2026, SyncForce