5 Fehler bei der deutschen Handelsrechnung für Exportdaten
Die Zollverzögerungen und Zollprüfungen auslösen

Wo diese Fehler tatsächlich auftreten — nicht in der Zollanmeldung, sondern in der Handelsrechnung

Eine deutsche Exportlieferung beginnt nicht mit der ATLAS-Ausfuhranmeldung. Sie beginnt mit der Handelsrechnung — einem Dokument, das zwei Arten von Feldern enthält, die die inländische Rechnung nie kennt: die zollrelevanten Felder, die die Exportabteilung in ihre Vorlage eintippt, und die buchhalterischen Felder, die die Finanzabteilung für die UVA benötigt. Jeder der fünf unten genannten Fehler entsteht in dieser Lücke zwischen „in die Rechnung eingetippt" und „vom System gelesen, das sie benötigt".

Der übliche Rat zur Vermeidung von Zolldatenfehlern ist verfahrenstechnisch: HS-Codes gegen EZT-online doppelt prüfen, EORI-Registrierung bei der Generalzolldirektion verifizieren, Incoterms mit dem Exportvertrag abgleichen, bei jeder Rechnung das Vier-Augen-Prinzip anwenden. Dieser Rat ist richtig — und er setzt eine Umgebung voraus, in der jede Handelsrechnung von zwei Personen geprüft wird, bevor sie den Zollspediteur erreicht. Bei einem mittelständischen deutschen Exporteur mit 30 Sendungen pro Monat und zwei Personen in der Exportabteilung ist die Prüfung ein Blick auf die Summen und eine Kontrolle, ob die Kundenadresse stimmt. Die zollrelevanten Felder — die 11-stelligen Zolltarifnummern, das Ursprungsland pro Position, die EORI, die Gewichte — werden aus den Stammdaten oder der letzten Rechnung übernommen und als korrekt vorausgesetzt. Genau in dieser Annahme entstehen die Fehler.

Bevor die einzelnen Fehler untersucht werden, ist es sinnvoll, den strukturellen Kontext zu verstehen, der die Handelsrechnung besonders fehleranfällig macht. Eine inländische Rechnung nach §14 UStG enthält Angaben zu Lieferant und Empfänger, die Steuernummer oder USt-IdNr, Rechnungsnummer und -datum, Menge und Bezeichnung der Waren oder Dienstleistungen, den Nettobetrag, den Umsatzsteuersatz und -betrag sowie die Bruttosumme — etwa zehn Felder, die alle in dasselbe Buchhaltungssystem fließen. Eine Handelsrechnung enthält all diese Felder plus die zollspezifischen Felder gemäß Union Customs Code (UCC, Verordnung (EU) Nr. 952/2013) und der Außenwirtschaftsverordnung (AWV). Das Dokument unterliegt gleichzeitig zwei Regelwerken — dem Umsatzsteuerrecht und dem Zollrecht — und die Felder aus beiden Regelwerken gehen an unterschiedliche nachgelagerte Systeme, die nicht miteinander kommunizieren. Dies ist das Problem der doppelten Pipeline, das die Analyse der doppelten Rechnungspipeline eingehend untersucht. Die unten genannten Fehler sind das, was in dieser Lücke passiert.

Fehler 1: Falsche Zolltarifnummer je Position — ATLAS-Ablehnung, bevor die Ware das Werk verlässt

Die 11-stellige Zolltarifnummer auf einer deutschen Handelsrechnung ist nicht eine Nummer pro Rechnung. Es ist eine Nummer pro Position — und eine einzelne Exportsendung kann Produkte unter drei, fünf oder zehn verschiedenen Zolltarifpositionen enthalten. Eine Lieferung von Industriepumpen mit Ersatzteilen, Montagehalterungen und Steuerpaneelen kann sich über die HS-Kapitel 84 (Maschinen), 73 (Eisen-/Stahlwaren) und 85 (elektrische Ausrüstung) erstrecken — jede Position benötigt ihren eigenen 11-stelligen Code, jeder Code bestimmt eine andere exportkontrollrechtliche Einstufung und, für den Importeur, einen anderen Zollsatz am Bestimmungsort.

Die 11-stellige deutsche Zolltarifnummer ist schichtweise aufgebaut: Die ersten sechs Stellen sind der internationale HS-Code (weltweit harmonisiert unter der Weltzollorganisation), die Stellen sieben und acht bilden die Erweiterung der EU-Kombinierten Nomenklatur (KN), die Stellen neun und zehn ergänzen TARIC-Maßnahmen (Antidumpingzölle, Zollaussetzungen, mengenmäßige Beschränkungen), und die elfte Stelle ist der deutsche nationale Code für die Umsatzsteuer-Kodierung und spezifische Importkontrollen. Ein 6-stelliger HS-Code, der korrekt ist, kann auf der 10. oder 11. Stelle dennoch falsch sein — und ATLAS prüft den vollständigen 11-stelligen Code, bevor die Ausfuhranmeldung angenommen wird.

Wie dieser Fehler in der Praxis entsteht. Die Exportabteilung erstellt eine Handelsrechnung für eine Sendung mit fünf verschiedenen Produkten. Die Produktstammdaten im ERP — SAP, Microsoft Dynamics oder DATEV — speichern den Zolltarifcode jedes Produkts. Aber der Produktstamm wurde zuletzt vor 18 Monaten aktualisiert, und die EU-Kombinierte Nomenklatur wurde im Januar geändert. Der KN-Code eines Produkts hat sich auf der Acht-Stellen-Ebene geändert. Ein anderes Produkt — ein Ersatzteil — wurde von der Konstruktion bei der letzten Prüfung unter dem Fertigwarencode eingestuft, weil „es Teil der Maschine ist". Keiner dieser Fehler ist auf der Handelsrechnung sichtbar. Die Rechnung trägt die Zolltarifnummer exakt so, wie sie im ERP erscheint. Der Fehler tritt zutage, wenn ATLAS die Ausfuhranmeldung verarbeitet und eine Diskrepanz zwischen dem angemeldeten Warencode und der Produktbeschreibung feststellt — oder wenn die Zollbehörde des Bestimmungslandes die Einstufung hinterfragt und der Exporteur sie nicht belegen kann.

Was nachgelagert passiert. ATLAS prüft die Tarifeinstufung gegen die angemeldete Warenbeschreibung und alle anwendbaren Handelsmaßnahmen (Antidumping, Dual-Use-Kontrollen), die auf TARIC-Ebene kodiert sind. Wenn die Einstufung inkonsistent ist, lehnt ATLAS die Anmeldung ab (Zurückweisung). Die Ablehnungskaskade ist nicht administrativ — sie ist operativ:

Über die unmittelbare Zurückweisung hinaus schafft eine fehlerhafte Klassifizierung Prüfungsrisiken. Die Generalzolldirektion führt nachträgliche Compliance-Prüfungen durch, und ein Muster wiederholter Klassifizierungskorrekturen über mehrere Sendungen hinweg deutet auf schwache interne Kontrollen hin – was tiefere künftige Prüfungen nach sich zieht. Im schlimmsten Fall wird der Fehler nicht von ATLAS entdeckt, sondern Monate später von der Zollbehörde des Bestimmungslandes, wenn dem Importeur Einfuhrabgaben samt Zinsen nachbelastet werden und der Exporteur aufgefordert wird, eine Klassifizierung zu belegen, die er nicht belegen kann.

Warum dies im Rechnungsstadium schwer zu verhindern ist. Die Exportabteilung, die die Handelsrechnung erstellt, vertraut dem ERP-Artikelstamm. Die Überprüfung der 11-stelligen Codes gegen EZT-online für jede Position jeder Rechnung – bei 30 Sendungen pro Monat mit durchschnittlich vier Positionen – ergibt 120 Klassifizierungsprüfungen pro Monat. Ein Zollspediteur kann Fehlklassifizierungen bei der ATLAS-Anmeldung erkennen, aber zu diesem Zeitpunkt ist die Rechnung bereits ausgestellt, der Kunde hat sie erhalten, und eine Korrektur bedeutet die Neuausstellung einer korrigierten Handelsrechnung und möglicherweise die Anpassung der Handelsbedingungen. Die strukturelle Lösung ist keine sorgfältigere Exportabteilung – es geht darum, die Klassifizierung zu erfassen, bevor die Rechnung finalisiert wird, also den extrahierten Zolltarifcode am Punkt der Datenerfassung mit einem bekannten Artikelstamm zu vergleichen. Die Analyse von HS-Code-Fehlern in Zollanmeldungen behandelt die Speditionsperspektive auf Klassifizierungsfehler; der Handelsrechnungsfehler ist die vorgelagerte Ursache, die diese speist.

Fehler 2: Inkonsistenz bei Incoterms – EXW auf der Rechnung, aber Fracht im Warenwert enthalten

Die Incoterms-2020-Klausel auf einer Handelsrechnung legt fest, wer Transportkosten, Versicherung und Zollrisiko auf jeder Transportstrecke trägt. Eine EXW-Rechnung (Ex Works) bedeutet, dass der Käufer die Ware am Standort des Verkäufers abholt und ab diesem Zeitpunkt alle Kosten und Risiken trägt – der Rechnungswert sollte der Ex-Works-Preis sein, ohne Fracht, Versicherung oder Exportabfertigungsgebühren. Eine FOB-Rechnung (Free On Board) bedeutet, dass der Verkäufer die Ware im benannten Hafen an Bord des Schiffs liefert – der Rechnungswert umfasst den Binnentransport zum Hafen, nicht aber Seefracht oder Versicherung. Eine CIF-Rechnung (Cost, Insurance, Freight) umfasst die Warenkosten, die Versicherung und die Fracht bis zum benannten Bestimmungshafen – der Rechnungswert ist der gelieferte Preis am Bestimmungsort.

Wie dieser Fehler entsteht. Die Exportabteilung erstellt eine Handelsrechnung mit Incoterms EXW Stuttgart. Das Rechnungsbetragsfeld trägt die Gesamtsumme am Ende der Rechnung – aber der Exportkoordinator hat, um schnell zu arbeiten, die Frachtkosten und die Versicherungsprämie in die Warenwert-Positionen aufgenommen. Die Incoterms auf der Rechnung sagen EXW. Die Zahlen auf der Rechnung sagen CIF.

Die Handelsrechnung kann die ATLAS-Ausfuhrprüfung in Deutschland unter Umständen dennoch passieren, da die Ausfuhranmeldung in erster Linie Warencodes, Gewichte und EORI-Nummern validiert – der Zollwert für Ausfuhrzwecke ist ein statistischer Wert, und ATLAS erzwingt auf der Ausfuhrseite keine strikte Konsistenz zwischen Wert und Incoterms. Der Fehler tritt bei der Zollbehörde des Bestimmungslandes auf. Der Importeur legt der zuständigen Zollbehörde die Handelsrechnung vor. Die Behörde liest die Incoterms: EXW. Für die zollrechtliche Bewertung gemäß dem WTO-Zollwertübereinkommen ist der Transaktionswert der tatsächlich gezahlte oder zu zahlende Preis für die Waren – und bei EXW sind die Binnenfracht und Versicherung bis zum Ausfuhrhafen zum FOB-Zollwert hinzuzurechnen. Auf dieser Handelsrechnung war die Fracht jedoch bereits im Warenwert enthalten. Die Zollbehörde steht nun vor der Wahl: den angegebenen EXW-Wert wie vorgelegt zu akzeptieren (unterbewertet – die Fracht wurde nicht hinzugerechnet, da sie bereits enthalten war) oder den Wert als inkonsistent mit den Incoterms anzufechten und unterstützende Dokumente anzufordern.

Die Folge für den Exporteur ist nicht immer eine unmittelbare Strafe. Es handelt sich um eine Sendung, die zur Zollwertprüfung zurückgehalten wird, einen Importeur, der Zölle auf einen umstrittenen Wert zahlt, und einen Kunden, der hinterfragt, ob der Exporteur seine eigenen Incoterms kennt. Für einen deutschen Exporteur, der unter DDP (Delivered Duty Paid) versendet – wobei der Verkäufer alle Einfuhrabgaben am Bestimmungsort zahlt – führt der Zollwertfehler direkt zu einer falschen Zollzahlung, die der Exporteur übernehmen muss.

Warum die Rechnung die Ursache ist. Der Exportkoordinator, der die Rechnungsdaten erfasst, arbeitet mit dem Verkaufsvertrag (der die Incoterms festlegt), dem Angebot des Zollspediteurs (das die tatsächlichen Transportkosten angibt) und der Produktpreisbildung des ERP-Systems (die den Warenwert angibt). Diese drei Quellen wurden von drei verschiedenen Personen zu drei verschiedenen Zeitpunkten im Verkaufszyklus erstellt – der Vertrag vom Vertrieb, das Frachtangebot von der Logistik, die Preisbildung von der Produktverwaltung. Die Handelsrechnung ist das erste Dokument, in dem alle drei Zahlen gemeinsam erscheinen. Die Inkonsistenz entstand in dem Moment, als die Rechnung erzeugt wurde. Sie wurde nur erst sichtbar, als eine Zollbehörde sie las.

Fehler 3: Ursprungsland positionsweise falsch — ungültiger Präferenznachweis, EUR.1 verweigert

Das Ursprungsland auf einer deutschen Handelsrechnung bestimmt, ob die Waren am Bestimmungsort eine Präferenzbehandlung erhalten. Gemäß UCC Art. 60 ist der nichtpräferenzielle Ursprung das Land, in dem die Waren vollständig gewonnen wurden oder — wenn mehr als ein Land beteiligt war — in dem die letzte wesentliche Be- oder Verarbeitung stattgefunden hat. Nach den Präferenzursprungsregeln der jeweiligen Freihandelsabkommen sind die Kriterien strenger — spezifische Zolltarifwechselregeln, Wertschöpfungsschwellen oder besondere Verarbeitungsanforderungen — und der Exporteur muss sie durch eine Lieferantenerklärung oder ein EUR.1-Warenverkehrsbescheinigung belegen.

Wie dieser Fehler entsteht. Ein deutscher Exporteur stellt ein Schaltschrank-Steuerpaneel her. Das Metallgehäuse wurde aus China bezogen. Die interne Verkabelung, die SPS und die Klemmen stammen aus Deutschland und wurden in Deutschland zu einem funktionsfähigen Steuerungssystem montiert. Nach den Präferenzursprungsregeln des EU-Japan-Wirtschaftspartnerschaftsabkommens kann das Steuerpaneel als Ursprungsware Deutschlands gelten, wenn die Montage eine ausreichende Be- oder Verarbeitung darstellt — das Metallgehäuse, wenn es als separate Ersatzteilposition auf derselben Handelsrechnung geliefert wird, behält jedoch seinen chinesischen Ursprung. Die Exportabteilung, die die Rechnung erstellt, trägt für jede Position auf der Handelsrechnung „DE" als Ursprungsland ein — einschließlich des chinesischen Metallgehäuses. Der EUR.1-Antrag wird mit dieser Rechnung als Beleg eingereicht. Die Zollbehörde bei der IHK oder dem Zollamt prüft den Antrag, gleicht die Ursprungserklärungen mit den Produktbeschreibungen ab und stellt die Abweichung fest. Der EUR.1 wird verweigert.

Besonders gefährlich ist dieser Fehler für deutsche Exporteure, die Sendungen mit mehreren Ursprungsländern abwickeln. Eine einzige Sendung mit Komponenten aus Deutschland, China und Thailand erfordert drei verschiedene Ursprungserklärungen auf drei verschiedenen Positionen derselben Handelsrechnung. Alle als „DE" zu behandeln ist keine Täuschung — es ist die Exportkoordinatorin oder der Exportkoordinator, der auf der Grundlage der Produktstammdaten arbeitet, die den Ursprung des Fertigerzeugnisses speichern, nicht aber den Ursprung auf Komponentenebene für separat verkaufte Ersatzteile. Die Produktstammdaten wurden für die Lagerverwaltung erstellt, nicht für Zollursprungserklärungen, und die Lücke zwischen beiden wird zum Fehler auf der Handelsrechnung.

Nach den üblichen deutschen Lieferbedingungen — Standardklauseln in allgemeinen Einkaufsbedingungen des verarbeitenden Gewerbes — ist ein Lieferant, der eine falsche Ursprungserklärung oder einen falschen Präferenznachweis erteilt, verpflichtet, dem Käufer alle daraus entstehenden Schäden zu ersetzen. Der EUR.1, der wegen einer leichtfertigen Ursprungseintragung auf der Handelsrechnung verweigert wurde, ist nicht nur eine abgelehnte Bescheinigung. Es ist eine Lieferantenhaftung.

Fehler 4: EORI-Nummer weicht zwischen Handelsrechnung und ATLAS-Anmeldung ab

Die EORI-Nummer (Economic Operators' Registration and Identification number) ist die eindeutige Kennung des Exporteurs im EU-Zollsystem. Ihr Format ist DE + 10 bis 15 Ziffern – zum Beispiel DE123456789012345. Gemäß UCC Art. 9 muss jeder Wirtschaftsbeteiligte, der an Zollaktivitäten beteiligt ist, registriert sein und seine EORI-Nummer in allen Zollanmeldungen verwenden. Eine EORI ist bei einer Exportsendung nicht optional. Ohne sie kann die ATLAS-Ausfuhranmeldung nicht eingereicht werden.

Wie dieser Fehler entsteht. Der Fehler besteht selten darin, dass die EORI fehlt. Vielmehr stimmt die auf der Handelsrechnung angegebene EORI nicht mit der in ATLAS registrierten EORI überein. Diese Abweichung hat mehrere häufige Ursachen:

Was danach passiert. ATLAS validiert die EORI gegen die zentrale EORI-Datenbank bei der Generalzolldirektion. Eine EORI-Abweichung führt zu einem von zwei Ergebnissen. Ist die EORI auf der Anmeldung gültig, gehört aber zu einer anderen juristischen Person als der auf der Rechnung genannten, kann ATLAS die Anmeldung zur manuellen Prüfung kennzeichnen – was die Abfertigungszeit um Stunden oder Tage verlängert. Ist die EORI nicht gültig (abgelaufen oder gehört zu einer abgemeldeten Gesellschaft), lehnt ATLAS die Anmeldung vollständig ab und die Sendung kann nicht abgefertigt werden.

Die heimtückischere Folge ist eine Diskrepanz im Prüfpfad. Die Handelsrechnung — die das Finanzamt als Beleg für die Umsatzsteuerbefreiung nach §4 Nr. 1a UStG heranzieht — trägt eine EORI-Nummer. Die ATLAS-Ausfuhranmeldung trägt eine andere. Im Rahmen einer Umsatzsteuer-Sonderprüfung kann das Finanzamt den Nachweis für den steuerfreien Ausfuhrumsatz anfordern, der in Zeile 27 der UVA ausgewiesen ist. Der Prüfer vergleicht die Handelsrechnung mit der ATLAS-Anmeldung und stellt fest, dass für dieselbe Sendung zwei unterschiedliche EORI-Nummern vorliegen. Der Prüfer hat nun eine Frage — und Fragen von Prüfern kosten Zeit, selbst wenn die Antwort harmlos ist.

Fehler 5: Nettogewicht / Bruttogewicht-Diskrepanz — ATLAS-Validierungsablehnung bei der Gewichtsprüfung

Von den fünf Fehlern auf dieser Liste wirkt die Diskrepanz zwischen Nettogewicht und Bruttogewicht am harmlosesten — und erzeugt den schnellsten, härtesten Stopp. ATLAS führt automatisierte Validierungsprüfungen der Gewichtsfelder in der Ausfuhranmeldung durch, und eine Gewichtsdiskrepanz kann die Anmeldung sofort ablehnen, bevor ein Mensch beim Zollamt sie überhaupt zu Gesicht bekommt.

Wie dieser Fehler entsteht. Die Exportabteilung trägt die Gewichte in die Handelsrechnung ein. Das Nettogewicht je Position stammt aus dem Produktstamm — eine Pumpe wiegt 45 kg, ein Motor wiegt 12 kg. Das Bruttogewicht — Ware plus Verpackung — wird geschätzt: pauschal 15 % für Paletten, Kisten und Umverpackung addiert. Oder es wird vom Packzettel des Zollspediteurs übernommen. Oder es stammt aus der vorherigen Sendung einer ähnlichen Lieferung. Die Handelsrechnung könnte ausweisen:

• Nettogewicht: 520 kg (Summe aller Positions-Nettogewichte)
• Bruttogewicht: 535 kg (geschätzte 15 kg Verpackung für 520 kg Ware)

ATLAS prüft das Verhältnis. Ein Verpackungs-Waren-Verhältnis von 15 kg bei 520 kg Maschinen — rund 2,9 % — ist unplausibel. Verpackung für Industriemaschinen (Holzkisten, Paletten, Verstrebungen, Feuchtigkeitssperren) liegt bei einer 520-kg-Sendung selten unter 40–50 kg. ATLAS markiert das Gewichtsverhältnis als außerhalb des erwarteten Bereichs und lehnt die Anmeldung ab.

Warum das Gewicht über die Validierung hinaus relevant ist. Das Bruttogewicht bestimmt die Frachtkosten — der Frachtführer berechnet nach dem frachtpflichtigen Gewicht, das bei Seefracht dem höheren Wert aus Bruttogewicht oder Volumengewicht entspricht. Ein zu niedrig angegebenes Bruttogewicht auf der Handelsrechnung kann vom tatsächlichen Gewicht abweichen, das der Zollspediteur im Konnossement oder Luftfrachtbrief erfasst hat, und so eine Dokumentendiskrepanz erzeugen, die der Zoll als Bewertungsinkonsistenz beanstanden kann. Das Nettogewicht löst zudem regulatorische Schwellenwerte aus: Nach den deutschen Ausfuhrvorschriften müssen Sendungen mit einem Warenwert über €1.000 oder einem Gewicht über 1.000 kg über ATLAS angemeldet werden. Ein Gewicht nahe 1.000 kg, das zu niedrig angegeben wird, könnte eine Sendung fälschlich unter die Anmeldeschwelle fallen lassen — ein Compliance-Verstoß, den das Zollamt als nicht angemeldete Ausfuhr behandelt.

Der Gewichtsfehler ist trügerisch einfach zu beheben — man wiegt die Sendung einfach — und trügerisch häufig falsch, weil die Exportabteilung, die die Handelsrechnung erstellt, mit Produktstammgewichten (netto, je Einheit) arbeitet, nicht mit tatsächlichen Verpackungsgewichten (die das Lager beim Verpacken der Ware ermittelt, oft nachdem die Rechnung bereits ausgestellt wurde). Die strukturelle Lösung ist keine Richtlinie. Es geht darum, die tatsächlichen Packzettelgewichte vor Übermittlung der ATLAS-Anmeldung in die Datenpipeline zurückzuführen — was bedeutet, dass der Extraktionsschritt die Handelsrechnungsgewichte zum Abgleich mit dem Packzettel des Zollspediteurs erfassen muss, nicht nur transkribieren.

Wie ein einziger Extraktionsschritt diese fünf Fehler eliminiert, bevor sie die Zollanmeldung erreichen

Die fünf Fehler haben eine gemeinsame strukturelle Ursache, die nichts mit Nachlässigkeit zu tun hat. Eine Handelsrechnung enthält rund 24 Felder – 14 aus der inländischen Rechnungsstruktur plus rund 10 zollspezifische Felder – und fünf dieser Zollfelder (Zolltarifnummer, Incoterms, Ursprungsland, EORI, Gewicht) sind voneinander abhängig: Der Wert eines Feldes begrenzt den gültigen Bereich eines anderen. Ein EXW-Incoterms begrenzt, ob Frachtkosten im Warenwert erscheinen dürfen. Eine DE-Ursprungserklärung für eine Position gilt nicht automatisch für die aus China bezogene Position. Die EORI auf der Rechnung muss mit der juristischen Person übereinstimmen, die die Anmeldung einreicht. Das Verhältnis von Nettogewicht zu Bruttogewicht muss physisch plausibel sein. Diese Querabhängigkeiten können nicht von einer Person überprüft werden, die ein PDF öffnet und jedes Feld einzeln prüft, denn der Fehler liegt nicht in einem einzelnen Feld – er liegt in der Beziehung zwischen den Feldern.

Benutzerdefinierte Spaltenextraktion – das Definieren einer Reihe von Spaltennamen, die beschreiben, was aus jedem Dokument extrahiert werden soll – löst dies nicht durch die Extraktion der Daten (was der offensichtliche Teil ist), sondern durch die Strukturierung in eine Tabelle, in der die feldübergreifende Validierung zu einer Tabellenkalkulationsoperation wird statt zu einer mentalen Checkliste. Wenn die Handelsrechnungsdaten als strukturierte Zeile mit Spalten für Zolltarifnummer, Incoterms, Ursprungsland pro Position, EORI, Nettogewicht und Bruttogewicht erfasst werden, wird jeder der fünf oben genannten Fehler auf einen Blick sichtbar:

Der Wandel führt vom positionsbasierten Lesen — einer Vorlage, die erwartet, dass jedes Feld der Handelsrechnung an einer festen Position steht, und die versagt, wenn sich das Layout eines Zollspediteurs von dem des SAP-Systems unterscheidet — zum semantischen Lesen: einer KI, die den Zolltarifcode findet, weil sie das 11-stellige Zahlenmuster versteht, unabhängig davon, wo es auf der Rechnung steht, die ein Incoterms-Feld von einem Zahlungsbedingungsfeld anhand seines dreibuchstabigen Codes unterscheidet, die weiß, dass EORI-Nummern das Präfix DE tragen und dass Ursprungsländercodes zweistellige ISO-Codes sind. Da die Extraktion ohne Vorlage erfolgt, erzeugen eine Handelsrechnung aus SAP, ein Scan eines unterschriebenen Papieroriginals aus der Exportabteilung und eine Pro-forma-Rechnung des Zollspediteurs Zeilen in derselben Ausgabetabelle, die denselben Validierungsprüfungen zugeführt werden.

Der Extraktionsansatz ersetzt nicht den Zollspediteur. Der Spediteur reicht weiterhin die ATLAS-Anmeldung ein, prüft die Dual-Use-Einstufung und pflegt die Beziehung zum Zollamt. Was die Extraktion ersetzt, ist der manuelle Schritt, bei dem die Exportabteilung eine Handelsrechnung erstellt, der Spediteur deren Felder in die ATLAS-Software überträgt und die Buchhaltung eine Teilmenge in das ERP-System überträgt — drei manuelle Datenerfassungsschritte, die jeweils eigene Übertragungsfehler einführen und deren Felder nicht gegeneinander validiert werden. Die strukturierte Extraktionsausgabe speist alle drei Zielsysteme aus einer Quelle, und die Quervalidierung erfolgt am Punkt der Erfassung — bevor die Daten in getrennte Pipelines auseinanderlaufen. Für die feldweise Extraktion einer einzelnen Handelsrechnung behandelt der Leitfaden zur Extraktion deutscher Handelsrechnungsdaten nach Excel die vollständige Spaltendefinition und Einrichtung. Für die Batch-Dimension — die Verarbeitung von vierzig Handelsrechnungen in einem Durchlauf — behandelt der Leitfaden zum Batch-Exportabgleich die Erstellung des konsolidierten Exportjournals.

FAQ