Independent AI agent for EU Deforestation Regulation compliance, not affiliated with the EU. Scope & disclaimer →
eudr.dev

Common pitfalls and how to fix them

The ten failure modes we see most often when companies, SMEs and AI agents put together their first DDS submission.

1. Self-intersecting polygon

What happens: TRACES NT validation rejects the submission with an opaque error. The polygon's outer ring crosses itself.

Why: GeoJSON polygons must be OGC-Simple. No self-intersections. Some GIS tools produce non-simple polygons when a parcel is digitised by hand.

Fix: Use the engine's intake validation (crates/eudr-server/src/routes.rs::validate_polygon_coords) which flags non-simple polygons. Run a topology repair in QGIS (Vector → Geometry Tools → Fix geometries) or geopandas (geom.make_valid()).

2. Coordinate precision under 6 decimal places

What happens: TRACES NT rejects the submission as imprecise.

Why: Commission guidance and the TRACES API contract expect ≥ 6 decimal places. Some legacy databases round to 4 (≈11 m precision).

Fix: Re-export from the source GIS at full precision. The engine warns at intake when precision is sub-6.

3. Wrong HS code

What happens: Engine returns not_in_scope verdict. The shipment is either out of EUDR scope (no DDS needed) or you got the code wrong (DDS needed but engine refuses to compile).

Why: HS codes are 6, 8, or 10 digits. EUDR scope is defined at HS-6 level for most commodities but some derivatives need HS-8.

Fix: Check the official Annex I of Reg. (EU) 2023/1115 against your HS code. Use the engine's /v1/reference/commodities to confirm the prefix is in scope.

4. Cattle plot submitted as polygon when point would have done

What happens: Nothing breaks, but you waste time digitising large pastures that the regulation lets you submit as a single point.

Fix: For cattle, supply a single point per establishment (Art. 9(1)(d) permits it). Polygons are also accepted but not required.

5. Non-cattle plot > 4 ha submitted as a point

What happens: The engine refuses, citing Art. 2(28), even if it didn't, TRACES NT would.

Why: Points are only permitted for non-cattle plots ≤ 4 ha. Above the threshold a polygon is mandatory.

Fix: Digitise the polygon. If you genuinely don't have the boundary, contact the producer.

6. Mixing low-risk and standard-risk sourcing

What happens: Operator assumes Art. 13 simplified due diligence applies because most of the supply chain is low-risk. The engine returns the full pipeline verdict instead.

Why: Art. 13 requires exclusivity. Every plot in the consignment must be from a low-risk country. One standard-risk plot disqualifies the entire consignment from simplified DD.

Fix: Either re-source the standard-risk plot from a low-risk supplier, or run the full Art. 10 + Art. 11 pipeline.

7. Stale country benchmark

What happens: Engine warns at startup that the country table is older than 180 days; deployer ignores; eventually a country gets re-classified and the engine still uses the old tier.

Fix: Drop the latest country_benchmarks_2025_1093.json (or its successor implementing regulation) into data/. The engine reads it on every request. No restart needed.

8. Missing producer address (Art. 9(1)(e))

What happens: Engine renders an amber "address not supplied" line on the DDS. TRACES may accept this; the regulator may not.

Why: Art. 9(1)(e) requires the name and address of the producer. Many connector flows (CSV uploads, EPCIS imports) carry the producer name but not the address.

Fix: Ask the supplier to add the producer's postal address before submission. Update your connector schema to require it.

9. Forgetting the upstream DDS reference

What happens: SME operator reuses an upstream party's DDS under Art. 4(8)/(9) but doesn't record the reference number. On audit, the chain breaks.

Why: Annex II point 4 (where the reference used to live) was deleted by Reg. 2025/2650. Easy to think the reference is no longer needed. It still is; it's just not a numbered Annex II field anymore.

Fix: Collect the upstream operator's TRACES reference number + verification code at every step. The engine has a slot for them under the upstream_dds[] field on the scenario.

10. Cloud-cover gap producing an "indeterminate" verdict

What happens: Plot is in a region with persistent cloud cover (equatorial wet seasons, monsoonal latitudes). Hansen GFC has no signal for the relevant year; the engine returns indeterminate.

Why: Hansen relies on cloud-free Landsat scenes. Some plots get one usable scene every few years.

Fix: Supply additional evidence. A Sentinel-1 SAR pass (cloud-penetrating), a JRC GFC2020 v3 entry, or a third-party verification. The engine accepts these via the upstream-evidence channel (currently a manual operator addendum; an automated path is on the roadmap).

See also