A supplier portal for packaging data is a tool that sits between the manufacturer and the brand clients who need BOM data for their EPR declarations. Instead of data travelling by email and spreadsheet attachment, the manufacturer enters it once into the portal and clients access it on demand.
The concept is straightforward, but the implementation details matter. This article explains how the data flow works end-to-end, what the core features of a good supplier portal look like, and what to evaluate before committing to one.
The data flow: from manufacturer to PRO
Understanding where a supplier portal fits requires seeing the full compliance data chain:
- You (manufacturer) produce and/or supply packaged goods. You know the material composition and weight of every packaging component.
- Your brand client sells those products to EU consumers. They are legally required to declare packaging quantities to national Producer Responsibility Organizations (PROs).
- The PRO (LUCID/dual system in Germany, CITEO in France, ECOEMBES in Spain, etc.) collects the declaration, invoices the eco-contribution fee, and funds recycling infrastructure.
The supplier portal sits at step 1→2: it is the mechanism by which your BOM data travels to your client in a structured, traceable, version-controlled way. The portal does not interact with PROs directly — that is your client's compliance software's job.
Core features a supplier portal must have
BOM entry and management
The portal needs a structured way to enter packaging BOMs per product. Each BOM entry should capture:
- Product identifier (SKU, EAN, or your own reference)
- Components: component name, material type, weight per unit (g), packaging level, recycled content (%)
- Version number and effective date
- Optional notes (e.g., certifications, material grade)
The entry interface should make it fast to add multiple components per product, and ideally allow reuse of common components across products (e.g., the same corrugated shipper used by 20 SKUs entered once and linked to each).
Share workflow
Sharing should be a single action: select the product, enter the client's email or name, confirm. The client receives either:
- A push share — you proactively share the BOM, they receive a notification with a preview link
- A pull request response — the client sends you a formal data request through the portal, and you respond from your dashboard
Both should result in the client having a clean, importable view of the BOM data. The share link should be stable — if the client bookmarks it or their compliance system imports from it repeatedly, it should continue to work.
Version control
This is non-negotiable. The portal must support multiple versions of the same BOM with effective dates. When you create a new version:
- Active shares pointing to the previous version should continue to work and continue to show the correct historical data
- New shares default to the latest version
- Clients can see the version history and select which version applies to their reporting period
Without this, a packaging change silently overwrites the data your clients received — and their previous declaration is no longer supportable.
Share dashboard
You need to know what you have shared, with whom, and whether it has been accessed. A share dashboard should show:
- All active shares, by product and client
- Date of last access (has the client actually looked at the data?)
- Import status (has the client imported the data into their system?)
- Pending incoming data requests and their status
This replaces the "did my email arrive?" uncertainty and gives you documented evidence of data delivery for audit purposes.
Export / download options
Not all clients use compliance software that can import directly from a supplier portal. The portal should allow clients to download BOM data as CSV or a standard format so they can use it however they need to. It should also allow you to export your full BOM library for your own records.
Features that are nice to have but not essential
- Multi-language support — useful if you work with clients across multiple EU countries in different languages
- Bulk BOM import — if you have a large product range and existing data in spreadsheets, the ability to import your existing data via CSV rather than entering product by product
- Client organisation accounts — if you want to give multiple contacts at the same client company access to your data
- API access — relevant only if your own systems will push BOM updates automatically
What to avoid
Portals that charge suppliers
The commercial logic of packaging compliance software is that brand owners pay — they have the regulatory obligation and the financial incentive to comply. Suppliers provide data as a service to their clients. A portal that charges suppliers creates friction, reduces adoption, and ultimately harms the brand clients who need the data.
Any supplier portal worth using is free for suppliers. If a vendor charges both sides, look elsewhere.
Portals locked to a single compliance platform
If the portal only works for clients using one specific compliance software, it limits your usefulness. Your clients use different tools — some use Pack Declare, some use other EPR software, some manage their declarations manually. Your supplier portal should be able to share data with any client, not just clients on the same platform.
No version control
Already covered above, but worth repeating: a portal without proper version control is not materially better than email for audit purposes. It may reduce the format-chaos problem but does not solve the data integrity problem.
How the request workflow works in practice
The two share modes — push and pull — cover the two real-world scenarios:
Push share (you initiate): You have added a new product to your range, or you are proactively distributing updated BOM data after a packaging change. You select the affected products, select the clients to notify, and send shares. Clients receive a notification and can import the data at their convenience.
Pull request (client initiates): A client needs your data for their quarterly declaration. Instead of sending you a vague email, they send a formal data request through the portal — specifying which products they need data for. You see the request on your dashboard, respond by sharing the relevant BOMs, and the client's request is marked as fulfilled.
Both modes create a timestamped record of the data exchange — who requested what, when you responded, what version was shared.
Setup time and ongoing effort
Setting up a supplier portal with a full BOM library for a product range of 30–50 SKUs typically takes two to four hours, depending on how much of your data is already structured. If you have existing spec sheets in a consistent format, the entry is mostly transcription.
Ongoing effort after setup: responding to new requests takes under a minute per client per product. Updating for packaging changes takes five to ten minutes per product — one new BOM version with an effective date. Quarterly, there is nothing to do for existing clients with active shares.
The Pack Declare supplier portal covers all the core features described here and is free for suppliers. Your brand clients who use Pack Declare can receive and import your BOM data in one click. Clients who use other tools can download your data in CSV.
For why the email/spreadsheet workflow fails as volumes grow, see why you should stop sending packaging data by email. For how BOM versioning works specifically, see packaging BOM version control: why it matters.