Nobody owns the commodity code, and your automation copies it anyway

Ask around your company who owns the commodity code on your export documents. Sales will point at logistics, logistics will point at purchasing, and purchasing will tell you the field is filled in when an article is created. Nobody owns it, and yet every cross-border document you produce quotes it.

That worked while a person typed the paperwork. Somebody had to look at the field to fill in the form. Once an automation builds the commercial invoice and the export declaration straight from the order, nobody looks at it again, and whatever sits in the article record becomes a statement made to a customs authority.

Two failure modes, and the cheap one is the loud one

An empty field is the harmless version. The freight forwarder calls, somebody finds a code that looks about right, types it onto the document, and the order ships. The article record stays empty, so the same call comes again next week. It is annoying, it is visible, and it costs almost nothing.

The expensive version is a code that is present, correctly formatted and wrong. Nothing stops. The declaration goes in, the duty rate is wrong, and the shipment clears. You find out during an audit, when the authority looks back over the open period and asks for the difference. If you ship delivered duty paid, that difference is yours, not your customer's.

Most of the cost is not the duty. It is the work of identifying which shipments were affected, because a wrong code appears in every document and is flagged as an error in none of them.

Codes are not permanent, and article records treat them as if they were

The combined nomenclature is revised every year, effective 1 January. Headings get split, merged or dropped, and the changes are published months in advance.

Your article number does not change. Your commodity code does. Any system that treats the field like a weight or a dimension, something you set once at creation, contains a defect that grows by one year every year.

We are regularly asked to have a workflow suggest the code from the article description, sometimes with a language model attached. Classification is a legal judgement, and where it is genuinely unclear there is a formal ruling you can apply for. A workflow that guesses moves the decision to something that carries no liability. The liability stays with you.

Country of origin is not where your supplier sits

The single most common mapping we find in export workflows takes the country from the supplier's address and writes it into the article as country of origin. That is a field from your creditor master. It is not an origin.

Origin follows where the goods were produced or substantially processed, not who invoiced them. The evidence is a supplier's declaration, and those are issued for a defined period. Long-term declarations expire, usually without anyone chasing them.

A country printed on the carton does not close that gap either. A manufacturer's marking is not proof of preferential origin.

If your document names an origin you cannot evidence, your customer loses a preference they claimed, and they will come back to you for the money.

Intrastat counts movements, not invoices

Statistical reporting is usually assembled from the month's invoice lines, because that data is clean and easy to query. The report asks for movements of goods instead.

So the cases without an invoice fall out: the free replacement after a complaint, the sample sent at no charge, the item that goes abroad for repair and comes back. All of them cross a border. None of them produce a line your workflow finds.

The reverse also holds. The statistical value includes freight and insurance up to the border, so the invoice total is not the figure being asked for. This rarely surfaces on its own. It surfaces when the statistical office queries a month that looks too small.

The import side fills the same field

On imports, your customs agent files in your name, and files what you send them. The code printed on your supplier's document is their classification under their law. It may well be right. The declaration is still yours.

A workflow that copies the code out of the supplier invoice into your handover file, because that is where it happens to sit in machine-readable form, has adopted somebody else's decision without checking it. This has become more common as ordering and customs systems have been wired together. When a person filled in the form, they were forced to look.

What the automation should actually do

It should not classify and it should not guess. Its job is to stop an empty or implausible field from reaching a document unnoticed.

Check at article creation, not at document creation. An article without a commodity code gets a flag and cannot be sold abroad until somebody supplies one. That is inconvenient, which is exactly why it works. Move the check to document creation and you are stopping an order the customer has already been promised.

Three checks are enough to start: is the field populated, does the content have the number of digits the declaration expects, and does that code exist in the current year's list rather than the 2019 one. The third is the one almost everybody skips. A code that used to exist looks exactly as plausible as a valid one.

Three queries worth running this week

Pull the articles with cross-border revenue over the last twelve months and filter for a missing commodity code. Count the revenue, not the articles. Forty articles carrying 900,000 in sales is a different problem from forty articles carrying 9,000.

Then look at the digit counts in the field. Six, eight and ten digit entries sitting side by side, some with dots and spaces, is not a formatting issue. It means several people wrote different things into the same box over the years.

Finally, check when the field was last modified. If that date matches the article creation date for most of your catalogue, your master data has never been through a single annual revision of the nomenclature.