Every time you click Generate declaration pack in Pack Declare, the system produces a ZIP bundle with six artefacts inside. One of them is your declaration itself — every figure the PRO's form asks for, in that portal's own categories and order; the other five are for you, your accountant, and any future auditor.
This article opens the ZIP and explains every file. If you've ever wondered what actually lives inside, or what to keep forever vs. throw away, this is for you.
The ZIP in one picture
pack-declare-FR-2026Q1.zip ├── totals.csv # Your CITEO figures, in CITEO's categories ├── totals.xlsx # Human-readable spreadsheet ├── summary.json # Machine-readable period summary ├── issues.json # Warnings & blockers detected during compute ├── evidences.json # Audit trail: what sales + BOMs drove the numbers └── documents-index.json # Metadata for the whole pack (hashes, dates, versions)
Everything is SHA-stable: regenerating the pack from the same inputs always produces byte-identical outputs. That matters for audits — you can prove that the figures you declared in April are exactly the ones Pack Declare produced.
totals.csv — your declaration, in the portal's dialect
This is the declaration itself. Each PRO asks for the same underlying information (what kind of packaging, how much of it, for which period), but structures it differently — and most portals are web forms you fill in, not file uploads:
- LUCID (Germany) is a form with exactly eight material categories — glass, paper/cardboard, ferrous metals, aluminium, beverage cartons, other composites, plastics, and other materials — in kilograms.
- CONAI (Italy) is an online grid with tonnages to three decimals per material, with plastics split into contribution bands (fasce).
- Verpact (Netherlands) is a matrix of packaging types × materials, with rigid and flexible plastic reported separately.
- CITEO (France) declares consumer sales units (UVC) plus weights per material — with a simplified flat-rate track for small declarants.
Pack Declare's country adapters handle that dialect translation for you: totals.csv arrives with your figures already aggregated into the exact categories, units, and order that country's form uses, so filing is copying numbers across — minutes, not days. When a PRO changes its categories, we ship a new adapter version and your next pack picks it up automatically. And where a portal offers a genuine machine path (LUCID's XML interface, CITEO's per-UVC Excel template for large declarants), that's what the adapter targets on our roadmap.
totals.xlsx — your internal spreadsheet
The exact same numbers as totals.csv, but in a spreadsheet format your finance team can open in Excel / Google Sheets / Numbers without any import fiddling. Columns are labelled in English regardless of the country adapter so it's readable by anyone on your team.
Keep totals.csv next to the portal when you file; the XLSX is the same data for your team's records.
summary.json — the pack at a glance
A small JSON document with the headline numbers:
{
"country": "FR",
"periodStart": "2026-01-01",
"periodEnd": "2026-03-31",
"totalWeightKg": 872.451,
"byMaterial": {
"CARDBOARD": 421.002,
"PLASTIC": 184.310,
"PAPER": 267.139
},
"byLevel": {
"PRIMARY": 720.001,
"SECONDARY": 121.450,
"SHIPPING": 31.000
},
"computeRunId": "run_2a9f…",
"generatedAt": "2026-04-24T14:20:11.003Z"
}Useful when you just want to cross-check totals against your finance dashboard without opening a spreadsheet.
issues.json — what we couldn't fully resolve
Compliance software that pretends everything is perfect is software that will one day lie to an auditor. Pack Declare intentionally surfaces every gap or ambiguity in the compute run:
- Sales lines with no matching BOM (typically a newly-added SKU where nobody's configured packaging yet).
- BOM components missing a recyclability flag (blocks eco-modulation optimization).
- Shipping packaging not configured for the country (means transport-layer weights default to zero — flagged as a warning).
- Potentially hazardous substances above threshold (heavy metals >100 mg/kg; PFAS on food-contact above 25 mg/kg).
Issues don't block the pack from generating — that's a deliberate product decision. A partial declaration filed on time with a known gap is usually better than no declaration at all. But issues.json lets you fix the root cause before the next period.
evidences.json — the audit trail
The most important file for defensibility. evidences.json contains every input that produced the totals.csv:
- The exact compute run ID, hash, and algorithm version.
- Which sales orders were aggregated (by ID, not by value — keeps the file small).
- Which BOM version was active for each SKU during the reporting period.
- Material subtype mappings that were applied (ALUMINIUM → Aluminium, CARDBOARD:CORRUGATED → Wellpapp, etc.).
- Every shipping packaging profile that contributed transport weights.
Pair this file with your sales order database and the adapter version (from documents-index.json) and you can always reproduce the exact numbers we filed, even three years later. That's what audit-proof looks like.
documents-index.json — the manifest
A tiny index file with SHA-256 hashes for every other file in the ZIP, the adapter version used, and the tenant's compliance profile at the moment of generation. If someone edits any of the other files, the hash mismatch tells you immediately.
This file is also what the T-56 audit packet uses to prove that the declaration-pack.zip inside the audit bundle is byte-identical to what your merchant downloaded.
What to keep, what to throw away
- Keep forever: the whole ZIP. Storage is cheap; reconstructing evidence after a regulatory request is expensive. Pack Declare keeps them for you by default, but you should also archive them to your own storage.
- Keep for the filing: just the totals.csv — the figures you entered in the portal. Save the portal's confirmation receipt separately — and better, record it in Pack Declare via Mark as submitted so it becomes part of the audit packet.
- Ignore: nothing. The files are small (typically <1 MB for the whole ZIP). Just keep the bundle.
How to inspect a pack yourself
You don't need special tools — any OS with unzip and a text editor works:
unzip pack-declare-FR-2026Q1.zip cat summary.json | jq . # Headline numbers cat issues.json | jq '.items[]' | head # Warnings, one per line wc -l evidences.json # Sanity-check the evidence count shasum -a 256 totals.csv # Compare to documents-index.json
The same shasum output shown in documents-index.json should match exactly. If it doesn't, the pack has been tampered with — re-generate from Pack Declare instead of trusting it.
Bottom line
A declaration pack is not a black box: it's six files with a clear purpose each. The CSV is what the PRO ingests. The other five are your audit trail. Read them at least once so you know what you're sitting on.
Run the 2-minute Pack Declare Readiness Check →
Related reading: EPR for e-commerce · Preparing for an EPR audit · The Packaging BOM guide