From ERP to EPR: packaging data across EU markets
Packaging reporting becomes easier to manage when the figures stay connected to the products, packaging versions and actual movements behind them — across departments and markets.
Purchasing has the supplier specifications. Production knows which packaging belongs to each product. The warehouse records what was packed and dispatched. Sales knows the customer and destination. At the end of the quarter, someone has to bring those facts together again.
For a company selling in several European countries, repeating that exercise for each market adds work. A changed carton weight, a duplicated delivery or a correction in the warehouse can affect more than one reporting file.
Kodo now offers packaging EPR automation through connected business systems. We design and implement API connections across purchasing, production, warehouse and sales, bringing the relevant records into one application. The shared evidence can support calculations and reporting preparation for several agreed EU markets.
EPR means extended producer responsibility. This article focuses on the packaging data needed to prepare that work: what was supplied, which packaging it used, where it went and how the quantities were calculated.
Connect the records where they originate
An ERP is a system for managing business resources and transactions. An API is an interface that lets software exchange data. Together with production and fulfilment applications, these systems can provide much of the evidence already created during everyday work.
The useful improvement is a recurring connection: new records and changes feed into packaging calculations without someone repeatedly exporting and copying the same fields.
| Business source | Information it can contribute |
|---|---|
| Purchasing and suppliers | Packaging specifications, materials, component weights and supplier references |
| Production and product records | Bills of materials, product variants, packaging combinations and consumption |
| Warehouse and fulfilment | Actual movements, dispatches, shipping packaging and return records |
| Sales and accounting | Quantities, customer destinations, responsible companies and corrections |
The design follows the way your company works. Several departments may use one ERP, or the warehouse may run a separate application. We establish which system holds each fact and how the records relate.
From API records to reporting preparation
Loading diagram…
Read diagram as text
flowchart TD
PUR["Purchasing and suppliers<br/>Packaging specifications"]
PROD["Production and products<br/>Bills of materials and variants"]
WH["Warehouse and fulfilment<br/>Movements, packing and returns"]
SALES["Sales and accounting<br/>Deliveries and corrections"]
PUR --> API
PROD --> API
WH --> API
SALES --> API
API["Agreed API connections<br/>New and changed records"]
API --> DATA["Kodo application<br/>Products, packaging versions and sources"]
DATA --> CHECK["Ongoing checks<br/>Units, duplicates, gaps and conflicts"]
CHECK --> CALC["Supported calculations<br/>Materials, periods and relevant flows"]
CHECK --> OPEN["Open items<br/>Missing evidence and affected results"]
CALC --> PORTAL["Your portal<br/>Results, sources and processing status"]
OPEN --> PORTAL
PORTAL --> CLOSE["Review and approve the period<br/>Reporting records and revision history"]
classDef source fill:#ffffff,stroke:#ded5ca,color:#282623;
classDef connection fill:#e8ded1,stroke:#c7b8ac,color:#282623;
classDef central fill:#282623,stroke:#282623,color:#f8f4ed;
classDef review fill:#ece2e5,stroke:#c2adb3,color:#57373f;
class PUR,PROD,WH,SALES,PORTAL source;
class API,CALC connection;
class DATA,CLOSE central;
class CHECK,OPEN review;The agreed connections feed ongoing checks and calculations. Open items remain visible alongside the results they affect.
The agreed workflow has six connected stages.
- Read new and changed records. API connections collect the relevant updates from selected systems at an agreed frequency. Importing the same record again updates its processing rather than creating another delivery.
- Connect products and packaging versions. Product and shipment identifiers link to documented packaging components. A new carton specification retains its effective period, so earlier deliveries keep their original packaging version.
- Check the evidence. Controls identify inconsistent units, duplicate records, missing components and conflicts between sources. A weight recorded in grams must be converted correctly before it is combined with quantities in kilograms.
- Calculate by actual movements and country. Processing connects quantities with the packaging actually used, the relevant period, responsible company and agreed country rules. Country allocation considers the physical and commercial flow, rather than relying on a billing address alone.
- Show results and open items in the portal. The overview separates supported calculations, working figures and unresolved questions. You can follow a total back to its source records and see which results a missing specification affects.
- Prepare the reporting records. After review and approval, the agreed outputs are prepared for the relevant country and reporting system. The approved period is preserved; a later correction creates a traceable revision.
A missing weight remains an open item, with its effect visible. It does not silently become zero. Supported records can continue through processing while the missing evidence is resolved.
Shared evidence, calculations adapted to each country
A common packaging catalogue can serve several European markets. The product reference, documented component weight and history of a packaging change should not have to be reconstructed independently for every country.
Local adaptation goes deeper than placing a total into a different form. Packaging classifications, calculation rules and reporting requirements can differ. For each agreed country, the implementation establishes how the shared records must be selected, classified and calculated.
The European Commission’s packaging overview explains the wider EU framework. The operational task is to connect that context with the requirements relevant to your products, companies and markets.
Kodo offers this service to companies operating across the EU. We agree the countries, source connections and required outputs individually. One set of source connections can then support several country workflows, with results and unresolved items organised in the same portal.
Loading diagram…
Read diagram as text
flowchart TD
SYSTEMS["Your business systems<br/>ERP, purchasing, production, warehouse and sales"]
SYSTEMS --> API["API connections to Kodo<br/>Agreed sources and update frequency"]
API --> SHARED["Shared packaging records<br/>Products, weights, versions and actual movements"]
SHARED --> CZ["Czechia<br/>Relevant classifications and calculations"]
SHARED --> DE["Germany<br/>Relevant classifications and calculations"]
SHARED --> EU["Other agreed EU countries<br/>Relevant classifications and calculations"]
CZ --> PORTAL["One portal<br/>Country results, source evidence and open items"]
DE --> PORTAL
EU --> PORTAL
classDef source fill:#ffffff,stroke:#ded5ca,color:#282623;
classDef connection fill:#e8ded1,stroke:#c7b8ac,color:#282623;
classDef central fill:#282623,stroke:#282623,color:#f8f4ed;
classDef country fill:#ece2e5,stroke:#c2adb3,color:#57373f;
class SYSTEMS,PORTAL source;
class API connection;
class SHARED central;
class CZ,DE,EU country;Shared evidence supports country-specific outputs. Countries and processing rules are agreed individually; representation and report submission are arranged separately.
An illustrative example: one carton change, three markets
Imagine a homeware manufacturer supplying ceramic mugs to Czechia, Germany and Austria. This is a fictional example, not an existing client implementation.
Its ERP identifies the products and sales. Production records the retail packaging. A fulfilment system records each dispatch and the shipping carton added at the warehouse.
During the period, the manufacturer changes its retail carton from 80 g to 65 g. The evidence establishes that 4,000 delivered products used the earlier carton and 2,000 used the later version. For this component alone, the control calculation is:
4,000 × 80 g + 2,000 × 65 g = 450 kg.
Applying the latest weight to every delivery would produce 390 kg and lose 60 kg from this component’s calculation. Preserving the actual version prevents that particular mistake.
The 450 kg is a cross-market control total for one component, not a finished national reporting figure. The workflow allocates the underlying movements to the appropriate companies and countries, applies the agreed local treatment and keeps shipping cartons and other components identifiable.
If a warehouse correction arrives later, the affected working calculations update. If a period has already been approved, the correction remains visible as a revision rather than silently replacing the earlier result.
What changes for the team
The practical benefit is less repeated handling of the same information. Purchasing can resolve a missing supplier weight against the affected component. The reporting team can see which country calculations depend on it. A manager can distinguish a prepared result from a total still awaiting evidence.
The portal also shows connection status and the time of the last successful update. That helps the team recognise whether a change has reached the calculation, rather than assuming that every figure is current.
The aim is fewer repeated exports, earlier checks and easier investigation of corrections. The benefit depends on the current process, the available data and the scope of the implementation.
Start with a defined part of the business
An initial assessment covers your systems, available APIs, identifiers, packaging records and target countries. From that, we define the connections, checks, outputs and update frequency.
We then validate the workflow against a selected period, comparing calculations with supporting records and explaining differences before routine operation. You can begin with one company, site or product group and extend the scope as the process is established.
For the first discussion, prepare the system names, information about API availability, a sample data structure, the countries involved and a description of your reporting process. Keep passwords and API keys out of the enquiry.
Setup and ongoing operation receive separate quotations. The scope reflects the systems, data quality, packaging variants, companies, countries and required outputs. Historical periods can be included by agreement.
Agree the handover into reporting
Data automation, representation and submission have distinct responsibilities. The automation service prepares the agreed records and calculations. Representation and report submission are arranged separately according to the country and service scope.
Your company supplies and confirms the factual source information and resolves questions about its products and movements. The agreed reporting process identifies who reviews the outputs and who is authorised to submit them. Existing registrations or representatives can remain part of that arrangement.
Frequently asked questions
Can one integration support several EU markets?
Yes. Shared source connections and packaging records can support several agreed country workflows. Each market’s classifications, calculations and reporting requirements are addressed in the implementation.
Do we need all departments to use the same software?
No. The design can connect separate purchasing, production, warehouse and sales applications, or relevant records from one ERP. We assess available APIs and the information each system actually holds.
What happens when a weight or packaging specification is missing?
The affected item is flagged, with the reason and impact on calculations. A missing weight is not treated as zero. The implementation also establishes how the evidence will be completed.
Does the integration submit every country’s EPR report?
Report preparation, submission and representation follow the agreed scope. Connecting source systems does not by itself appoint a representative or authorise submission in another country. We agree those responsibilities separately.
How is the service priced?
Initial implementation and ongoing operation are quoted separately. Pricing depends on API availability, source complexity, data quality, packaging variants, companies, countries and outputs. The first step is an assessment of your systems and sample records.
The main conclusion
Choose a product group and reporting period, identify where its packaging and movement records originate, and map the countries that need outputs. That gives an integration a clear starting point and a result that can be checked against evidence.
How Kodo can help
Kodo designs and implements packaging EPR data automation for companies operating across EU markets. We connect agreed business systems, establish the processing rules and provide a portal view of calculations, source evidence and open items. Country coverage, reporting preparation and ongoing operation are defined for your business.
For legal, tax, regulatory, certification and investment-incentive matters, companies should work with qualified specialists and the responsible authorities.
Discuss your systems and target countries with Kodo.
Related reading
- Czech packaging EPR: a client portal and API data flow
- Czech packaging EPR: a data review before reporting
- Czech e-commerce operations: from order to EPR report
Sources
Service scope and public offer checked on 21 October 2026. The example is illustrative; its figures do not describe a client or establish country-specific reporting treatment.
- Kodo: packaging EPR automation and EU country workflows
- European Commission: packaging and packaging waste
This article explains a data-automation service. Applicable packaging requirements, reporting treatment and submission responsibilities must be confirmed for the relevant companies, countries and periods.
