VTA Identifiers - ID

VTA Identifiers

Identifiers for value chain data exchange

VTA identifiers are designed to support reliable data exchange across value chains. In a value chain, many different parties need to exchange data about products, packaging, facilities, batches, serialized items, brands, materials and economic operators. This data often moves between different systems, standards, markets and organisations.

For this to work, every object or party referenced in the data exchange needs a stable identifier. Without stable identifiers, systems cannot reliably understand whether two data records refer to the same product model, the same packaging system, the same facility, the same batch or the same economic operator.

VTA identifiers provide a structured way to identify the main entities that are needed for value chain data exchange.

Why VTA identifiers are needed

Many existing identifiers are designed for a specific industry, market, organisation or use case. They are often excellent within their original context, but less suitable when data needs to move across many domains.

Value chain data exchange requires identifiers that are:

• globally understandable
• machine-readable
• stable over time
• suitable for multiple entity types
• usable by both central authorities and local issuing systems
• flexible enough for different industries and technical environments

VTA identifiers are not intended to replace all existing identifiers. Instead, they provide a common identifier framework that can be used in data exchange to reference entities consistently.

A VTA identifier can point to a product model, a packaging system, a sales unit, a facility, a batch, a serialized item, a material platform, an economic operator or a trademark/brand.

Central and local issuing

VTA supports both central and local issuing of identifiers.

Some identifiers need to be governed centrally because duplicate identifiers would create major problems in the value chain. Economic Operator identifiers are an example. If the same legal or economic party receives multiple independent identifiers from different issuers, systems may not be able to determine that these identifiers refer to the same party. For this reason, Economic Operator identifiers can be centrally issued.

Other identifiers can be issued locally by authorised issuers. For example, a product manufacturer or system provider may issue identifiers for product models, packaging systems, batches or serialized items within its own namespace. As long as the issuer prefix is unique, the resulting full VTA identifier remains globally unique.

This combination makes VTA practical for real-world implementation. It allows central governance where needed, while still allowing local systems to create identifiers at scale.

Identifier structure

A VTA identifier consists of several parts:

Part	Description
Scheme prefix	Identifies the identifier system as VTA
Issuer code	Identifies the issuing namespace
Entity class	Identifies the type of entity
Identifier body	Identifies the specific entity within the issuer and entity class namespace

A simplified structure is:

VTA + Issuer Code + Entity Class + Identifier Body

Example:

VTA0000H12345678

In this example:

Part	Example	Meaning
Scheme prefix	VTA	VTA identifier
Issuer code	0000	Centrally issued by VTA
Entity class	H	Economic Operator
Identifier body	12345678	Specific Economic Operator

The issuer code ensures that different issuers can issue identifiers without creating collisions. The entity class ensures that the identifier can be interpreted in the correct context.

Reserved central issuer code

The issuer code 0000 is reserved for centrally issued VTA identifiers.

This means that an identifier such as:

VTA0000H...

can be recognised as a centrally issued VTA Economic Operator identifier.

The code 0000 should not be used as a placeholder, unknown value, default value or temporary value. It is a valid reserved issuer code for centrally governed VTA identifiers.

Flexible length

VTA identifiers support flexible identifier lengths. Different entity classes have different practical requirements.

For example, a Product Model identifier may need a different length than a Batch identifier or a Serialized Item identifier. Some identifiers are expected to remain relatively short and stable, while others may need additional capacity because they are issued in large volumes.

Each entity class can define its own minimum, preferred and maximum length for the identifier body.

Key	Entity class	Type	Minimum length	Preferred length	Maximum length
A	Product Model	Object	6	7	8
B	Packaging System	Object	8	8	8
C	Sales Unit	Object	8	8	8
D	Facility	Object	8	8	8
E	Batch	Object	5	5	12
F	Serialized Item	Object	8	10	12
G	Material Platform	Object	6	6	6
H	Economic Operator	Party	8	8	8
I	Trademark / Brand	Object	6	6	6

Flexible length makes the identifier framework more adaptable. It avoids forcing all entity types into the same format, while still keeping the overall structure consistent.

Field keys for data exchange

In XML, JSON, XLS and other data exchange formats, each VTA identifier type should have a clear and stable field key.

The recommended convention is to use the readable English entity name in UpperCamelCase, followed by ID. This keeps the data exchange format understandable without requiring users to learn short internal abbreviations.

Identifier type	Field key
Product Model	ProductModelID
Packaging System	PackagingSystemID
Sales Unit	SalesUnitID
Facility	FacilityID
Batch	BatchID
Serialized Item	SerializedItemID
Material Platform	MaterialPlatformID
Economic Operator	EconomicOperatorID
Trademark / Brand	TrademarkBrandID

For future VTA entity classes, the same convention should be used:

EntityNameID

Examples:

Future entity class	Field key
Packaging Component	PackagingComponentID
Material Source	MaterialSourceID
Declaration	DeclarationID

Entity classes

VTA identifiers use an entity class key to indicate what type of entity is being identified.

A: Product Model

A Product Model identifies the product as a model or specification. It is not a single physical item and not necessarily a specific commercial sales unit. It is the product definition that can be used across markets, channels or packaging configurations.

Product Model identifiers are useful when product-related data needs to be exchanged independently from packaging, logistics or serialization.

B: Packaging System

A Packaging System identifies a packaging configuration or packaging structure. This can include the combination of packaging components that together form the packaging system for a product or sales unit.

Packaging System identifiers support exchange of packaging-related data, such as material composition, recyclability, packaging tax data and sustainability information.

C: Sales Unit

A Sales Unit identifies a commercial unit that can be sold or exchanged in the market. It can combine product, packaging and other commercial attributes.

Sales Unit identifiers are useful when data exchange needs to refer to a tradeable unit rather than only the product model or packaging system.

D: Facility

A Facility identifies a physical site, such as a production location, warehouse, distribution centre or other relevant value chain location.

Facility identifiers can be used in data exchange for traceability, sustainability declarations, manufacturing information, compliance data and supply chain transparency.

E: Batch

A Batch identifies a group of products or materials produced, processed or handled together under defined conditions.

Batch identifiers are important for traceability, quality management, recalls, compliance and product-specific declarations that apply to a production batch rather than to an individual item.

The Batch entity class supports a flexible identifier body length, allowing different industries and systems to use batch identifiers with different levels of complexity.

F: Serialized Item

A Serialized Item identifies an individual physical item.

Serialized Item identifiers may be issued in very high volumes and are often generated in operational systems. VTA supports this by allowing authorised issuers to issue serialized item identifiers within their own issuer namespace.

For serialized items, the issuer prefix can be followed by an identifier body that is generated by an internal system. This allows companies to continue using internal serial number generation logic while making the resulting identifier globally unique in the VTA framework.

For example:

VTA1234FABC987654

In this example:

Part	Example	Meaning
Scheme prefix	VTA	VTA identifier
Issuer code	1234	Local issuing namespace
Entity class	F	Serialized Item
Identifier body	ABC987654	Internally generated serial reference

This makes VTA suitable for item-level data exchange without requiring every serial number to be centrally issued.

G: Material Platform

A Material Platform identifies a material concept or material platform that can be referenced across products, packaging or value chain processes.

This can be used to exchange data about material composition, material origin, recycled or virgin content, certification, environmental impact and other material-related declarations.

H: Economic Operator

An Economic Operator identifies a party in the value chain. This can include manufacturers, importers, distributors, authorised representatives, fulfilment service providers or other parties that have a role in placing, moving or maintaining products in the market.

Economic Operator identifiers are candidates for central issuing because the same party may appear in many data exchanges, systems and value chains. A centrally issued identifier reduces the risk of duplicates and helps systems recognise the same party across different contexts.

Example:

VTA0000H12345678

This indicates a centrally issued VTA identifier for an Economic Operator.

I: Trademark / Brand

A Trademark / Brand identifier identifies a brand, trademark or other market-facing identity.

This is useful when product data exchange needs to distinguish between the manufacturer, the owner of the brand, the commercial product identity and the actual product model.

Issuer permissions

Not every issuer should be allowed to issue every type of VTA identifier.

VTA can use issuer permissions to define which entity classes an issuer is allowed to issue. This prevents uncontrolled creation of identifiers for entity classes that require stronger governance.

For example, an issuer may be allowed to issue Product Model, Batch and Serialized Item identifiers, but not Economic Operator identifiers.

This creates a clear governance model:

Role	Description
Central issuer	Issues centrally governed identifiers
Local issuer	Issues identifiers within its own authorised namespace
Registrar	Requests or registers entities for identification
Maintainer	Maintains the data record linked to the identifier
Resolver	Provides access to the data or metadata linked to the identifier

The issuer of an identifier does not need to be the same party as the maintainer or resolver of the related data. This distinction is important in value chain data exchange, where different parties may create, maintain, exchange or host different parts of the data.

Relationship with existing identifiers

VTA identifiers can coexist with existing identifiers. A product, facility, batch, item or economic operator may already have other identifiers from industry standards, regulatory frameworks or internal systems.

A VTA identifier can be used as a common reference in data exchange, while existing identifiers can be stored as additional identifiers or external references.

Examples of external identifiers include:

Entity	Possible external identifiers
Product Model	Internal product code, model number, GTIN-related references
Sales Unit	GTIN, SKU, retailer item number
Facility	GLN, internal site code, regulatory site number
Batch	Internal batch code, production lot number
Serialized Item	Internal serial number, item-level code
Economic Operator	LEI, VAT number, company registration number, EORI
Trademark / Brand	Trademark registration number, internal brand code

This makes VTA a bridge for data exchange, not a replacement for every identifier already used in the market.

Benefits of the VTA identifier model

The VTA identifier model provides several benefits:

Benefit	Explanation
Global uniqueness	The combination of scheme, issuer, entity class and identifier body prevents collisions
Human readability	The structure makes it possible to recognise the identifier system, issuer namespace and entity type
Central governance where needed	Critical identifiers, such as Economic Operators, can be centrally issued
Local scalability	High-volume identifiers, such as serialized items, can be issued by local systems
Flexible length	Each entity class can have a length suitable for its purpose
Data exchange readiness	Identifiers are designed to be used across organisations, systems and standards
Coexistence	Existing identifiers can remain in use as external references

Example identifiers

Example identifier	Meaning
VTA0000H12345678	Centrally issued Economic Operator identifier
VTA1234A7654321	Product Model issued by local issuer 1234
VTA1234B87654321	Packaging System issued by local issuer 1234
VTA1234D23456789	Facility issued by local issuer 1234
VTA1234ELOT25	Batch issued by local issuer 1234
VTA1234FABC987654	Serialized Item issued by local issuer 1234
VTA1234I654321	Trademark / Brand issued by local issuer 1234

These examples are illustrative only. The actual identifier body must be created according to the issuing rules for the entity class and issuer.

Summary

VTA identifiers provide a structured identifier framework for value chain data exchange.

They combine:

• a VTA scheme prefix
• an issuer namespace
• an entity class
• a flexible identifier body

This allows VTA to support both centrally governed identifiers and locally issued identifiers. Central issuing can be used where uniqueness across the full value chain is critical, such as Economic Operators. Local issuing can be used where identifiers need to be created at scale, such as Product Models, Batches or Serialized Items.

The result is an identifier framework that is structured, scalable and suitable for cross-company data exchange.