Germany's ATLAS data check from 1 September 2026: Export and transit must match item by item

On 1 September 2026, German customs will activate the new internal interface between ATLAS Export and ATLAS Transit. When export is followed by a transit procedure, ATLAS will automatically compare selected information in both declarations.

That may sound like a technical system update. In daily operations, however, it can determine whether a truck is released or remains at the departure location. According to ATLAS-Info 0981/2026, a negative comparison means that the transit declaration is not received, accepted, or released. A new corrected transit declaration then has to be created.

Workflows that consolidate several export items into one transit item are particularly exposed. Such shortened data entry may have passed unnoticed in a manual workflow, but it does not reproduce the referenced export declaration at item level. The automated comparison makes that discrepancy visible.

What exactly changes on 1 September 2026?

The purpose of the interface is to confirm that the export and transit declarations describe the same goods. The transit declaration therefore connects the export MRN and its export items with the corresponding NCTS data.

According to German customs, ATLAS checks in particular:

A reduced comparison takes place when the transit declaration is received, followed by the full check at acceptance. For an authorised consignor, receipt and acceptance effectively occur together. This leaves little opportunity to correct the dataset between the two checks.

Does every field really have to match 100 percent?

No. German customs does not describe a complete field-by-field comparison of both declarations. Invoice value, consignee, gross mass, vehicle identification, and package details are not named as part of this particular automated check in the participant notice.

However, the checked fields and references must connect the goods unambiguously at item level. The notice does not publish a rounding or error tolerance for net mass. Operationally, companies should therefore assume that the declared values need to match exactly.

“One hundred percent” is only accurate when it means: Every referenced goods item must be present and mapped correctly. It does not mean that every field in the export and transit declarations must be identical.

Why consolidated transit items become a problem

A common shortcut looks something like this:

• The export declaration contains three items with different commodity codes.
• The transit declaration contains only one item.
• That item uses the commodity code of the first export item.
• Its weight or value represents the entire shipment.
• The export MRN is referenced as the previous document.

In simplified form:

The shipment totals may look plausible. At item level, however, the transit declaration does not match the export declaration:

• ATLAS expects 420 kg for export item 1, not 550 kg.
• There are no corresponding transit items for commodity codes B and C.
• The goods cannot be mapped unambiguously to their export items.

ATLAS-Info 0601/2024 therefore describes a one-to-one model for NCTS Phase 5. Every goods item in the house consignment needs to correspond to an item in the export movement. No export items may be omitted and no unrelated items may be added.

What does the correct NCTS structure look like?

When a transit declaration refers to a previous export declaration, the export declaration is generally referenced as previous document N830. The export relationship also needs to be represented correctly for export followed by transit.

In simplified terms, the NCTS Phase 5 principles are:

1. One house consignment generally references exactly one export movement.
2. The house consignment contains all goods items from that export movement.
3. It contains no goods items that do not belong to the referenced export movement.
4. Every transit item corresponds one to one to an export item.
5. If the item order differs, the original export item number is mapped explicitly.
6. Several export movements are represented through separate house consignments in the transit declaration.

This is not a cosmetic data requirement. ATLAS needs this structure to identify which NCTS item corresponds to which export item and to compare commodity code, net mass, and destination country correctly.

What happens after a negative comparison?

The outcome depends on the point at which ATLAS identifies the discrepancy:

• The transit declaration is not received.
• It is not accepted after presentation.
• Or the goods are not released for the transit procedure.

In all three cases, the movement cannot continue as planned. Under the current participant notice, a new corrected transit declaration needs to be created. That costs more than processing time: the driver, warehouse, dispatch team, customs team, and potentially the customer all wait for a new release.

This is particularly risky for companies with a zero-minute release timer or very short operational lead times. A data discrepancy then stops being a minor follow-up question and immediately becomes a clearance problem.

Reuse export data by MRN instead of entering it again

The logical way to solve this problem is to reuse the export data already available to customs for the subsequent transit procedure. ATLAS provides an intended workflow for exactly this scenario.

In the appropriate process, the transit participant sends the export MRN for presentation at exit for onward movement under transit. After positive processing, ATLAS provides the export information through the “Exit data” message (E_EXT_DAT). The corresponding house consignments and goods items can then be built into the transit declaration.

This is not a public MRN search. The MRN alone does not give everyone access to complete export data. Retrieval takes place within the intended ATLAS process and requires the correct procedural context, customs office, and participant role.

Declarium retrieves export data using the MRN, processes the available items in a structured way, and prepares the NCTS transit declaration. Commodity codes, net masses, destination countries, and item references no longer have to be copied manually from the export document, PDFs, emails, or another customs system.

The practical workflow is:

1. The export MRN is provided to Declarium.
2. The intended ATLAS workflow for export followed by transit is initiated.
3. The export data made available by ATLAS is processed at item level.
4. Declarium creates the appropriate house consignments and goods items for NCTS.
5. Previous-document and item references are prepared in a structured way.
6. The dataset is reviewed and then processed for the transit procedure.

This reduces duplicate data entry and prevents an internal operational shortcut from later appearing as a contradiction in the customs system.

What companies should review before the deadline

Companies should not limit their preparation to installing a customs software update. The entire data handover between exporter, customs agent, freight forwarder, warehouse, and authorised consignor matters.

A practical checklist:

• Are all export items provided to the party creating the transit declaration?
• Are commodity code and net mass retained at item level?
• Is the destination country transferred consistently?
• Is the export MRN referenced as N830 on the correct house consignment?
• Can the system map a different item order unambiguously?
• Are several export MRNs processed as separate house consignments?
• Is it clear who communicates changes after export acceptance?
• Is there a process for transit declarations that are not accepted or released?
• Does the software provider support the exit data message and its transfer into NCTS?

Testing should include realistic multi-item consignments. A successful single-item test says little about whether consolidation, several MRNs, or different item orders are handled correctly.

Airfreight and Road Feeder Service exception

ATLAS-Info 0981/2026 describes an exception for air transport, including Road Feeder Services. Under the conditions stated in the notice, additional-information code T0002 can be declared in the transit declaration. The comparison then remains manual.

This exception should not be treated as a general workaround. It is tied to the specific airfreight or substitute road transport workflow and, according to the notice, cannot simply be added later by customs or declared only on the transit accompanying document.

Conclusion: Missing items turn a data check into an operational bottleneck

From 1 September 2026, it is no longer enough for export and transit declarations to describe approximately the same shipment at an aggregate level. The referenced goods items need to be structured so ATLAS can compare them unambiguously.

Companies that currently compress several export items into one transit item or collect data manually from different sources should change their workflow before the deadline. The most reliable data source is the existing export declaration itself.

With Declarium's MRN-based export data retrieval, the available export items can be transferred in a structured way and prepared for NCTS before a missing item leaves a truck waiting.

Sources

• ATLAS-Info 0981/2026: Interface activation on 1 September 2026
• ATLAS-Info 0611/2024: Export–transit interface and scope of the data comparison
• ATLAS-Info 0601/2024: Referencing previous export movements
• European Commission: New Computerised Transit System (NCTS)