EUDR Information System: How to Register and Submit Compliance Data
Most explanations of EUDR compliance jump straight to due diligence — geolocation, legality, risk assessment. Fewer explain the actual system those pieces eventually have to pass through, and what registering on it correctly even involves.
That system has a formal name most exporters never hear: the Information System, established under the regulation's Article 33 and given legal shape by a dedicated Commission implementing regulation. In practice, everyone calls it by the platform it runs on — TRACES NT — but the legal obligations attach to the Information System itself, not to the software brand running underneath it.
Getting registered on it correctly, in the right environment, with the right account type, is a prerequisite most guides skip past entirely, right before explaining how to fill in a Due Diligence Statement.
That gap causes real problems. An exporter can spend months getting geolocation and legality data in perfect order, only to discover at the moment a shipment needs clearing that their company never actually completed registration on the environment where real, legally binding filings happen. The data was ready. The account wasn't.
Once you're registered, the mechanics of actually filing a statement are their own topic. Our DDS submission guide for the EUDR portal covers that filing process in detail — this guide focuses one step earlier, on getting the account itself set up correctly.
That earlier step matters more than it looks. The amount of data you're expected to submit, and how closely it gets checked, also depends partly on your country's classification under the regulation's benchmarking system. Our EUDR country risk classification guide explains how that tiering shapes what the Information System expects from you.
What follows walks through what the Information System actually is, who needs an account on it, and the practical sequence for getting from a blank registration form to a submitted statement.
What the Information System Actually Is
The Information System is formally defined as the IT system that holds the Due Diligence Statements submitted by operators and traders under the regulation. Its required functionalities are set out in the regulation's own text, then further detailed in a dedicated Commission implementing regulation governing exactly how the system must work.
It runs on TRACES NT — Trade Control and Expert System, New Technology — a platform that predates EUDR and was originally built for plant and animal health certificates. The Commission repurposed it as the Registry of Due Diligence Statements rather than building an entirely new platform from the ground up.
That history matters for expectations. The interface still carries some of its original design logic, and its functionality has been added to incrementally to meet EUDR's specific requirements, rather than being designed as a purpose-built due diligence platform from day one. Exporters shipping cocoa from Ghana, for instance, will eventually route their farm-level data through this same system, regardless of how that data was originally collected — our Ghana cocoa compliance guide covers that upstream data collection process in detail.
It's worth being precise about what the Information System is not. It is not a due diligence tool in itself — it doesn't run risk assessments, doesn't verify land tenure, and doesn't check satellite imagery for deforestation. Those tasks happen upstream, using whatever data collection and analysis tools an exporter or their partners rely on. The Information System is where the conclusions of that work get formally recorded and filed, not where the work itself takes place.
Registering: Acceptance vs Live Environments
This is the distinction that catches out more first-time users than any other part of the registration process. The Information System runs in two separate environments, and they don't share accounts.
| Environment | Purpose | Legal Status |
|---|---|---|
| Acceptance server | Testing and practice submissions | Not legally binding; used for training and system familiarisation |
| Live server | Real, production submissions | Legally binding; generates the reference numbers customs authorities check |
Registering an account on the Acceptance environment does not automatically create or grant access to an account on the Live environment, and the reverse is equally true. Each environment requires its own separate registration, even though they sit on the same underlying platform and look nearly identical to a new user.
This trips up teams more often than it should, usually because someone completes a smooth test run on Acceptance and assumes they're ready to file for real, only to discover at shipment time that no Live account actually exists yet. Exporters working across multiple commodities — cocoa from Côte d'Ivoire alongside other regulated products, for instance — should confirm Live registration well ahead of their first real shipment, not the week it's due to leave port. Our Ivory Coast cocoa compliance guide covers the kind of sourcing timeline pressure that makes this distinction especially costly to discover late.
The two environments exist for a sound reason, even if the separation is inconvenient. Acceptance gives teams a genuinely safe space to test data formats, train new staff, and troubleshoot upload errors without any risk of an incomplete or malformed test submission somehow counting as a real legal filing. The trade-off is that this safety comes at the cost of an extra registration step — one that's easy to forget precisely because the Acceptance environment feels, on the surface, identical to the real thing.
Who Needs to Register
Registration obligations follow the same operator and trader categories that apply throughout EUDR, though the specific account type differs depending on where a company sits in the chain.
| Role | Registration Need | Practical Note |
|---|---|---|
| Operator (places goods on EU market) | Full account, files DDS directly | Usually the EU-based importer for African exporters |
| Trader | Account to reference or manage existing DDS | Obligations have been simplified for many downstream traders |
| Authorised representative | Account acting on behalf of an operator | Useful for non-EU exporters without their own EU registration |
| Non-EU exporter (no EU entity) | No direct account in most cases | Supplies data to the registered operator or representative instead |
A recent simplification introduced a "downstream operator" category with obligations aligned to traders rather than full operators, meaningfully reducing how many separate statements need to be filed as a product moves further through the supply chain. This matters for exporters diversifying across commodities, since a company handling soya alongside other regulated products may find its downstream filing burden lighter than expected once this category applies. Our EUDR soya compliance guide covers commodity-specific due diligence obligations that sit alongside this registration structure.
For most African exporters, the practical reality is that registration itself happens somewhere else in the chain — typically with the EU-based buyer acting as operator, or with an authorised representative retained specifically for this purpose. That doesn't reduce the exporter's own workload, though. It shifts it from "manage an account on the Information System" to "supply accurate, complete, well-formatted data to whoever holds that account" — a responsibility that's easy to underestimate simply because it doesn't involve logging into the platform directly.
What Data You Can Submit
The Information System's core function is holding Due Diligence Statements, but a statement is really a container for several distinct categories of underlying data.
| Data Category | What Gets Submitted |
|---|---|
| Company and product identification | Legal entity details, product description, Harmonised System code |
| Geolocation data | GPS coordinates or polygon boundaries for the plot of origin |
| Supply chain information | Known operators and traders that handled the product upstream |
| Risk assessment outcome | Documented conclusion on deforestation and legality risk |
| Reference linkages | Prior DDS reference numbers for downstream or making-available filings |
How thoroughly this data gets reviewed depends partly on the country risk tier attached to the product's origin. Low-risk sourcing generally allows a simplified submission focused on information gathering, while standard- and high-risk sourcing requires the fuller risk assessment and mitigation documentation to sit behind the same submission. The system itself doesn't change shape between tiers — what changes is how much supporting evidence a filer needs to have ready behind it.
It's worth noting that the reference linkage category grows more important the further downstream a product moves. A raw commodity's first filing carries the full weight of geolocation and risk evidence. Every subsequent statement referencing that same material can lean on the original reference number rather than repeating the underlying evidence from scratch — which is precisely why keeping an accurate internal record of every reference number issued matters just as much as the initial filing itself.
Format matters as much as content for most of these categories. Geolocation data, in particular, has to be submitted as structured geographic data rather than a written address or a general description of a region — a distinction that catches out filers translating existing paper-based farm records into digital form for the first time. Getting the underlying category right but the file format wrong produces the same rejection as missing the data entirely, which is why testing submissions on the Acceptance environment before filing live is worth the extra step it takes.
Step-by-Step: Registration to First Submission
The path from a blank account to a completed filing follows a consistent sequence, regardless of commodity or country of origin.
- Confirm your role. Determine whether you're registering as an operator, trader, downstream operator, or authorised representative, since this shapes which account type you need and what obligations attach to it.
- Register on the Acceptance environment first. Use this to test data formats and familiarise your team with the interface before anything is legally binding, catching structural errors early.
- Register separately on the Live environment. Do this well ahead of your first real shipment, not in the days immediately before it's due to leave port, since account setup can take longer than expected.
- Assemble your underlying data. Gather geolocation, legality, and supply chain information before opening a live submission, rather than hunting for it mid-form under time pressure.
- Complete a test submission on Acceptance. Use this to catch formatting errors in a non-binding environment before they become a live filing problem that delays an actual shipment.
- File your first live Due Diligence Statement. Submit through the Live environment and retain the resulting reference number and security token in a secure, accessible internal record.
- Establish an internal registration record. Keep a clear log of which team members and systems are registered in which environment, since access confusion is one of the most common recurring issues as staff change over time.
Exporters bringing coffee to market face the same sequence, just with commodity-specific data behind it. Our Ethiopia coffee compliance guide walks through what that underlying data collection looks like for a heavily smallholder-based supply chain, before it ever reaches this registration and filing stage.
Access, Interoperability, and Common Pitfalls
Beyond the Acceptance-versus-Live confusion, a handful of other access issues come up repeatedly for new users of the system.
The Information System is also built to interoperate with EU customs systems through a broader digital framework connecting non-customs regulatory platforms to customs clearance processes. In practical terms, this means a valid DDS reference number isn't just a compliance record sitting in a separate database — it's designed to be checked directly as part of the customs clearance process itself, which is exactly why an invalid or missing reference number can hold a shipment at the border rather than simply triggering a follow-up paperwork request.
This interoperability is a meaningful design choice, not an incidental technical detail. It means the Information System and the customs process aren't two separate hurdles an exporter clears one after another — they function as a single connected checkpoint. A shipment's customs clearance can, in effect, be waiting on a database lookup rather than a manual document review, which speeds up clearance for clean filings but leaves very little room for a missing or malformed reference number to slip through unnoticed.
The system has also occasionally undergone scheduled maintenance windows to deploy updates reflecting changes to the regulation's provisions, with access temporarily limited during those periods and advance notice generally provided. Exporters running time-sensitive shipments should build a buffer around any known maintenance window rather than assuming the system will always be available exactly when a filing deadline falls.
A further common pitfall is assuming a single company-wide account covers every team member who needs access. In practice, individual users typically need their own registered access within the company's account structure, and losing track of who has active access, in which environment, is a frequent source of last-minute filing delays.
A related, less obvious pitfall involves staff turnover. When the person who originally registered a company's account leaves, access can become genuinely difficult to recover if login details and registration records weren't documented anywhere beyond that individual's own memory or personal inbox. Treating system access as company infrastructure — documented, transferable, and reviewed periodically — rather than as one employee's personal responsibility avoids a surprisingly common and entirely avoidable compliance gap.
- The Information System is the formal, legally defined platform — running on TRACES NT — where Due Diligence Statements are filed under the regulation.
- Acceptance and Live are separate environments with separate registrations; one does not grant access to the other.
- Registration obligations differ by role: operators, traders, downstream operators, and authorised representatives each have a different account relationship to the system.
- The system doesn't verify the truth of submitted data — it checks completeness and format, while legal liability for accuracy stays with the filer.
- A valid DDS reference number is checked as part of customs clearance itself, not as a separate compliance record.
- Scheduled maintenance windows can temporarily limit access, so time-sensitive shipments need a buffer built around known update periods.
Frequently Asked Questions
Is the EUDR Information System the same thing as TRACES NT?
Effectively yes. TRACES NT is the software platform the Information System runs on. The Information System is the formal legal term for the registry itself, as defined under the regulation, and the two names are generally used interchangeably in practice.
Does registering on the Acceptance server give me access to file real statements?
No. Acceptance is a non-binding testing environment. A separate registration on the Live environment is required before any legally binding Due Diligence Statement can be filed, and the two registrations don't carry over automatically.
Can a non-EU exporter register their own account on the Information System?
Generally only with a valid EU or Northern Ireland EORI number. Most non-EU exporters instead supply data to a registered EU operator or an authorised representative who files on their behalf, rather than holding a direct account themselves.
Does the system check whether my submitted data is actually accurate?
No. It validates completeness and formatting, not the underlying truth of the data. The filer remains legally liable for accuracy regardless of what the system accepts, and can still be audited on the underlying evidence at any point.
What happens if the system is undergoing maintenance when my shipment needs a DDS filed?
Access can be temporarily limited during scheduled update windows, generally with advance notice. Exporters with time-sensitive shipments should file ahead of any known maintenance period rather than waiting until the last moment and risking a delay entirely outside their control.
The Information System isn't the hard part of EUDR compliance — the farm-level data collection behind it is. But getting registration right, in the right environment, well before a shipment deadline, is the difference between a filing that goes smoothly and one that stalls at the exact moment it matters most. Treat account setup as infrastructure to put in place early, not as a formality to handle once a shipment is already waiting on it.