Das Problem der deutschen Importdatenerfassung
Warum ATLAS die Lücke schafft, die es schließen sollte
Die Abgabe einer Zollanmeldung über das deutsche ATLAS (Automatisiertes Tarif- und Lokales Zollabwicklungssystem) dauert einen Zollspediteur etwa drei Minuten pro Anmeldung – die Daten werden elektronisch übermittelt, ATLAS prüft sie, das System gibt eine Annahmemeldung mit einer 18-stelligen MRN zurück, und die Ware wird abgefertigt. Was der Importeur im Anschluss erhält, ist ein PDF derselben Zollanmeldung – ein flaches, für die Archivierung formatiertes Dokument. Die 11-stellige Zolltarifnummer, der angemeldete Zollwert, das Ursprungsland, die EORI-Nummer des Anmelders, die Eigenmasse und der Zollverfahrenscode (4-stellig) sind alle korrekt auf der Seite vorhanden. Sie sind dort aber auch eingeschlossen. Um jedes Feld wieder in ein sortierbares Format zu bekommen – eine Tabelle für die monatliche Berichterstattung, einen ERP-Bildschirm für den Rechnungsabgleich, ein Compliance-Dashboard für die Zollplanung – muss man das PDF öffnen und jeden Wert neu eingeben. Für einen mittelständischen deutschen Importeur, der 40 Sendungen pro Monat abwickelt, kostet dieser erneute Abtippvorgang etwa 3 Stunden pro Monat. Und er existiert, weil das System, das Zollanmeldungen digitalisiert hat, dazu entwickelt wurde, sie zu prüfen, nicht um sie als strukturierte Daten an den Importeur zurückzugeben, der für sie bezahlt.
Die wichtigsten Erkenntnisse
- Ihr Spediteur gibt die Zollanmeldung in 3 Minuten über ATLAS ab – die Übertragung derselben 11-stelligen Zolltarifnummern, Zollwerte und EORI-Nummern aus dem resultierenden PDF in Ihre Tabelle kostet weitere 3 Stunden pro Monat, und diese Abtipplücke ist in keinem Vertrag oder Budgetposten enthalten.
- Die sichtbaren Kosten betragen etwa 100 € monatlicher Personalzeit – die unsichtbaren Kosten sind der Tarifnummern-Übertragungsfehler, der Waren in die falsche Zollposition verschiebt, die Abgleichsverzögerung, die Zolldifferenzen drei Wochen lang unentdeckt lässt, und die Analysefragen, die niemand stellt, weil die Daten über 40 isolierte PDFs verstreut sind.
- Schließen Sie die Lücke an ihrer Quelle: Definieren Sie Ihre Extraktionsspalten einmalig mit deutscher Zollterminologie, führen Sie jedes Zollanmeldungs-PDF von jedem Spediteur und jedem Meldekanal in dieselbe Tabelle ein, und machen Sie aus der Person, die 400 Felder pro Monat abtippt, die Person, die sie prüft.
Die sichtbaren drei Minuten – und die unsichtbaren drei Stunden
Jeder, der an einer deutschen Importtransaktion beteiligt ist, kann die Gebühr des Zollvertreters (auch Zollspediteur genannt, wenn er mit Spedition kombiniert wird) sehen. Der Zollvertreter reicht die elektronische Zollanmeldung über ATLAS ein, die automatisierte Zoll-IT-Plattform, die vom ITZBund gemäß dem Unionszollkodex (Verordnung EU Nr. 952/2013, UZK) betrieben wird. ATLAS validiert die Zolltarifnummer anhand der EZT-online-Datenbank, überprüft die EORI-Nummer im EU-Register, berechnet den Zoll und die Einfuhrumsatzsteuer (19 % Regelsteuersatz / 7 % ermäßigter Steuersatz) und stellt – bei Annahme – einen Steuerbescheid sowie eine 18-stellige MRN (Master Reference Number) aus. Die Rechnung des Zollvertreters trifft ein: eine Position für die Zollabfertigung, eine Position für die ATLAS-Anmeldung. Der Importeur bezahlt sie. Die Transaktion scheint abgeschlossen.
Was die Rechnung des Zollvertreters nicht abdeckt – und was in keiner Position einer Logistikrechnung erfasst wird –, ist das, was nach der ATLAS-Annahme passiert. Der Importeur erhält die Zollanmeldung als PDF. In dieser PDF befinden sich die Felder, die der Importeur für seinen eigenen Betrieb benötigt: die 11-stellige Zolltarifnummer für den monatlichen Importmengenbericht nach Tarifposition, der Zollwert in Euro für den Abgleich der Lieferantenrechnung (Vergleich des deklarierten CIF-Zollwerts mit der FOB-Handelsrechnung des Lieferanten), das Ursprungsland für das vierteljährliche Ursprungsdokumentationsaudit, der Zollverfahrenscode (4-stellig) für den Working-Capital-Cashflow-Forecast zur Unterscheidung zwischen verzolltem freien Verkehr und ausgesetzter Abgabe im Zolllagerverfahren. Jedes dieser Felder wurde als strukturierte Daten in ATLAS eingegeben. Jedes einzelne davon wird dem Importeur als flaches PDF zurückgegeben. Der Schritt, sie aus der PDF wieder in eine Tabelle zu extrahieren, ist keine Zoll-Compliance-Tätigkeit. Es ist eine Formatübersetzung – und sie steht in keiner Stellenbeschreibung, in keinem Budget und auf keiner Rechnung.
ATLAS wurde entwickelt, um papierbasierte Zollanmeldungen zu ersetzen. Das ist gelungen. Wofür es nicht entwickelt wurde – und was der Importeur am Monatsende feststellt –, ist, Daten an den Importeur in einem Format zurückzugeben, das seine internen Systeme lesen können. Die Papieranmeldung wurde durch eine PDF-Anmeldung ersetzt. Der Schritt des erneuten Abtippens ist nicht verschwunden; er hat sich vom Schreibtisch des Zollvertreters auf den Bildschirm des Importeurs verlagert.
Anatomie der Datenlücke: Wie strukturierte Eingabe zu unstrukturierter Ausgabe wird
Um zu verstehen, warum diese Lücke existiert, müssen Sie die Daten auf ihrem gesamten Weg verfolgen. Dies ist keine Geschichte über versagende Technologie. Es ist eine Geschichte über zwei Systeme – ATLAS und das ERP des Importeurs –, die nie dafür ausgelegt waren, miteinander verbunden zu werden, und bei der ein Mensch die Lücke mit einer Tastatur überbrückt.
Der Zollspediteur (oder der Importeur, sofern er direkt über die ATLAS-Internet-Anmeldung IZA oder über Software wie DAKOSY, AEB Import Filing oder MIC-CUST anmeldet) gibt die Sendungsdaten in ein ATLAS-kompatibles Formular ein: die 11-stellige Zolltarifnummer pro Warenposition, den Zollwert in Euro, das Ursprungsland als ISO-2-Länderkürzel, die EORI-Nummer des Anmelders und des Empfängers, den 4-stelligen Zollverfahrenscode, die Eigenmasse und Rohmasse in Kilogramm, die Anzahl der Packstücke und – bei Präferenzansprüchen – das Präferenzursprungsland und den Präferenzcode. Diese Daten werden als EDIFACT- oder XML-Nachricht an ATLAS übermittelt. Sie werden validiert, mit dem elektronischen Zolltarif (EZT-online) abgeglichen und innerhalb von Minuten entweder angenommen oder abgelehnt. Die Daten gelangen als strukturierte Daten in ATLAS. ATLAS verarbeitet sie als strukturierte Daten. Es sendet eine Annahmebestätigung als strukturierte Daten zurück – eine MRN, einen Steuerbescheid mit dem berechneten Zollbetrag und einen Statuscode.
Das Zollanmeldungs-PDF, das der Spediteur an den Importeur sendet, ist der rechtliche Nachweis der Anmeldung. Gemäß Artikel 51 UZK muss der Anmelder Kopien der Zollanmeldungen und der dazugehörigen Unterlagen mindestens drei Jahre lang für mögliche Zollprüfungen aufbewahren. Das PDF dient als dieser rechtliche Nachweis. Es ist für das menschliche Lesen formatiert, nicht für die maschinelle Verarbeitung. Die Felder, die als einzelne Datenpunkte eingegeben wurden – die 11-stellige Zolltarifnummer, der Zollwert, das Ursprungsland – werden als Text auf einer Seite dargestellt, ohne Metadaten, die sie als extrahierbare Felder kennzeichnen. Die strukturierten Daten, die in ATLAS eingegeben wurden, sind zu einem Textbild auf einem PDF geworden.
Für den Importeur ist die Zollanmeldung kein Archivdokument. Sie ist ein Eingabedokument für mindestens vier interne Prozesse: den monatlichen Importvolumenbericht sortiert nach Tarifposition, den Abgleich der Lieferantenrechnungen (Vergleich des angemeldeten Zollwerts mit dem FOB-Wert der Handelsrechnung zuzüglich Fracht und Versicherung), das vierteljährliche Cashflow-Modell für die Zollprognose und das jährliche Audit der Ursprungsdokumentation, das nach den EU-Freihandelsabkommen erforderlich ist. Ein ERP-System – ob SAP, DATEV, Lexware oder eine benutzerdefinierte Excel-basierte Importtabelle – benötigt strukturierte Daten, um eine dieser Funktionen ausführen zu können. Der Importeur hat ein PDF. Das ERP benötigt Zeilen und Spalten. Die Lücke dazwischen wird von einer Person geschlossen, die jedes Feld von einem Bildschirm auf den anderen überträgt. Bei 40 Anmeldungen pro Monat mit je 10 Feldern sind das 400 manuelle Übertragungen – etwa drei Stunden Arbeit, die in keinem Prozessablauf, keiner Kostenschätzung und keinem Spediteursvertrag auftauchen.
Diese Lücke ist strukturell identisch mit der, die in der Analyse beschrieben wurde, warum die BAS-Abgabe australische Kleinunternehmen mehr kostet, als das Formular vermuten lässt – das Formular akzeptiert strukturierte Zahlen, aber die Dokumente, die diese Zahlen enthalten, kommen als PDFs an, und der manuelle Schritt der Datenextraktion aus Dokumenten in das Formular ist der Engpass, den niemand budgetiert. Die Zollanmeldung und die Steuererklärung sind dasselbe Problem in verschiedenen behördlichen Formularen: Der Schritt der Datenerfassung übertrifft den Schritt der Einreichung bei weitem, und die meisten Tools, die darauf abzielen, es „einfacher zu machen“, adressieren die Einreichungsseite, während die Erfassungsseite manuell bleibt.
Was die Abtipplücke tatsächlich kostet – jenseits der drei Stunden
Die sichtbaren Kosten der manuellen Dateneingabe sind leicht zu berechnen: 40 Anmeldungen pro Monat zu je 4–5 Minuten ergeben etwa 3 Stunden Arbeitszeit. Bei einem mittleren Gehalt eines Importkoordinators in einem deutschen Logistikzentrum wie Hamburg oder Bremerhaven entspricht dies etwa 75–100 € pro Monat an direkten Arbeitskosten. Hochgerechnet auf 12 Monate sind das rund 900–1.200 € pro Jahr an Personalkosten für die Formatübersetzung. Dies ist die Zahl, die die meisten Importeure sehen, wenn sie überhaupt eine Zahl sehen. Sie ist jedoch der kleinste Teil der tatsächlichen Kosten.
Die Übertragungskosten. Eine 11-stellige Zolltarifnummer – sagen wir 6204.62.31.00.9 für Damen-Baumwollhosen – sind 11 Tastenanschläge. Eine Übertragungsfehlerrate von etwa 1 pro 500 Tastenanschlägen bedeutet, dass bei 400 Feldern (40 Anmeldungen × 10 Felder, wobei etwa die Hälfte numerische Codes sind) ein Feld pro Monat falsch eingegeben wird. Eine falsche Ziffer in der Zolltarifnummer – eine „3“ anstelle einer „2“ – kann die Ware in eine völlig andere Tarifposition mit einem anderen Zollsatz verschieben. Wenn ATLAS den korrekten Code zum Zeitpunkt der Abfertigung validiert hat, existiert der Fehler nur in der internen Tabelle des Importeurs. Aber zwei Dinge machen ihn gefährlich: Er fließt in den monatlichen Importmengenbericht ein, der wiederum in die vierteljährliche Zollprognose und diese in die Liquiditätsplanung einfließt; und er kann während einer Zollprüfung mit den Daten des Zollspediteurs abgeglichen werden, wo eine Diskrepanz zwischen den Aufzeichnungen des Importeurs und den beim Zoll eingereichten Daten Fragen zu den internen Kontrollen des Importeurs aufwirft – selbst wenn der Fehler rein buchhalterischer Natur ist.
Die Kosten für Verzögerungen beim Abgleich. Der Zweck der Extraktion von Zollanmeldungsdaten in eine Tabelle ist nicht die Tabelle an sich. Es geht um den Abgleich mit der Handelsrechnung des Lieferanten. Die Handelsrechnung des Lieferanten weist einen FOB-Wert Shenzhen von 12.000 € aus. Die Zollanmeldung deklariert einen Zollwert von 13.200 € – den CIF-Wert Hamburg inklusive Fracht und Versicherung. Die Differenz von 1.200 € ist korrekt. Wenn der Importkoordinator den Zollwert jedoch erst am Monatsende extrahiert – weil sich der Dateneingabe-Rückstand über drei Wochen aufgestaut hat – erfolgt der Abgleich, der die 1.200 €-Differenz bestätigt, drei Wochen nachdem die Ware abgefertigt wurde. Wenn der Zollwert falsch eingegeben worden wäre – sagen wir, die Fracht wurde doppelt gezählt und der Wert mit 13.800 € statt 13.200 € deklariert – bliebe diese Diskrepanz drei Wochen lang unentdeckt, in denen der Zoll einen Nacherhebungsbescheid mit Zinsen ausstellen könnte.
Die Kosten der übergreifenden Zollanmeldungsanalyse, die nie anfallen. Wenn Zollanmeldungsdaten in 40 separaten PDFs vorliegen, stellt niemand analytische Fragen dazu. „Wie hoch war der durchschnittliche Zollwert pro Kilogramm unserer Textilimporte im letzten Quartal?“ erfordert das Extrahieren des Zollwerts und der Eigenmasse aus 120 PDFs (3 Monate × 40 Anmeldungen) und deren Division. Niemand tut dies, weil die Extraktion selbst die Zeit verbraucht, die für die Analyse benötigt würde. Die Kosten sind hier keine Position in der Rechnung – es sind verlorene Erkenntnisse. Der Importeur zahlt jeden Monat Zoll und kennt den Gesamtbetrag aus dem Aufschubkonto-Auszug. Was der Importeur nicht weiß – weil die Daten über PDFs verstreut sind – ist, welche Zolltarifnummern, welche Ursprungsländer und welche Zollverfahren diesen Gesamtbetrag verursachen. Dies ist dieselbe Erkenntnis, die eine Batch-Verarbeitung freisetzt, wie in der Analyse zur Erstellung einer Zolltarifübersicht aus 50 gebündelten Zollanmeldungen beschrieben – aber nur, wenn die Daten zuerst in eine Tabellenkalkulation gelangen.
Warum ATLAS-Anmeldesoftware die Lücke nicht schließt
Eine naheliegende Frage an dieser Stelle: Wenn der Importeur ATLAS-kompatible Anmeldesoftware wie DAKOSY, AEB Import Filing, MIC-CUST oder Declarium verwendet, erfasst diese Software dann nicht bereits die Anmeldedaten? Das tut sie – für die Anmeldungen, die über genau diese Software eingereicht werden. Die Einschränkung liegt im Umfang, nicht in der Fähigkeit.
Ein deutscher Importeur, der DAKOSY für Seefrachtimporte aus Asien nutzt, kann Luftfrachtanmeldungen direkt über ATLAS Internet-Zollanmeldung (IZA) abgeben und bestimmte Sendungen über einen Spediteur, der seine eigene LIS- oder MIC-CUST-Installation verwendet. Jeder Anmeldekanal erzeugt seinen eigenen Satz von Anmeldedatensätzen. Der DAKOSY-Bericht deckt die Seefrachtanmeldungen ab. Die IZA-Anmeldungen erzeugen PDFs. Die Anmeldungen des Spediteurs treffen als PDFs aus dessen System ein. Der Importeur, der eine konsolidierte Monatsendübersicht aller Anmeldungen benötigt, hat drei Datenquellen – zwei davon PDF, eine ein Softwarebericht – die nie für eine Zusammenführung konzipiert wurden.
Selbst wenn ein einziger ATLAS-Softwareanbieter alle Anmeldungen erfasst, sind die erfassten Daten für ATLAS-Konformitätsfelder optimiert, nicht für die internen Berichtsanforderungen des Importeurs. Die Software speichert die Zolltarifnummer (11-stellig) als Zeichenkette, den Zollwert als Euro-Betrag und den Zollverfahrenscode (4-stellig) als Zahl – genau die Felder, die ATLAS benötigt. Was sie in der Regel nicht erzeugt, ist ein konsolidierter Export, der der Berichtsstruktur des Importeurs entspricht: eine Zeile pro Anmeldung mit den Feldern, die das Finanzteam des Importeurs benötigt, zusammen mit abgeleiteten Feldern wie „HS-Kapitel (abgeleitet aus der 11-stelligen Zolltarifnummer)“ oder „Zollbelastung (Zollwert × MFN-Satz) versus Präferenzsatz, falls gültiges Ursprungszeugnis vorliegt.“ Die Software exportiert, was ATLAS benötigt. Der Importeur benötigt, was der Importbericht benötigt. Die Lücke zwischen den beiden Exporten ist eine weitere Runde manueller Feldauswahl, Formatierung und ergänzender Dateneingabe.
Eine weitere Komplikation, die spezifisch für das deutsche Zollumfeld ist, ist die Rolle des indirekten Vertreters. Wenn ein Zollspediteur eine Zollanmeldung als indirekter Vertreter einreicht, handelt er im eigenen Namen für den Importeur und übernimmt die gesamtschuldnerische Haftung für die Zollschuld gemäß Artikel 84 UZK. Die ATLAS-Anmeldedaten des Spediteurs gehören zum System des Spediteurs. Der Zugang des Importeurs zu diesen Daten – sei es als strukturierter Export oder sogar als PDF – hängt von der Bereitschaft und technischen Fähigkeit des Spediteurs ab, sie in einem nutzbaren Format bereitzustellen. Viele Spediteure senden einen PDF-Scan der Anmeldung als Standardlieferung. Die strukturierten Daten, die in ATLAS eingegeben wurden, verbleiben in der ATLAS-Software des Spediteurs. Der Importeur erhält das gleiche flache PDF, das er auch erhalten hätte, wenn die Anmeldung in Papierform eingereicht worden wäre – und der manuelle Neueingabeschritt ist nicht nur unverändert, sondern jetzt auch von den Datenformatpräferenzen eines Dritten abhängig.
Die Lösung: Datenerfassung vor der Tastatur
Das Problem ist nicht, dass ATLAS defekt ist. ATLAS tut genau das, wofür es entwickelt wurde – Zollanmeldungen elektronisch validieren und die Abfertigung beschleunigen. Das Problem ist, dass die Datenpipeline des Importeurs an einem PDF endet und jeder nachgelagerte Prozess, der von den Daten in diesem PDF abhängt, mit einem manuellen Übertragungsschritt beginnen muss, für den niemand zuständig ist.
Die strukturelle Lösung ist keine bessere ATLAS-Integration. Es geht darum, den Übertragungsschritt vollständig zu eliminieren – die Daten aus dem PDF an dem Punkt zu erfassen, an dem sie in den Workflow des Importeurs gelangen, bevor jemand eine Tabelle öffnet, um sie neu einzutippen. Die benutzerdefinierte Spaltenextraktion macht dies möglich: Definieren Sie die Feldnamen einmalig mit der exakten deutschen Zollterminologie, die Ihr Team verwendet („Zolltarifnummer (11-stellig)“, „Ursprungsland“, „Zollwert in EUR“, „Zollverfahrenscode (4-stellig)“, „EORI-Nummer“), laden Sie jedes Zollanmeldungs-PDF von jedem Makler, Spediteur und IZA-Einreichungskanal hoch und erhalten Sie eine einzige Tabelle mit einer Zeile pro Anmeldung, den Spalten als Kopfzeilen und den Feldern, die aus den PDFs befüllt werden. Die 3 Stunden manueller Übertragung werden zu einem 10-minütigen Upload- und Prüfschritt. Die Ausgabetabelle speist direkt den monatlichen Importbericht, den Abgleich der Lieferantenrechnungen und die vierteljährliche Zollprognose – nicht über einen Engpass des Neuabtippens.
Dies ist genau der Extraktionsansatz, der in der Schritt-für-Schritt-Anleitung zum Extrahieren deutscher Zollanmeldungsdaten nach Excel detailliert beschrieben wird – dieselbe Spaltendefinition, die auf jede Anmeldung angewendet wird, dieselbe Ausgabestruktur jeden Monat, dieselbe Tabelle, die jeden nachgelagerten Prozess speist. Der Unterschied zwischen einer manuellen Datenpipeline und einer extraktionsbasierten ist keine Frage der Geschwindigkeit. Es ist eine Frage der Formatübersetzung. In der manuellen Pipeline erledigt eine Person diese Arbeit, Monat für Monat, auf Kosten ihrer Zeit und dem Risiko ihrer Übertragungsfehler. In einer extraktionsbasierten Pipeline springen die Daten direkt aus dem PDF in eine strukturierte Tabelle, und die Person prüft, anstatt zu übertragen.
FAQ — Das Problem der erneuten Dateneingabe bei ATLAS-Zollanmeldungen
Warum stellen deutsche Zollspediteure die Anmeldedaten nicht als Excel-Datei statt als PDF zur Verfügung?
Einige tun dies – insbesondere größere Zollspediteure, die Importeure mit hohem Volumen betreuen. Es ist jedoch kein Standarddienst, und das Format variiert. Ein Spediteur exportiert eine XML-Datei mit ATLAS-Feldcodes; ein anderer exportiert eine CSV mit abgekürzten deutschen Spaltenüberschriften; ein dritter sendet einen unformatierten Textdump. Wenn ein Importeur mit drei verschiedenen Spediteuren zusammenarbeitet und einige Anmeldungen auch direkt über IZA einreicht, liefern selbst die Spediteure, die Excel-Exporte anbieten, diese in inkompatiblen Formaten. Der Importeur steht dann vor einer Daten-Normalisierungsaufgabe – der Zuordnung von drei verschiedenen Spediteurausgaben zu einer einheitlichen Berichtsstruktur. Der Extraktionsansatz umgeht dies, indem er direkt mit dem PDF arbeitet, das jeder Spediteur unabhängig von seiner Softwarekonfiguration in einem lesbaren Format bereitstellt.
Kann ATLAS selbst Anmeldedaten an den Importeur exportieren?
Nein. ATLAS ist eine Plattform zur Verarbeitung von Anmeldungen, kein Datenportal für Importeure. Es nimmt Anmeldungen an, validiert sie, berechnet Abgaben und erstellt Steuerbescheide. Der Zugriff des Importeurs auf ATLAS erfolgt ausschließlich über die Anmeldesoftware oder den Spediteur, der die Anmeldung einreicht. Die Zollverwaltung stellt die Datenbank EZT-online für die Zolltarifrecherche und das Zoll-Portal für EORI-Anträge und bestimmte Verwaltungsprozesse zur Verfügung, aber es gibt keine Funktion „Meine Anmeldedaten herunterladen“ in ATLAS für Importeure. Die Anmeldedaten, die in ATLAS eingehen, verlassen ATLAS nur als PDF-Datensatz, der vom Spediteur aufbewahrt und mit dem Importeur geteilt wird – ein Dokumentenformat, kein Datenformat.
Wie unterscheidet sich das Problem der erneuten Dateneingabe für Importeure, die Zolllager nutzen?
Es verschärft sich. Für Waren, die in ein Zolllagerverfahren (Zollverfahrenscode 7100) überführt werden, ist die Abgabe bis zum Verlassen des Lagers in den zollrechtlich freien Verkehr ausgesetzt. Eine einzelne Sendung kann mehrere Entnahmen umfassen – Teilentnahmen über Wochen oder Monate –, die jeweils eine separate Zollanmeldung mit einem Verfahrenswechsel von 7100 auf 4000 auslösen. Der Importeur muss nicht nur die ursprüngliche Eingangsanmeldung verfolgen, sondern jede nachfolgende Entnahmeanmeldung und diese mit den Lagerbestandsaufzeichnungen und der endgültigen Zahlung der Abgaben abgleichen. Wenn jede Entnahmeanmeldung als separates PDF eingeht, vervielfacht sich der Dateneingabeaufwand mit jeder Teilentnahme. Eine einzige Zolllagersendung, die in fünf Chargen entnommen wird, erzeugt sechs neu einzutippende Anmeldungen – die Eingangsanmeldung plus fünf Entnahmen – für einen operativ einheitlichen Vorgang.
Gilt das Problem auch für Ausfuhranmeldungen?
Ja, obwohl die Konsequenzen unterschiedlich sind. Deutsche Ausfuhranmeldungen, die über ATLAS-AES (Automatisiertes Ausfuhrsystem) eingereicht werden, enthalten einen anderen Satz von Schlüsselfeldern – die 8-stellige Warennummer (im Gegensatz zur 11-stelligen Codenummer bei der Einfuhr), das Ausfuhrland, den statistischen Wert und die Ausfuhrzollstelle. Der Exporteur benötigt diese Daten für die Intrastat-Meldung (EU-weite Handelsstatistiken für Warenbewegungen zwischen Mitgliedstaaten), für die Nachverfolgung der Ausfuhrbestätigung und für den Nachweis der Umsatzsteuerbefreiung in der Umsatzsteuervoranmeldung (UVA). Das Muster der Dateneingabe ist dasselbe: Strukturierte Daten gelangen in ATLAS-AES, ein PDF landet im Posteingang des Exporteurs, und der Exporteur tippt die Felder erneut in das interne Berichtssystem ein. Der Extraktionsansatz lässt sich direkt übertragen – definieren Sie die ausfuhrrelevanten Felder einmal, laden Sie die Ausfuhr-PDFs hoch und erhalten Sie die strukturierte Ausgabe.
Der Zollspediteur gibt die Zollanmeldung in drei Minuten über ATLAS ab. Die Rückgewinnung der Daten aus dem PDF in Ihr Berichtssystem dauert drei Stunden. Die Lücke ist kein Zollproblem – sie ist ein Datenpipeline-Problem. Schließen Sie sie an der Quelle.
Extrahieren Sie Ihre Zollanmeldungen