How Geolocation Data Is Submitted to the Information System

Submit the required production locations

Geolocation information submitted to the EUDR Information System must describe the production plots or cattle establishments required by the regulation. The Commission's interface supports location entry and GeoJSON files, with detailed format rules in the current official technical documentation. The first task is deciding which real production locations belong to the relevant product; choosing a file format comes afterwards.

The operator should distinguish an ordinary due diligence statement from a qualifying primary operator's simplified declaration. Article 4a permits the prescribed postal-address alternative in its own regime. That does not create a general right for every importer to replace production geolocation with a supplier's office address because coordinates are difficult to obtain.

Gather locations at the appropriate level

For ordinary plot-based production, the EUDR definition specifies latitude and longitude using at least six decimal digits. For plots of more than four hectares used to produce commodities other than cattle, polygons describe the plot perimeter. Cattle information concerns the relevant establishments where the animals were kept. The information must remain connected to the commodities and products it is intended to cover.

A cocoa cooperative may provide a file containing hundreds of member plots. The importer needs to establish whether that file is the relevant origin set for the purchased products or simply the cooperative's complete membership database. Uploading every available coordinate can conceal the absence of a reliable product-to-origin connection and can introduce unnecessary data into the submission.

Prepare the file against the current specification

GeoJSON has its own structure and coordinate conventions. Use the official EUDR file description and validation documentation for the actual accepted properties and geometry. Do not assume that an export accepted by a desktop mapping programme will be accepted unchanged by the Information System. Equally, do not rename a spreadsheet file with a GeoJSON extension and expect the system to interpret it.

Check coordinate order carefully. A common source of errors is confusing the latitude-and-longitude order used in conversational descriptions with the longitude-and-latitude order used by GeoJSON coordinate arrays. Inspect a sample on a map before importing a large file. A point in the sea or another continent can be structurally valid JSON while being factually impossible for the intended production site.

The Information System guide explains why technical entry and the due diligence conclusion are separate steps. Keep the original supplier dataset and the transformed submission version so a later reviewer can understand what changed during preparation.

Validate geometry and meaning separately

Technical checks should consider whether the geometry is correctly formed, rings are closed where required, coordinates are within valid bounds and the file follows the current accepted schema. Factual checks consider whether the land matches the supplier and country, whether the required area is represented and whether the plot can be connected to the goods. Neither category replaces the other.

For example, software can fix an invalid polygon ring without establishing that its vertices follow the actual production boundary. Ask who approved any material geometric correction and whether the corrected shape still matches the source evidence. Preserve that decision rather than silently replacing the supplier file with a cleaner-looking drawing that nobody has verified.

Handle multiple origins without losing traceability

Where a product contains or is made from commodities from different plots, the applicable origins must be represented. Design the internal data structure to retain the relationship between country, production location and product line. A single undifferentiated folder of map files is difficult to use when different products in one statement draw from different origin sets.

Where the same location data is reused, check that it remains current for the specific transaction. Reuse is a data-entry convenience, not proof that a new delivery came from those places. Supplier changes, boundary corrections or cattle movements can require a fresh review. Keep a version identifier or dated record for the source file and the reviewer who authorised its use.

Testing, submission and correction

Test complex files in the acceptance environment before relying on them for production operations. A test result does not itself create a legally usable production statement. Verify that the production submission contains the intended locations, retains the correct product associations and produces the expected outcome. Avoid testing with unnecessary personal or commercially sensitive information when representative test data will serve the purpose.

If an error appears, use the Information System troubleshooting process to distinguish a file-format rejection from missing permissions or a blocked amendment. If an incorrect origin file has already been used for a submitted statement, assess the applicable correction and notification duties. Merely fixing the master mapping file will not change a legal record already submitted to the system or resolve products previously released against inaccurate information.

Check the coordinate reference system as well as the numbers themselves. The official GeoJSON description uses WGS 84 decimal-degree coordinates. A dataset exported in a national projected grid requires a proper transformation; changing the field labels does not convert its values. Retain the transformation method and inspect sample locations afterwards. This provides a reproducible explanation when a reviewer compares the submitted coordinates with the supplier's original mapping records.