From Farm to DDS: Where Data Quality Breaks Down

When an importer receives a geo-data file from a supplier, it looks like an endpoint. The data has arrived. The file opens. The rows are there. What else is there to check?

Quite a lot, as it turns out. Geo-data does not begin at the moment a supplier sends a file. It begins at the moment a farmer records a coordinate in a field — and between that moment and the submission of a Due Diligence Statement, it passes through six distinct stages, each with its own failure modes, its own error patterns, and its own opportunity to introduce problems that will not surface until it is too late to fix them easily.

This post traces that journey. Not as an abstract exercise, but with the specific errors we see in practice — because understanding where problems enter is the first step to catching them before they become compliance failures.

Stage 1: Collection at the farm

This is where the most fundamental problems originate. A farmer using a GPS device set to a local coordinate system — UTM, Gauss-Krüger, or Ethiopia's Adindan grid — records coordinates that are perfectly valid in that system. They are useless in WGS84, which is what EUDR requires, without a reprojection step that most farmers and many exporters have no way to perform.

A farmer recording a polygon by walking the plot boundary may accidentally double-record a corner point — creating a pair of identical consecutive coordinates that make the polygon geometrically degenerate. A field agent transcribing coordinates from a GPS device to a paper form may transpose two digits, shift a decimal point, or omit a negative sign on a longitude that happens to fall in the western hemisphere.

None of these errors are the farmer's fault. They are the predictable output of collecting precise geographic data in difficult field conditions, with equipment that was not designed for EUDR compliance, by people who were not told what the data would eventually be used for.

Stage 2: Aggregation at the cooperative or exporter

A supplier aggregating farm data from 900 smallholder farmers in Honduras is not dealing with one dataset. They are dealing with records from multiple field agents, multiple GPS devices, multiple mobile apps, and multiple seasons of collection. When those records are merged, the inconsistencies between them become visible — but only if someone looks.

Field names are the most common casualty. One field agent recorded area as area_ha. Another used AreaHectares. A third used superficie. A fourth used a column with no name at all. When these records are merged into a single spreadsheet, the column headers are inconsistent — and the importer who receives that spreadsheet has no reliable way to know which column contains the area data without reading every row.

Mixed geometry types are another aggregation artefact. Farmers who had smartphones got polygon geometries. Farmers who did not got GPS points. Both sets of records end up in the same file, which now contains a mix of Point and Polygon features — some of which may be above the 4-hectare threshold that requires a polygon under EUDR.

Stage 3: Export to file format

The EUDR Information System accepts GeoJSON only. Suppliers send whatever their data management tool exports. In practice, this means CSV tables with coordinate columns, Excel sheets with one row per farm, KML files from Google Earth, and occasionally GeoJSON — but GeoJSON that was exported from a tool that uses a non-standard property structure.

The export step also introduces encoding problems. A supplier exporting from a Spanish-language system on a Windows machine may produce a CSV with Windows-1252 encoding. Field names with accented characters — Área, Núcleo, Localización — arrive garbled. The column that should say Área says something unreadable. The data is there, but the field name is not parseable.

KML exports from Google Earth introduce their own problems: non-standard XML tags, placemarks without names, coordinate strings with inconsistent precision, and geometry types that do not map cleanly to the EUDR GeoJSON specification.

Stage 4: Transit to the importer

Transit itself introduces few new errors. The file that arrives is the file that was sent. What transit does is create a moment of false confidence — the file has arrived, therefore the data is ready. This assumption is wrong in most cases, but it is easy to make because nothing in the arrival of a file signals what is wrong with its contents.

This is the moment at which most importers' current workflows end. The file arrived. It goes into the compliance tool. Whatever happens next is the compliance tool's problem.

Stage 5: Validation and correction

This is the step that most importers do not have. Not because they do not want it, but because until recently there was no structured process for it — and no clear understanding of what it needed to check.

Validation at this stage has two outputs. The first is a corrected file — records where the error was deterministic and recoverable are fixed automatically. Missing decimal points, negative sign errors, coordinate transpositions, duplicate polygon vertices, non-standard field names — these are all recoverable without human judgment, because the correct answer can be derived from the data itself.

The second output is a flag list — records where the error is real but the correct answer cannot be determined from the data alone. A point geometry for a farm above 4 hectares cannot be converted to a polygon without a field resurvey. A coordinate that falls outside any plausible country bounding box cannot be corrected without knowing where the farm actually is. These flags go back to the supplier with a precise description of what is needed.

Stage 6: Submission to the compliance tool and DDS

Compliance tools — Osapiens, Satelligence, and others — do sophisticated work at this stage. They cross-check farm polygons against forest cover maps, calculate deforestation risk, and generate the Due Diligence Statement that goes to the EUDR Information System. This is where the regulatory verification happens.

What compliance tools cannot do is fix bad input. A compliance tool that receives a point coordinate for a farm above 4 hectares cannot generate a valid polygon. A compliance tool that receives coordinates in the wrong country cannot determine the correct location. A compliance tool that receives an unclosed polygon ring may either reject the record or produce an unpredictable result.

The deforestation check is only as reliable as the polygon it is checking. A farm polygon that extends slightly beyond the cultivated plot — into adjacent forest cover — will produce a higher deforestation risk score than the actual farm warrants. For agroforestry farms where the satellite map already struggles to distinguish cultivation from forest, polygon precision is not a minor detail. It determines whether the compliance check passes or fails.

By the time geo-data reaches Stage 6, the coffee it represents has already been pooled at a washing station. It cannot be separated by farm. If the geo-data for any contributing farm is non-compliant, the entire batch is at risk. There is no partial compliance option — and there is no time to go back to Stage 1 and resurvey a plot.

What the journey looks like in practice

Across four real batches processed by TraceBean in 2026 — covering 1000+ farms from South America, in KML, Excel, and GeoJSON formats — the pattern is consistent:

• 3 out of 4 batches had at least one compliance issue requiring either automatic correction or supplier follow-up.
• The batch that arrived as GeoJSON — the "correct" format — still contained 10+ invalid records and 20+ pairs of duplicate polygon vertices requiring cleanup.
• The largest batch — 900 farms from South America in Excel — was fully compliant after 20+ automatic corrections, all of which were coordinate errors introduced at Stage 1.
• Mixed geometry types appeared in every KML file, with no area data for point records — making the 4-hectare threshold check impossible without additional supplier information.

None of these problems were visible from the outside of the file. None of them would have been caught by a tool that simply converts format without validating content. All of them would have surfaced — at the worst possible moment — inside a compliance tool or at customs.

← Back to Blog