Submission preparation · Operational guide

EUDR DDS file size limits: what should you check before submitting?

A small file can still contain too many entries. A large file can contain only one highly detailed plot. Check both the size of the geolocation data and the structure of the statement before your team starts filing for a client.

What is the published DDS geolocation size limit?

The Commission’s published validation-rules page lists a 25 MB total geolocation limit per DDS, alongside the structural limits below.

Published DDS validation limits, checked 7 September 2026
What is countedPublished limitWhat to check
Geolocation data25 MB per DDSThe published rule concerns total geolocation data, not an arbitrary attachment or Excel workbook.
Commodity entries100 per DDSCount entries in the statement, not the seven regulated commodity categories.
Producer records1,000 per commodity; 10,000 per DDSA producer record and a polygon vertex are different things.
Scientific/common-name pairs500 per commodityRelevant when preparing wood-product entries.

Portal upload size and API request size are different checks

For a portal workflow, inspect the actual GeoJSON file you intend to import. The DDS preparation workbook is an organising aid, not that import file. Its size tells you little about the geolocation payload.

For an integration, inspect both the source geometry and the complete request. The published V3 DDS model represents geometry as Base64-encoded GeoJSON. Encoding and the surrounding message add bytes. A check on the original file alone does not establish that the complete request will be accepted.

Keep these measurements separately: source-file bytes, prepared geolocation bytes, complete request bytes, commodity count and producer count. Record the rule version used for the check. We have not verified one universal request-body ceiling, compression allowance or maximum polygon-vertex count; do not substitute a guessed number.

How do you reduce a large GeoJSON file safely?

  1. Keep the original. Save the supplier’s export separately from the version prepared for filing, with its client, lot and production-place mapping.
  2. Remove packaging, not evidence. Check for accidental duplicate records, unused export properties and unnecessary whitespace. Confirm what the receiving format requires before removing a property.
  3. Check the geometry after every change. Our local GeoJSON checker and map preview can reveal structural problems. It does not certify acceptance by TRACES or the truth of a production location.
  4. Escalate boundary changes. Reducing vertices can change a plot. Ask the person responsible for the location data to review any simplification against the original, rather than silently accepting a smaller shape.

A required polygon cannot simply become a point to save space. Keep the production-location requirements intact. The Commission’s GeoJSON format guide also distinguishes the supported file structures from general-purpose GIS exports.

Can you split an oversized DDS?

Splitting the data is a filing decision, not just a file operation. Establish which goods, quantities and production locations each resulting statement covers. Have the client’s responsible reviewer approve that allocation, then preserve the mapping from the original lot to every resulting statement.

For example, if one client file needs separate submissions, give each prepared part a distinct internal identifier. Reconcile every successful result to that part. Otherwise a team can accidentally duplicate a quantity, omit a plot, or send a customer the identifier for the wrong goods.

Do not combine different clients merely to make a batch convenient. Keep the represented legal entity and filing authority explicit. Nor should a grouping feature be assumed to remove payload limits: verify its availability and rules separately. This guide does not establish whether a particular commercial allocation or grouping is legally appropriate.

A preflight check for every client file

  • Correct client, environment and declaration route: DDS and simplified declaration are separate models.
  • Counts and measured sizes checked against the relevant system release.
  • Complete product-to-producer mapping retained after preparation.
  • Original and prepared location files retained; material changes reviewed.
  • Each planned submission assigned an internal reference and an owner.

Once the file passes these checks, use the portal submission walkthrough or your tested integration. If a request still fails, diagnose the submission error and its outcome before repeating it.

Make file checks part of client delivery

When several colleagues prepare files for several operators, a written limit is easy to miss. We can help scope multi-client EUDR workflows that check incoming data, return a useful correction list and preserve the client-to-submission trail.

Discuss your submission-preparation workflow