EUDR geolocation requirements: points, polygons, four hectares and the six-decimal rule.

Last updated: 23 August 2026

What EUDR actually asks for

The regulation does not ask where your supplier is, or where the farm is as a dot on a map. It asks for the geolocation of every plot of land where the coffee or cocoa was produced. Article 9 of Regulation (EU) 2023/1115 requires “the geographic coordinates in latitude and longitude of all plots of land where the relevant commodities… were produced,” together with the date or time range of production.

The unit is the plot, not the farm and not the supplier. One consignment that draws on twenty plots needs the geolocation of all twenty.

Two consequences follow immediately. First, the geolocation travels with the goods: if any one of those plots shows post-2020 deforestation, every commodity from that plot is disqualified, so the plot list has to be complete, not a representative sample. Second, this is full due diligence. The simplified declaration introduced in late 2025 (which lets certain small primary operators in low-risk countries skip geolocation and give a postal address) does not reach an EU importer sourcing coffee or cocoa from a non-EU origin. If that is you, plot geolocation is required, full stop. We explain who that carve-out really covers in the FAQ.

Point or polygon: the four-hectare line

Whether a plot may be a single point or must be a full boundary comes down to one number: four hectares.

• A plot of four hectares or less may be given as a single point: one latitude/longitude pair.
• A plot of more than four hectares must be given as a polygon: the actual boundary of the plot, as a closed ring of coordinates.

For coffee and cocoa this line matters more than it first appears. A great many smallholder plots genuinely sit at or under four hectares, so a point is often legitimate, but a point carries an assumption you should understand before you rely on it (see the Area default below). Larger estates, and any plot you cannot honestly call four hectares or less, need a real polygon. There is no partial credit for “roughly the right area”: a polygon is a closed boundary or it is not accepted.

A point is a promise that the plot is four hectares or smaller. If it is larger, a point is not just imprecise: it is the wrong geometry.

The GeoJSON file, concretely

Plots reach the EU information system (TRACES) as GeoJSON, a plain-text geographic format. You do not have to hand-write it, but knowing its shape tells you what “good” data looks like and why bad data fails. A file is a FeatureCollection; each plot is one Feature with a geometry (a Point or a Polygon) and a set of properties. A minimal, correct file with one point plot and one polygon plot looks like this:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": { "ProducerName": "Finca La Esperanza", "Area": 3.2 },
      "geometry": {
        "type": "Point",
        "coordinates": [ -75.512367, 4.734921 ]
      }
    },
    {
      "type": "Feature",
      "properties": { "ProducerName": "Cooperative Block 7" },
      "geometry": {
        "type": "Polygon",
        "coordinates": [ [
          [ -75.514900, 4.736100 ],
          [ -75.513200, 4.736050 ],
          [ -75.513250, 4.734800 ],
          [ -75.514980, 4.734860 ],
          [ -75.514900, 4.736100 ]
        ] ]
      }
    }
  ]
}

Three details in that file trip people up more than any others:

• Coordinates are [longitude, latitude], in that order. This is the GeoJSON standard and the reverse of how people say coordinates aloud (“lat, long”). Swap the two and a Colombian plot lands in the Indian Ocean. It is the single most common silent error.
• A polygon ring must close. The last coordinate pair must repeat the first exactly, so the boundary forms a closed loop. In the example, the ring begins and ends on [-75.514900, 4.736100].
• Property names are case-sensitive and capitalised. Area, ProducerName, ProducerCountry. PascalCase. A lowercase area is not the field the system reads; it is silently ignored.

The Area field, and the silent four-hectare default

For a point, you may include an Area property giving the plot’s size in hectares. It is optional, and that optionality hides a consequence worth stating plainly.

If you submit a point with no Area, the EUDR system does not treat it as “unknown.” It sets the area to four hectares by default.

In other words, an undeclared point silently claims up to four hectares of land around that coordinate. For a small shade plot that is usually harmless; near a forest edge it can quietly pull a screening footprint across ground you never meant to declare. If you know the plot is 1.2 hectares, say so: "Area": 1.2. Two further rules on this field catch people out:

• It must be a number, not a string. "Area": 3 is read as three hectares; "Area": "3" (with quotes) is read as zero, because a quoted value is not recognised as a number. A single pair of quotation marks changes the declared size to nothing.
• It applies to points only. A polygon carries its own boundary, so its area is computed from the geometry; an Area property on a polygon is not what defines it.

The six-decimal rule, and why more precision can break a plot

The regulation defines geolocation as coordinates expressed “using at least six decimal digits” (Article 2(28)). Six decimal places of a degree is roughly eleven centimetres on the ground, ample to identify a plot. The at least is what misleads people into thinking more decimals are always safer. They are not.

The EU system rounds every coordinate to six decimals when it stores your plot. Precision beyond that isn’t just wasted: it can invalidate the geometry.

Here is the trap. Suppose two vertices of your polygon differ only at the seventh decimal place, a fraction of a centimetre apart. On storage, the system rounds both to six decimals, and the two now-identical points collapse into one. A polygon that arrived valid becomes a ring with a duplicated coordinate, which is rejected. Sub-centimetre GPS precision, exported blindly, is a known cause of rejected geometry. The fix is not less care: it is rounding your coordinates to six decimals before you submit, then confirming the polygon is still a valid closed ring afterwards, so what you send is exactly what the system stores. That round-then-revalidate step is part of how we prepare every plot; the reasoning behind it runs through the method.

The geometry errors that get a plot rejected

Beyond the six-decimal collapse, a handful of geometry problems will bounce a plot at submission. None is exotic; all are avoidable once you know to look:

• An unclosed polygon ring: the last coordinate does not repeat the first, so the boundary never closes.
• A self-intersecting boundary: the outline crosses over itself (a “bow-tie”), usually from vertices listed out of order.
• Holes drawn as one shape: a plot with an interior exclusion has to be modelled correctly, not sketched as a single doughnut outline.
• The wrong geometry type: a route or edge submitted as a LineString. EUDR plots are points or polygons, not lines.
• Out-of-range coordinates: a latitude beyond ±90 or a longitude beyond ±180, almost always the lat/long-order swap in disguise.

A useful habit: before anything is filed, plot your coordinates on an ordinary map and look at them. If a point sits in the sea, or a boundary ties itself in a knot, the file is wrong, and that is far cheaper to see on a map than to discover as a rejected Due Diligence Statement.

Where the coordinates come from, and who is responsible

The coordinates originate at the source: a producer, a cooperative, an exporter, or a field team with a GPS handset or a mapping app. For a single estate that can be straightforward; for a cooperative aggregating hundreds of smallholders it is real work, and the data arrives in every format imaginable: spreadsheets, KML from a phone app, photographs of hand-drawn maps, a WhatsApp message with a pin. Turning that into clean, valid, correctly-attributed GeoJSON is most of the effort, and it is where plots quietly go wrong long before they reach TRACES. Getting it out of the chain in the first place is its own practical challenge: there’s a separate guide on collecting geolocation from your suppliers.

Whoever assembles the file, the legal duty does not move. As the operator (the business first placing the coffee or cocoa on the EU market), the Due Diligence Statement is filed in your name and the responsibility for it stays with you. Getting the geolocation right is not a formatting nicety; it is the evidentiary spine of a statement you have to be able to stand behind. Our part is to do that work well: take the coordinates in whatever shape they arrive, turn them into valid geometry, run each plot through a type-aware deforestation screen, and file a statement that is defensible, not to assume a legal risk that was never ours to take. That distinction is deliberate, and we keep it honest across the full importer guide.