AI OCR to EUCDM XML: EU Customs Automation

EU customs automation with OCR works like this: an AI pipeline reads the freight document — invoice, bill of lading or packing list — extracts the fields that customs needs, validates them against EU Customs Data Model business rules, and emits an EUCDM XML declaration that systems like ICS2, ASYCUDA and national customs platforms can consume. Done well, it turns hours of manual keying per consignment into seconds of automated extraction, with a human only in the loop where confidence is low.

This guide is the reference documentation for that process: what EUCDM is, how OCR maps documents to the model, what a minimal EUCDM XML declaration looks like, which document types the pipeline handles, and the governance that keeps automated customs data filing compliant. It is the technical companion to Balasci by Esnaj, the EUCDM-ready OCR product that turns freight paperwork into customs-ready XML. The same document-to-data pipeline powers Esnaj’s data extraction service, which converts freight paperwork into structured fields for customs and ERP systems.

What Is EUCDM

EUCDM is the EU Customs Data Model — the single, authoritative source of data requirements for trans-European customs systems such as NCTS (transit), AES (export) and ICS (import), and for the national customs clearance systems of EU member states. The Commission maintains it so that the same data element means the same thing across every national implementation, which is what makes “one declaration, many systems” possible.

Three facts to anchor on:

• The data requirements in EUCDM are defined in the Union Customs Code implementing acts — Delegated Regulation 2015/2446 and Implementing Regulation 2015/2447 — with declarations and notifications in Annex B, applications and decisions in Annex A, and the EORI dataset in Annex 12-01 (European Commission).
• Version 7.0 was released in April 2025, aligned with the UCC and covering NCTS, AES, ICS, EOS and the Customs Decisions System (European Commission, EUCDM 7.0 release note, April 2025).
• EUCDM uses the WCO data model mapping tool, so it stays interoperable with the World Customs Organization’s global data model and can be customized by national authorities without breaking EU rules.

When we say “AI OCR to EUCDM XML,” the model is the destination: the extracted fields must map to EUCDM data elements, codes and formats, or the declaration will be rejected or flagged by the receiving customs system.

How OCR Maps Invoices and Bills of Lading to EUCDM XML

The mapping from a scanned freight document to an EUCDM declaration is a five-step pipeline. It is worth being precise here, because this is the part most customs document automation tools get wrong.

1. Capture and pre-processing. The document is scanned or photographed, deskewed, and prepared so OCR reads cleanly. A misaligned scan silently degrades every downstream field.
2. OCR and layout analysis. The OCR engine reads the text and reconstructs the document structure — which block is the consignee, which are the line items, where the values are.
3. Field extraction and classification. An AI layer classifies each extracted value into a semantic field: declarant EORI, consignee, commodity code, gross mass, document references. This is where 95%+ accuracy on invoices and bills of lading is achieved in production (Balasci by Esnaj, 2026).
4. Validation against EUCDM business rules. Extracted values are checked against EUCDM codes and pick-lists — country codes, customs procedure codes, document type codes, HS commodity codes. A value that is not a valid code is quarantined, not guessed.
5. XML emission. A mapping layer renders the validated fields into an EUCDM XML declaration, ready for the receiving system or for a licensed customs professional to review and file.

Each step is deterministic where the standard allows, and probabilistic only where the document itself is ambiguous — and every ambiguous field goes to a human exception queue, never straight to a declaration. On the ERP side, the resulting EUCDM XML feeds straight into the Odoo for 3PL connectors that keep warehouse, transport and customs data in one system.

EUCDM XML Structure: A Minimal Example

The full EUCDM 7.0 schema is large, so this is a minimal, illustrative fragment — the fields that appear in nearly every declaration: declarant, consignee, commodity and document reference. It shows the shape, not the complete XSD.

<?xml version="1.0" encoding="UTF-8"?>
<ns:CustomsDeclaration xmlns:ns="https://europa.eu/customs/eucdm/7.0">
  <ns:Declaration>
    <ns:FunctionalReferenceID>2026EU0001234567</ns:FunctionalReferenceID>
    <ns:TypeCode>IM4</ns:TypeCode>
    <ns:GoodsItemNumber>1</ns:GoodsItemNumber>
    <ns:Declarant>
      <ns:ID>NL851234567</ns:ID>
      <ns:Name>Northwind Forwarding B.V.</ns:Name>
    </ns:Declarant>
    <ns:Consignee>
      <ns:ID>NL111222333</ns:ID>
      <ns:Name>Euro Distribution GmbH</ns:Name>
    </ns:Consignee>
    <ns:Commodity>
      <ns:CommodityCode>8542.31</ns:CommodityCode>
      <ns:GoodsDescription>Electronic integrated circuits</ns:GoodsDescription>
      <ns:CountryOfOrigin>CN</ns:CountryOfOrigin>
      <ns:GrossMass>125.50</ns:GrossMass>
      <ns:StatisticalValue>48200.00</ns:StatisticalValue>
    </ns:Commodity>
    <ns:Document>
      <ns:DocumentTypeCode>704</ns:DocumentTypeCode>
      <ns:DocumentReferenceID>INV-2026-000123</ns:DocumentReferenceID>
    </ns:Document>
  </ns:Declaration>
</ns:CustomsDeclaration>

The mapping layer’s job is to fill exactly these nodes from the OCR output: Declarant and Consignee from the bill of lading, Commodity fields from the invoice line items, Document from the document itself. Every code value — the IM4 procedure type, the 8542.31 HS code, the 704 document type, the CN country — comes from an EUCDM pick-list that validation enforces before emission.

Customs Document Types OCR Handles

Different freight documents carry different slices of the declaration, so the pipeline treats them as distinct extraction profiles rather than “any document.”

Document	Primary fields extracted	Where they map in EUCDM
Commercial invoice	Commodity descriptions, HS codes, values, currency, seller and buyer	Goods item, statistical value, parties
Bill of lading (BOL)	Consignee, consignor, vessel/voyage, port of loading/discharge, container numbers	Shipment and transport data, parties, itinerary
Packing list	Package counts, package types, gross and net mass, marks and numbers	Goods item packaging and mass
Certificate of origin / customs certificate	Origin country, certificate reference, issuing authority	Country of origin, document references

This table is also why “customs document automation” is a mapping problem first and an OCR problem second: the invoice and the bill of lading both contribute to the same declaration, but from different fields, and only a pipeline that understands both can assemble a complete EUCDM file.

ICS2 and ASYCUDA Alignment

EUCDM is the model, and ICS2 and ASYCUDA are two of the systems that consume it. Alignment matters because the EUCDM XML your OCR pipeline produces has to survive contact with both a regional and a global customs system.

ICS2 (Import Control System 2) is the EU’s advance cargo information system. The transition to Release 3 — covering maritime, road and rail, in addition to air — was completed in 2025, and ICS2 became fully operational in all member states for all transport modes on 1 September 2025, replacing ICS1 (European Commission, 29 August 2025). Every economic operator bringing goods into or through the EU must submit safety and security data via the Entry Summary Declaration (ENS). A running theme of the ICS2 rollout has been data quality: in the old ICS1, around 60% of maritime entry summary declarations were not complemented by house bill of lading information needed for meaningful risk analysis (European Commission, ICS2 transition strategy). OCR-to-EUCDM automation is a direct answer to exactly that gap — structured house-level data instead of missing or manual fields.

ASYCUDA World is UNCTAD’s customs management system, deployed in more than 185 countries and territories. Unlike ICS2, which is EU-wide, ASYCUDA is per-country and its integration is country-specific. The EUCDM XML output maps into ASYCUDA filings through country-tailored connectors, which is why our customs integrations are always scoped per country and per workflow rather than as a single universal adapter. At European gateways like Rotterdam — where we built the Haven van Rotterdam platform for Europe’s largest port — pre-arrival ENS data quality is exactly the difference between a smooth gate pass and a storage bill.

Governance and Compliance

Automation changes the workload, not the accountability. Customs declarations are legal documents, so AI OCR to EUCDM XML has to ship with a governance model. In our deployments that model has three layers:

• Extraction QA. Every field carries a confidence score. Below a threshold, the document goes to a human exception queue; nothing low-confidence reaches the declaration unattended.
• Licensed customs professionals in the loop. For actual filing, a trained operator or licensed customs agent reviews and submits. The OCR pipeline produces the pre-filled declaration; the professional owns the legal act.
• Audit trail. Every declaration traces back to its source document, the extraction run, and the operator who signed it off — because customs asks, and because an audit trail is what makes automation defensible.

The governance layer is also why OCR-to-EUCDM work should be treated as a custom software development engagement rather than an off-the-shelf install: the extraction profiles, validation rules and country connectors are the product, and they only work when built against your documents and your workflows.

The reform context reinforces why this discipline matters. The EU is mid-way through its most ambitious customs reform since 1968: the European Parliament and Council reached a political agreement on the reform package in March 2026, and the new EU Customs Data Hub is scheduled to open for e-commerce consignments in 2028, on a voluntary basis for other importers in 2031, and becomes mandatory in 2034 — a single online environment where data is compiled and assessed “via machine learning, artificial intelligence and human intervention” (European Commission, EU Customs Reform). Around one billion e-commerce purchases enter the EU every year, which is exactly the volume that only automated, AI-assisted customs document processing can absorb.

Frequently Asked Questions

What is EUCDM?

EUCDM is the EU Customs Data Model — the authoritative source of data requirements for trans-European customs systems (NCTS, AES, ICS) and national clearance systems. It is defined by UCC Regulations 2015/2446 and 2015/2447, and version 7.0 was released in April 2025.

How does AI OCR produce EUCDM XML?

Through five steps: capture, OCR, field extraction, validation against EUCDM rules, and XML emission. Balasci by Esnaj sustains 95%+ extraction accuracy on invoices and bills of lading, and the mapping layer renders validated fields into the EUCDM declaration.

Is OCR-extracted customs data reliable enough for filing?

Yes, with a governance layer: confidence-scored extraction, exception queues for ambiguous fields, human review, and licensed customs professionals signing off the final filing.

What documents can customs OCR handle?

The core set is commercial invoices, bills of lading, packing lists and certificates of origin — each with a dedicated extraction profile that maps its fields into the EUCDM declaration.

Does EUCDM OCR work with ICS2 and ASYCUDA?

Yes. ICS2 has been fully operational for all transport modes since September 2025, and ASYCUDA World covers 185+ countries. The EUCDM XML produced by OCR feeds both, with country-specific connectors for ASYCUDA filings.