Tested on TRACES · EUDR
What TRACES actually checks in your EUDR GeoJSON — and what it silently accepts
We uploaded a suite of deliberately broken GeoJSON files — self-intersections, swapped coordinates, text-typed areas, unclosed rings, donut holes — to the official TRACES ACCEPTANCE environment (build EUDR 8.2.0.2, July 2026). The result surprised even us: exactly one visible rejection exists. Every other defect imported silently — and put wrong data into the declaration.
Fix your file — freeEUDR is mandatory for medium & large operators from 30 December 2026 — get your supplier files TRACES-ready now.
Files never leave your browser · no upload
The only error TRACES ever shows
Broken JSON syntax. The browser's parser fails before TRACES even looks at the content, and you get SyntaxError: Expected double-quoted property name in JSON at position… — see the fix for that error. Verified verbatim-identical on builds 8.2.0.1 and 8.2.0.2. That is the entire visible defence.
Everything TRACES accepts silently — with the numbers
| What was wrong with the file | What TRACES showed | What was actually true |
|---|---|---|
| Self-intersecting polygon (figure-8 «bowtie») | Imported, Total Area 0.01 ha | The real plot is 239.09 ha — under-declared ×24,000. Details |
| Area typed as text ("3" instead of 3) | Imported, Total Area 0.0000 | 3 ha declared by the supplier — silently zeroed. Details |
| Latitude and longitude swapped | Imported, no message | Plots render in the ocean / the wrong country. Details |
| Polygon with a hole (donut) | Imported, Total Area 119.11 ha | The 19.13 ha hole is counted as production; true net is ≈100.4 ha. Details |
| Ring not closed (first ≠ last point) | Imported, no message | File violates the GeoJSON spec — portability risk on any stricter re-check. |
| LineString instead of a polygon | Imported, no message | The production place is created empty — no geometry at all, 0 ha. |
| Self-touching «pinched» ring (machine-traced) | Imported, no message | Geometrically invalid polygon riding into an official declaration. |
Numbers from our July 2026 test run on the ACCEPTANCE environment, build EUDR 8.2.0.2. TRACES also does not check coordinates against the declared country, does not validate the country code in the file, and does not compare the declared area with the geometry.
It got quieter between builds, not stricter
On build 8.2.0.1 there was one semantic warning left: a yellow "Polygon with holes are not accepted by the system". On 8.2.0.2 that warning is gone — the same donut file imports with no message on either import path. The direction of travel is clear: TRACES is an intake system, not a validator. Checking the data is entirely the operator's job.
What this means for your DDS
"TRACES accepted the file" tells you nothing about whether your declaration is right. The errors above are the ones competent-authority checks can surface later — with your company name on the DDS. DDSpass exists for exactly this gap: drop the file and every defect in this table is caught, fixed where possible, and explained in a report your supplier can act on. It also converts the Excel, KML and Shapefile sources TRACES cannot read at all. Everything runs in your browser — nothing is uploaded.
Questions
Does TRACES validate coordinates against the declared country?
No. In our tests, plots with swapped coordinates rendering in the middle of the ocean imported without any message, regardless of the country selected for production.
If TRACES accepted my file, is my DDS correct?
Not necessarily. TRACES rejects only broken JSON syntax. Wrong areas, wrong locations, invalid geometry and wrong country codes all import silently — the responsibility for correct data stays with the operator submitting the DDS.
Which TRACES version were these tests run on?
The official ACCEPTANCE environment, builds EUDR 8.2.0.1 (July 8, 2026) and 8.2.0.2 (July 18, 2026). Production may lag behind acceptance; we re-test when builds change.