PPWR declaration and SKU – does every product need a separate declaration?

An SKU is not the PPWR declaration unit

The concept of an SKU is not the basic unit of the conformity assessment procedure laid down in the PPWR.

An SKU – Stock Keeping Unit – is used by an undertaking to identify products in:

• ERP,
• the warehouse,
• sales,
• e-commerce,
• production planning.

One technically identical packaging type may be used for dozens of different SKUs.

Conversely, one SKU may simultaneously use several different packages:

• a bottle,
• a cap,
• a label,
• a unit carton,
• an outer carton,
• transport packaging.

Therefore, building a PPWR system directly as:

SKU → separate PDF

often leads to extensive duplication.

What does Annex VIII say about packaging identification?

The model EU declaration of conformity in Annex VIII contains two particularly important sections.

Point 1 requires the packaging to be clearly identified.

Point 4 concerns the subject matter of the declaration and its identification in a manner allowing traceability, together with a description of the packaging.

The Regulation does not specify a mandatory format here:

• SKU,
• GTIN,
• EAN,
• ERP code,
• commercial product number.

A company may use its own identifier system, provided that it genuinely makes it possible to determine which packaging the declaration concerns.

Does the PPWR literally require “one declaration for each packaging type”?

Not in such a simplified form.

Industry materials often refer to the rule:

“a declaration for each packaging type”.

This is a very useful organisational model, but it should not be presented as a literal sentence from Article 39 or Annex VIII.

The PPWR requires:

• identification of the packaging,
• documentation enabling its conformity to be assessed,
• traceability of the subject matter of the declaration,
• maintenance of production conformity.

The concept of a “packaging type” is therefore a very good way of implementing these obligations, but the boundaries of a particular type need to be defined technically.

Article 15: type, batch, serial number or another identification element

Article 15 also requires the manufacturer to ensure packaging identification by means of:

• type,
• batch,
• serial number,
• or another element enabling its identification.

This does not mean, however, that a new declaration must be drawn up for each batch.

The batch number may be used to determine which physical production belongs to a specific assessed design and documentation.

It is therefore possible to distinguish between:

identification of the assessed design / configuration

and:

identification of a specific production batch.

The most practical unit: packaging configuration

For the purposes of the internal system, it is worth creating the concept of:

‘PPWR packaging configuration’.

This is not a term defined by the Regulation, but a practical record describing a set of characteristics relevant to conformity assessment.

The configuration may include:

• main material,
• construction,
• dimensions,
• mass,
• components,
• closure,
• label,
• adhesive,
• coatings,
• intended use,
• manufacturer,
• version.

Multiple SKUs can then be assigned to such a record.

When can several SKUs use the same basis for a declaration?

Grouping makes sense where the difference between products does not change the packaging assessed or the scope of its conformity.

Example:

• SKU-001 – lemon drink 500 ml,
• SKU-002 – raspberry drink 500 ml,
• SKU-003 – orange drink 500 ml.

Each uses:

• the same PET bottle,
• the same bottle mass,
• the same cap,
• the same label construction,
• the same adhesive,
• the same scope of intended use.

If the technical assessment of the packaging is the same, there is no point in copying identical tests three times simply because the drink flavour has changed.

However, the company should maintain a table showing that all three SKUs actually use the same configuration.

When should SKUs not be combined within one assessment scope?

Variants should not be grouped merely because they look similar from a marketing perspective.

Changes relating to the following may require separate assessment:

• material,
• thickness,
• mass,
• dimensions,
• capacity,
• coating,
• label,
• adhesive,
• closure,
• recycled content,
• intended use.

If a difference affects a PPWR requirement or the evidence on which its assessment is based, a single shared configuration should not be artificially maintained.

Different product flavours – do they require different declarations?

Not merely because of a different flavour.

If the packaging remains technically identical, the product variant inside does not itself have to change the PPWR assessment.

However, caution is needed if different product variants result, for example, in the use of:

• a different label,
• a different coating,
• a different closure,
• different storage conditions.

The technical differences must then be assessed, not just the SKU name.

Does each packaging colour require a separate declaration?

Not automatically.

If several colours use the same approved material specification and the difference does not affect:

• substances,
• sorting,
• recyclability,
• functional properties,

variants may remain within one controlled assessment scope.

However, if the colour indicates the use of a different pigment or additive affecting earlier conclusions, an appropriate impact assessment must be carried out.

The same bottle, but different labels – one or several declarations?

This is one of the most common cases with multiple SKUs.

A change in graphics does not necessarily mean a technical change to the packaging.

However, different SKUs may use labels differing in:

• material,
• format,
• surface area,
• adhesive,
• inks,
• metallisation.

If any of these parameters changes, the previous result relating, for example, to recyclability may no longer be representative.

Therefore, the system should distinguish:

graphic variant

from:

technical label variant.

250 ml and 500 ml – are they the same packaging type?

Different capacities should not automatically be treated as one assessed variant.

A 250 ml bottle and a 500 ml bottle may differ in:

• mass,
• geometry,
• the ratio of packaging mass to function,
• label,
• closure,
• mechanical test results.

This is particularly important for minimisation.

Both sizes can be managed within one technological family, but each variant must be covered by an actual assessment basis.

The same material does not automatically mean the same PPWR packaging

Two packages may be made of PET and nevertheless differ in a way that is relevant to compliance.

For example:

• bottle A – 20 g, colourless, paper label,
• bottle B – 38 g, coloured, sleeve label,
• bottle C – multilayer construction.

“PET” is a material characteristic, not a complete definition of the assessment item.

Therefore, grouping by material code alone is too broad.

One SKU may use several different PPWR packages

Imagine an SKU:

50 ml face cream.

Its supply chain may include:

1. jar,
2. cap,
3. label,
4. sales carton,
5. grouped carton,
6. transport carton,
7. stretch film on a pallet.

Not all these components need to be one item of the same assessment.

They may:

• belong to different packaging categories,
• have different manufacturers,
• have separate specifications,
• be subject to different specific requirements.

Therefore, the number of SKUs determines neither the minimum nor the maximum number of declarations.

Sales packaging – the first level of SKU mapping

Sales packaging creates a sales unit for the end user.

For a bottle with a cap and label, the actual packaging configuration must be assessed, rather than each component in isolation.

One configuration code can then be assigned to all SKUs using exactly the same assessed set.

Example:

PACK-SALES-017-R2 → SKU-001, SKU-002, SKU-003, SKU-007.

Grouped packaging may have its own mapping

The same products may be delivered to different customers in:

• a carton of 6 units,
• a carton of 12 units,
• a tray of 24 units.

This means several grouped packaging configurations for one SKU.

The system should therefore allow the relationship:

SKU → more than one grouped packaging configuration.

Transport packaging should not be hidden in a single SKU record

A transport carton, crate or pallet may be shared by many different products.

Example:

one type of shipping carton is used for 120 different SKUs in the warehouse.

Creating 120 copies of its specification and reports would be highly prone to errors.

It is better to maintain one controlled carton record and 120 relationships to SKUs.

An e-commerce SKU may have several different shipping packages

E-commerce further complicates the mapping.

The same product may be shipped:

• in an envelope,
• in a small carton,
• in a larger carton together with other products.

Therefore, shipping packaging cannot always be assigned to an SKU through a 1:1 relationship.

A more accurate model may look as follows:

SKU → packing rule → shipping format → PPWR configuration.

Packaging component versus complete packaging – do not create declarations by simply copying suppliers

The bottle supplier may provide:

• material specification,
• test reports,
• substance-related data,
• its own documents relating to empty packaging.

The label supplier may do the same.

However, the manufacturer of the final packaging should not automatically treat every component declaration as a declaration for the entire configuration.

Annex VII requires an assessment of packaging corresponding to the actual item being placed on the market.

Does each production batch need a separate declaration?

PPWR does not establish a general rule of “one batch = one DoC”.

A batch primarily serves traceability and production control.

Example:

• PACK-017-R3 – assessed configuration,
• LOT-2026-091 – batch 1,
• LOT-2026-104 – batch 2,
• LOT-2026-126 – batch 3.

All may remain production of the same technical version if the process ensures conformity with the documentation.

Therefore, the creation of another batch does not in itself require the entire declaration to be redrawn.

Can an EAN or GTIN number identify PPWR packaging?

It may be part of the system, but PPWR does not establish GTIN or EAN as a mandatory declaration unit.

A GTIN primarily identifies a trade item.

If it exactly corresponds to the assessed packaging configuration, it can be used in the mapping.

The problem arises where:

• one GTIN uses several packaging variants,
• the packaging changes without a change to the GTIN,
• several GTINs use the same packaging.

Therefore, it is advisable to have a separate technical packaging identifier independent of the product code.

How to build a packaging configuration identifier?

An example internal system may look as follows:

PKG-SALES-PET500-R3

where:

• PKG – packaging object,
• SALES – packaging level,
• PET500 – technology family,
• R3 – revision.

This is solely an organisational example.

The Regulation (EU) 2025/40 on packaging and packaging waste does not prescribe such a scheme.

It is important that the identifier is:

• unambiguous,
• stable,
• version-controlled,
• linked to the dossier.

Technical documentation should be organised around the packaging, not solely the SKU

Annex VII requires documentation enabling the conformity of the packaging to be assessed.

This includes, among other things:

• description and intended use,
• design,
• materials,
• components,
• standards and specifications,
• relevant assessments,
• test reports.

If 100 SKUs use identical assessed packaging, there is no need to copy the same laboratory report into one hundred separate locations.

A better model:

report → component → packaging configuration → all SKUs using it.

Packaging family – how can variants be grouped safely?

With a large catalogue, internal ‘packaging families’ can be created.

This is not a term defined in the Regulation (EU) 2025/40 on packaging and packaging waste, so the company must define the grouping rules itself.

It is useful to group variants sharing the following within one family:

• manufacturer,
• basic design,
• materials relevant to the assessment,
• closure,
• intended use,
• scope of Regulation (EU) 2025/40 on packaging and packaging waste requirements,
• basis for testing and calculations.

However, each variant in the family should be individually identifiable.

Identical design does not always mean an identical scope of conformity

This is an important pitfall.

Assume that the same paper tray is used:

• for technical screws,
• for sandwiches.

The design may be identical.

However, the intended use is not identical.

In the second case, additional requirements relating to packaging intended to come into contact with food may apply, including the PFAS restriction under Article 5(5).

Therefore, safe grouping requires not only similar geometry, but also a consistent scope of use.

Can SKUs be combined in one PPWR configuration? Matrix

The table presents a practical analysis model, not a closed classification established in the PPWR.

Example: 3,200 SKUs do not have to mean 3,200 separate declarations

The company has:

• 3,200 SKUs,
• 42 basic packaging components,
• 160 controlled commercial configurations,
• 18 transport carton formats.

Incorrect model:

3,200 SKUs → 3,200 folders → 3,200 copies of reports → 3,200 independently updated declarations.

Better model:

42 components → 160 configurations → mapping to 3,200 SKUs → controlled set of documentation and declarations.

The number of declarations then results from the actual scope of the packaging assessed, rather than directly from the number of commercial records.

What should an SKU → packaging → declaration table look like?

Such a table is a practical internal tool and does not constitute a form prescribed by the PPWR.

The greatest benefit of grouping arises when a single component changes

Assume that one label occurs in:

• 17 packaging configurations,
• 240 SKUs.

The supplier changes the adhesive.

In a well-designed system, we change the component record and automatically see:

which 17 configurations require an impact assessment.

There is no need to manually open 240 SKU folders.

This is where the relational model significantly reduces the risk of error.

An SKU should indicate not only the configuration, but also its version

Simply assigning “SKU-001 uses PACK-017” is insufficient if PACK-017 has changed over time.

You need to know:

• from when the SKU used R1,
• when R2 was implemented,
• which batches were still produced in R1,
• which declaration applied to each version.

Practical relationship:

SKU → configuration → revision → period of use → dossier → DoC.

Article 22 of the PPWR and SKUs – do not confuse two types of traceability

Article 22 primarily concerns the traceability of economic operators in the supply chain.

At the request of an authority, an economic operator should be able to indicate, among other things:

• who supplied it with the packaging or packaged product,
• to whom it subsequently supplied it.

This provision should not be taken to mean that:

“each SKU must have its own declaration”.

These are two different issues:

• identification of the subject of the declaration,
• identification of supply chain participants.

What is more important during an inspection than the number of declarations?

The most important thing is the ability to reconstruct the relationship between the actual packaging and its assessment.

For a selected SKU, the company should be able to show:

1. which packaging was used,
2. which version,
3. who its manufacturer was,
4. which components it consisted of,
5. which evidence related to those components,
6. which technical documentation was used,
7. which declaration corresponded to that configuration.

If a company has 10,000 declarations but cannot perform such a trace for one product, a large number of PDFs is of little help.

Can one declaration cover multiple SKUs?

PPWR does not prohibit the use of one assessed packaging solution for multiple products, nor does it require declarations to be duplicated for each trade code.

In practice, one clearly identified packaging configuration may be linked to multiple SKUs if:

• all use the same assessed solution,
• the intended use is the same,
• the technical documentation genuinely covers all cases,
• the company can demonstrate a list of products using the configuration.

This is a practical way to meet the traceability requirement, not a literal PPWR rule entitled ‘SKU grouping’.

Must all SKUs be entered directly in the declaration?

Annex VIII does not contain a separate mandatory field for a ‘list of all SKUs’.

The company may of course decide to use:

• a list of identifiers in the declaration,
• an annex to the declaration,
• a controlled mapping table in the system,
• a packaging family code leading to the relevant mapping.

The selected model should ensure unambiguity and version control.

With thousands of SKUs, entering the full list directly on one page of the DoC is often less functional than controlled mapping in the system.

When should declarations be separated?

Separate scopes are particularly justified where there is a change in:

• manufacturer,
• main material,
• intended use affecting the requirements,
• design,
• packaging level,
• assessment method or result,
• legal or technical basis,
• the body of evidence, making it impractical to maintain one common configuration.

The objective is not the minimum number of declarations. The objective is the minimum number of documents while maintaining an unambiguous and defensible assessment scope.

Most common errors in mapping SKUs and PPWR declarations

• assuming ‘one SKU = one mandatory PDF’;
• the opposite error – one declaration for the company’s entire catalogue;
• grouping all packaging made from the same material;
• no separate packaging identifier;
• using only the product EAN as a technical identifier;
• no distinction between graphic and technical variants;
• ignoring the label, adhesive or closure;
• grouping different capacities without assessment;
• no distinction between sales, grouped and transport packaging;
• no mapping of e-commerce packaging;
• no configuration versioning;
• changing a component without identifying all affected SKUs;
• copying one report into hundreds of folders;
• overwriting an old configuration version;
• treating a ‘declaration per type’ as a literal PPWR-defined rule without determining what the given type is;
• confusing Article 22 on economic operators with an obligation to provide a separate document for each SKU.

PPWR declaration and SKUs – company checklist

1. Export the list of all SKUs.
2. Assign the applicable packaging levels to each SKU.
3. Identify all packaging components.
4. Assign your own technical identifiers to the components.
5. Link the components into actual packaging configurations.
6. Assign version numbers to the configurations.
7. Determine their intended use.
8. Identify the correct manufacturer of each configuration.
9. Check which SKUs actually use an identical configuration.
10. Do not group variants solely on the basis of a similar appearance.
11. Check materials, adhesives, labels, closures and coatings.
12. Check differences in capacity and dimensions.
13. Check differences in intended use.
14. Link the configuration to the technical documentation.
15. Link the configuration to the relevant EU declaration of conformity.
16. Maintain an SKU → configuration table.
17. Maintain a history of configuration changes.
18. Link batches to the production version.
19. Perform an impact assessment whenever a component changes.
20. Do not create a new declaration solely because a new SKU using existing, already assessed packaging has been introduced.
21. However, check whether its intended use changes the scope of requirements.
22. Keep old mappings together with earlier versions of the documentation.

How do you manage PPWR declarations for thousands of SKUs?

With a large portfolio, a model based solely on SKU folders quickly leads to duplication.

The same:

• carton,
• jar,
• adhesive,
• label,
• laboratory report,

may be used in hundreds of products.

Therefore, data should be stored relationally.

Model:

supplier → component → version → evidence → packaging configuration → technical documentation → declaration → SKU.

Then, a new SKU using an existing configuration primarily requires creating a new relationship, rather than copying the entire documentation.

Conversely, once a component has changed, you can immediately identify all SKUs and declarations that may require review.

Does every SKU need a separate PPWR declaration? Summary

No. The PPWR does not establish an automatic rule of “one SKU = one EU declaration of conformity”.

The obligation concerns properly demonstrating packaging conformity and its unambiguous identification.

Therefore, many products may use a common technical basis if they actually use the same assessed packaging and their link to it can be demonstrated unambiguously.

At the same time, one SKU may be linked to several different packaging items:

• sales,
• grouped,
• transport,
• e-commerce.

Therefore, the best model should not look like this:

SKU → PDF.

It should look like this:

SKU → packaging configuration → version → components → evidence → technical documentation → declaration of conformity.

This reduces duplication while retaining the key PPWR requirement: the ability to determine unambiguously which actual packaging a given assessment and declaration concern.

FAQ – PPWR declaration and SKU