Packaging BOM Version Control: Why It Matters and How to Do It Right

Packaging changes regularly. A lighter shipper box to reduce material costs. A corrugated board with higher recycled content after switching supplier. A new plastic-free inner tray. Each change is routine from a production standpoint — and each one means that some of the packaging data you have shared with clients is no longer accurate.

The question version control answers is: for any given reporting period, which version of your packaging data applies? If a client is filing a Q3 2025 EPR declaration and your packaging changed in October 2025, they need the version valid through Q3 — not the current one.

Without a proper versioning system, neither you nor your client can reliably answer that question. This article explains the scenarios where versioning matters, what good version control looks like, and how to implement it without overcomplicating things.

Why EPR makes versioning a compliance requirement, not a nice-to-have

Most supply chain data management — prices, specifications, certificates — has informal versioning at best. The latest document supersedes the previous one, and nobody goes back to check historical values.

EPR declarations break this model because they are retrospective and auditable. A brand files a declaration in March 2026 for the calendar year 2025. The declaration must accurately reflect the packaging that was actually sold to consumers during 2025. If packaging changed mid-year, the declaration must use the correct weights and materials for each period.

National authorities can — and increasingly do — audit declarations after the fact. Germany's ZSVR, France's DGCCRF, and Spain's regional authorities all have the power to request supporting documentation for submitted declarations. Brands that receive audit requests trace the data back to their suppliers.

If you cannot show that you provided the client with the correct BOM data for the correct period, the audit trail has a gap — and that gap sits in your relationship with the client.

The four scenarios where versions matter

1. A packaging component changes weight or material

This is the most common case. You switch corrugated board supplier and the new board weighs 12% less. Or you move from a 50g HDPE bottle to a lighter 44g design. Clients using the old weight data will over-declare (and overpay fees) or under-declare (a compliance risk) depending on which direction the change went.

The correct version control response: create a new BOM version with an effective start date. The old version remains accessible and covers any reporting period before the change date.

2. Recycled content certification changes

You obtain a new mass balance certification showing your PET tray now has 30% post-consumer recycled content, up from 0% previously. This is good news — but it only applies from the date you started using the certified feedstock. Your clients cannot retroactively claim the eco-modulation bonus for periods before the certified material was in use.

The correct approach: create a new BOM version with the recycled content updated and an effective date matching when the certified material entered production. Include a reference to the certification. Old shares point to the previous version (0%) for the pre-certification period.

3. A component is added or removed

You eliminate the tissue paper wrap from a product redesign. Or you add a paper insert that was not there before. The BOM itself changes structurally — it is not just a weight or material update.

Create a new version. The component list differs between versions, and clients need to know which version of the product configuration applies to which period.

4. You discover an error in previously shared data

You realise the weight you quoted for the outer shipper was per two-unit pack, not per single unit — meaning you sent clients weights that are twice what they should be. Some clients have already used the data in declarations.

This is the scenario most damaged by poor version control. With versioning, you can create a corrected version, notify affected clients specifically, and they can assess whether they need to file amended declarations. Without versioning, there is no systematic way to identify who has the incorrect data and no documented record of when the correction was made.

What good version control looks like

Version identifier

Each BOM version should have a clear identifier. Simple sequential numbers work well: v1, v2, v3. Avoid date-based version names like "BOM_April2025_final_v2.xlsx" — they are not machine-readable, they invite "final_FINAL" naming chaos, and they cannot be reliably linked to a specific effective period.

Effective date range

Each version should have an effective start date and, once superseded, an effective end date. This creates a non-overlapping, complete timeline:

Given this history, a client filing a 2024 annual declaration needs v1 for January–September and v2 for October–December. A client filing a 2025 H1 declaration needs v2 for January–March and v3 for April–June. This level of precision is exactly what supports a clean audit.

Change notes

Each new version should include a brief note explaining what changed and why. "Outer shipper weight reduced from 210g to 185g — new box design from Sept 2024 production run" is sufficient. This gives clients the context to assess whether the change affects their declaration and, if so, how.

Client notification

When you create a new version, clients with active shares for that product should be notified. The notification does not need to be alarming — a simple "BOM updated for [product name], new version effective [date]" message lets them decide whether to update their data.

Clients using data for a period entirely within an older version do not need to take action. Clients whose current reporting period spans the version change date need to decide how to handle it.

Versioning in practice: avoiding over-engineering

Not every packaging difference warrants a new formal version. Practical guidelines:

• Create a new version for: weight changes of more than 2–3%, material type changes, recycled content changes, addition or removal of components
• Do not create a new version for: label design changes (if the substrate is unchanged), printing colour changes on existing materials, packaging artwork updates that do not change the physical material
• Document minor corrections within a version by adding a note rather than creating a new version — for example, correcting a typo in a component name without changing any values

The guiding question: does this change affect the weight, material type, or recycled content of any component in a way that would change a declaration calculation? If yes, new version. If no, a note is sufficient.

The link between version control and audit readiness

If you receive an audit-related question from a client — "confirm what packaging data you provided us for H2 2024" — a versioned BOM system gives you a clean answer in seconds: version 2 was effective from October 2024, here is the data, here is the effective date. The client can compare their declaration against the correct BOM version and demonstrate consistency.

Without versioning, the same question requires an email search, comparison of multiple spreadsheet copies, and a best-guess about which file was actually used. That is not an answer that satisfies an auditor.

The Pack Declare supplier portal handles versioning automatically — you create a new version with an effective date, old shares remain pointing to the correct historical version, and your dashboard shows the full version timeline per product.

For the broader case against email-and-spreadsheet workflows, see why you should stop sending packaging data by email. For a full overview of how a supplier portal works, see how a supplier portal for EPR packaging data works.