TRACES NT rejected your DDS: the error catalog, and how each one is fixed.

Last updated: 23 August 2026

The three layers a DDS passes through

A Due Diligence Statement is not accepted or rejected in one step. It is checked in sequence, and knowing which stage rejected yours tells you almost everything about the cause:

1. Layer 1: client-side. Before anything is sent, the submission tooling checks the shape of the statement. A failure here never reaches Brussels; it is caught on your side.
2. Layer 2: the schema. The statement reaches TRACES, which validates it against a strict data schema (an XSD). Wrong types, or a mandatory element left out, are rejected here.
3. Layer 3: the business rules. The statement is well-formed and schema-valid, but a value breaks a rule: an impossible country code, an unrecognised operator. TRACES rejects it at this final gate.

Read the stage, not just the message. A Layer 1 failure is a structural mistake; a Layer 3 failure is a data mistake. They are fixed in completely different places.

Layer 1: caught before it ever leaves your computer

The current EUDR submission interface is version 3 (V3), and V3 changed some fundamentals. The most common Layer 1 mistakes are hangovers from earlier versions or from copied examples:

• An activity type that no longer exists. V3 recognises only IMPORT, EXPORT and DOMESTIC. The old TRADE value is gone; a statement still using it is rejected immediately, before it is ever transmitted.
• A mandatory field simply missing. V3 makes geoLocationConfidential (a yes/no on whether the coordinates are commercially confidential) mandatory, and requires the operator’s country of activity. Omit one and the statement never assembles.
• Geolocation in the wrong form. The plot geometry must be supplied as a GeoJSON encoded in base64. V3 does not encode it for you. A raw GeoJSON string pasted where the encoded value belongs fails here.

None of these are visible to a Competent Authority, because the statement never reaches one. They are a sign the submission is being assembled by hand or from an outdated template.

Layer 2: the schema rejects it

A statement can be perfectly well-structured and still be turned away by the schema for omitting something the schema insists on. The one we see most:

EUDR_COMMODITIES_DESCRIPTOR_NET_MASS_EMPTY: the net weight is missing.

For an import or export, TRACES requires the net mass of the commodity in kilograms. It is an easy omission because some tooling only sends the weight element when a value is present, so a blank weight field silently drops the element, and the schema then rejects the statement for a mandatory value it never received. The fix is not subtle: supply the net weight. But the message is subtle, which is why it strands first-time filers.

Layer 3: the business rules reject it

The last gate is the strictest to diagnose, because the statement is valid in every structural sense (correct types, real GeoJSON, all mandatory fields present), yet a value is not allowed. A representative example:

EUDR_COMMODITITY_PRODUCER_COUNTRY_CODE_INVALID: a country code that is well-formed but not real.

A two-letter string like ZZ is a valid shape for an ISO country code, so it sails through the schema; but no such country exists, so the business-rule layer rejects it. The same class of error catches a mistyped origin, or a producer country that doesn’t match the consignment. These are data-quality problems, fixed in the source record, not in the file format, which is why re-exporting the same wrong data in a “cleaner” file never helps.

The geometry failures, specifically

Geometry is the single richest source of rejections, and most of it comes down to a handful of rules that GPS tools and spreadsheets quietly break. We cover the requirements in depth in the geolocation requirements guide; here is what actually rejects a plot:

• Coordinates in the wrong order. GeoJSON (RFC 7946) requires longitude first, then latitude. Most consumer GPS output and most people write latitude first. Swapped coordinates either reject or (worse) place the plot in the wrong hemisphere and pass, screening the wrong ground.
• Too much precision, not too little. TRACES stores coordinates at six decimal places and rounds to six on save. Excess precision is not just wasted: rounding can collapse two nearly-identical points into one and turn a valid polygon invalid. Six decimals is roughly ten centimetres; more is false accuracy.
• A self-intersecting boundary. Walking a plot perimeter and crossing your own path creates a “bow-tie” polygon. It is not a valid area, and TRACES rejects it.
• A ring that doesn’t close, or collapses on rounding. A polygon ring must start and end at the same point and keep at least four distinct points after rounding. A ring left open, or one whose points round together into a zero-length edge, is rejected.
• The Area field on the wrong geometry. The optional Area attribute (PascalCase, in hectares) belongs to a point, which stands in for a small plot; it does not belong on a polygon. Where a point carries no area, EUDR treats the plot as the default four hectares, which may not be what you intended. The geolocation guide explains that default in full.

Two things that look like failures but aren’t

Not every alarming response is a rejection. Two in particular send filers into a panic that isn’t warranted:

• A reference number that isn’t there yet. On submission you first receive an internal identifier (a UUID). The official DDS reference number and its verification number are issued a moment later, when the statement moves from SUBMITTED to AVAILABLE. A missing reference number in the first instant is the system working, not failing.
• A rate-limit error on read-back. Querying a statement too soon or too often can return a rate-limit rejection from the web service even while the statement is perfectly AVAILABLE. The failure is the read request, not the filing. Confirm in the EUDR interface before assuming anything went wrong.

The pattern underneath all of them

Almost every TRACES rejection is one of two things: a structural problem in how the statement was assembled (Layers 1-2), or a data problem in what it says (Layer 3 and geometry). Tools that promise a “one-click” filing tend to hide the first and cannot touch the second, which is why an operator can be stuck for days on a message that names a symptom, not a cause.

When we file as your Authorised Representative, this catalogue is the checklist that runs before anything is submitted: coordinates re-ordered and rounded to what TRACES will store, rings validated after rounding, mandatory fields confirmed, country and commodity codes checked against the rules, so the submission clears the three layers the first time. You can see the whole thing end to end in the sample due-diligence file, and the filing walkthrough in how to file a DDS in TRACES.