Logistikdokumente: Lieferscheine, Konnossemente, Zoll

Spediteure, Frachtführer, Verlader und Zollagenten arbeiten weiterhin mit einem Strom halbstrukturierter Dokumente: Lieferscheine, CMR, Konnossemente, Packlisten, Handelsrechnungen und Zollpapiere, in jedem Layout und vielen Sprachen, als PDF, Scan und Handyfoto. Vision-Language-Modelle und Dokumentenparser lesen sie ohne Vorlagen je Partner, prüfen sie gegeneinander und gegen den Auftrag und übergeben saubere Daten an TMS, ERP oder Zollsoftware. Die Beschäftigten bearbeiten nur noch die Ausnahmen.

Problem & Nutzen

• Heute: Disponenten und Zollsachbearbeiter tippen Referenzen, Empfängeradressen, Gewichte, Warenbeschreibungen und Containernummern aus E-Mail-Anhängen in das TMS und die Zollsoftware ab. Papier-Lieferscheine und unterschriebene PODs kommen Tage später zurück, was die Fakturierung verzögert; Abweichungen zwischen Rechnung, Packliste und B/L verursachen Zollrückfragen sowie Standgeld (Demurrage und Detention).
• KI-Nutzen: Erfassung von Standarddokumenten ohne Eingriff, schnellere Abläufe von POD bis Rechnung, dokumentübergreifende Prüfungen vor der Abgabe einer Anmeldung und ein vorbereiteter, nachvollziehbarer Datensatz für die (menschliche) anmeldende Person.
• Rückenwind durch Regulierung: Die EU-Zollreform ist am 20. September 2026 in Kraft getreten (Verordnung (EU) 2026/2108; die meisten Bestimmungen gelten ab dem 21. September 2027) und wird schrittweise eingeführt: Der EU-Zolldatenhub wird für den E-Commerce am 1. Juli 2028 und für alle Importeure am 1. März 2034 verpflichtend [4]. Elektronische Frachtbeförderungsinformationen (eFTI, VO (EU) 2020/1056; aktuelle Anwendungsdaten prüfen) und das elektronische Konnossement (DCSA-eBL-Standard, UNCITRAL MLETR) verlagern einen Teil des Volumens auf strukturierte Daten [2][5]. Papier-, PDF- und gescannte Dokumente kleiner Partner sowie Ursprünge außerhalb der EU bleiben noch Jahre der lange Schwanz.
• Branchenzahlen sind meist Herstellerangaben; die von DCSA zitierte McKinsey-Schätzung beziffert den möglichen Gewinn bei vollständiger eBL-Einführung auf etwa 18 Mrd. USD [2]. Messen Sie lieber Ihre eigene Ausgangslage, statt sich auf ROI-Zahlen von Herstellern zu verlassen.

Varianten

• Spedition / 3PL: Erfassung eingehender Mails ins TMS: Speditionsaufträge, B/L-Entwürfe, Packlisten, Ankunftsmeldungen.
• Frachtführer / kleines Transportunternehmen: Fahrerfoto des unterschriebenen Lieferscheins oder CMR per App → POD-Abgleich → Rechnungsfreigabe.
• Verlader / Hersteller / Händler: Wareneingangsbuchung anhand von Lieferscheinen (Abgleich mit der Bestellung), siehe DOC-001.
• Zollagent / betriebliche Zollabteilung: Extraktion von Rechnungs-, Packlisten- und Ursprungsdaten zum Vorausfüllen von Import-/Export- Anmeldungen (ATLAS in Deutschland [3]); der HS-Code-Vorschlag selbst ist LANG-031.
• Hafen / Terminal / Lager: Gate- und Wareneingangsdokumente, Containernummern, Plombennummern.
• Handelsfinanzierung einer Bank: Die Prüfung mehrerer Dokumente gegen ein Akkreditiv ist ein eigener Fall: DOC-022.
• Private Nutzung: Zollrechnungen für Pakete und Einfuhrabgabenbescheide von Privatpersonen: nur am Rande; allgemeine DOC-Werkzeuge nutzen.

So funktioniert es

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

• Extraktion: Ein VLM liest das Seitenbild und liefert JSON gemäß einem Schema je Dokumenttyp; klassische OCR + Vorlagen ist Altbestand.
• Regeln schlagen das Modell bei der Validierung: Prüfziffern von Containernummern, Datumslogik und Summenprüfungen sind deterministisch.
• Mensch-in-der-Schleife (Human-in-the-Loop): Felder mit niedriger Konfidenz, neue Partner, Gefahrgut und zollrelevante Felder (Wert, Ursprung, Warenbeschreibung) erhalten immer eine Prüfung durch eine Sachbearbeiterin oder einen Sachbearbeiter. Zollanmeldungen bleiben in der rechtlichen Verantwortung der anmeldenden Person.
• Erkennung von Unterschrift/Stempel: Beim POD wird geprüft, ob eine Unterschrift und ein Empfängerstempel vorhanden und lesbar sind. Das ist eine Dokumentenprüfung, keine Identifikation einer Person.

Datenaufbereitung

Daten: Lieferscheine, CMR, Konnossemente, Packlisten, Rechnungen und Zollpapiere sowie Stammdaten (Aufträge, Sendungen, Beteiligte, Artikelstamm, HS-Code-Listen). Im Mittelstand kommen sie per E-Mail, als Fahrerfotos, per Fax und auf Papier; Stammdaten liegen im ERP oder TMS; abgelegte Kopien in einem DMS oder auf Dateifreigaben.

Typische Lücken: zerknitterte, gedrehte oder fotografierte Dokumente, PDFs mit mehreren Dokumenten, Stempel und Handschrift, viele Sprachen, uneinheitliche Partnernamen und Artikelnummern sowie fehlende Verknüpfungen zwischen einem Dokument und seiner Sendung.

Aufbereitungsschritte: 1. Den Eingang in einem Postfach oder Portal bündeln und Formate vereinheitlichen (PREP-005, PREP-007). 2. 20-50 echte Beispiele je Dokumenttyp und Partner als Testmenge sammeln (PREP-018, PREP-016). 3. Saubere Stammdaten aus ERP oder TMS exportieren, mit einheitlichen Partnernamen und Aliasen (PREP-015, PREP-012). 4. Zielschema und Validierungsregeln festlegen (Prüfziffern von Containern, HS-Format, Gewichtssummen). 5. Zuerst Klassifikation und Trennung einrichten (DOC-008). 6. Den Umgang mit personenbezogenen Daten von Fahrern und Empfängern klären (PREP-025).

Werkzeuge: ERP-Export oder API-Konnektoren, OCRmyPDF, Dokumenten-KI-Dienste, eine einfache Regelbibliothek.

Aufwandsanteil: etwa 30 Prozent; der meiste Aufwand entfällt auf die Bereinigung der Stammdaten und das Sammeln von Beispielen, nicht auf die Extraktion selbst. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A. Ausgereifte, in der EU hostbare Extraktionsprodukte für Logistikdokumente mit TMS- und ERP-Konnektoren gibt es zu KMU-tauglichen Preisen, und Lieferscheine und CMR sind Standarddokumente.
• Großunternehmen: Weg B. Volumen, mehrere Frachtführer und eigene TMS-, ERP- und Zollsysteme sprechen für API-basierte Pipelines mit eigenen Validierungsregeln.
• Entwickler: Weg B. Cloud-Dokumenten-KI- und VLM-APIs mit einer schemabasierten Extraktionsschicht sind für Integratoren der schnellste Weg.
• Öffentlicher Sektor: Weg B. Zoll- und Hafenbehörden können EU-Region-APIs mit strengem AVV nutzen, da die Dokumenttypen standardisiert sind und es sich überwiegend um Geschäftsdaten handelt.

Weg A — Kaufen (für die meisten KMU empfohlen)

• Logistikspezifische IDP- / E-Mail-zu-TMS-Werkzeuge: z. B. Cargowise-Ökosystem und in TMS eingebettete Erfassungsmodule sowie spezialisierte Anbieter wie Hypatos (München, DE), Rossum, ABBYY Vantage, Klippa (NL), Mindee (FR), Docsumo, Nanonets; die Logistik-Unterstützung des Anbieters für CMR/B/L/AWB prüfen. Aus der EU: Hypatos (DE), Klippa (NL), Mindee (FR); bei den anderen den Datenstandort prüfen.
• Archiv/DMS und Posteingang: DocuWare, d.velop, ELO (DE) decken Wareneingang, POD-Archivierung und revisionssichere Ablage ab.
• Zollsoftware: zertifizierte ATLAS-Softwareanbieter (Liste auf zoll.de [3]) ergänzen zunehmend den Dokumentenimport.
• A wählen, wenn: Standarddokumenttypen vorliegen, ein TMS/ERP mit vorhandenem Konnektor genutzt wird und das Volumen unter einigen 100.000 Dokumenten/Jahr liegt.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Dokumenten-APIs: Azure AI Document Intelligence (vorgefertigte Rechnungs- und Layoutmodelle, eigene Extraktion und Klassifikation; EU-Regionen) [1], Amazon Textract (AnalyzeDocument-Abfragen, benutzerdefinierte Abfragen, AnalyzeExpense für Rechnungen; EU-Regionen) [6], Google Document AI (EU-Standort), Mistral OCR (EU-Anbieter; Tabellen, Kopf-/Fußzeilen, Bounding-Box-Blöcke, Annotationen für strukturierte Ausgabe) [7].
• Allgemeine VLM-Extraktion: multimodale Spitzenmodelle (Claude, Gemini, GPT, Mistral) mit strukturierten Ausgaben für Layouts aus dem langen Schwanz; eine EU-Region oder einen in der EU gehosteten Endpunkt festlegen.
• Orchestrierung: n8n / Power Automate / eigener Dienst; Anbindung über TMS-API, EDI (EDIFACT IFTMIN, CUSCAR) oder die Importschnittstelle der Zollsoftware.
• B wählen, wenn: eigene Logik, viele Dokumenttypen oder die Integration in ein individuelles TMS nötig sind.

Weg C — Selbst betreiben (Open Source)

• Parsing: Docling (IBM, MIT-Lizenz, läuft lokal/air-gapped, MCP-Server, Granite-Docling-VLM) [8], olmOCR 2 (AI2, Apache 2.0, benötigt eine GPU mit ≥12 GB) [9], PaddleOCR / PaddleOCR-VL, MinerU.
• Extraktion: offene VLMs wie Qwen3-VL (2B–235B, Apache 2.0, OCR in 32 Sprachen, mit Cookbook zur Extraktion von Schlüsselinformationen) [10], betrieben mit vLLM und eingeschränkter JSON-Dekodierung.
• Workflow: n8n selbst betrieben oder Camunda; DMS für das Archiv.
• Hardware: HW2 (eine GPU mit 24–32 GB) deckt eine mittelgroße Spedition mit einem 8B-VLM ab; HW3 für Modelle der 32B-Klasse oder hohes Volumen.
• C wählen, wenn: Geschäftsdokumente und Empfängerdaten das Haus nicht verlassen dürfen oder das Volumen die API-Kosten hoch treibt.

Weg D — Eigenes Training

Selten nötig. Ein kleines VLM oder einen Klassifikator nur bei sehr hohen Mengen ungewöhnlicher Dokumente feintunen (z. B. handschriftliche Fahrernotizen in mehreren Sprachen, regionale Zollformulare) oder um die Inferenzkosten zu senken. Pro Typ werden einige hundert bis einige tausend annotierte Dokumente benötigt; die Korrekturen der Prüfenden am Bearbeitungsbildschirm sind die natürlichen Trainingsdaten.

Stand der Technik (2026)

• Vorlagenfreie Extraktion durch VLMs ist Standard. Offene Parser (olmOCR 2 erreicht 82,4 im eigenen olmOCR-Bench [9], Qwen3-VL, Granite-Docling) und kommerzielle APIs liegen nah genug beieinander, dass die Wahl von Sprachmix, Scanqualität und Hosting-Vorgaben abhängt statt von der Spitzengenauigkeit.
• Strukturierte Ausgaben verhindern fehlerhaftes JSON; eine Konfidenz je Feld/Block bieten mehrere APIs (z. B. Mistral OCR [7]).
• Dokumentübergreifendes Schlussfolgern (Rechnung vs. Packliste vs. B/L) ist die Stelle, an der LLMs gegenüber reiner OCR den größten Mehrwert bringen, mit deterministischen Regelprüfungen als Rückgrat.
• Agentische Ausnahmebehandlung: Agenten, die fehlende Dokumente bei Partnern anfordern oder einem POD hinterherlaufen, werden in AGENT-024 behandelt.
• Digitale Dokumente: eBL (DCSA-Standard mit offenen APIs [2]), die auf MLETR beruhende rechtliche Anerkennung elektronischer übertragbarer Aufzeichnungen [5] und eFTI verringern mit der Zeit den OCR-Bedarf, bringen aber Aufgaben bei Validierung, API-Integration und rechtlicher Kontrolle mit sich.
• Grenzen: schlechte faxartige Scans, gewölbte Handyfotos, Handschrift, Stempel über Text, gemischte Sprachen und mehrseitige Tabellen mit Warenpositionen verursachen weiterhin Fehler; VLMs können plausible, aber falsche Werte liefern (HS-Codes, Gewichte). Zollrelevante Werte nie ohne Prüfungen automatisch übermitteln.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (ocr-docparse + vlm + llm-general): DOC-001 Rechnungen, DOC-005 Handschrift, DOC-008 Posteingang/Klassifikation, DOC-014 Parsing für RAG, DOC-019 Zertifikatsprüfung, DOC-022 Prüfung bei der Handelsfinanzierung: Ein selbst betriebener VLM-Server (HW2/HW3) und eine Prüfoberfläche können alle bedienen.
• Vor- und nachgelagert: LANG-031 (HS-/TARIC-Klassifikation) nutzt die hier extrahierten Warenbeschreibungen; ANOM-021 (zollrechtliche Risikoanalyse, Behördenseite) und ANOM-011 (Lieferantenrisiko) verarbeiten die Daten; PRED-018 (ETA-Vorhersage) profitiert von zeitnahen Meilenstein- und POD-Daten.
• Workflow: AGENT-002 (Back-Office-Automatisierung) und AGENT-024 (Agent für den Frachtbetrieb) steuern die Folgeaktionen.
• Gemeinsame Datenpipeline: Partner- und Beteiligten-Stammdaten, Referenztabellen für ISO 6346 / UN-LOCODE / HS und das Archiv.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis wenige Wochen; Preise typischerweise je Dokument oder je Nutzer.
• Weg B: 1–3 Monate einschließlich TMS-/ERP-Integration; die API-Kosten pro Seite sind im Vergleich zur Arbeitszeit der Sachbearbeitung normalerweise gering.
• Weg C: 2–4 Monate; ein GPU-Server plus Betrieb. Die Autoren von olmOCR nennen unter 200 USD pro Million Seiten für die Konvertierung auf eigenen GPUs [9], ohne Extraktionslogik und Betrieb.
• Kennzahlen: Anteil ohne Eingriff je Dokumenttyp, Genauigkeit auf Feldebene (insbesondere Containernr., Gewichte, Referenzen), POD-Durchlaufzeit, Kosten pro Dokument, Rate der Zollrückfragen, Demurrage-/Detention-Fälle, Anteil der Dokumente mit manuellem Korrekturbedarf.

Menschen & Veränderung

Einbinden: Geschäftsleitung (Einsparungen, Risikobereitschaft), die Leitung Logistik oder Disposition als Prozessverantwortliche, die Sachbearbeiter, die Dokumente prüfen, die IT (TMS- und ERP-Schnittstellen), die Datenverantwortlichen der Stammdaten, die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten (Fahrernamen, Unterschriften) sowie wichtige Frachtführer oder Kunden, die die Dokumente senden. Zollagenten sollten einbezogen werden, wenn vorausgefüllte Anmeldungen geplant sind.

Betriebsrat: abhängig vom Einzelfall. Ein Prüfbildschirm, der Korrekturen oder den Durchsatz je Sachbearbeiter protokolliert, kann objektiv zur Leistungsüberwachung geeignet sein, was die Mitbestimmung nach §87 Abs. 1 Nr. 6 BetrVG auslöst (BAG: Eignung genügt). Personenbezogene Statistiken abschalten oder in einer Betriebsvereinbarung regeln; den Betriebsrat in jedem Fall nach §90 Abs. 1 Nr. 3 informieren. Siehe GUIDE-004.

Datenschutz: Namen, Unterschriften und Fahrerdaten sind personenbezogene Daten; mit dem Anbieter einen AVV abschließen und von der/dem Datenschutzbeauftragten prüfen lassen, ob eine DSFA nötig ist (GUIDE-005).

KI-Kompetenz: Die Sachbearbeitung mit einer kurzen Schulung zu typischen Extraktionsfehlern und dazu unterstützen, wann überstimmt werden muss (KI-Verordnung Art. 4; GUIDE-006).

Pilot und Kommunikation: mit einer Relation oder einem Kunden beginnen, zwei bis vier Wochen im Schattenbetrieb neben der manuellen Erfassung laufen lassen und dann auf Prüfung nur der Ausnahmen umstellen (GUIDE-009, GUIDE-008).

Bedenken: Arbeitsplatzverlust (Verschiebung vom Tippen zur Ausnahmebehandlung und zum Kundenservice), Fehler in Zolldaten (die anmeldende Person bleibt verantwortlich; kritische Felder werden immer von Menschen geprüft).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko bei der Erfassung von Geschäftsdokumenten; keine Kategorie nach Anhang III. Die Pflicht zur KI-Kompetenz (Art. 4) gilt für die Beschäftigten. Ein von Behörden zur zollrechtlichen Risikobewertung eingesetztes System ist eine eigene Frage (ANOM-021; Grenz-/Migrationskontexte können Hochrisiko sein).
• DSGVO: Lieferscheine und CMR enthalten Empfängernamen, Adressen, Telefonnummern und Fahrerunterschriften. Auftragsverarbeitungsvertrag, EU-Hosting, Aufbewahrungsfristen, rollenbasierter Zugriff auf PODs; Fahrerfotos mit Gesichtern nicht an APIs in Drittländern senden.
• Zollrecht: Die anmeldende Person haftet nach dem Zollkodex der Union für die Richtigkeit der Anmeldung; die KI-Ausgabe ist ein Entwurf. Den Prüfpfad Quelldokument → extrahierter Wert → übermittelter Wert aufbewahren.
• Steuer/Buchführung: Die deutschen GoBD gelten für Lieferscheine und Rechnungen als Buchungsbelege (nachvollziehbare Verarbeitung, unveränderbare Archivierung).
• Rechtlicher Wert von Dokumenten: Ein gescanntes B/L ist kein begebbares Original; elektronische übertragbare Aufzeichnungen brauchen ein rechtlich anerkanntes System (MLETR-basierte Gesetze) [5].
• Gegenmaßnahmen: Schemavalidierung, deterministische Prüfungen, Konfidenzschwellen, Vier-Augen-Prinzip bei zollrelevanten Feldern, regelmäßige Stichproben automatisch freigegebener Dokumente.

Erste Schritte

1. Dokumenttypen, Sprachen, Kanäle und Volumen erfassen; 100 echte Dokumente je Typ sammeln, einschließlich schlechter Scans und handschriftlicher Notizen.
2. Prüfen, ob Ihr TMS/ERP/Ihre Zollsoftware bereits eine Erfassung anbietet (Weg A) und welche EU-Datenstandort-Bedingungen gelten.
3. 2–3 Kandidaten (ein Herstellerwerkzeug, eine Cloud-API, ein offenes VLM wie Qwen3-VL über Docling) an den eigenen Beispielen testen und die Genauigkeit auf Feldebene messen.
4. Schema, deterministische Validierungen und Konfidenzschwellen festlegen; einen Prüfbildschirm mit Quellenhervorhebung bauen.
5. Mit einem Ablauf beginnen (z. B. POD bis Rechnungsfreigabe), die Quote ohne Eingriff messen und dann B/L und Zolldokumente ergänzen.

Quellen

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