Excel to TRACES-ready EUDR geodata — without rejections

The traps in a supplier spreadsheet

Swapped latitude/longitude, commas used as decimal separators, an area typed as text (which TRACES reads as 0 ha), points over 4 ha that must be polygons — these pass a human glance but break the declaration.

DDSpass auto-detects the columns, fixes what it safely can, and clearly separates “what we fixed” from “what your supplier must correct and re-send”.

From spreadsheet to submission

Drop the .xlsx or .csv in. You get a TRACES-ready GeoJSON, a map preview to eyeball the plots, and a supplier report in EN/ES/PT/FR/DE/NL/DA. Nothing is uploaded.

How your columns are found

There is no template to fill in first. DDSpass reads the header row and scores each candidate, so Latitude, Latitud, Breitengrad, Breddegrad and Lat all resolve to the same thing; accents and capitalisation are folded away. Real exports also carry a logo or title row above the table, so if row 1 has no coordinate columns the next rows are scanned for the real header, and a cover or README sheet is skipped in favour of the first sheet that actually exposes coordinates.

• latitude + longitude columns → the plot geometry
• an area or hectares column → Area, converted to a number
• a plot, place, farm, finca or parcela column → ProductionPlace
• a country, país, pays or land column → ProducerCountry, normalised to ISO2
• a WKT or GeoJSON boundary column → a real polygon instead of a point

Coordinates recorded the field way are converted rather than rejected: degrees-minutes-seconds (12°34'56"N), a bare degree symbol, or a hemisphere letter attached to a decimal (15.733457E, S 12,5) all become the decimal degrees TRACES needs, with S and W carrying the minus sign.

The two number bugs that survive a manual conversion

Comma decimals. A supplier in a European locale writes 12,901234, and a spreadsheet reader guessing types reads that comma as a thousands separator: the value arrives as 12901234, far outside the coordinate range and easily mistaken for metres. DDSpass keeps the raw text, converts the comma to a dot, and tells you how many cells it repaired.

Area typed as text. This is the quietest failure on the list. "Area": "3" — three hectares written as a string rather than a number — imports without a murmur and TRACES reads it as 0 hectares. A numeric-looking string is converted and logged; anything that is not a number at all, such as 3 ha approx, is blocked so the supplier can restate it.

Swapped latitude and longitude are handled the same way. Where the numbers can only be one way round — a latitude of 47.2 in the longitude column — the swap is definite and reversed automatically. Where both values are under 90 the file is genuinely ambiguous, so the plot is tested against the declared country instead, and a latitude past 90 that no swap can rescue is blocked rather than exported.

Getting a real boundary out of a spreadsheet

For the non-cattle commodities, a plot over 4 hectares has to be sent as a mapped boundary; a single point is only allowed at 4 hectares or under. A spreadsheet of latitude/longitude pairs produces nothing but points, so every large plot in it is blocked — correctly, because a point cannot describe the field.

The fix does not mean changing tools. Add a boundary column and DDSpass reads it: headers such as WKT, Geometry, Boundary (WKT) or Polygon, holding either WKT (POINT, POLYGON, MULTIPOLYGON) or a GeoJSON geometry pasted into the cell. WKT is written longitude first, the same order as GeoJSON. Those rows become real polygons; this is the only way a spreadsheet can satisfy the boundary rule.

The column is trusted only once at least one cell genuinely parses, so a numeric Polygon area header cannot hijack the mapping. Rows whose boundary cell is empty or unreadable fall back to their latitude/longitude point and are counted separately in the report, so a half-mapped file still gives you everything that is ready plus a precise list of what your supplier still owes you.

Questions

Which columns does it need?

Latitude and longitude at minimum; it also detects area, producer name and country columns automatically.

What if a plot is a single point over 4 ha?

It is flagged: under EUDR Art. 2(28) plots over 4 ha must be sent as a mapped field boundary, not a point.

My coordinates use commas as decimal separators — will they be read correctly?

Yes. "12,901234" is converted to 12.901234 before anything else happens. This matters more than it looks: a spreadsheet reader that guesses types treats that comma as a thousands separator and returns 12901234, which is not a coordinate at all and is easily mistaken for a projected value in metres. The number of repaired cells appears in the fix report.

Can I paste rows straight from Excel instead of saving a file?

Yes. Copy the rows, press Ctrl/Cmd+V anywhere on the page, or use the Paste from Excel button. If you copied only the data cells without the header row, the columns are identified by type and precision instead of by name. Pasted rows are processed in the browser exactly like a dropped CSV, and nothing is uploaded.

TRACES accepted my converted spreadsheet with no error — is the declaration right?

Not necessarily. The system visibly rejects only two things: invalid JSON syntax and a polygon with holes. Everything else semantically wrong is accepted silently — an area typed as text imports as 0 hectares, a point with no area at all is defaulted to 4 hectares, and swapped coordinates simply render somewhere else on the map. Check the numbers, not the absence of an error message.