Use caseDocument AIWorkflow automation
Customs declarations drafted from commercial invoices and packing lists, for the declarant to sign
Invoices, packing lists and bills of lading cross-checked, tariff codes proposed from your history and EU rulings, and drafts ready for a declarant to sign.
A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .
The short version
A drafting workflow for customs brokers and in-house customs teams. It reads the commercial invoice, packing list and bill of lading for each shipment, checks them against each other, computes the customs value, takes tariff codes from the broker's own accepted history or proposes new ones with EU binding rulings as evidence, and writes a draft into the customs software that files to ATLAS or CDS. A declarant reviews and signs every declaration; screening hits and new classifications always go to a person.
- Best for
- Customs brokers and importers filing dozens to hundreds of import declarations a day from emailed shipment documents.
- Connects to
- Customs software (CargoWise, AEB, DAKOSY or similar), ATLAS (Germany) or CDS (UK), Outlook, Excel, EU TARIC and EBTI, Classification history, Sanctions lists
- The AI does
- Reads invoices, packing lists and transport documents in any layout or language, and argues a tariff code for goods it has not seen before.
- People do
- Decide every new classification and preference claim, clear screening hits, and sign each declaration before it is transmitted.
- Built as
- AI Workflow Automation, usually $15K - $30K
Two hundred declarations a day, keyed line by line
Take a customs broker in Hamburg with twelve declarants filing about 200 import declarations a day, most of them for sea containers coming through the port. Documents arrive by email from forwarders and importers, and every one of them sends a different format: a commercial invoice as a PDF, a packing list that is sometimes a PDF and sometimes a spreadsheet, a bill of lading or sea waybill, and now and then a statement on origin or a certificate.
The declarant keys the header and every line into the customs software: seller, buyer, Incoterm, currency, quantities, weights, values, origin and a ten-digit commodity code per line. A container of mixed components can run to forty lines. Most codes are known, because the same importer ships the same part numbers every month, but they still have to be looked up. The new items are where the time goes: Tarifflo, which sells classification software, puts the cost of classifying one product at a broker at about $100 and says it can take weeks.
Mistakes stay expensive long after the container has gone. A broker acting as indirect representative is a debtor for the customs debt alongside the importer, and customs can revisit declarations in a post-clearance audit years later. A wrong code, freight left out of the customs value or a preference claimed on an invalid origin proof turns into a demand for duty, and into questions about the broker's reliability.
What the broker needs is not an AI that files declarations. It needs a draft that is right where the answer is knowable (values, weights, codes already accepted), honest where it is not, and fast for a declarant to check.
One container's paperwork, checked before anyone keys a line
The declarant's first view of a shipment is not a blank declaration. It is a draft with the problems already listed at the top.
Customs inbox, Monday 07:42
Forwarder · Email
Pre-alert: 1 x 40' ex Ningbo, ETA Hamburg Wednesday. Invoice, packing list and sea waybill attached. Consignee as usual.
- extract(document: "commercial_invoice.pdf")seller and buyer identified / Incoterm FOB Ningbo / currency USD / 5 lines summing to the invoice total of USD 38,460.00 / no statement on origin
- extract(document: "packing_list.xlsx")5 lines / 316 cartons / gross 7,412 kg / net 6,980 kg
- extract(document: "sea_waybill.pdf")1 container / 316 packages / gross 7,412 kg / Ningbo to Hamburg
- cross_check(shipment: "S-26-10417")packages 316 / 316 / 316 / gross weight agrees / line 3 quantity: invoice 2,400 pcs, packing list 2,040 pcs: MISMATCH
- classification_history(importer: "K-1182", lines: 5)lines 1 to 4: part numbers declared before, codes accepted on 11 earlier declarations, no customs queries / line 5: new part, 'LED driver 24V 60W IP67'
- suggest_code(line: 5, evidence: ["data sheet", "EBTI", "explanatory notes"])candidate 8504 40 (static converters) under GIR 1 and 6 / data sheet confirms AC input, constant-current DC output / 3 comparable BTIs found / declarant to decide
- customs_value(incoterm: "FOB", freight: "EUR 1,840.00", insurance: "EUR 38.50")invoice converted at this month's customs exchange rate / freight and insurance to the EU border added / method: transaction value
- screen(shipment: "S-26-10417")seller, manufacturer, buyer, notify party: no matches on the sanctions lists
Drafting workflow · Customs software
Draft S-26-10417 created, status 'awaiting review', not transmitted. Two items need you. Line 3: the invoice says 2,400 pieces, the packing list 2,040; a query to the forwarder is drafted. Line 5: new part, suggested 8504 40, with three comparable BTIs and the data sheet linked. Lines 1 to 4 use codes from the importer's accepted history.
- The declarant sends the query. The forwarder replies at 09:15 with a corrected packing list showing 2,400 pieces, and the cross-check re-runs on its own. Nothing reaches ATLAS until the declarant signs.
How a shipment turns into a draft declaration
The model reads documents and argues for tariff codes. Values, exchange rates, screening and the decision to file belong to code and to people.
01 Trigger · Microsoft Graph, CargoWise
Shipment documents arrive
A pre-alert in the customs inbox, an importer's upload, or documents attached to a job in the forwarding system. Each is linked to a shipment by bill of lading, container or job number, and documents that arrive later update the same draft instead of starting a new one.
02 AI model · Vision model, strict schema
Read every document
Invoice, packing list and transport document are classified and extracted into header and line fields, each with its page and position, using the same extraction core as PDF data extraction. Goods descriptions are kept verbatim, because the declarant needs the supplier's own words rather than a paraphrase.
03 Plain code
Cross-check and compute the value
Packages, quantities and weights must agree across the documents within tolerances set per importer, and line values must sum to the invoice total. The customs value follows the Incoterm: an FOB invoice gets freight and insurance to the EU border added. Currency is converted at the month's customs exchange rate, never the market rate on the invoice date.
04 Plain code · Sanctions lists, TARIC
Screen parties and goods
Seller, manufacturer, buyer and notify party are matched against the sanctions lists, and each code against restriction measures in TARIC. Any hit stops the draft and goes to a named compliance person.
05 Decision
Where does each line's code come from?
Decided line by line, in a fixed order of trust.
- The importer's part number was declared before and accepted then the code is reused and labeled as history
- New goods with a usable description or data sheet then the model proposes a code with its reasoning and comparable BTIs, for the declarant to decide
- 'Parts', 'accessories', 'samples', or no data sheet then no suggestion; a request for a technical description is drafted to the importer
06 System · TARIC, EZT
Pull the measures for each code
Duty rates, anti-dumping measures and their additional codes, licensing requirements and preferential rates come from TARIC, and for ATLAS filings through the German electronic customs tariff. A preferential rate is only offered when an origin proof is on file.
07 Person
The declarant reviews and signs
The draft opens with the problems first: mismatches, new codes, screening results, preference claims. Each field sits next to its source. The declarant decides new codes, confirms or rejects preference and signs, and each decision is recorded with its reason.
08 Result · ATLAS, CDS
Filed through the customs software
The software transmits to ATLAS or CDS and returns acceptance, queries or release. If its interface is down, drafts queue with their status visible and declarants key urgent shipments by hand as before. Decisions on new goods are stored against the part number, so the next shipment starts from history.
Lines that need a declarant's judgment
These cases decide whether a drafting workflow is still trusted after its first month.
Descriptions that describe nothing
'Spare parts', 'accessories' and 'samples' cannot be classified by anyone, human or model. The workflow refuses to guess, holds the line and drafts a request for a technical description or data sheet. The answer is stored in the importer's parts master, so the question is asked once, not every month.
Mixed shipments and groupage
A consolidated container can carry goods for several consignees under one bill of lading, and one invoice can cover several containers. Documents are matched at line level, weights are allocated per consignee, and a declaration is drafted only when every line traces back to one set of documents.
Preference claimed on paper that does not qualify
A lower duty rate under a trade agreement needs a valid proof of origin, such as a statement on origin in the agreement's prescribed wording or a movement certificate. The model reads the statement and flags wording that does not match, but only the declarant decides to claim preference, because a wrong claim comes back as a duty demand after an audit.
Anti-dumping rates that depend on the manufacturer
Some measures set different rates per producer through TARIC additional codes, and the lower company rate needs the invoice declaration the regulation prescribes. The workflow compares the manufacturer on the documents with the listed companies and never applies a company rate unless that declaration is on the invoice.
Sanctions and restricted goods
Screening runs in code on every party, including manufacturer and notify party, and on each code's restriction measures. A match is never cleared by the model, however obvious the false positive looks: a named person clears or escalates it, and the decision is kept with the declaration.
Documents that disagree by a little
A packing list that rounds weights, an invoice with freight folded into a goods line, a typo in the package count. Tolerances are set per importer (a small weight difference can pass, a quantity difference never does), so declarants see the discrepancies that matter instead of a wall of trivial flags.
Where a tariff code comes from, in order of trust
Not every code needs the same review. The draft labels each one with its source, and the review screen treats them differently. Searching rulings and explanatory notes for comparable goods is a retrieval problem, built the way the RAG architecture guide describes.
| Source | When it applies | What the declarant does |
|---|---|---|
| Accepted history | The same importer and part number were declared before, with no customs query | Spot-checks; a changed description, supplier or origin drops the line to a lower level |
| The importer's own BTI | The importer holds a binding tariff information decision for these goods | Confirms it is still valid and covers these goods; it binds only its holder |
| Comparable BTIs from EBTI | Rulings issued to other operators for similar goods | Reads them as evidence rather than as binding, and checks the goods description in each |
| Model suggestion with reasoning | New goods with a usable description or data sheet | Decides the code; the reasoning and the chosen code become history for the next shipment |
| No suggestion | Vague descriptions, or goods under restriction measures | Gets the technical description from the importer before deciding |
Reading, arithmetic and signatures: who owns which
The AI model
Read invoices, packing lists and transport documents in any layout or language
Layouts vary by supplier; a model reads them without a template per supplier.
Argue a tariff code for new goods, with comparable rulings
A useful case for a declarant to check, never a decision.
Draft queries to forwarders and importers
A specific question ('line 3: 2,400 or 2,040 pieces?') gets answered faster than 'please check'.
Plain code
Cross-check documents and compute the customs value
Incoterm rules, exchange rates and arithmetic must be exact and repeatable.
Reuse codes from accepted history
A lookup, not a judgment.
Screen parties and goods
List matching is deterministic, with thresholds set by the compliance team.
A person
Decide new classifications and preference claims
The broker carries the liability, so a declarant with the knowledge makes the call.
Clear screening hits
Sanctions decisions belong to a named person.
Sign and release the declaration
Filing is the legal act; the workflow only prepares it.
Your customs software's own automation, a specialist tool, or a drafting layer of your own?
There are good products for this. Digicust, an Austrian company, automates customs clearance work across Europe and reports more than 500,000 declarations processed, its own figure from its EUR 2.3M funding announcement. US brokers have classification tools such as Tarifflo and TariffLens. The customs platforms most brokers file from (AEB, Descartes, DAKOSY, CargoWise) are adding automation of their own, so ask your vendor first. If your documents are fairly standard and a vendor module fits, buy it.
A custom layer wins when the value sits in your own data and system mix: years of accepted classifications per importer that no vendor has, filings into more than one customs system (ATLAS for German work, CDS for UK work), documents from hundreds of forwarders in no standard shape, and tolerances and query habits of your own. It sits in front of the software you already file from and can be pointed at a different one if you ever change vendors.
What I would suggest to most brokers is a hybrid: the customs software remains the only thing that talks to customs, the intake, cross-checks and classification history become your own workflow, and a vendor classification tool can be one more source in the order of trust if it earns its place. Other logistics use cases reuse the same document intake.
How you would know it is working
A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.
- Lines drafted from accepted history
- The share rises as history fills. Lines outside it are where declarant time goes, so this is the number that shows the workflow maturing.
- Declarant changes before signing
- Fields edited per draft, by field type and source. Values and quantities should almost never change; codes for new goods sometimes will.
- Acceptance of classification suggestions
- For new goods, how often the declarant chose the suggested code, broken down by tariff chapter to show where suggestions are weak.
- Customs queries and post-release corrections
- Queries from customs and amendments after release, for the same importers before and after the workflow went live.
- Time from complete documents to filing
- Per importer and shipment type, with time spent waiting for documents separated from review time.
What a build like this costs
This is built as AI Workflow Automation, which runs $3.5K - $60K overall. A build like this one usually lands in the multi-step workflow tier: $15K - $30K, 3-5 weeks. The first working version runs on your real data well before the end of that window.
What it costs to run
A routine shipment with known part numbers costs a few cents in model usage to read and check. A new item costs more, because rulings and notes are pulled into context for the classification argument. TARIC and EBTI are public EU databases; a commercial sanctions screening service, if you use one, is usually a subscription.
What moves the price
- How the customs software accepts drafts: a documented API, an import file, or neither
- How many customs systems and countries are in scope: ATLAS alone, or ATLAS and CDS
- The state of the classification history, and how much cleaning and normalizing per importer it needs
- The number of document layouts and languages across your forwarders and suppliers
- Importer-specific rules such as anti-dumping exposure, licensing or CBAM goods
Who this is for
- Customs brokers in Hamburg, Bremerhaven, Rotterdam or Antwerp filing high daily volumes for returning importers
- Importers with in-house customs teams re-keying supplier invoices into ATLAS or CDS software
- Forwarders that offer customs clearance and are losing its margin to manual entry
- Brokers whose classification knowledge lives in senior declarants' heads and old declarations rather than a searchable history
Questions people ask about this
Can AI classify HS codes accurately?
It can propose good candidates with reasoning, especially when the description is specific and comparable binding rulings exist, but it should not decide. Classification turns on details a description often leaves out: material, function, how the goods are presented. Here a code the importer has declared before comes from history, a new code comes from the declarant, and the model's suggestion is the argument the declarant checks.
How do I automate customs declarations from commercial invoices?
Extract the invoice, packing list and transport document into fields with page positions, check them against each other in code, compute the customs value from the Incoterm and the monthly customs exchange rate, and write the result as a draft into the customs software you already file with. A declarant reviews it, decides anything new and signs. The automation removes typing and finds mismatches; it does not remove the signature.
Does it send declarations to ATLAS or CDS directly?
No, and deliberately so. Your customs software stays the only system that transmits to customs; the workflow writes drafts into it through an API or import format. That keeps the software's certification, its response handling and its audit trail, and it gives you a fallback: if the workflow is down, declarants keep working in the same software as before.
What happens with vague descriptions like 'spare parts'?
Nothing is guessed. The line is held, the draft tells the declarant why, and a request for a technical description or data sheet goes to the importer. When the answer comes back it is stored against the part number, so the next shipment of the same goods does not trigger the same question.
Can AI screen shipments for sanctions?
Screening itself should be code, not a model: every party and every code is matched against the sanctions lists and TARIC restriction measures, with thresholds your compliance team sets. What the model adds is reading names and addresses out of messy documents so nothing escapes the screen. Every hit goes to a named person, who clears or escalates it.
What does customs declaration automation cost to build?
Builds like this typically sit in the multi-step tier of AI workflow automation shown here, three to five weeks for the first importers and document types. What moves the price is how your customs software accepts drafts, how many customs systems are involved, and how much classification history needs cleaning first. Running costs per shipment are small; the history is where the value builds up.
Sources