Why supplier declarations are difficult to automate
A supplier declaration proves the preferential or non-preferential origin of goods. You need it for a EUR.1 certificate or an origin declaration on the invoice. The problem: every supplier creates their own version. One delivers a German Word document, another an English PDF on their own letterhead, a third sends an Excel table with commodity codes spread across three tabs. The fields you need appear in a different place each time, in a different language, with a different product description. Formats also change whenever a supplier updates their house style or switches to a new ERP. That makes the classic 'one template per sender' model fragile.
Approach 1: manual processing
The most widely used approach is still the employee who opens the declaration, reads the relevant fields, and enters them into the customs system or ERP. That works fine at ten declarations a month. But at a hundred or more documents a month, the data entry piles up, errors creep into commodity descriptions, and turnaround times grow. A mistake in the origin code or a missing invoice reference can lead to corrections at customs or loss of tariff benefits. Manual processing is cheap at low volumes and expensive at high volumes.
Approach 2: OCR with templates
Classic OCR tools work with fixed templates: you define the coordinates of each field on the page for each sender. That is reliable as long as the layout does not change. For supplier declarations, that is a problem: you quickly end up with dozens of suppliers, each with their own format. Every new supplier or layout change requires a new template. The maintenance burden grows with your supplier base. Template OCR only makes sense if you have a small, stable number of fixed suppliers who never change their format.
Approach 3: RPA (Robotic Process Automation)
RPA bots can read screens and copy data between systems. They are strong in repetitive, tightly structured processes. But RPA cannot read unstructured PDFs or variable layouts without an underlying extraction step. In practice, companies combine RPA with OCR templates: the bot picks up the extracted data and deposits it in the target system. That works, but you still have the template problem for the extraction itself. RPA bots are also fragile when screens or document layouts change. The setup and maintenance costs reflect that.
Approach 4: document AI with human-in-the-loop
Document AI reads documents without fixed templates. The tool understands the context of a field, even if that field appears in a different position than last time or is described in German rather than Dutch. For supplier declarations, that means the tool recognises the commodity description, the origin code, the invoice reference, and the validity date, regardless of which supplier prepared the document. What document AI does not do: decide independently. Deviations, low confidence scores, or missing fields are flagged for human review. The employee approves, corrects where necessary, and forwards the document. Legal responsibility stays where it belongs: with the person signing off on the declaration.
Which approach fits which situation?
Low volume, fixed suppliers, stable formats: manual processing or template OCR is sufficient. The maintenance burden of a more advanced system does not outweigh the time savings. High volume, many different suppliers, varying languages and formats: document AI pays off. The threshold is roughly a few hundred declarations per year where you already have multiple formats in play. If you fall somewhere in between, the honest advice is: first map your current error rate and turnaround time. If errors in origin codes are already costing you money at customs, that is a stronger reason to automate than the time argument alone.
What you need to arrange beyond the tool
No system replaces knowing the preferential origin rules. Which commodity code falls under which trade agreement? Does the description in the declaration match the description on the invoice and the packing list? These are substantive questions that an employee must be able to answer. A good tool removes the reading and data entry work, but customs expertise remains essential. That is precisely why the human-in-the-loop model fits here: the tool handles the extraction, the employee handles the substantive sign-off.