A Danish distributor changes the protective insert used for a product. Purchasing uploads a new specification. The warehouse finishes its remaining stock of the old insert before switching. Months later, an analyst multiplies annual product sales by the latest packaging weight and calls the result a report.
The arithmetic may be correct for the selected inputs. The inputs may describe packaging that was never used for part of the year. This is the buying problem behind packaging data software: connecting what the business actually put into circulation with the classification, measurement and evidence used in its report.
Put the reporting owner in the design meeting
Dansk Producentansvar's packaging guidance states that businesses subject to producer responsibility must register and report annually on packaging quantities placed on the Danish market. Applicability depends on the business and its role. Software should implement a reviewed interpretation of that scope, rather than classify a company solely because it sells physical goods.
The DPA legislation overview also describes the developing Danish and EU framework, including the Packaging and Packaging Waste Regulation's applicability from August 2026. Individual provisions and reporting obligations need their own assessment. This article uses the official material reviewed on 12 October 2026 to frame a data project, not to promise legal compliance from an ERP connector.
Bring purchasing, warehouse operations, finance and the reporting specialist together. Each controls a different part of the evidence. If the project is owned only by the team that exports the final spreadsheet, missing upstream information will become an annual manual exercise.
Treat packaging as a versioned specification
A saleable product can have a bottle, lid, label, grouped pack, shipping carton and protective fill. Model the components your business actually needs to report. Give each specification a version, source, measurement unit, reviewer and effective period. Preserve the supplier document or measured evidence used to approve it.
Do not overwrite a component's weight when a supplier changes its design. Create a revision and decide how the transition is recognised in purchasing or fulfilment. Where old and new stock overlap, a date alone may not identify the version that shipped. Batch information, a packing configuration or an explicit estimation policy may be needed.
Unknown is a useful status. If a supplier has not provided a measurement, mark the gap and assign it to an owner. Filling the field with zero makes the form pass validation while hiding a problem that will return during reporting.
Describe the packing decision at the right level
An ERP product line does not necessarily describe the outbound packaging. A warehouse may combine several products in one carton or split a large order into multiple parcels. An integration should capture the packing configuration at the level where the decision is made.
Start with a practical source: the warehouse system's carton selection, a dispatch record or a small operator screen. The project does not automatically need cameras, scales and a new warehouse platform. First establish which reliable events already exist and which missing field would make them useful.
For an illustrative test, use an order containing several products that share one outer carton. The report should not count that carton once for every product line. Then split the order and show how the actual packing records change the result. These two demonstrations reveal more than a polished chart of estimated annual tonnage.
Keep classification separate from observation
DPA's explanation of packaging types distinguishes sales, grouped, transport and service packaging. It also explains that using an item repeatedly does not by itself establish the legal classification of reusable packaging. The design and the return system matter.
Record observable events such as a crate dispatch or return independently of the approved classification. A specialist can then revise a classification with a reason while the warehouse history remains intact. The software should show which classification version a calculation used.
This separation is particularly helpful when a business introduces a returnable packaging scheme. Operational tracking can begin with asset or pool identifiers, dispatches, returns and losses. Whether and how those records feed a specific report remains an explicit reporting decision, not a hidden formula embedded in a scanner application.
Build a report that can explain its totals
The reporting screen should let a reviewer move from a total to the contributing transactions and specification versions. Show excluded records, unresolved mappings and the assumptions applied. A neat total without a traceable calculation is difficult to defend or correct.
Decide how adjustments work before exporting. A corrected supplier weight may affect historical calculations, while a new packaging design may apply only to later shipments. Those changes should not share the same “update all” button. Save the previous report version and explain why a replacement differs.
Export a reconciliation package alongside the submission file: source references, calculation version, review decisions and exception counts. Use whatever submission channel the responsible reporting organisation actually supports. Do not pay for a supposed automatic filing API until the supplier can demonstrate access, documented capabilities and the required authorisation.
Choose a pilot that exposes the difficult cases
Select a product family with a manageable mix of packaging and at least one real specification change. Include domestic and other destinations where relevant to the agreed scope, a shared outer carton and an unresolved supplier record. Use these as acceptance cases, not as reasons to postpone the pilot until the catalogue is perfect.
The supplier's quote should separate source-system access, initial data preparation, calculation rules, review screens and ongoing maintenance. Ask who owns updates when a reporting scheme changes its export format. Keep credentials and data exports accessible to the business so that the integration remains supportable after handover.
Our Danish bookkeeping migration guide explores a related challenge: preserving the explanation behind a balance. The software discovery deliverables guide helps define the source mapping and acceptance evidence before implementation.
TuniCyberLabs can connect these records through custom software development. Share an anonymised packaging specification, a dispatch export and your reporting template to scope a focused integration around the information you already have.