So extrahieren Sie deutsche Handelsrechnungs-Exportdaten
für Zoll und Buchhaltung
Eine deutsche Ausfuhrhandelsrechnung (Handelsrechnung) enthält rund ein Dutzend Felder, die eine inländische Rechnung (Rechnung) nicht aufweist: die EORI-Nummer des Exporteurs, die 11-stellige Zolltarifnummer pro Position, das Ursprungsland pro Position, die geltenden Incoterms, das Nettogewicht und das Bruttogewicht sowie den Abschnitt zur Ausfuhrbestätigung. Jedes dieser Felder wurde von der Exportabteilung in die Rechnungsvorlage eingegeben. Und jedes einzelne muss in mindestens zwei weitere Systeme übertragen werden: in die ATLAS-Ausfuhranmeldung für den Zoll und in das interne ERP für die Buchhaltung. Der nachfolgend beschriebene Extraktionsansatz ersetzt beide Übertragungsschritte durch eine einzige strukturierte Ausgabe – eine Zeile pro Handelsrechnung, einmal definierte Spalten, jedes Feld aus dem PDF erfasst.
Die wichtigsten Erkenntnisse
- Eine deutsche Handelsrechnung enthält rund ein Dutzend reiner Zollfelder – EORI-Nummer, 11-stellige Zolltarifnummer pro Position, Ursprungsland, Incoterms, Nettogewicht und Bruttogewicht – die eine inländische Rechnung nie erfordert, und jedes einzelne muss aus dem PDF in ATLAS und das ERP übertragen werden.
- Ein Exporteur mit 30 monatlichen Sendungen überträgt jeden Monat etwa 240 Zollfelder aus PDFs in Tabellen – jeder Tastendruck eine potenzielle Abweichung zwischen dem, was der Zoll sieht, und dem, was die Buchhaltung verbucht, eine Diskrepanz, die das Finanzamt bei Prüfungen kreuzweise abgleicht.
- Definieren Sie Ihre Extraktionsspalten einmal, laden Sie die PDFs hoch anstatt sie abzutippen, und beide Pipelines – ATLAS-Ausfuhranmeldung und ERP-Buchhaltungseintrag – greifen auf eine einzige strukturierte Tabelle zu, wodurch die Übertragungslücke an ihrer Quelle beseitigt wird.
Was eine Handelsrechnung von einer Inlandsrechnung unterscheidet
Jedes deutsche Unternehmen stellt Rechnungen aus. Eine Inlandsrechnung muss gemäß §14 UStG den Namen und die Anschrift des Lieferanten, das Rechnungsdatum und die Rechnungsnummer, den Namen und die Anschrift des Kunden, die Menge und Art der gelieferten Waren oder erbrachten Dienstleistungen, den Nettobetrag, den Umsatzsteuersatz und -betrag sowie den Bruttogesamtbetrag enthalten. Diese Felder speisen das Debitorenbuchhaltungssystem, die Umsatzsteuervoranmeldung (UVA) und den Jahresabschluss. Es sind die Felder, für die jede deutsche Buchhaltungssoftware – DATEV, Lexware, SAP – ausgelegt ist.
Eine Handelsrechnung enthält all diese Felder. Sie enthält jedoch auch eine zusätzliche Reihe von Feldern, die es aus einem einzigen Grund gibt: Die Waren überschreiten eine Zollgrenze. Dies sind die Felder, die die Zollbehörden des Bestimmungslandes benötigen, um Zölle zu bewerten, den Ursprung zu überprüfen und den angemeldeten Wert zu validieren. Gemäß dem Zollkodex der Union (UZK, Verordnung (EU) Nr. 952/2013) muss jede Handelsrechnung, die Waren begleitet, die aus der EU in ein Nicht-EU-Land ausgeführt werden, Folgendes enthalten:
| Feld (deutscher Begriff) | Englische Beschreibung | Warum der Zoll es benötigt |
|---|---|---|
| EORI-Nummer | Wirtschaftsbeteiligten-Registrierungs- und Identifikationsnummer — Format: DE + 15 Ziffern | Identifiziert den Exporteur im EU-Zollsystem. Erforderlich gemäß UZK Art. 9 für alle Zollanmeldungen. Ohne sie lehnt ATLAS die Ausfuhranmeldung ab. |
| Zolltarifnummer (HS-Code) | 11-stelliger deutscher Zolltarifcode pro Position — erste 6 Stellen = internationaler HS, Stellen 7-8 = EU-Kombinierte Nomenklatur, Stellen 9-10 = TARIC, Stelle 11 = nationale Codenummer Deutschlands | Bestimmt die Ausfuhrkontrollklassifizierung, etwaige Ausfuhrbeschränkungen und – für den Importeur – den Einfuhrzollsatz am Bestimmungsort. Pro Position, nicht pro Rechnung. |
| Ursprungsland | Ursprungsland pro Position – das Land, in dem die Waren vollständig gewonnen wurden oder der letzten wesentlichen Be- oder Verarbeitung unterzogen wurden (UZK Art. 60) | Bestimmt die Präferenzzollberechtigung am Bestimmungsort. Muss pro Position angegeben werden, da eine Sendung Waren aus mehreren Ursprungsländern enthalten kann. |
| Lieferbedingungen (Incoterms) | Incoterms-2020-Klausel – z. B. EXW Stuttgart, FOB Hamburg, CIF New York, DDP Tokio | Definiert, wer Transportkosten, Versicherung und Zollrisiko auf jeder Etappe trägt. Bestimmt, was der angemeldete Zollwert umfasst (Fracht + Versicherung oder nicht). |
| Nettogewicht / Bruttogewicht | Nettogewicht (nur Waren) und Bruttogewicht (Waren + Verpackung) pro Position oder pro Sendung in Kilogramm | Erforderlich für Transportdokumente (CMR, AWB, B/L) und die Zollwertermittlung. Das Bruttogewicht bestimmt Frachtkosten und Handhabungsanforderungen. |
| Ausfuhrbestätigung | Ausfuhrbestätigungsabschnitt – typischerweise ein reservierter Bereich für Zollstempel oder den elektronischen ATLAS-Ausgangsvermerk | Nachweis, dass die Waren das Zollgebiet der Union physisch verlassen haben. Erforderlich für die Umsatzsteuerbefreiung nach §4 Nr. 1a UStG. Ohne diesen Nachweis kann der Exporteur die Steuerbefreiung in der UVA nicht belegen. |
Jedes dieser Felder wird von der Exportabteilung in die Handelsrechnungsvorlage eingegeben. Dieselben Felder müssen dann in der ATLAS-Ausfuhranmeldung erscheinen – und die Exportabteilung oder ein Zollagent gibt sie dort erneut ein. Und dann benötigt die Buchhaltung eine Teilmenge (Rechnungsnummer, Gesamtbetrag, EORI für das Exporthauptbuch), die ein drittes Mal in das interne ERP eingegeben wird. Die Handelsrechnung wird einmal erstellt. Ihre Daten werden dreimal eingegeben.
Das Zwei-Pipeline-Problem: Eine Rechnung, zwei Systeme, null Verbindung
Ein deutscher Exporteur, der 30 Sendungen pro Monat verschickt, erstellt 30 Handelsrechnungen. Jede durchläuft zwei völlig getrennte Datenpipelines – und keine der beiden Pipelines kommuniziert mit der anderen.
Pipeline 1: Zoll (ATLAS AES). Die Exportabteilung oder ein Zollspediteur übernimmt die Daten aus der Handelsrechnung und gibt sie in die ATLAS-AES-Ausfuhranmeldung ein. Diese Anmeldung erfordert die EORI-Nummer, die Zolltarifnummern pro Position, das Ursprungsland pro Position, die Incoterms, den Zollwert sowie das Nettogewicht und Bruttogewicht. Die Anmeldung erfolgt über ATLAS-kompatible Software – AEB Export Filing, DAKOSY GE, MIC-CUST, SAP GTS – oder über das eigene System des Zollspediteurs. ATLAS verarbeitet sie, führt eine Risikoanalyse durch und stellt bei Annahme das Ausfuhrbegleitdokument (EAD) mit einer 18-stelligen Movement Reference Number (MRN) aus. Wenn die Waren die EU verlassen, erhält der Exporteur den Ausgangsvermerk – den Nachweis, dass die Waren physisch ausgeführt wurden, der die Umsatzsteuerbefreiung belegt.
Pipeline 2: Buchhaltung (ERP). Die Buchhaltung erhält dieselbe Handelsrechnung – in der Regel als PDF von der Exportabteilung oder aus dem Dokumentenmanagementsystem. Der Buchhalter muss den Exportverkauf verbuchen: die Rechnungsnummer, das Rechnungsdatum, den Kundennamen, den Gesamtwert, die Incoterms für die Kostenverteilung (Fracht und Versicherung werden auf andere Konten gebucht als der Warenwert) und die EORI-Nummer für das Ausfuhrbuch. Für die Umsatzsteuervoranmeldung (UVA) muss der Buchhalter jede Handelsrechnung mit dem zugehörigen Ausgangsvermerk abgleichen, um die steuerfreien Ausfuhrerlöse gemäß §4 Nr. 1a UStG zu belegen. Für die Intrastat-Meldung (innergemeinschaftliche Handelsstatistik, verpflichtend nach dem Außenhandelsstatistikgesetz) benötigt der Buchhalter die Zolltarifnummern, das Bestimmungsland und den statistischen Wert pro Warencode.
Die Lücke. Pipeline 1 erhält ihre Daten von der Exportabteilung, die sie entweder direkt in die ATLAS-Software eingibt oder per E-Mail an einen Spediteur sendet. Pipeline 2 erhält ihre Daten aus dem PDF der Handelsrechnung, das als flaches Dokument im Posteingang der Buchhaltung landet – jedes Feld sichtbar, aber nichts davon strukturiert. Der Buchhalter öffnet das PDF und tippt die Rechnungsnummer, das Datum, den Gesamtbetrag, die EORI, die Incoterms und die Zolltarifnummern erneut in das ERP ein. Bei 30 Handelsrechnungen pro Monat mit jeweils etwa 8 zollrelevanten Feldern sind das 240 Felder, die monatlich manuell vom PDF in die Tabelle übertragen werden. Jeder Tastendruck birgt das Risiko eines Übertragungsfehlers. Jeder Fehler hat Folgen: Eine falsch eingegebene Zolltarifnummer im Buchhaltungsjournal stimmt möglicherweise nicht mit der in ATLAS gemeldeten Zolltarifnummer überein, was zu einer Diskrepanz führt, die bei einer Zollprüfung oder einer Umsatzsteuer-Sonderprüfung auffällt.
Dies ist dieselbe strukturelle Lücke, die in der Analyse beschrieben wird, warum ATLAS die Datenerfassungslücke schafft, die es schließen sollte – das System, das Zollanmeldungen digitalisiert hat, gibt Daten als PDF an den Importeur zurück, und der manuelle Übertragungsschritt füllt die Lücke zwischen ATLAS-Ausgabe und ERP-Eingabe. Die Handelsrechnung ist der Ausgangspunkt derselben Pipeline auf der Exportseite: Die Daten werden als strukturierte Eingabe erstellt, intern als PDF geliefert und in jedes System, das sie benötigt, neu eingegeben.
So richten Sie die Extraktion ein: Definieren Sie Ihre Spalten einmal, verarbeiten Sie jede Handelsrechnung
Die Lösung besteht nicht darin, die Erstellung von Handelsrechnungen in der Exportabteilung zu ändern. Die Daten werden dort bereits einmal erfasst. Die Lösung besteht darin, diese Daten aus dem PDF zu dem Zeitpunkt zu erfassen, an dem sie in die jeweilige nachgelagerte Pipeline gelangt – und damit den erneuten Eingabeschritt zwischen PDF und System zu eliminieren.
Die benutzerdefinierte Spaltenextraktion funktioniert, indem Sie eine Reihe von Spaltennamen definieren, die beschreiben, was Sie aus jedem Dokument extrahieren möchten. Die KI liest jedes PDF, versteht den Inhalt semantisch und findet den passenden Wert für jede Spalte – unabhängig davon, wo auf der Seite der Wert steht oder wie sich das Layout zwischen den Rechnungen unterscheidet. Sie definieren die Spalten einmal. Jede Handelsrechnung, die Sie danach hochladen, füllt dieselbe Tabellenstruktur.
Schritt 1: Definieren Sie die Kern-Zollspalten
Dies sind die Felder, die Pipeline 1 – die ATLAS-Ausfuhranmeldung – benötigt. Definieren Sie jede Spalte mit der exakten deutschen Terminologie, die Ihr Exportteam verwendet, damit die KI den semantischen Kontext korrekt zuordnet:
| Spaltenname | Was die KI extrahiert |
|---|---|
Handelsrechnung Nummer (Commercial Invoice Number) | Die Rechnungsnummer – typischerweise mit „HR-“ oder „EX-“ auf deutschen Exportrechnungen, abweichend von der Nummerierung inländischer Rechnungen |
Handelsrechnung Datum (Invoice Date, DD.MM.YYYY) | Das Rechnungsdatum im deutschen Datumsformat |
EORI-Nummer (DE + 15 digits) | Die EORI-Nummer des Exporteurs – muss mit der die ATLAS-Anmeldung einreichenden Stelle übereinstimmen |
Kunde (Customer Name and Address) | Der vollständige Name und die Anschrift des ausländischen Käufers inklusive Land |
Zolltarifnummer (11-digit Customs Tariff Code) per Position | Der vollständige 11-stellige deutsche Zolltarifcode für jede Position auf der Rechnung |
Ursprungsland (Country of Origin, ISO Code) per Position | Das Ursprungsland pro Position – z. B. DE für Waren deutschen Ursprungs, CN für Waren chinesischen Ursprungs |
Lieferbedingungen (Incoterms 2020) | Die Incoterms-Klausel – z. B. FOB Hamburg, CIF New York, EXW Stuttgart, DDP Tokyo |
Nettogewicht pro Position (Net Weight per Line Item, in kg) | Nettogewicht pro Warenposition |
Bruttogewicht Gesamt (Total Gross Weight, in kg) | Gesamtbruttogewicht der Sendung inklusive aller Verpackungen |
Schritt 2: Abgeleitete Spalten zur Gegenprüfung hinzufügen
Abgeleitete Spalten ermöglichen es der KI, Informationen aus dem bereits Gelesenen abzuleiten – sie erzeugt Werte, die die Handelsrechnung möglicherweise implizit nennt, die Zollanmeldung jedoch explizit erfordert. Fügen Sie diese Spalten unterhalb Ihrer direkten Extraktionsspalten hinzu:
| Name der abgeleiteten Spalte | Was die KI ableitet |
|---|---|
HS Chapter (derive from Zolltarifnummer: output 2-digit chapter number with description, e.g. "84 — Machinery and Mechanical Appliances") | Wandelt den 11-stelligen Code in das lesbare HS-Kapitel um – nützlich für die Intrastat-Warengruppierung und zum Erkennen von Fehlklassifizierungen, bei denen das Kapitel eines Codes nicht zur Produktbeschreibung passt |
Bestimmungsland (Country of Destination, from Customer Address) | Extrahiert das Bestimmungsland aus der Kundenadresse – das Land, in das die Waren physisch versendet werden, das vom Rechnungsland abweichen kann |
Schritt 3: Eine berechnete Spalte zur Prüfung des Zollwerts hinzufügen
Ein häufiger Fehler in deutschen Ausfuhranmeldungen ist die Abweichung des Zollwerts – der auf der Handelsrechnung angegebene Wert (der je nach verwendetem Incoterms als EXW, FOB oder CIF ausgewiesen sein kann) unterscheidet sich von dem Wert, den die ATLAS-Anmeldung erfordert. Die ATLAS-Ausfuhranmeldung benötigt den statistischen Wert an der deutschen Grenze – typischerweise den FOB- oder EXW-Wert zuzüglich des Inlandstransports zum deutschen Ausgangshafen oder -flughafen.
Fügen Sie eine berechnete Spalte hinzu, um eine etwaige Differenz zwischen dem Rechnungsgesamtbetrag und der Summe der Positionen zu kennzeichnen – dies ist ein Vorläufer der Zollwertberechnung:
| Name der berechneten Spalte | Was die KI berechnet |
|---|---|
Invoice Total vs Line Item Sum Check (Rechnungssumme minus Summe aller Positionen — output "OK" if matched within €1, "CHECK" if difference exceeds €1) | Summiert alle Positionsbeträge und vergleicht sie mit dem Rechnungsgesamtbetrag – erkennt Rechenfehler, bevor die Daten in die ATLAS-Anmeldung oder den Buchungssatz gelangen |
Positionen Anzahl (Number of Line Items, count total commodity lines on this invoice) | Zählt die Anzahl der Positionen – nützlich zur Überprüfung, ob die Extraktion alle Zeilen erfasst hat, und für die Intrastat-Meldung, bei der jeder Warencode einen separaten statistischen Eintrag darstellt |
Dateien werden sicher verarbeitet und nicht gespeichert.
Schritt 4: Laden Sie jede Handelsrechnung jeder Exportsendung hoch
Laden Sie die Handelsrechnungs-PDFs hoch – für den aktuellen Monat, das aktuelle Quartal oder ein ganzes Geschäftsjahr. Die KI verarbeitet jede Rechnung innerhalb des Batches unabhängig. Eine Rechnung mit einem anderen Layout (anderes Template, andere Spaltenpositionen, andere Platzierung der Incoterms) wird genauso behandelt wie die Standardvorlage – da die KI Felder anhand ihrer semantischen Bedeutung und nicht anhand ihrer Position auf der Seite lokalisiert.
Für deutsche Exporteure, die neben Handelsrechnungen auch inländische Rechnungen führen, verarbeitet der Extraktionsansatz beide Dokumenttypen im selben Batch – definieren Sie die zollrelevanten Spalten (EORI, Zolltarifnummern, Ursprungsland, Incoterms, Gewichte) als Ihre Spalten, und bei inländischen Rechnungen (denen diese Felder fehlen) bleiben diese Zellen einfach leer. Die gemeinsamen Felder – Rechnungsnummer, Datum, Kunde, Gesamtbetrag – werden bei beiden Dokumenttypen befüllt, sodass Sie eine konsolidierte Exporttabelle erhalten, unabhängig davon, ob es sich um eine inländische Rechnung oder eine exportierte Handelsrechnung handelt.
Was Sie erhalten: Eine Zeile pro Handelsrechnung, jedes Feld an seinem Platz
Die Ausgabe ist eine Tabelle – Excel, CSV oder direkt in Google Sheets über das Google Sheets-Add-on – mit einer Zeile pro Handelsrechnung. Die Spalten sind die von Ihnen definierten. Die Werte in jeder Zelle sind das, was die KI aus dem PDF extrahiert hat.
Diese Tabelle speist beide Pipelines gleichzeitig:
Die EORI-Nummer, Zolltarifnummern, Ursprungsländer, Incoterms und Gewichte, die die ATLAS-Anmeldung erfordert, sind bereits in der Tabelle enthalten. Die Exportabteilung oder der Zollagent überträgt sie direkt aus der Tabelle in die ATLAS-Software – ohne jedes PDF öffnen und Daten abtippen zu müssen. Wenn Ihre ATLAS-Software (AEB, DAKOSY, MIC-CUST) den CSV- oder Excel-Import für Sammelanmeldungen unterstützt, speist die Tabelle die Anmeldung direkt ein. Wenn Sie einen Zollagenten beauftragen, senden Sie ihm die Tabelle anstelle der PDFs – der Agent erfasst die Daten schneller und mit weniger Übertragungsfehlern, da er aus einer Tabelle kopiert und nicht aus einem PDF abliest.
Rechnungsnummer, Datum, Kunde, Gesamtbetrag, EORI und Incoterms fließen in das Ausfuhrbuch und die Umsatzsteuervoranmeldung (UVA) ein. Die HS-Kapitel und Bestimmungsländer fließen in die Intrastat-Meldung ein. Statt dass der Buchhalter 30 PDFs öffnet und 240 Felder abtippt, öffnet er eine Tabelle, prüft die Werte anhand der PDFs und importiert die Daten in DATEV, Lexware oder SAP. Die Prüfung deckt Fehler auf. Das Abtippen erzeugt sie.
Die Tabelle wird zur einzigen Quelle der Wahrheit für die Handelsrechnungsdaten. Filtern Sie nach EORI-Nummer, um zu bestätigen, dass jede Ausfuhranmeldung die korrekte Exporteurkennung verwendet. Filtern Sie nach HS-Kapitel, um das Exportvolumen nach Warengruppe für den vierteljährlichen Intrastat-Bericht zu gruppieren. Vergleichen Sie die berechnete Spalte „Rechnungssumme vs. Positionssummen-Prüfung“, um arithmetische Abweichungen zu erkennen, bevor sie in die ATLAS-Anmeldung gelangen. Derselbe Datensatz, der die Ausfuhranmeldung speist, speist auch den Buchungssatz – Quelldaten konsistent über beide Pipelines hinweg, wodurch der häufige Prüfungsbefund vermieden wird, dass der zollseitig gemeldete Wert vom buchhalterisch erfassten Wert abweicht.
FAQ — Extraktion von Daten aus deutschen Handelsrechnungen
Kann das Tool Handelsrechnungen mit mehreren Positionen verarbeiten, die jeweils unterschiedliche Zolltarifnummern und Ursprungsländer haben?
Ja. Jede Position wird mit ihrer eigenen Zolltarifnummer und ihrem eigenen Ursprungsland extrahiert. Die Ausgabe behält die Struktur „eine Zeile pro Rechnung“ bei. Wenn Sie stattdessen eine Zeile pro Position benötigen, definieren Sie Ihre Spalten mit dem Präfix „pro Position“ und die KI behandelt jede Warenzeile als separate Extraktionseinheit. Für die meisten Export-Workflows ist jedoch eine Zeile pro Rechnung ausreichend, bei der die Zolltarifnummern und Ursprungsländer entweder zusammengefasst oder durch die Hauptware repräsentiert werden. Dies liegt daran, dass die ATLAS-Anmeldung bereits die Positionsdetails enthält und der Buchhaltungseintrag nur die Zusammenfassung auf Rechnungsebene benötigt.
Wie verarbeitet die Extraktion verschiedene Incoterms – insbesondere den Unterschied zwischen EXW-, FOB- und CIF-Werten auf derselben Rechnung?
Die KI extrahiert die Incoterms so, wie sie auf der Rechnung angegeben sind – FOB Hamburg, CIF New York, EXW Stuttgart. Sie berechnet keine Transport- oder Versicherungszuschläge. Für die Berechnung des Zollwerts (des Werts, der in die ATLAS-Anmeldung eingeht) müssen Sie den Rechnungswert basierend auf den Incoterms anpassen: EXW-Wert + Inlandstransport zur EU-Grenze = statistischer Wert; der FOB-Wert ist in der Regel für die ATLAS-Ausfuhranmeldung ausreichend; der CIF-Wert enthält Fracht und Versicherung, die für die ausfuhrseitige Anmeldung separiert werden müssen. Die berechnete Spalte „Rechnungssumme vs. Positionssummen-Prüfung“ validiert die Rechnungsarithmetik, aber die Anpassung der Incoterms an den Zollwert bleibt ein manueller Berechnungsschritt – oder kann mit einer berechneten Spalte automatisiert werden, wenn Ihre Fracht- und Versicherungskosten pro Sendung bekannt sind.
Ersetzt dieses Tool die ATLAS-AES-Ausfuhranmeldung?
Nein. Die Extraktion erzeugt die Eingabedaten für die ATLAS-Anmeldung. Für die Abgabe der Anmeldung ist weiterhin ATLAS-kompatible Software erforderlich (AEB, DAKOSY, MIC-CUST, SAP GTS oder das System des Zollbrokers) sowie eine aktive ATLAS-Teilnehmerregistrierung bei der Generalzolldirektion. Die Extraktion ersetzt den manuellen Dateneingabeschritt – das Lesen der Handelsrechnungs-PDF und das Eintippen der Felder in die ATLAS-Software – nicht die Software selbst. Für den vollständigen Workflow von der Zollanmeldung bis zu einem strukturierten Datensatz deckt die Anleitung zur Extraktion deutscher Zollanmeldungsdaten nach Excel das importseitige Äquivalent ab.
Wie fügt sich die Ausfuhrbestätigung / der Ausgangsvermerk in diesen Workflow ein?
Die Ausfuhrbestätigung ist der Nachweis, dass die Ware das Zollgebiet der EU physisch verlassen hat. Sie wird von der Ausgangszollstelle über ATLAS ausgestellt, nachdem die Ware gestellt und abgefertigt wurde. Es handelt sich nicht um ein Feld auf der Handelsrechnung selbst – es ist eine separate elektronische Nachricht oder ein Stampiglie, die/der nach der Verarbeitung der Ausfuhranmeldung eingeht. Im Extraktions-Workflow werden zuerst die Handelsrechnungsdaten extrahiert (als Eingabe für die ATLAS-Anmeldung). Nachdem die Anmeldung abgegeben wurde und die Ware ausgeführt ist, wird der Ausgangsvermerk empfangen. An diesem Punkt können Sie eine Spalte zu Ihrer Tabelle hinzufügen – Ausgangsvermerk erhalten (J/N) – und jede Zeile manuell markieren, wenn die Bestätigung eintrifft. So erhält Ihre Buchhaltungsabteilung eine einheitliche Sicht darauf, welche Exporte für die Umsatzsteuer-Nullbesteuerung belegt sind und welche noch ausstehen.
Kann das gleiche Spalten-Setup auch Daten aus deutschen Rechnungen extrahieren?
Ja – die gängigen Felder (Rechnungsnummer, Datum, Kunde, Beträge) werden aus jedem Rechnungsformat befüllt. Die zollspezifischen Spalten (EORI, Zolltarifnummern, Ursprungsland, Incoterms, Gewichte) bleiben bei inländischen Rechnungen leer. Das bedeutet, Sie können eine gemischte Charge hochladen – 20 Handelsrechnungen und 40 inländische Rechnungen – und erhalten eine einheitliche Tabelle. Sortieren Sie nach der EORI-Spalte, um Exportrechnungen von inländischen zu trennen. Das gleiche Prinzip gilt für die Extraktion von ELSTER-Steuerformulardaten: Definieren Sie die Spalten einmal und befüllen Sie sie aus den Quelldokumenten – der Leitfaden zur Extraktion deutscher ELSTER-Steuerformulardaten nach Excel wendet denselben Spaltendefinitionsansatz auf einen anderen Dokumenttyp an.
Die Handelsrechnung enthält bereits jedes Feld, das Ihre Zollanmeldung und Ihr Buchhaltungssystem benötigen. Der Engpass sind nicht fehlende Daten – es ist ein PDF, wo Tabellen sein sollten.
Handelsrechnung extrahieren