EUDR and supplier data: structuring collection in the ERP

This guide addresses the practical question facing IS, Data/Master Data, Purchasing, Quality and Supply Chain teams: how to structure the collection of EUDR supplier data in the ERP and in the master data repositories around it, without rebuilding an Excel file for each buyer. You will find out where each piece of data lives today, why the ERP alone is not enough, a minimal data model, how to link a DDS (Due Diligence Statement) to a lot and a goods receipt, version management, the contribution of AI (artificial intelligence), governance and an operational checklist.

In brief

From plot to lot, and back. The lot exists in the ERP, the origin at the supplier: by default, nothing links them. These three keys make the connection.

EUDR data to collect and where it lives today

Article 9 of the Regulation sets out the list of information and supporting documents to gather for each relevant product, and the European Commission details what due diligence covers. Translated into an IS project, this list breaks down into eight data blocks - which, at most manufacturers, live in five different places.

What these eight blocks have in common: none of them is a new regulatory field to be created from scratch. They are attributes of existing objects - supplier, site, item, lot, document - to which two genuinely new objects are added: geolocation and the DDS.

“[…] the operator shall collect, organise and keep for five years from the date of the placing on the market or of the export of the relevant products the following information, accompanied by evidence, relating to each relevant product […]”Regulation (EU) 2023/1115, Article 9(1) · consolidated text, EUR-Lex

Why the ERP alone is not enough, and what to add to it

The ERP (Enterprise Resource Planning) is essential, but it was designed to manage transactional flows: orders, goods receipts, stock, invoices. EUDR compliance requires something else.

Five building blocks therefore need to plug into the ERP, each with a clear owner and identifier:

1. An origin repository (site and plot), able to store points and polygons in GeoJSON (RFC 7946) and to return them in the format expected by the EUDR information system.
2. An EUDR commodity identifier linked to the item, distinct from the CN code but connected to it, to state unambiguously “this item contains cocoa” or “this item is out of scope”.
3. A versioned document base, with document type, issuer, issue date, expiry date, status and owner.
4. A compliance repository holding the DDS reference, the declaring operator and the products covered.
5. An API exposure point to the EUDR information system, for sending and retrieving references - bearing in mind that the operator API described by the Commission is a SOAP service, and therefore an integration item to scope with the IT department.

To see how a supplier data platform plugs into the ERP, read Tracklab and your ERP: the integration guide.

Minimal data model: six entities and their relationships

You do not need an exhaustive model to get started. Six entities are enough to cover the requirements of Article 9 and to make the file enforceable in the event of an inspection.

Three relationships hold the whole framework together:

• lot ↔ plot: this is the relationship that turns origin data into evidence. A lot can cover several plots (mixing), and a plot can feed several lots.
• lot → document: evidence of legality and attestations are attached to the object they cover, not to a shared folder.
• lot → DDS: each incoming lot must be able to point to the statement reference that covers its origin, at the date of entry.

The EUDR data foundation: three master data repositories, three flow objects, two keys, and the DDS on top. After the dot, the master system for each object.

The classic trap is storing geolocation as an attachment to a supplier record. A geometry is not a document: it must be a queryable object, linkable to lots, with a version.

Linking a DDS to a lot and a goods receipt

This is the operation most poorly handled in practice: the DDS arrives as a PDF, it is archived, and six months later nobody knows which lots it covers. Four steps are enough.

1. Record the DDS as an object. Reference number, declaring operator, submission date, list of CN codes and products covered, country of origin. The PDF is an attachment to this object, not the object itself.
2. Link the DDS to the product lines, i.e. to the ERP items and their CN code, then to the lots concerned. A DDS may cover several lots and several deliveries; an incoming lot must only point to the statement valid at its date of entry.
3. Link the lot to goods receipts and movements. This is the ERP link: which receipt, what quantity, what unit, what date, which warehouse.
4. Check that quantities are consistent. The cumulative quantity of the lots linked to a DDS cannot exceed what the statement covers, unless mass balance traceability is documented.

This level of detail is not decorative: it is what enables a downstream operator to retrieve the DDS reference and keep it, in line with the logic resulting from the 2025 amendment. Identifying the lot by combining GTIN + lot number is a proven convention, described in the GS1 traceability standards.

Versions and document history: what must be tracked

A compliance file is judged on a given date: the date of placing on the market. You must therefore be able to demonstrate what you knew on that date. A file overwritten without history does not allow this.

Three simple rules make this history usable: never overwrite (a correction creates a version), a validity start and end date, an identified author. The expected retention period is five years for the statement and supporting documents. The evidence to present in the event of an inspection is detailed in our EUDR audit checklist.

The role of AI in extracting supplier data

Most EUDR data arrives as unstructured documents: deforestation-free attestations, permits, land titles, plot tables in PDF or Excel, certificates with lot numbers. That is where AI comes in, and nowhere else: turning these documents into structured fields, with their provenance and a confidence level.

Three safeguards are non-negotiable. First, source traceability: for each extracted field, you must be able to trace it back to the document and its page. Second, human validation of data feeding a regulatory statement - Regulation (EU) 2024/1689 on AI also imposes, for certain uses, transparency and human oversight obligations. Finally, write-time control: no extracted data should enter the repository without passing the model's validation rules.

Governance: who updates what, how often, with which controls

Projects rarely fail on technology: they fail on data ownership. Compliance data without an owner is never up to date. Here is a split that works, to be adapted to your organisation.

The discipline that structures all this has a name: MDM (Master Data Management), i.e. the set of rules defining who creates, validates and corrects shared data. For data exchange, the ISO 8000-110:2021 standard provides a useful framework on the quality of master data exchanged between systems.

Four controls, which can be automated, are enough to cover the essentials: completeness (are all the Article 9 fields there?), consistency (quantities, units, countries, dates), freshness (expired or missing documents) and uniqueness (no duplicate supplier or lot of origin).

Common mistakes

1. Treating the EUDR as a legal project. The Regulatory department drafts the procedure, nobody creates the fields in the ERP, and collection remains manual.
2. Creating an “EUDR” Excel file. It duplicates master data, diverges within three months and is not linked to any lot.
3. Storing geolocation as an attachment. A geometry must be a queryable object, not a PDF in a record.
4. Linking the DDS to the supplier rather than to the lot. You then cannot tell which statement covers which delivery.
5. Leaving CN codes at HS6 level. Customs classification determines inclusion; an incomplete code distorts the entire scope.
6. Overwriting versions. Without history, it is impossible to demonstrate what was valid on the date of placing on the market.
7. Automating without human validation. Unchecked AI-extracted data ends up in a regulatory statement.
8. Not appointing data owners. Each field must have an owner, a master system and an update frequency.

Operational checklist

• Scoping the model
• The six entities (supplier, site, plot, lot, document, DDS) are defined with their key identifiers.
• The master system for each field has been decided and documented.
• The ERP item carries an EUDR commodity identifier linked to a complete CN code.

• Collection and linking
• Critical suppliers are segmented and the collection campaign runs through a dedicated channel.
• The expected geographic format (GeoJSON, longitude/latitude, coordinate precision) is enforced and automatically checked.
• Each incoming lot points to its plots of origin and to a valid DDS reference.

• Documents and versions
• The document base manages type, version, issuer, expiry date and status.
• No data is overwritten: every correction creates a version with author and reason.
• Five-year retention is configured.

• Extraction and governance
• AI-extracted fields are traced back to their source document.
• A confidence threshold triggers human validation.
• The four controls (completeness, consistency, freshness, uniqueness) run regularly.

Going further

The EUDR is not won or lost in the text or the timetable, but in the ability to hold supplier data, product data and documentary evidence together. For the full regulatory framework - product scope, deadlines, geolocation and risk assessment - our pillar guide “EUDR: the complete guide to bringing your supply chain into compliance” directly extends this satellite guide.