·9 min read
What AI can and cannot do with customs documents
Every vendor in this market now says its software reads your documents. That is true, up to a point. This is the honest version: what automatic extraction really solves, where it demonstrably breaks, and why the way a system shows its doubt matters more than how often it gets things right first time.
What does it actually mean when software says it reads your documents?
Reading documents is not one operation but three, and they fail in different ways. The first is extraction: working out from a pdf or a scan which characters are on the page and which field they form. That the page says EUR 14,320.00 is one thing. That this is the invoice total and not the subtotal or the freight amount is another. The second is classification: deciding what kind of document you are holding and what role each block of text plays. A delivery note, a proforma invoice and a commercial invoice look alike, and the differences sit in details that one layout puts at the top and another at the bottom. The third step is the one that saves the most work in practice: laying the documents alongside each other. Does the number of packages on the packing list agree with the invoice lines. Is the gross weight on the bill of lading anywhere near the one on the packing list. Does the certificate refer to the same consignment number. That third step is no longer a reading problem, it is arithmetic and comparison, and it is exactly there that a machine is tireless in a way nobody is at four in the afternoon.
Where does extraction work without complaint?
On the boring majority. A commercial invoice produced by a regular supplier's ERP, sent as a pdf with a real text layer, carrying the same headings in the same places every month, is almost a structured file that happens to travel as a document. The same holds for packing lists out of a WMS and for standard certificates an authority issues on a fixed template. The pattern behind those cases is not a good looking document, it is repetition. With a sender you see every week, a system knows where the incoterm sits, that the currency is in the top right and not next to the amount, that Ref. means the purchase order number for this party and the container number for another. The more often a sender comes back, the less there is to guess. That is also the honest limit of the promise. Extraction works well on the traffic you already know, and by volume that traffic fills most of your days. It is not the part where declarations get stuck, because that is not where your time goes. Your time goes into the exceptions.
Where does it demonstrably break?
The list is concrete and anyone who files declarations recognises it. Handwriting, for instance a weight added in pen on the quay, or a signature with a date under it that is what makes the certificate valid. A stamped document that was once a fax, then copied, scanned and forwarded again, with the stamp landing squarely over the text you need. A packing list of eleven pages whose line count does not add up to what the invoice says. A table that continues across a page break, where the headers are not repeated and the last line of page three and the first of page four are in reality one line. Documents in two languages at once, with a Chinese description and an English one under it that does not say the same thing. And the photograph: a page someone captured at an angle with a phone, with a shadow over the right column and a fold running through the amount. What these cases share is that they are not merely a bit harder. They are the cases where a system that has to produce an answer anyway fills in something plausible. Everyone sees an empty field. Nobody sees a neatly filled wrong one.
Why a confidence score is not the same as being right
A score says how well an answer fits the patterns the model has seen before. That is a different question from whether the answer is true. A cleanly printed invoice with an amount sitting in the wrong column produces a high score on exactly that wrong amount, because the shape is right. The score measures the shape, not reality. That is the asymmetry you have to design around. A field flagged as uncertain costs you twenty seconds and ends well. A field that is wrong with high confidence goes into the file, past the colleague who trusts it, into the declaration and eventually to customs. Wrong with confidence is more expensive than uncertain. So the interesting question is not how often a system gets it right, but whether it knows when it does not know, and what it does then. A reader that would rather leave a field empty when in doubt is more useful than one that always fills something in. The first costs an action. The second costs a correction after the fact, and sometimes more than that.
Why every field has to carry a source label
Once you accept that a system is sometimes wrong, the question is no longer how to rule out errors but how to find them within seconds. That is a design requirement, not a nice extra. Every extracted field carries a label back to the document it came from and to the position on the page, so one click puts the fragment next to the field. The difference in daily work is large. Without a source label you check an invoice total by opening the document, finding the right page, hunting with your eyes and comparing the amount. With one, the line the value came from sits next to the field and you either confirm or correct. Checking becomes looking instead of retyping. You need that same chain later on. In an audit you have to be able to show where a declared customs value comes from: which invoice amount, which freight costs up to the place of introduction into the Union, which exchange rate at which moment. A system that keeps the number but not its origin lets you down at exactly the moment the question is asked.
Why classification is not an extraction problem
Extraction and classification get mentioned in one breath and they are different things. Extraction is a factual question: does this appear here. Classification is a legal judgement. You apply the classification rules to a product, you weigh its nature, its composition and its function, you choose between headings that exclude each other, and you move through an hs code that fixes the first six digits to the full code the duty rate hangs on. Liability hangs on that judgement. The code sets the duty rate, any preference, whether anti dumping duty applies and which prohibitions and restrictions come with it. If it is wrong, a post clearance recovery follows, and under indirect representation it lands with you. Anyone who wants certainty applies for a BTI, and that route exists precisely because the answer cannot be read off the document. Software may help here by narrowing the search: putting the description next to earlier consignments, proposing the code you used before for this sender and this article, and warning when a proposed code brings measures the file does not cover. Propose and substantiate. The decision stays with the declarant.
So what is the human in the loop actually for?
Not for going over everything again. Anyone who re-checks every field has given away the time saved and is left with one more screen. The human is there for the places where judgement lives, and a well built reader pushes them towards those places. There are three of them. First, the fields the system cannot close by itself, with the source document beside them, so the decision takes seconds. Second, the contradictions between documents: the packing list with twelve lines against an invoice with eleven, the description on the certificate naming a different species than the invoice. A machine can point at the difference but cannot decide which document is right, because that takes a phone call to the sender. Third, the judgement that belongs to the declarant: the classification, the customs value under an unusual pricing arrangement, the question whether a proof of origin fits this flow of goods. That is exactly the work you employ a declarant for. The gain is not in replacing that judgement, but in stopping it from drowning in the retyping of data that already exists digitally somewhere, even on a perfectly ordinary import declaration.
