Automating EUDR DDS Filing: A Realistic Integration Guide for the 30 December 2026 Deadline
Today is 7 September 2026. Large and medium operators must comply with the EUDR from 30 December 2026 - roughly 16 weeks away. That is enough time to build and test a machine-to-machine integration with the EUDR Information System. It is not enough time to start the decision-making process in October.
This post is for the compliance lead or IT systems owner who has to answer one question right now: do we automate DDS submission, or do we keep filing through the web form? It assumes you already know the basics of what a DDS contains and how to file one manually - if not, our step-by-step TRACES NT filing guide covers that ground. It also assumes you know what changed when the Information System relaunched - our June 2026 relaunch post covers that. This post picks up where those two leave off.
What actually changed on 17 July 2026
For most of 2025 and early 2026, any team that started building an API integration was building against a moving target. The Commission placed temporary access limitations on the Information System from 16 February 2026, pausing new registrations and submissions on both the live production server and the acceptance environment while a substantial rebuild was underway.
That uncertainty is now closed. Implementing Regulation (EU) 2026/1565, adopted on 13 July 2026 and in force since 17 July 2026, sets the final technical rules for the Information System - including updated API specifications for companies that want to automate DDS submission at volume. The regulation also introduces the simplified declaration form for micro and small primary operators and codifies contingency arrangements for system outages.
A frozen specification is the precondition for any integration project. Before 17 July, a development team building against draft API documentation risked having to rework their integration when the rules changed. That risk is now largely closed. Both the production and the test (acceptance) environments are operational, so integration work can proceed against stable specifications and be tested in a safe environment before any real statements are filed.
If your team was waiting for the specs to stop moving before committing engineering resource, the wait is over.
Three filing patterns - and when you outgrow each one
Not every operator needs an API integration. The right approach depends on your filing volume, your internal systems, and how much manual re-keying you can absorb. Here are the three realistic patterns.
Pattern 1: Manual web form
Who it fits: Operators filing fewer than roughly 20-30 DDS per month, with a small, stable product range and a single person responsible for compliance.
How it works: A compliance officer logs into the TRACES NT interface, enters data for each statement, and submits. The system returns a reference number, which the officer then copies into the relevant order record, invoice, or customs declaration.
The failure mode: Volume. The web form is designed for individual statements, not batches. When shipment frequency increases - a new season, a new supplier, a new commodity line - the time cost scales linearly. The same plot coordinates get re-keyed for every shipment. Reference numbers get pasted into ERP by hand, creating a transcription error risk at exactly the point where accuracy matters most (customs clearance). If the person who knows the system is unavailable, filings stop.
Signal that you've outgrown it: You are spending more than a few hours per week on DDS entry alone; the same geolocation data appears in more than one statement and is being re-entered each time; or reference numbers are being manually copied between TRACES and your ERP or order management system.
Pattern 2: Assisted or bulk upload
Who it fits: Operators filing dozens to a few hundred statements per month, where data can be prepared in a structured format (CSV or similar) and uploaded in batches rather than entered field by field.
How it works: The Information System supports structured data uploads that allow multiple statements to be prepared offline and submitted together. This reduces the per-statement time cost and allows data preparation to be separated from the submission step.
The failure mode: The upload process still requires a human to initiate each batch, monitor for rejections, and handle errors manually. It does not solve the reference number problem: numbers still have to be extracted from TRACES and matched back to order records by hand. And if your data lives in an ERP, you are still exporting, reformatting, and re-importing rather than connecting systems directly.
Signal that you've outgrown it: You are running bulk uploads daily; rejected statements require significant manual investigation to diagnose; or your logistics team is waiting on reference numbers before they can complete customs documentation, creating a bottleneck.
Pattern 3: Full API integration (machine-to-machine)
Who it fits: Operators filing hundreds to thousands of DDS per month, or any operator where DDS data already exists in a structured system (ERP, trade management platform, traceability tool) and the bottleneck is getting it into TRACES and getting the reference number back out.
How it works: Your internal system calls the Information System API directly - submitting statements, receiving reference numbers, and handling amendments or withdrawals programmatically. The reference number is written back to the originating order record automatically, with no manual copy-paste step.
The failure mode: Integration complexity and maintenance overhead. An in-house integration requires ongoing support as the API evolves, error handling for edge cases (rejected geolocations, system outages), and internal expertise to maintain. The upfront investment is real.
Signal that you need it: You are filing more than a few hundred statements per month; your DDS data is already structured in an ERP or trade system; or reference number delays are causing downstream problems with customs or customers.
The reference number is the integration's real payload
The strongest argument for automation is not filing speed. It is getting the reference number back into your ERP or order record reliably, without a human in the loop.
The DDS reference number must appear on customs import declarations, commercial invoices to downstream buyers, transport and shipping documents, and internal compliance records. Without it, goods are legally blocked at customs - no exceptions. Submitted declarations can be changed or withdrawn within 72 hours after the reference number has been assigned, as long as the reference number has not yet been used in a customs declaration. Miss that window because the number is sitting in someone's inbox, and you have a problem.
In a manual process, the reference number is generated in TRACES, noted by the compliance officer, and then communicated downstream - by email, by updating an invoice, by calling the customs broker. Each handoff is a point of failure. In an automated integration, the API call that submits the DDS returns the reference number, which is written directly to the order record in your ERP. Your logistics team sees it immediately. Your customs broker pulls it from the system. No transcription, no delay, no lost email.
The legal obligation to pass on the DDS reference number to the first downstream actor leaves open how this should be done technically - in practice, channels include delivery notes, invoices, separate EUDR accompanying documents, and EDI interfaces for automated data exchange between ERP systems. An API integration makes the EDI route straightforward; without it, you are relying on one of the manual channels for every shipment.
Use the acceptance environment - seriously
The Commission operates two separate environments: a production environment for real filings and an acceptance (test) environment for rehearsal. Registration for the acceptance environment and the live production environment is separate - an account in one does not grant access to the other.
Register for the acceptance environment now, before you have built anything. Use it to run a structured test plan before your integration goes live. Here is what to rehearse:
- Happy path: Submit a complete, valid DDS and confirm the reference number is returned and written back to your test order record correctly.
- Rejected geolocation: Submit a statement with deliberately malformed coordinates and confirm your system handles the error response gracefully - logging it, alerting the right person, and not silently dropping the filing.
- Amended statement: Submit a DDS, then amend it within the 72-hour window. Confirm the amendment is reflected correctly in both TRACES and your internal record.
- High-volume batch: Submit a realistic volume of statements in a short window and observe how your system handles queuing, rate responses, and any failures.
- Simulated outage: Confirm your fallback process - what happens if the API is unavailable when a shipment needs to clear customs? The implementing regulation includes contingency arrangements; make sure your team knows what they are and has practised them.
Rehearsing in the acceptance environment before December matters more than feature completeness. A partial integration that has been tested and has a documented manual fallback is safer than a fully-featured integration that has never been stress-tested. Do not skip the outage scenario.
The acceptance environment URL is published in the Commission's Information System documentation. The user guide and registration instructions are on the Green Forum implementation hub.
Build, buy, or broker - an honest comparison
Once you have decided that automation is right for your volume, you have three delivery options. None is universally correct.
| Approach | What you get | Main advantage | Main risk | Liability position |
|---|---|---|---|---|
| In-house API integration | Direct connection from your ERP or trade system to the Information System API | Full control; reference numbers flow natively into existing systems | Requires internal development resource and ongoing maintenance as the API evolves | Operator retains full liability — no change |
| Compliance platform vendor | A third-party platform that connects to the Information System on your behalf, with a UI for data management | Faster to deploy; vendor handles API maintenance and error handling | Dependency on vendor's uptime and roadmap; data leaves your systems | Operator retains full liability — the vendor files on your behalf but you remain responsible for the due diligence |
| Customs broker or agent filing on your behalf | A service provider who manages TRACES access and submits DDS as your authorised representative | Low internal overhead; useful for non-EU operators appointing an EU representative | Slowest for high volumes; reference number still has to travel back to your systems; broker cannot perform your due diligence for you | Operator retains full liability — outsourcing the filing does not outsource the obligation |
The liability point deserves emphasis. The regulation permits representatives to file DDS on behalf of an operator, while the exporter or operator retains full legal responsibility. Outsourcing the mechanics of filing to a broker or platform vendor does not transfer your obligation to conduct due diligence, verify geolocation data, or retain records for five years. If the data you provide to your filing agent is wrong, the consequences fall on you.
A note on national system interoperability: the Commission has flagged that the Information System is designed to interoperate with national traceability systems such as SUMAL in Romania. This work is ongoing and the details of how interoperability will function in practice are still being finalised. If your supply chain runs through countries with their own mandatory traceability registries, monitor the Commission's guidance on this point - do not assume it will be seamless from day one.
A 16-week plan
Sixteen weeks is workable, but only if the first two are spent on decisions and access, not on scoping documents.
Make the build-vs-buy decision. Register for both the acceptance and production environments — these are separate registrations and approval can take time. Confirm your Annex I product list: check which of your products are covered under the core regulation (deadline 30 December 2026) and which, if any, fall under the new Annex I additions from the July 2026 delegated act (deadline 30 December 2027). Attend one of the Commission's free September training sessions (3, 8, 10 or 15 September 2026, 14:00 CEST) to see the system demonstrated live.
Get all plot geolocation data into a single, validated structure before you write a line of integration code. This is consistently the longest-lead-time task. Suppliers who cannot provide GPS coordinates or polygons will block your filings regardless of how good your integration is. Use this window to chase outstanding data, validate coordinate formats, and confirm that your ERP product codes map cleanly to EUDR commodity categories and HS codes.
Build the integration (or configure your chosen platform) against the Commission's published API specifications — do not build against third-party documentation or assumptions. Run the full test plan in the acceptance environment: happy path, rejected geolocation, amendment, high-volume batch, simulated outage. Document every error response and confirm your system handles each one.
Run the integration in parallel with your existing manual process for a defined period. File real statements through both routes and compare results. This surfaces discrepancies between what your ERP thinks a shipment contains and what TRACES actually accepts. It also gives your logistics and customs teams time to adapt to receiving reference numbers from a system rather than an email.
Switch to the integration as your primary filing route. Document the manual fallback process explicitly — who does what, using which credentials, if the integration fails. This is not a theoretical exercise: the Information System will have outages, and an integration that fails in the first week of January with no human process behind it is worse than no integration at all.
Keep this week as buffer. Do not plan to be cutting over to a new system in the final days before 30 December. If you are still in parallel running in week 16, that is a sign the timeline slipped somewhere — use the buffer to stabilise, not to rush.
What can wait: You do not need to automate every edge case before go-live. A working happy path with a documented manual fallback for exceptions is a better position than a feature-complete integration that has not been tested under load.
What cannot wait: Registration. Access approval for both environments, and confirmation of your product scope, must happen in the next two weeks. Everything else depends on it.
Your free next step: the Commission's September training sessions
The Commission is running free virtual training sessions on the Information System throughout September. Operator sessions are scheduled for 3, 8, 10 and 15 September 2026 at 14:00 CEST, with a first dedicated session for micro and small primary operators on the simplified declaration on 17 September 2026 at 14:00 CEST; further dates are to be announced. Registration links and the system user guide are on the Green Forum Information System page.
These sessions are the fastest way to see the API and submission flow demonstrated by the people who built the system. If you are sponsoring an integration project, attending one session before your team starts scoping work will save time and prevent assumptions from hardening into architecture.
For official reference, the consolidated regulation text is at EUR-Lex (CELEX 02023R1115-20251226), and the Commission FAQ, Guidance document, and list of Member State Competent Authorities are all linked from the Green Forum implementation hub.
One final caution: keep a manual fallback path documented, tested, and staffed. The Information System is live and stable, and the technical risk that drove the first postponement in October 2024 is largely closed. But no system is infallible. An integration that fails in week one of January with no human process behind it is a worse outcome than filing manually from the start. Build the automation - and keep the fallback.
This post covers the machine-to-machine filing route. For the step-by-step manual filing process, see our TRACES NT submission guide. For what changed when the Information System relaunched, see our June 2026 relaunch post. For the broader regulatory picture, see our 2026 Simplification Package overview.
Related reading
EUDR Enforcement in 2026: How Competent Authorities Will Monitor, Flag, and Penalize Non-Compliance
Article 25 gives every EU Member State the same four sanctions to work with - fines, confiscation, procurement exclusion, and trading bans - but each Competent Authority enforces them nationally. Here's how the monitoring and penalty system actually works as enforcement obligations begin.
EUDR Cocoa Compliance: The Complete Guide for Grinders, Traders, and Chocolate Makers
Cocoa is one of the EUDR's seven core commodities and one of the highest-scrutiny supply chains, given deforestation pressure in Côte d'Ivoire and Ghana. Here is what grinders, traders, and chocolate makers need to do before the 30 December 2026 deadline.
EUDR Coffee Compliance: What Importers and Roasters Must Do Before the Deadline
The EU imports roughly a fifth of the world's coffee, and every bag now needs plot-level geolocation and a due diligence statement. Here's what coffee importers, roasters, and green-bean traders need in place before large operators must comply.