LearnAll blog articles

EUDR

Fix rejected EUDR GeoJSON: the 15 errors the EU lists

The European Commission publishes its own list of 15 common EUDR GeoJSON file errors. What each one means, and which ones a geometry check never sees.

A smallholder farm boundary walked with a handheld satellite receiver, neighbouring plots and a dirt access track visible in low morning light

A rejected EUDR GeoJSON is often not a geometry problem at all. The European Commission publishes its own list of fifteen common file errors in the EUDR GeoJSON File Description, and five of them — a number written as text, a mis-typed property name, a missing bracket, a password on the file, a PDF that got renamed — are things a geometry checker never looks at.

So before you redraw a single boundary, work out which of the fifteen you’re holding. Below is that list, what each entry means in practice, and the two refusals your file cannot fix no matter what you do to it.

The list comes from the Commission’s EUDR GeoJSON File Description, linked from the EUDR Information System page. The legal requirements behind it are in Regulation (EU) 2023/1115 (EUDR) and the geometry conventions in IETF RFC 7946.

Which thing actually rejected it?

Three different systems can turn you away, and they need three different responses.

Where the refusal came from What it’s telling you What fixes it
The file check, when you upload the GeoJSON The file itself is malformed, or a geometry isn’t one the system accepts One of the fifteen errors below
The assembled declaration The file is fine; the declaration it went into is over a documented ceiling Split the declaration — see the 25,000,000-byte geolocation ceiling
Nothing — you’re waiting No reference number yet is not a refusal Nothing. Keep the UUID and check the status

That last row catches more people than it should, so it’s worth being precise about it further down.

Swipe to see all three branches →
Three branches for a rejected EUDR GeoJSON: the file check refuses malformed files and unsupported geometry, with longitude before latitude, coordinates within minus 180 to 180 and minus 90 to 90, six decimals kept and a point with no Area treated as four hectares; the assembled declaration refuses a valid file that is over a documented ceiling; and no reference number yet is not a refusal at all
Every number here is cited below. Passing the file check is a format result, not acceptance and not a compliance verdict.

The fifteen errors the Commission lists

These are the Commission’s own “Common GeoJSON file errors”. The middle column is what each one means when you’re staring at your file.

What the file has What that means What to do
Coordinate lines crossing A boundary that intersects itself — a figure-of-eight. Not supported. Redraw the boundary. Splitting it changes the plot’s shape, so look at it on a map first.
Overlapping sides “Internal overlap or holes where part of the polygon folds inward, creating a concave shape within the boundary are not accepted by the system.” Re-trace the fold. This is usually a GPS track that doubled back.
Doughnut shapes A polygon with a hole in the middle. Not supported. The Commission’s own workaround: two half-moon shapes.
Open polygons “All polygons must represent closed shapes (i.e. the 1st coordinate pair same as the last).” Repeat the first coordinate pair at the end. Nothing moves; this one is safe to fix automatically.
LineString or MultiLineString A walked track, not an area. “Do not represent valid geocoordinate shapes for declaring production places and will not be accepted/processed.” Re-export from the source as a polygon. Don’t rename the type field — the coordinate nesting differs.
Coordinates representing straight lines The ring is collinear, so it encloses no area. It isn’t a production plot yet. Re-trace it.
Duplicate coordinates after rounding Two vertices that differed only past the sixth decimal become one point once the system truncates. Apply the truncation yourself and re-check before you upload.
File syntax errors A missing ) or }. The file isn’t valid JSON. Open it in any JSON validator; the line number is usually exact.
Invalid property names A typo or the wrong capitalisation — the Commission’s examples are "geomerty" and "productionplace" instead of "ProductionPlace". Property names are case-sensitive. Fix the spelling and the case.
Invalid file format A PDF or a .txt submitted as geolocation. Export GeoJSON from the source system.
Out-of-range coordinates Latitude outside ±90 or longitude outside ±180. Usually a swapped pair, or degrees-minutes-seconds pasted into a decimal field.
Invalid ISO2 country codes The production country isn’t a valid two-letter code. UK is not a country code, for example; GB is.
Password-protected files The system can’t open it. Remove the protection and re-export.
Data representation issues "Area": "3" — a number written as text. Also point coordinates nested one level too deep. See below. This one is quietly expensive.
Holes inside a polygon “The system does not take into account holes inside a polygon, but only the outer boundaries.” Don’t rely on a hole to reduce your declared area.

You can check a file against the geometry rules right now. Clearlane’s free EUDR GeoJSON validator and repair tool runs a cited rule profile in your browser, draws the plots on a map, and hands back a repaired file. Nothing is uploaded — the file stays on your machine.

The three that cost the most time

"Area": "3" is not three hectares. It’s zero.

The Commission is blunt about this one: “For example, "Area": "3" instead of "Area": 3 will result in area = 0.” Quotation marks around the number turn it into text, and the system reads text as nothing.

Now put that next to the default. If a Point carries no Area property at all, the File Description says it “will be set by default to ‘4’ (four) hectares when processed by the EUDR system”.

So an unsized point isn’t a blank. It’s a claim of four hectares — and four hectares is exactly the line Article 2(28) of Regulation (EU) 2023/1115 (EUDR) draws. Above it, a non-cattle plot needs a polygon with enough points to describe its perimeter. A quoted Area that silently becomes zero can drop a large plot below that line without anyone noticing.

The same entry catches a subtler shape problem: “The coordinates for points should be array and not array of arrays.” A Point takes one position. Wrapping it in an extra set of brackets makes it something else.

A capital letter in a property name

"productionplace" and "ProductionPlace" are not the same key. Neither are "geomerty" and "geometry". The Commission lists both as real, common causes.

This is the error that survives every visual check, because the map still draws. The geometry was never the problem — the system just couldn’t find the property it was looking for.

Seven decimals that become six

Two rules pull in opposite directions here, and they’re both real.

Article 2(28) of Regulation (EU) 2023/1115 (EUDR) sets at least six decimal digits as the floor. The File Description sets the ceiling in the same place: “The information system will truncate coordinate points to 6 decimal places before storing.”

Usually that’s harmless. Occasionally it isn’t. If two vertices of a small plot differ only in the seventh decimal, they become the same point after truncation — the Commission’s own example — and a ring that loses vertices can end up collinear or duplicated. The file was valid when you sent it and invalid after it was stored.

Truncate to six decimals yourself, then re-check the geometry. Finding this at the portal is the expensive way.

Longitude first. Always.

The File Description is explicit: “The order of elements must follow longitude, latitude for coordinates in the EPSG:4326 geographic coordinate reference system.” RFC 7946 says the same.

People say it the other way round, spreadsheets store it the other way round, and plenty of GPS apps export it the other way round. A swap often stays inside the legal ranges, so nothing errors — the plot just moves to another continent. If your file passed every check and the rejection came later, a swapped pair is the first thing to rule out.

Where the Commission’s own document leaves a gap

Worth knowing before you spend an afternoon on it.

The list contains two entries about holes that don’t say quite the same thing. One says doughnut shapes are not supported. The other says the system “does not take into account holes inside a polygon, but only the outer boundaries” — which is a refusal in the first case and a silent ignore in the second. Either way the safe reading is the same: never let your declared production area depend on a hole, because the system may not be subtracting it.

The File Description also states no maximum file size and no maximum number of features. That isn’t because there is no ceiling — it’s because the ceilings apply to the assembled declaration rather than to your file, and they’re documented in the Commission’s Operator API reference instead. They’re covered separately.

Two refusals your file cannot fix

The declaration is over a ceiling

The Commission’s Operator API V3 reference documents limits for an assembled declaration: 100 commodities per declaration, 1,000 producers per commodity, 10,000 producers per declaration, 500 scientific-name and common-name pairs per commodity, 2,000 grouping references, and 25,000,000 bytes of geolocation data.

Consolidating hundreds of smallholder plots into one submission? The geolocation ceiling is the one you’ll meet first, and no amount of editing an individual plot will move it. The answer is a different declaration structure, not a different file.

Nothing has been rejected yet

This is the one people misread as a failure.

Under Article 7 of Commission Implementing Regulation (EU) 2026/1565, every due diligence statement and simplified declaration goes through “an automated electronic risk profiling” once submitted. The reference number and the associated verification number “shall be made available to the Information System user upon concluding the risk profiling” — in other words, afterwards, not on submission.

So the absence of a reference number is not a refusal. Keep the UUID the system gives you and retrieve the status with it.

And don’t read anything into how long the wait is. The same Article says the Information System assigns a risk status “which shall not be disclosed to the Information System user”. A delay is not a hidden verdict about your plots, and no tool can tell you otherwise. What the submission lifecycle actually looks like is a separate question worth reading before you file.

What a file that passes still doesn’t prove

A clean file means the supported format and data-quality checks passed. It does not mean the EUDR Information System has accepted a declaration, and it is not a legal or compliance verdict.

It doesn’t prove the goods are deforestation-free. It doesn’t prove they were produced in accordance with the relevant legislation of the country of production. Under Article 3 of Regulation (EU) 2023/1115 (EUDR), those conditions have to hold alongside a due diligence statement or simplified declaration. Geometry is the first step of one of them.

The operator stays responsible for the full due diligence assessment and for the statement submitted to the authority.

Fix it before it goes back

If the file is in front of you, start there. Clearlane’s free EUDR GeoJSON validator and repair tool checks it in your browser against a cited rule profile, plots every production place on a map so a swapped pair becomes obvious, records the repairs it can make safely, and gives you the corrected file back. No account, no upload.

If the same errors keep arriving from the same supplier, that’s a data-collection problem rather than a file problem, and Clearlane’s EUDR preparation workflow is built for it.

Clearlane prepares and validates the data. It does not file to the EUDR Information System or any registry on your behalf.

This article is educational guidance, not legal advice or a compliance verdict.