Automating customs documents: AI prepares, the declarant decides

Automating customs documents means reading, checking and preparing the data a customs declaration needs automatically. Today, in dispatch or customer service, someone usually sits with a commercial invoice in one hand and the packing list in the other, keying item, value, weight and country of origin into a spreadsheet for the customs broker. A system can take over much of that work. The declaration itself stays with the declarant.

What does the system take over?

The system pulls the data out of the separate documents, so the declarant no longer does that by hand. It is about the preparation. The system reads what comes in, sets it against what you already know from your WMS or ERP and flags what does not match.

After that check the data goes in a fixed format to the declarant or their declaration software. How such a reading step works in general is in document processing in logistics.

Which documents do you read to prepare a customs declaration?

To prepare a customs declaration you mainly read the commercial invoice and the packing list, and set them against the order or shipping instruction in your own system. Sometimes a statement of origin, a certificate or a consignment note comes with them.

Every supplier and every client lays those documents out differently. One sends a clean PDF from its ERP, another a scan with handwritten corrections, a third a spreadsheet with the invoice and the packing list on two tabs. That is work a language model does well: finding the lines in each document, with description, quantity, unit, value, currency, net weight, gross weight and country of origin.

What the model does not know, it leaves empty. If a line has no country of origin, the field stays blank and the line goes on the list for a person. In this work a tidy looking guess is more dangerous than an empty field.

Can AI determine an HS code?

AI can suggest an HS code, but the commodity code that goes on the declaration is confirmed by a person. The model reads the description on the invoice, looks at which code you used before for the same item and searches the nomenclature. What comes out is a suggestion with the reason next to it.

How a commodity code is built

The European commodity code comes from the Combined Nomenclature (CN) and has 8 digits. The first 6 are the HS code of the World Customs Organization, which is the same worldwide and changes once every five years. The last 2 refine the classification within the EU. On import the code is called the TARIC code. Measures can be attached to a code, such as an anti-dumping duty or an import restriction. They are held in the European Commission’s TARIC database.

The CN is revised every year. Dutch Customs says the new version is always published before 1 November and takes effect on 1 January. A system that suggests codes therefore has to know which version applies on the date of the declaration, and flag a code that lapses on 1 January as a doubtful case.

Why a person confirms

A description like ‘cable, black, 2 metres’ fits several codes, depending on material and use. The model sees that too, and should then say which details are missing. According to Dutch Customs, a wrong code can lead to extra costs, delays at import or a fine.

If you want certainty about how a product is classified, you can apply to customs for Binding Tariff Information (BTI). That decision is generally valid for three years and binds the holder and every customs authority in the EU, for formalities completed after its start date. If the declarant or your client holds a BTI for an item, the system takes that code over and suggests nothing itself.

What do you check against the order before the data goes to the declarant?

You check the value, origin, weights and quantities on the commercial invoice against the order, the packing list and what your warehouse actually picked and packed. That is the advantage of a system that looks into your own WMS or ERP: it knows what leaves the building.

Value and currency

On import the customs value is as a rule the transaction value, the price actually paid or payable for the goods (article 70 of the Union Customs Code). The system sets the invoice price per line against the order price, checks that the currency is stated and adds the lines up to the invoice total. A difference goes on the list. Whether the value still needs adjusting, for freight for example, is for the declarant to judge.

Origin

You set the country of origin on the invoice against the item master. If your ERP has an item as made in Vietnam and the invoice says China, someone wants to know before it goes on a declaration.

Weights and quantities

Net weight per line, gross weight per shipment and the number of packages are set against the packing list and your own pick and weighing data. A 400 kilo pallet on a packing list where the invoice says 40 kilos then stands out. It is usually a typo, but one that ends up on the declaration if nobody looks.

Who is responsible for the customs declaration?

Whoever lodges the customs declaration is responsible for the accuracy and completeness of the data and for the documents supporting it. That is article 15 of the Union Customs Code. If a customs representative lodges the declaration, those obligations apply to the representative too.

That representation can be direct, in the name and on behalf of someone else, or indirect, in the representative’s own name but on behalf of someone else (article 18). In the Netherlands, Dutch Customs requires every customs representative to meet the AEO criteria, which include practical competence and proper records.

That is why the AI system we build signs nothing and lodges nothing. It prepares. The declarant sees the suggestion and the source for each field, and decides. What the European AI Act asks of such a system is in the AI Act in logistics.

How does the data reach the declarant or the declaration software?

The data goes in the format your declarant or their declaration software already uses, as a file, through an integration or in a portal. In the Netherlands the declaration itself is lodged electronically through the DMS declaration system of Dutch Customs, and anyone declaring themselves needs approved declaration software for it.

If you work with an external customs broker, a fixed export file per shipment is often enough. If you have your own customs desk, the prepared data can land straight in that desk’s software. The system then sits in the seam between your WMS, your TMS and the declarant, see connecting WMS, TMS and ERP.

You often need the same data for the consignment note as well. How the digital consignment note and the European rules for electronic freight information connect to it is in e-CMR and eFTI.

Checklist for the first export flow

Start with the flow where the most retyping happens now. It suits as a first flow if you can tick these points:

• A client ships the same kind of export every week.
• The invoices arrive as PDFs and are retyped by hand now.
• You know how long that retyping takes per shipment now.
• You can set the system’s suggestions for the past months against the declarations actually lodged.

That last point tells you how often it is right before anything goes live, as our way of working describes. A few real shipments from that flow are worth bringing to an introductory call.