Why EUDR GeoJSON Files Get Rejected: The 7 Errors That Sink a Due Diligence Statement

The public conversation about EUDR is about farmers, cost and market access, and rightly so. But when a due diligence statement actually fails, the reason is usually none of those things. It is geometry. The EU Information System accepts geolocation in exactly one format, GeoJSON, and it validates what you upload. A supply chain can be genuinely deforestation-free and still not clear filing because a polygon crosses itself somewhere south of Abidjan by forty centimetres.

These are the seven errors that do the sinking, in roughly the order they occur in the wild, with the fix for each.

1. Coordinates in the wrong order

GeoJSON puts longitude first, then latitude. Most spreadsheets, GPS apps and humans think latitude first. Swap them and a cocoa plot in Côte d'Ivoire relocates to a spot with the axes flipped, often in the ocean or another continent, where the deforestation check produces nonsense. The file parses fine, which is what makes this error so common: nothing looks broken until you plot it. The fix is a five-second sanity check: open the file in any map viewer and confirm the plots sit in the producer country before anything gets filed.

2. The wrong coordinate system entirely

The system requires WGS84, EPSG:4326, in decimal degrees. Field data frequently arrives in UTM zones or national grids, where coordinates are metre values like 654321.05. Those numbers are outside any valid longitude or latitude range, and the upload fails. The symptom is unmistakable, six or seven digit coordinates, and the fix is a reprojection in any GIS tool, not a retype.

3. Rings that do not close

A GeoJSON polygon must end where it began: the last coordinate pair identical to the first. Data exported from field apps or hand-assembled from GPS tracks often stops one vertex short. To a human the shape looks closed; to a parser it is an open line pretending to be an area. The fix is mechanical, append the first point at the end, and any validation step catches it instantly.

4. Self-intersecting boundaries

The classic: a farmer walks the boundary with a phone, doubles back around an obstacle, and the recorded track crosses itself, producing a bowtie instead of a field. Self-intersections are often sub-metre and invisible at normal zoom, which is why they survive manual review and die at machine validation. Fixing them by nudging vertices is fiddly; fixing them at capture, walk slowly, one clean loop, review the shape before leaving the field, is cheap. For existing data, automated geometry repair handles most cases and flags the rest for a human.

5. A point where a polygon is required

Plots larger than 4 hectares must be polygons. Points are allowed only at 4 hectares and below, and the system's own file specification notes that tiny polygons get processed as points anyway. Submitting a point for a 12-hectare plot may upload, but it undermines the statement it supports: the deforestation check cannot assess a boundary you never provided, and an authority or buyer reviewing the filing will notice the mismatch between the declared area and the geometry type. When in doubt, map the polygon; it is legally required above the threshold and quietly protective below it.

6. Files too heavy to accept

The Information System caps a DDS submission at 25 MB, and GeoJSON is a verbose format. The usual culprit is vertex bloat: GPS tracks recorded at one point per second turn a rectangular field into a two-thousand-vertex monster, and a few hundred such plots blow the limit. Simplify geometries with a standard tolerance of a few metres, which removes redundant vertices without moving boundaries meaningfully, and split very large supplier sets across multiple statements where needed.

7. Schema and property mistakes

The quiet category: a missing bracket, property names in the wrong casing, numbers quoted as strings, a producer country that is not a two-letter ISO code. One structural quirk deserves special mention: the system does not process holes inside polygons, only outer boundaries, so an enclave has to be represented as separate polygons rather than an interior ring. None of this is intellectually hard; all of it fails silently in a text editor and loudly at upload.

What a clean minimal feature looks like

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "ProducerCountry": "CI",
        "ProductionPlace": "Plot 0142"
      },
      "geometry": {
        "type": "Polygon",
        "coordinates": [[
          [-5.512345, 6.812345],
          [-5.510210, 6.812890],
          [-5.509876, 6.810654],
          [-5.512001, 6.810123],
          [-5.512345, 6.812345]
        ]]
      }
    }
  ]
}

Longitude first, six decimals, ring closed, WGS84, country as ISO2. Boring, and boring is the goal.

The workflow that prevents all seven

Every one of these errors is detectable before filing, which means every DDS rejection on these grounds was optional. The pattern that works: validate geodata the day it arrives from a supplier, not the week the shipment sails. Run automated checks for the full set, coordinate ranges and order, CRS, ring closure, self-intersection, geometry type against declared area, file size, schema, and send failures back upstream immediately with the plot ID and the specific error. Fix at the source, keep farmer and plot identifiers stable so corrections replace rather than duplicate, and only then let the file near a due diligence statement.

Frequently asked questions