The most common mistake with geolocation data for the EUDR is not that they are missing, but that they exist and still do not meet the requirement. A supplier sends an address, a village name, or a collection point instead of the exact location of the plot where the product was grown or harvested. The data appear complete, but do not cover what the regulation requires: the place where the raw material actually comes from.
This problem often only becomes apparent when the file is being prepared, when coordinates are placed side by side and it turns out that two shipments share the same location, that a point lies in the sea or in the middle of a city, or that the format does not match what is required for the plot size. At that point you must go back to the supplier, which costs time you could have saved earlier in the process.
Why this goes wrong more often than expected
Geolocation data sound technical, but the error usually lies not in the technology: it lies in assumptions. A supplier provides the data he has always kept, for example for his own administration or another certification scheme, and assumes this is sufficient. Often this is an address of the company or of a collection point, not of the plot itself. For small plots the regulation requires a point, for larger ones a polygon that shows the perimeter of the plot. Anyone who does not know this difference will submit the wrong type without anyone noticing until it is checked.
A second recurring pattern is outdated data. A plot that was reported in the last season is automatically reused for the new shipment, while the harvest in the meantime comes from a different piece of land. The coordinates are then technically correct — they are valid, they load on a map — but they do not belong to this shipment.
What happens when it is discovered late
The inconvenient thing about this error is that it does not announce itself immediately. A file with coordinates opens without problems, the map shows a point or an area, and at first glance everything seems to be in order. Only when carefully comparing with the rest of the file — country of origin, supplier, period of shipment — does it become clear that the location does not match. For companies working with multiple suppliers and harvest periods, this type of error can run through several shipments before it is noticed.
This is also why loose coordinates without context say little. A point on a map is only useful if it is clear which shipment, which harvest year, and which supplier it belongs to. Without that link, a file emerges with much data and little certainty.
How to prevent this in practice
The most effective step is to ask early in the process what type of data the regulation requires, rather than working with what a supplier happens to already have. Ask specifically for coordinates of the plot itself, not of the company address, and ask whether it is a single point or a polygon. Establish which shipment and which harvest year the data belong to, so that verification afterwards is not necessary to reconstruct that link.
It also helps to maintain a fixed rhythm per product stream: with each new shipment or each new season, check again whether the location is still current, rather than automatically transferring data. For companies working with many small suppliers, this is precisely the point where a structured file per product stream makes a difference: data are then not viewed in isolation per shipment, but in context with supplier, country of origin, and period. the knowledge base with explanations per topic provides more detail on what is required per raw material.
Whether a submitted location meets the requirements of the Regulation remains an assessment that lies with the operator itself; eudri.com structures and validates the data you provide, but does not declare that a parcel or product is deforestation-free. If you are unsure about your own role in the supply chain and what that means for the data you need to collect, then the role check in a few questions provides a first direction.
Those who after this step want to know how such a file is concretely built — from loosely submitted coordinates to a validated whole per product stream — will find that via the explanation of how the working method fits together. For questions that frequently come up among SMEs who are just starting with geolocation data, the overview with frequently asked questions is also a good starting point.
Do you want to know where you stand before diving deeper into geodata and file building? Take the free quick-scan or browse through the topics in the knowledge base to see which part of this process is relevant for your products.