If you sell packaged goods into multiple European markets plus the UK, you are reporting to multiple EPR schemes. Each scheme has its own material categories, its own reporting format, its own portal, and its own deadlines. Managing this across spreadsheets is where things break down.
The format problem
Every EPR scheme requires data in a different shape. This is not a theoretical concern - the formats are materially different:
- Germany (LUCID / Zentrale Stelle) requires XML using VerpackG material codes. Code 02 is PPK (paper, card, cardboard). Code 03 is ferrous metals. Code 04 is aluminium. Code 05 is plastics. Code 06 is wood. Code 07 is composite packaging (Sonstige Verbundverpackungen). The system also requires LUCID registration numbers and volume data per material code
- France (CITEO) requires CSV with component-level breakdowns per CSU (conditional sales unit). Each component row includes material, weight, and format data, plus eco-modulation bonus and malus flags. CITEO also expects a separate household vs commercial split
- UK (RPD / Environment Agency) requires CSV in the RPD upload format, broken down by material type, packaging level (primary, secondary, transit), and activity type. The UK also requires separate Plastic Packaging Tax data for HMRC
- Belgium (Fost Plus) uses the MyFost portal with its own material categories and volume bands
- Spain (Ecoembes) requires Excel uploads with data split across seven tabs
- Italy (CONAI) uses online forms with material-specific fee bands
- Netherlands (Afvalfonds / Verpact) uses the PackTool with weight-based declarations
- Austria (ARA) uses ARA Connect with its own material classification
The material mapping problem
The deeper issue is that material categories do not map 1:1 across schemes. Aluminium in one scheme might be bundled with "metals" in another. Composite packaging - packaging made from multiple bonded materials - is categorised differently in nearly every jurisdiction. A plastic-coated paperboard tray might be "composite" in Germany (code 07), "paper with barrier" in France, and "plastic" or "card" in the UK depending on the dominant material by weight.
If you are managing this in spreadsheets, you are maintaining parallel material mappings for every jurisdiction. One wrong mapping and your declared volumes are wrong. Wrong volumes mean wrong fees - either overpaying or, worse, underdeclaring and facing penalties.
The same problem applies to packaging levels. Some schemes require primary/secondary/transit classification. Others want household vs commercial splits. Others want both. The definitions of what counts as "primary" or "transit" packaging can differ between schemes.
The single-data-set approach
The solution is to capture packaging data once at the component level - material, weight, format, dimensions, recycled content - and let the system handle the mapping to each scheme.
When you record a component as aluminium with a specific weight, the system knows that this maps to the aluminium material type for Germany, to the correct CITEO material row for France, and to the RPD aluminium category for the UK. You do not need to know the scheme-specific codes. The system maps them.
When you generate an export, the output is in the exact format the scheme requires. XML for LUCID, with the correct element structure and material codes. CSV for CITEO, with component-level rows and eco-modulation flags. CSV for RPD, in the Environment Agency upload format. Each export draws from the same underlying data, so your declarations are consistent across jurisdictions.
Cross-export consistency
This is the part that spreadsheets cannot guarantee. When every export draws from the same component-level data, a component recorded as aluminium stays aluminium whether you are exporting to LUCID, CITEO, or your recyclability assessment. There is no reconciliation step, no cross-checking between jurisdiction-specific spreadsheets, no drift between one declaration and another.
If a component is updated - say a supplier changes a material weight or corrects a recycled content figure - every subsequent export reflects that change. You are not patching data in six different spreadsheets.
Schemes supported
Merchant Packaging generates scheme-specific exports for:
- Germany - LUCID XML and Excel exports (VerpackG material codes)
- France - CITEO CSV and Excel exports (component-level with eco-modulation)
- UK - RPD CSV (Environment Agency format), Plastic Packaging Tax exposure report, Supplier Data Hub export
- Italy - CONAI declaration (modulo 6.2)
- EU-wide - PPWR Declaration of Conformity
Each export uses the format, material categories, and structure required by the scheme. You review the output and submit through the relevant portal. The data behind every export is the same.
Merchant Packaging does not produce outputs for other schemes, such as Belgium (Fost Plus), Spain (Ecoembes), the Netherlands (Verpact), Austria (ARA) or Ireland (Repak). For those, the component materials and weights a declaration is built from can be exported as CSV or Excel.