One Farm Without a Polygon Can Block an Entire Shipment

In the previous post, we looked at why Point-instead-of-Polygon is the one geo-data error that cannot be auto-fixed — and why flagging it clearly is the only honest response a validation tool can give.

There is a follow-on problem that deserves its own explanation. Because the way coffee moves from a smallholder farm to an exporter means that a single unfixed polygon problem does not affect one farm's compliance. It affects every farm in the same batch.

Once coffee is pooled at a washing station, the geo-data of every contributing farm becomes part of a single Due Diligence Statement. One gap affects all of them.

How coffee actually moves from farm to exporter

Smallholder coffee farmers rarely deliver their harvest directly to an exporter. The volumes are too small, the logistics too fragmented. Instead, their cherry is collected — daily, during harvest — at a local washing station or cooperative wet mill. Dozens or hundreds of farmers deliver to the same facility within the same harvest window.

At the washing station, the cherry from all contributing farmers is processed together. It is pulped, fermented, washed, and dried as a single batch. By the time the coffee leaves the washing station as parchment, it is no longer traceable to individual farms in any physical sense. It is a pooled lot.

That lot then travels to an exporter, gets milled, blended or kept as a single-origin lot, and eventually reaches the European importer as part of a shipment.

This is not a data problem. This is simply how smallholder coffee supply chains work, and have worked for decades. The washing station is the aggregation point — commercially, logistically, and now, for EUDR purposes, the point at which individual farm geo-data must be consolidated into a compliant batch record.

What EUDR requires at the shipment level

A Due Diligence Statement submitted under EUDR must account for the geo-data of every farm that contributed to the shipment. Not a sample. Not the farms above a certain size. Every farm.

This means that a washing station lot drawing from 800 smallholder farmers requires 800 valid farm records — each with the correct geometry type, within the expected country boundary, with area data where applicable. The DDS covers the lot as a whole, but the underlying farm-level data must be complete and compliant for all contributors.

In practice, this means that 40 farms with point geometries instead of polygons — in a batch of 800 — do not represent 5% of the compliance problem. They represent a potentially non-compliant DDS for the whole shipment.

When the problem is discovered matters as much as what the problem is

The critical variable in this scenario is timing. And the timeline of a coffee shipment leaves very little room for error once the harvest has been processed.

The washing station is the point of no return. Before it, geo-data problems are fixable — with time and supplier cooperation. After it, the options are limited to accepting compliance risk, delaying the shipment, or in the worst case, rejecting it entirely.

The implication for how importers work with suppliers

Most importers currently receive geo-data from their suppliers in one of two ways: either bundled with the shipping documents at the point of export, or as a separate file shortly before the DDS needs to be submitted.

Both of these are after the washing station. Both are after the point of no return.

This is not because importers are careless. It is because the data collection and submission workflows were built around commercial timelines, not compliance timelines. The harvest happens. The coffee moves. The paperwork follows. Geo-data was treated as paperwork.

EUDR changes that logic. Geo-data is now a prerequisite for a compliant shipment — which means it needs to be validated before the coffee is pooled, not after it is loaded onto a container ship.

What this means in practice

Shifting geo-data validation to before the harvest requires a change in how importers communicate with their suppliers — and how suppliers communicate with their farmers. It is not purely a software problem. But software is part of it.

• Validation needs to happen early enough to allow correction. A report that arrives two weeks before export cannot be acted on if the problem requires a field re-survey. A report that arrives three months before harvest can.
• The report needs to be farm-level and actionable. A supplier receiving "your geo-data file has errors" cannot fix anything. A supplier receiving "Farm ID ETH-0447 has point geometry; area recorded as 5.1 ha; polygon required" can instruct a field agent specifically.
• The importer needs visibility, not just the supplier. When geo-data problems exist in a supplier's dataset, the importer needs to know — not to intervene directly, but to factor it into commercial and logistics planning before it becomes a customs problem.

The structural shift EUDR is forcing

What EUDR is ultimately requiring is that geo-data becomes part of the pre-harvest supplier relationship, not the post-export paperwork process. That is a significant operational shift for importers who have built their supply chain workflows around the current commercial timeline.

The companies that will handle EUDR compliance most smoothly are not necessarily those with the cleanest current geo-data. They are those who build the validation loop early enough that problems surface when they can still be fixed — before the washing station makes them permanent.