We Uploaded Eight Broken Farm Polygons to the EUDR Information System. It Accepted All of Them.

Every post in this series has described what can go wrong with farm geo-data — swapped coordinates, missing decimal points, wrong coordinate systems, polygons that cross themselves. What we had not tested until now is what happens when that broken data reaches the EUDR Information System itself.

The answer, it turns out, is nothing.

In July 2026, we ran a series of tests on the EUDR Information System's public acceptance server — the replica testing environment provided by the European Commission for operators to familiarise themselves with the system before the 30 December 2026 compliance deadline. We uploaded eight GeoJSON features, each containing a different, deliberate geo-data error. The system accepted all eight.

Eight test features, seven deliberate errors, one valid control. The EUDR Information System acceptance server accepted all eight without warning.

What we tested — and what the system did

Each test was designed to check whether the Information System validates a specific aspect of geo-data quality. The tests ranged from obvious errors — a farm located in the middle of the Atlantic Ocean — to subtler issues like a polygon declared as Colombian but located in Brazil. In each case, we uploaded the feature as part of a GeoJSON file and observed the system's response.

Test 1 — Valid polygon in Antioquia, Colombia Control ✓

A correctly formed polygon with valid coordinates in a Colombian coffee-growing region. The system accepted it and calculated an area of 30.59 hectares from the coordinate ring. This is the reference point — everything that follows should have been caught by the system but was not.

Test 2 — Swapped latitude and longitude Accepted ✗

A Colombian farm polygon with latitude and longitude values reversed. The resulting coordinates place the polygon near Antarctica — lat -75.56°, lon 6.24°. The declared country is Colombia. The system accepted the feature without warning and calculated an area of 7.77 hectares.

Test 3 — Missing negative sign on longitude Accepted ✗

A Honduran farm with longitude 87.65° instead of -87.65°. This places the farm in the Bay of Bengal, near Bangladesh — the opposite side of the world from Honduras. The declared country is HN. The system accepted the feature and calculated 29.77 hectares.

Test 4 — Unclosed polygon ring Accepted ✗

A polygon with four coordinate pairs where the first and last points do not coincide — an unclosed ring, which is technically invalid GeoJSON. The system silently closed the ring and returned five coordinate pairs with the last matching the first. No warning that the input was modified.

Test 5 — Self-intersecting polygon (bowtie) Accepted ✗

A polygon whose edges cross each other, forming a bowtie shape — a geometry that is invalid under OGC standards and produces undefined area calculations. The system accepted it and returned an area of 0.01 hectares — effectively zero, because the self-intersection causes the polygon to cancel itself out. No warning that the geometry is invalid.

Test 6 — Point in the Atlantic Ocean Accepted ✗

A Point geometry at lon -40.00°, lat 6.24° — the middle of the Atlantic Ocean, roughly 2,500 kilometres from the nearest Colombian coast. The declared country is Colombia. The system accepted the feature and preserved the submitted area of 2.1 hectares.

Test 7 — Polygon in wrong country Accepted ✗

A polygon with coordinates near Brasília, Brazil — lon -47.92°, lat -15.78° — declared as Colombian (ProducerCountry: CO). The system accepted the feature without comparing the coordinates to the declared country. Area calculated as 29.64 hectares.

Test 8 — Point with no Area property Accepted ✗

A Point geometry with no Area in the properties. The system accepted the feature and assigned a default area of 4.0 hectares — which is the EUDR threshold below which a point geometry is acceptable instead of a polygon. The system assumed the maximum allowable size rather than flagging the missing field.

What this means — and what it does not

It is important to be precise about what these results show. The EUDR Information System is a submission platform, not a validation tool. It was built to receive Due Diligence Statements and the geo-data that accompanies them — not to verify the accuracy of that data. That is a reasonable architectural choice for a system designed to handle submissions from operators across 27 member states, for seven commodities, at scale.

But it means that the system places full responsibility for data quality on the operator. If an operator uploads a GeoJSON file with swapped coordinates, a polygon in the wrong hemisphere, or a self-intersecting geometry, the system will accept it. The Due Diligence Statement will be filed. The reference number will be generated. And if, three years later during an audit, a competent authority discovers that the farm coordinates pointed to the Atlantic Ocean rather than a coffee plantation in Honduras, the operator — not the system — bears the consequence.

The silent correction problem

Test 4 revealed something worth highlighting separately. The system did not reject the unclosed polygon ring — it silently closed it. The input had four coordinate pairs. The output had five, with the last matching the first. No warning was issued. No flag was raised. The operator has no way to know that the system modified their data unless they compare the uploaded file to the exported result line by line.

Silent correction is arguably more dangerous than silent acceptance. When a system accepts bad data unchanged, at least the bad data is preserved — a later audit can see what was submitted. When a system quietly modifies the data, the audit trail no longer matches the source file. The operator submitted one thing. The system stored another. Neither party recorded the difference.

The default Area problem

Test 8 showed that when a Point geometry is submitted without an Area property, the system assigns a default of 4.0 hectares — the EUDR threshold for point-versus-polygon geometry. This is the maximum farm size for which a Point (single coordinate pair) is acceptable under the regulation. Larger farms require a full polygon boundary.

Assigning the maximum allowable value as a default, rather than flagging the missing field, creates an implicit assumption: every Point without an Area is treated as though it represents a 4-hectare farm. For smallholder origins where many farms are well below one hectare, this default overstates the farm size — and by extension, the area that any subsequent deforestation screening would check.

What validation looks like before the upload

Every error in these eight tests is detectable before the file is submitted. Swapped coordinates are caught by checking whether the resulting location falls within the declared country boundary. Missing negative signs are caught by the same check. Unclosed rings are caught by verifying that the first and last coordinate pairs match. Self-intersecting geometries are caught by standard OGC validity checks. Points in the ocean are caught by any land-boundary dataset. Polygons in the wrong country are caught by comparing coordinates to the declared ProducerCountry.

None of these checks require proprietary data, complex algorithms, or access to restricted information. They require running the file through a validation step that the Information System does not perform — and doing it before the upload, when correction is still possible.

All tests were conducted on the EUDR Information System acceptance server (acceptance.eudr.webcloud.ec.europa.eu) in July 2026. The acceptance server is a replica of the production server provided by the European Commission for testing and training. Submissions on the acceptance server do not have legal value. Test data used synthetic coordinates only — no real farm data was uploaded.