Logistics documents: delivery notes, bills of lading, customs

Freight forwarders, carriers, shippers and customs brokers still run on a stream of semi-structured documents: delivery notes, CMR, bills of lading, packing lists, commercial invoices and customs papers, in every layout and many languages, arriving as PDFs, scans and phone photos. Vision-language models and document parsers read them without per-partner templates, check them against each other and against the order, and hand clean data to the TMS, ERP or customs software. Staff handle only the exceptions.

Problem & value

• Today: dispatch and customs clerks retype references, consignee addresses, weights, goods descriptions and container numbers from email attachments into the TMS and the customs software. Paper delivery notes and signed PODs return days late, which delays invoicing; mismatches between invoice, packing list and B/L cause customs queries, demurrage and detention costs.
• AI value: touchless capture of standard documents, faster POD-to-invoice cycles, cross-document checks before a declaration is filed, and a prepared, explainable data set for the (human) declarant.
• Policy tailwind: the EU customs reform entered into force on 20 September 2026 (Regulation (EU) 2026/2108; most provisions apply from 21 September 2027) and is being phased in: the EU Customs Data Hub becomes mandatory for e-commerce on 1 July 2028 and for all importers on 1 March 2034 [4]. Electronic freight transport information (eFTI, Reg. (EU) 2020/1056; check current application dates) and the electronic bill of lading (DCSA eBL standard, UNCITRAL MLETR) shift part of the volume to structured data [2][5]. Paper, PDF and scanned documents from small partners, and non-EU origins remain the long tail for years.
• Industry figures are mostly vendor claims; the McKinsey estimate cited by DCSA puts the potential gain of full eBL adoption at about USD 18 bn [2]. Measure your own baseline instead of relying on vendor ROI numbers.

Variants

• Forwarder / 3PL: inbound email-to-TMS capture of shipping instructions, B/L drafts, packing lists, arrival notices.
• Carrier / trucking SMB: driver photo of the signed delivery note or CMR via app → POD match → invoice release.
• Shipper / manufacturer / retailer: goods-receipt posting from delivery notes (matching to purchase order), see DOC-001.
• Customs broker / in-house customs: extraction of invoice, packing list and origin data to prefill import/export declarations (ATLAS in Germany [3]); HS-code suggestion itself is LANG-031.
• Port / terminal / warehouse: gate and receiving documents, container numbers, seal numbers.
• Bank trade-finance desk: multi-document examination against an L/C is a separate case: DOC-022.
• Private use: parcel customs invoices and import-duty notices for individuals: only marginal; use general DOC tools.

How it works

1. intake (email / EDI inbox / driver app / portal / scanner)
2. classification & splitting (CMR vs. B/L vs. packing list vs. invoice; multi-document PDFs) [DOC-008]
3. OCR + layout parsing (stamps, handwriting, multi-language, rotated scans)
4. schema-based extraction by VLM/LLM (parties, references, container/seal no., goods lines, weights, Incoterms)
5. normalisation & validation (ISO 6346 container check digit, HS format, country/UN-LOCODE, weights/volume plausibility)
6. cross-document matching (invoice ↔ packing list ↔ B/L ↔ order/shipment)
7. confidence routing
8. human review screen with source highlighting
9. TMS / ERP / customs software (via API, EDI, or RPA) + archiving

• Extraction: a VLM reads the page image and returns JSON against a schema per document type; classic OCR + templates is legacy.
• Rules beat the model for validation: container-number check digits, date logic and sum checks are deterministic.
• Human-in-the-loop: low-confidence fields, new partners, dangerous-goods and customs-relevant fields (value, origin, goods description) always get a clerk review. Customs declarations remain the declarant's legal responsibility.
• Signature/stamp detection: POD checks whether a signature and a consignee stamp are present and legible. This is a document check, not identification of a person.

Data preparation

Data: delivery notes, CMR, bills of lading, packing lists, invoices and customs papers, plus master data (orders, shipments, parties, item master, HS code lists). In an SMB these arrive by e-mail, driver photos, fax and paper; master data lives in the ERP or TMS; filed copies sit in a DMS or on file shares.

Typical gaps: crumpled, rotated or photographed documents, multi-document PDFs, stamps and handwriting, many languages, inconsistent partner names and item numbers, and missing links between a document and its shipment.

Preparation steps: 1. Centralise intake in one mailbox or portal and normalise formats (PREP-005, PREP-007). 2. Collect 20-50 real samples per document type and partner as test set (PREP-018, PREP-016). 3. Export clean master data from ERP or TMS, with consistent party names and aliases (PREP-015, PREP-012). 4. Define the target schema and validation rules (container check digits, HS format, weight sums). 5. Set up classification and splitting first (DOC-008). 6. Clarify driver and consignee personal data handling (PREP-025).

Tools: ERP export or API connectors, OCRmyPDF, document-AI services, a simple rules library.

Effort share: about 30 percent; most effort goes into master-data cleanup and sample collection, not the extraction itself. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path A. Mature, EU-hostable extraction products for logistics documents with TMS and ERP connectors exist at SMB prices, and delivery notes and CMR are standard documents.
• Enterprise: Path B. Volume, multiple carriers and own TMS, ERP and customs systems favour API-based pipelines with custom validation rules.
• Developer: Path B. Cloud document-AI and VLM APIs with a schema-based extraction layer are the fastest route for integrators.
• Public: Path B. Customs and port authorities can use EU-region APIs with strict AVV, because the document types are standard and the data is mostly business data.

Path A — Buy (recommended for most SMBs)

• Logistics-specific IDP / email-to-TMS tools: e.g. Cargowise-ecosystem and TMS-embedded capture modules, plus specialised vendors such as Hypatos (Munich, DE), Rossum, ABBYY Vantage, Klippa (NL), Mindee (FR), Docsumo, Nanonets; verify the vendor's logistics support for CMR/B/L/AWB. EU-based: Hypatos (DE), Klippa (NL), Mindee (FR); check data residency for the others.
• Archive/DMS and mailroom: DocuWare, d.velop, ELO (DE) cover receiving, POD archiving and revisionssichere Ablage.
• Customs software: certified ATLAS software vendors (list on zoll.de [3]) increasingly add document import.
• Choose A when: standard document types, a TMS/ERP with an existing connector, volume below several 100k documents/year.

Path B — Build on cloud APIs

• Document APIs: Azure AI Document Intelligence (prebuilt invoice, layout, custom extraction and classification; EU regions) [1], Amazon Textract (AnalyzeDocument queries, custom queries, AnalyzeExpense for invoices; EU regions) [6], Google Document AI (EU location), Mistral OCR (EU provider; table, header/footer, bounding-box blocks, annotations for structured output) [7].
• General VLM extraction: multimodal frontier models (Claude, Gemini, GPT, Mistral) with structured outputs for long-tail layouts; pin an EU region or EU-hosted endpoint.
• Orchestration: n8n / Power Automate / custom service; integrate via TMS API, EDI (EDIFACT IFTMIN, CUSCAR) or the customs software's import interface.
• Choose B when: you need custom logic, many document types or integration into a bespoke TMS.

Path C — Self-host (open source)

• Parsing: Docling (IBM, MIT licence, runs locally/air-gapped, MCP server, Granite-Docling VLM) [8], olmOCR 2 (AI2, Apache 2.0, needs a ≥12 GB GPU) [9], PaddleOCR / PaddleOCR-VL, MinerU.
• Extraction: open VLMs such as Qwen3-VL (2B–235B, Apache 2.0, OCR in 32 languages, has a key-information-extraction cookbook) [10], served with vLLM and constrained JSON decoding.
• Workflow: n8n self-hosted or Camunda; DMS for archive.
• Hardware: HW2 (one 24–32 GB GPU) covers a mid-sized forwarder with an 8B VLM; HW3 for 32B-class models or high volume.
• Choose C when: commercial documents and consignee data must not leave your premises, or volume makes API costs high.

Path D — Custom training

Rarely needed. Fine-tune a small VLM or a classifier only for very high volumes of unusual documents (e.g. handwritten driver notes in several languages, regional customs forms) or to cut inference cost. A few hundred to a few thousand labelled documents per type are needed; reviewer corrections from the clerk screen are the natural training data.

State of the art (2026)

• Template-free extraction by VLMs is standard. Open parsers (olmOCR 2 scores 82.4 on its own olmOCR-Bench [9], Qwen3-VL, Granite-Docling) and commercial APIs are close enough that choice depends on language mix, scan quality and hosting rules rather than headline accuracy.
• Structured outputs remove malformed JSON; confidence per field/block is available from several APIs (e.g. Mistral OCR [7]).
• Cross-document reasoning (invoice vs. packing list vs. B/L) is where LLMs add most value over plain OCR, with deterministic rule checks as the backbone.
• Agentic exception handling: agents that request missing documents from partners or chase a POD are covered in AGENT-024.
• Digital documents: eBL (DCSA standard with open APIs [2]), MLETR-based legal recognition of electronic transferable records [5] and eFTI reduce OCR need over time but add validation, API-integration and legal-control tasks.
• Limits: poor fax-like scans, curved phone photos, handwriting, stamps over text, mixed languages, and multi-page tables of goods lines still cause errors; VLMs can produce plausible but wrong values (HS codes, weights). Never auto-submit customs-relevant values without checks.

Shared resources & combinations

• Same stack (ocr-docparse + vlm + llm-general): DOC-001 invoices, DOC-005 handwriting, DOC-008 mailroom/classification, DOC-014 parsing for RAG, DOC-019 certificate verification, DOC-022 trade-finance examination: one self-hosted VLM server (HW2/HW3) and one review UI can serve all of them.
• Upstream/downstream: LANG-031 (HS/TARIC classification) uses the goods descriptions extracted here; ANOM-021 (customs risk targeting, authority side) and ANOM-011 (supplier risk) consume the data; PRED-018 (ETA prediction) benefits from timely milestone and POD data.
• Workflow: AGENT-002 (back-office automation) and AGENT-024 (freight operations agent) orchestrate follow-up actions.
• Shared data pipeline: partner and party master data, ISO 6346 / UN-LOCODE / HS reference tables, and the archive.

Effort, cost & KPIs

• Path A: days to a few weeks; pricing typically per document or per user.
• Path B: 1–3 months incl. TMS/ERP integration; API cost per page is normally small compared to clerk time.
• Path C: 2–4 months; one GPU server plus operations. olmOCR's authors cite under USD 200 per million pages for conversion on own GPUs [9], excluding extraction logic and ops.
• KPIs: touchless rate per document type, field-level accuracy (esp. container no., weights, references), POD turnaround time, cost per document, customs-query rate, demurrage/detention incidents, share of documents needing manual correction.

People & change

Involve: management (savings, risk appetite), the logistics or dispatch lead as process owner, the clerks who review documents, IT (TMS and ERP interfaces), the data owner of master data, the DPO (driver names, signatures) and key carriers or customers who send the documents. Customs brokers should be consulted when prefilled declarations are planned.

Works council: depends. A review screen that logs corrections or throughput per clerk can be objectively suited to monitor performance, which triggers co-determination under §87(1) no. 6 BetrVG (BAG: suitability suffices). Disable per-person statistics or agree on them in a works agreement; inform the council under §90(1) no. 3 in any case. See GUIDE-004.

Data protection: names, signatures and driver data are personal data; conclude an AVV with the vendor and let the DPO assess whether a DPIA is needed (GUIDE-005).

AI literacy: support clerks with a short training on typical extraction errors and when to override (AI Act Art. 4; GUIDE-006).

Pilot and communication: start with one lane or one customer, run in shadow mode next to manual entry for two to four weeks, then switch to review-by-exception (GUIDE-009, GUIDE-008).

Concerns: job loss (shift from typing to exception handling and customer service), errors in customs data (the declarant stays responsible; critical fields always get human review).

Risks, regulation & compliance

• EU AI Act: minimal risk for document capture of commercial documents; no Annex III category. AI literacy duty (Art. 4) applies to staff. A system used by authorities for customs risk assessment is a separate matter (ANOM-021; border/migration contexts can be high-risk).
• GDPR: delivery notes and CMR carry consignee names, addresses, phone numbers and driver signatures. Data processing agreement, EU hosting, retention limits, role-based access to PODs; avoid sending driver photos with faces to third-country APIs.
• Customs law: the declarant is liable for the correctness of the declaration under the Union Customs Code; AI output is a draft. Keep the audit trail of source document → extracted value → submitted value.
• Tax/bookkeeping: German GoBD applies to delivery notes and invoices as accounting documents (traceable processing, unchangeable archive).
• Legal value of documents: a scanned B/L is not a negotiable original; electronic transferable records need a legally recognised system (MLETR-based laws) [5].
• Mitigations: schema validation, deterministic checks, confidence thresholds, four-eyes for customs-relevant fields, regular sampling of auto-approved documents.

Getting started

1. Inventory document types, languages, channels and volume; collect 100 real documents per type, including bad scans and handwritten notes.
2. Check whether your TMS/ERP/customs software already offers capture (Path A) and what the EU data-residency terms are.
3. Test 2–3 candidates (a vendor tool, a cloud API, an open VLM such as Qwen3-VL via Docling) on your own samples and measure field-level accuracy.
4. Define the schema, deterministic validations and confidence thresholds; build a review screen with source highlighting.
5. Start with one flow (e.g. POD to invoice release), measure the touchless rate, then add B/L and customs documents.

Sources

1. Microsoft — Azure AI Document Intelligence invoice model (prebuilt, custom extraction/classification, v4.0 GA) — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/invoice
2. DCSA — Bill of Lading standard (eBL, open APIs, McKinsey estimate) — https://dcsa.org/standards/bill-of-lading
3. German Customs (Zoll) — ATLAS IT system overview, certified software — https://www.zoll.de/DE/Fachthemen/Zoelle/ATLAS/atlas_node.html
4. European Commission, DG TAXUD — EU customs reform, Customs Data Hub and EUCA timeline — https://taxation-customs.ec.europa.eu/customs/eu-customs-reform_en
5. UNCITRAL — Model Law on Electronic Transferable Records (MLETR) — https://uncitral.un.org/en/texts/ecommerce/modellaw/electronic_transferable_records
6. AWS — What is Amazon Textract? — https://docs.aws.amazon.com/textract/latest/dg/what-is.html
7. Mistral AI — Document AI / Basic OCR documentation — https://docs.mistral.ai/capabilities/document_ai/basic_ocr/
8. Docling project — https://github.com/docling-project/docling
9. Allen Institute for AI — olmOCR — https://github.com/allenai/olmocr
10. Qwen team — Qwen3-VL — https://github.com/QwenLM/Qwen3-VL