Your supplier spent weeks collecting geo-data from hundreds of smallholder farmers. The file arrives with coordinates, farm boundaries, farmer names, plot IDs, area measurements, harvest dates, certification codes, elevation readings, soil types, and a column labelled "notes" that someone evidently used for personal reminders. The file is thorough. The supplier is proud of it.
When you upload that file to the EUDR Information System as part of a Due Diligence Statement, the system reads the coordinates. It reads the geometry. And it reads — at most — four properties. Everything else is discarded without warning, without error, and without any indication that it was ever there.
What the specification actually says
The EUDR GeoJSON File Description, version 1.5, is a publicly available document that defines what the Information System accepts. It is unambiguous on this point. A GeoJSON feature submitted to the system may include properties — but the system recognises only four of them, all optional.
"ProducerCountry" — ISO 3166-1 alpha-2 country code (optional)
"ProductionPlace" — name or description of the production place (optional)
"Area" — area in hectares, for Point geometries only (optional)
Everything else — silently ignored
No farm ID. No harvest date. No certification reference. No elevation. No variety. No lot number. None of the operational data that a supplier typically includes in a geo-data file has any meaning to the system. The specification does not reject files that contain additional properties — it simply does not read them. The upload succeeds, the extra data disappears, and nobody is told.
What a typical supplier file looks like versus what the system reads
This is the gap in practice. A supplier file assembled by a cooperative field team or an origin-country exporter typically carries the fields that make operational sense for tracking farms, managing relationships, and documenting sourcing — none of which are things the EUDR Information System was built to process.
What the supplier sends
- farm_id
- farmer_name
- latitude
- longitude
- area_ha
- harvest_date
- variety
- certification
- cooperative_name
- elevation_masl
- region
- municipality
What the IS reads
- ProductionPlace
- ProducerCountry
- ProducerName
- Area
The coordinates and geometry are read — those are part of the GeoJSON structure itself, not the properties block. But every named field in the properties section that is not one of the four recognised names is invisible to the system. A field called "farm_id" is not read. A field called "FarmID" is not read. A field called "farmer_name" is not read — even though the system does recognise "ProducerName," which is a different field name for a similar concept.
The system does not reject unknown fields. It does not warn about them. It accepts them and discards them. The upload looks successful. The operator has no way to know that half the file was ignored — unless they know what the specification says before they upload.
Why the field names matter exactly
The four recognised properties are case-sensitive and must be spelled exactly as the specification defines them. "ProducerName" is recognised. "producer_name" is not. "producerName" is not. "PRODUCERNAME" is not. The system treats these as unknown properties and ignores them.
This creates a specific failure mode. A supplier who diligently records the farmer's name in a column called "farmer_name" — a perfectly reasonable field name for an internal database — has done real work that will not survive the upload to the Information System. If the operator wants that name to appear in the DDS, the field must be renamed to "ProducerName" before upload. Not "producer_name." Not "Farmer_Name." The exact string "ProducerName" — one word, capital P, capital N, no underscore.
The same applies to area. The system expects "Area" with a capital A, in hectares — and only for Point geometries. A field called "farm_area" or "area_m2" is not recognised. And there is a subtlety here that is easy to miss: the Area property exists because a Point has no shape, so the system cannot calculate surface area from the geometry alone. A Polygon, by contrast, has its area calculated automatically from the coordinate ring. The Area property on a Polygon feature is redundant — the system already knows.
What this means for data preparation
There are two practical consequences of this specification that affect how an operator prepares geo-data for DDS submission.
The first is that the file uploaded to the Information System must be a separate, purpose-built output — not the raw supplier file with extra columns left in. A raw supplier file contains the data the operator needs for their own records: farm IDs for traceability, harvest dates for lot tracking, certification codes for buyer requirements. That data has real value. But it is not the data the Information System reads, and including it in the upload adds file size without adding information the system will use.
The second is that the four recognised properties must be named exactly as specified, with the correct field names and units. This is a mapping step — translating "farmer_name" to "ProducerName," converting hectares to square metres for the "Area" field, mapping a country name to an ISO 3166-1 alpha-2 code for "ProducerCountry." It is a mechanical transformation, but it requires knowing the specification in advance. An operator who discovers the mapping requirements at the moment of upload — with a shipment deadline approaching — is in a different position than one who built the mapping into their data preparation process from the start.
The supplier file and the EUDR IS upload file are two different documents serving two different purposes. The supplier file is for the operator's internal traceability. The IS upload file is a stripped-down, specification-compliant extract. Treating them as the same file is the root cause of most upload problems.
What the specification does not say — and why that matters too
One field that operators often expect to find in the specification is harvest date. EUDR requires operators to document the date or time range of production as part of the Due Diligence Statement. But harvest date is not a GeoJSON property — it is entered separately in the DDS form within the Information System itself. An operator who includes a "harvest_date" column in the GeoJSON file, expecting the system to read it, will find that it is silently ignored. The date must be entered through the form interface, not through the geo-data file.
This is a broader pattern worth understanding. The GeoJSON file serves one purpose in the DDS workflow: it defines where the production took place. Everything else — what was produced, how much, when it was harvested, who the operator is — is captured elsewhere in the DDS, not in the GeoJSON. The file is a spatial input, not a complete compliance record. Expecting it to carry the full weight of a DDS submission leads to files that are large, complex, and contain information the system was never built to process.
TraceBean produces two output files for every batch processed. The first is an EUDR IS-ready GeoJSON — stripped to the four recognised properties (ProductionPlace, ProducerCountry, ProducerName, Area), with field names and units matching the v1.5 specification exactly. Ready to upload directly to the Information System without further transformation.
The second is an internal GeoJSON with the full set of validated and corrected data — farm IDs, geohashes, geometry details, correction notes — for the operator's own traceability records. Two files, two purposes. The specification defines what the system reads. TraceBean produces exactly that, and nothing more.
Source: EUDR GeoJSON File Description, Version 1.5, dated 5 May 2025. Published by the European Commission.
← Back to Blog