Intrastat-Meldung aus Lieferantenrechnungen erstellen

Eine Intrastat-Meldung an das Statistische Bundesamt (Destatis) ist verpflichtend, sobald die innergemeinschaftlichen Eingänge eines Unternehmens im laufenden oder vorangegangenen Kalenderjahr 3 Millionen Euro überschreiten oder die Versendungen 1 Million Euro. Wird die Schwelle erst im laufenden Jahr überschritten, beginnt die Meldepflicht mit dem Berichtsmonat der Überschreitung; wer weder im Vorjahr noch im laufenden Jahr oberhalb der Schwelle liegt, ist für diese Verkehrsrichtung befreit, bis die Grenze erneut überschritten wird. Die Anhebung der Anmeldeschwellen ab Januar 2025 hat beide Werte deutlich erhöht und den Personenkreis der monatlich Meldenden damit auf volumenstarke Großhändler und DE-Töchter internationaler Konzerne konzentriert.

Die Meldung wird Position für Position aus den Lieferantenrechnungen des Berichtsmonats erzeugt. In jede Position gehören Warennummer (8-stellig nach dem Warenverzeichnis für die Außenhandelsstatistik), Ursprungsland, Versendungsland, Eigenmasse in kg, statistischer Wert und Art des Geschäfts. Frist ist der 10. Arbeitstag des Monats, der auf den Berichtsmonat folgt; übertragen wird entweder über eSTATISTIK.core (maschinell erzeugte INSTAT/XML-Datei) oder über IDEV (das manuelle Webformular im Erhebungsportal).

Die gängigen Compliance-Übersichten zu diesem Thema, von Destatis selbst, von Kammerseiten, von ERP-Anbietern, setzen alle auf der Stammdatenseite an: Warennummer, Eigenmasse und statistischer Wert sollen ihrer Logik nach bereits sauber im Artikelstamm hinterlegt sein. Die Realität in einer DE-Tochter sieht anders aus. Auf dem Tisch der AP-Leitung liegt jeden Monat ein Stapel PDFs aus EU-Lieferländern, und aus diesem Stapel muss die Eingangsmeldung erzeugt werden, nicht aus einem fertig befüllten Stamm. Dieser Leitfaden arbeitet die Intrastat-Meldung aus Lieferantenrechnungen in der umgekehrten Richtung auf: vom Eingangsrechnungs-PDF zur fertigen INSTAT-Position.

Begriffsabgrenzung am Rand: Die hier behandelte Form ist die Eingangsmeldung für Waren, die physisch aus einem anderen EU-Mitgliedstaat nach Deutschland gelangen. Ihr Spiegelbild, die Versendungsmeldung für Warenversendungen aus Deutschland in andere EU-Mitgliedstaaten, geht ebenfalls an das Statistische Bundesamt; Feldmapping, Übermittlungsweg und Frist ähneln sich, aber Verkehrsrichtung und Empfängerland drehen sich um.

Vom Eingangsrechnungs-PDF zur INSTAT-Position — Feld-für-Feld-Mapping

Eine durchschnittliche Lieferantenrechnung aus einem EU-Lieferland enthält ungefähr die Hälfte der Pflichtangaben einer Intrastat-Position direkt, einen Teil nur mittelbar und einen Teil gar nicht. Die operative Aufgabe der monatlichen Meldung besteht darin, jedes Pflichtfeld pro Position einer Quelle zuzuordnen, der Rechnung selbst, der zugehörigen Speditionsrechnung, dem Lieferschein, den eigenen Buchungsstammdaten oder der eigenen Lieferadresse.

Die Pflichtfelder im Überblick und woher sie stammen:

• Warennummer (8-stellig): häufig direkt auf der Rechnung als Zolltarifnummer oder Warennummer ausgewiesen. Nicht selten allerdings nur 6-stellig (HS-Code) statt 8-stellig, gelegentlich auch gar nicht. Die genaue Behandlung, Übernahme, Validierung und Lookup im Warenverzeichnis, folgt im nächsten Abschnitt.

• Ursprungsland (ISO-2-Code): typischerweise als Code (DE, CN, US) oder als Klartext ("Made in China") in der Positionszeile oder im Tabellenkopf der Rechnung. Bei Handelsware mit gemischten Ursprüngen ist das Feld pro Position separat zu erfassen, nicht pauschal aus dem Rechnungsabsender abzuleiten. Dasselbe Feld speist außerdem den Zoll- und Außenhandelsabgleich; der Ursprungsland-Abgleich aus Lieferantenrechnungen behandelt diesen Abgleich separat.

• Versendungsland: das EU-Mitgliedsland, aus dem die Ware physisch nach Deutschland versendet wurde. Leitet sich aus der Lieferanten-Adresse oder, bei abweichendem Versandort, aus dem Lieferschein ab. Versendungsland und Ursprungsland fallen in vielen Fällen zusammen, müssen es aber nicht: Ein französischer Lieferant, der chinesische Ware aus seinem Lager in Lyon nach Deutschland versendet, ergibt Ursprungsland CN und Versendungsland FR. Ware aus einem deutschen Lager ist dagegen kein Intrastat-Eingang.

• Eigenmasse in kg: in einer separaten Spalte oder in der Positionsbeschreibung der Rechnung, sofern der Lieferant sie überhaupt ausweist. Bei Lieferanten ohne Gewichtsangabe wird das Feld aus den eigenen Stammdaten oder aus dem Lieferschein der Spedition ergänzt. Eigenmasse meint das Gewicht der Ware ohne Verpackung.

• Besondere Maßeinheit: nur für einen Teil der Warennummern vorgeschrieben (Stück, Liter, Quadratmeter, Paar). Welche Warennummer eine besondere Maßeinheit verlangt, regelt das Warenverzeichnis, nicht die Rechnung; der Wert selbst stammt dann meist aus der Positionsmenge.

• Statistischer Wert: ohne Umsatzsteuer, mit anteilig auf die Position verteiltem Fracht- und Versicherungsanteil bis zur deutschen Grenze. Steht selten direkt auf der Rechnung. Er wird aus dem Positionsnettowert plus oder minus anteilig zugeordneter Fracht und Versicherung bis zur Grenze berechnet, wobei die Frachtkosten oft in einer separaten Speditionsrechnung stehen, nicht in der Warenrechnung. Welcher Anteil der Fracht im Rechnungsbetrag bereits enthalten ist und welcher addiert oder abgezogen werden muss, hängt von der vereinbarten Lieferbedingung ab; die Incoterms auf der Handelsrechnung als Grundlage des statistischen Werts sind hier der entscheidende Hebel.

• Art des Geschäfts (zweistelliger Code): praktisch nie auf der Rechnung. Wird aus der Geschäftsart abgeleitet, endgültiger Kauf, Lohnveredelung, Rücksendung, Konsignationslieferung, und muss aus dem Buchungskontext ergänzt werden.

• Verkehrszweig: der Verkehrsträger beim Grenzübertritt (Straße, Schiene, Binnenwasserstraße, See, Luft, Post, eigener Antrieb). Aus der Speditionsrechnung oder dem Lieferschein, nicht aus der Warenrechnung.

• Beförderungsbedingung: der Incoterm, soweit auf der Warenrechnung ausgewiesen, andernfalls aus dem zugrundeliegenden Liefervertrag.

• Empfängerregion in Deutschland: der Bundesland-Schlüssel der innergemeinschaftlichen Empfangsstelle. Kommt aus der eigenen Lieferadresse, nicht aus dem Lieferanten-PDF.

Der statistische Wert verdient eine eigene Erklärung, weil er der häufigste Stolperstein im Mapping ist. Den statistischen Wert Intrastat aus der Rechnung zu berechnen heißt: Fracht- und Versicherungskosten bis zur deutschen Grenze anteilig nach Wert oder Gewicht auf die Positionen der Warenrechnung verteilen. Bei Lieferung mit Klauseln wie EXW oder FCA liegen die Transportkosten bis zur Grenze beim Empfänger und kommen oft als separater Beleg von der Spedition. Beispiel: 12 Positionen mit zusammen 24.000 Euro Nettowarenwert, separate Frachtrechnung über 480 Euro Transport bis zur deutschen Grenze. Verteilt nach Nettowert ergibt das einen Frachtaufschlag von 2 Prozent pro Position. Eine Position mit 1.500 Euro Netto trägt damit 30 Euro Fracht, der statistische Wert dieser Position beträgt 1.530 Euro. Bei frei-Haus-, DAP- oder DDP-Lieferungen an einen Bestimmungsort in Deutschland ist Fracht im Rechnungsbetrag bereits enthalten; dann ist zu prüfen, welcher Anteil hinter der deutschen Grenze anfällt und vom statistischen Wert abzuziehen ist.

Die Art des Geschäfts aus der Lieferantenrechnung herzuleiten lässt sich für eine reguläre AP-Pipeline schnell standardisieren. Code 11 (endgültiger Kauf/Verkauf gegen Bezahlung) deckt den Großteil der monatlichen Eingänge ab, der reguläre Wareneinkauf vom EU-Lieferanten gegen Rechnung gehört dort hinein. Abweichende Codes treten als Ausnahmen auf: 21 oder 22 für Rückwaren, wenn eine Lieferung aus einem früheren Monat zurückgeht oder ersetzt wird; 41 oder 42 für Warenbewegungen zur Lohnveredelung und 51 oder 52 für Warenbewegungen nach Lohnveredelung; die 30er-Reihe für unentgeltliche Lieferungen. Diese Ausnahmefälle sind am Buchungskonto erkennbar, Rückwaren laufen über das Reklamations- oder Retourenkonto, Lohnveredelung über ein Veredelungskonto, und der Code wird beim Mapping aus dieser Buchung mitgegeben.

Warennummer aus der Rechnung gewinnen — und das Warenverzeichnis-Lookup, wenn der Lieferant keine angibt

Wenn der Lieferant die 8-stellige Warennummer auf der Rechnung ausweist, ist der erste Schritt unspektakulär: Der Code wird positionsgenau in die Eingangsmeldung übernommen. Auf Rechnungen steht derselbe Wert nicht immer unter demselben Namen. Gängige Bezeichnungen sind Warennummer, Zolltarifnummer, KN-Code, CN-Code oder Combined-Nomenclature-Code. Entscheidend ist die Länge und Gültigkeit: Für die deutsche Intrastat-Meldung reicht nicht die Warenbeschreibung, sondern die 8-stellige Nummer nach dem Warenverzeichnis für die Außenhandelsstatistik.

Auch ein vorhandener Code sollte nicht ungeprüft in den Monatslauf wandern. Das Warenverzeichnis wird jährlich zum 1. Januar aktualisiert; einzelne Codes entfallen, werden aufgeteilt oder erhalten geänderte Beschreibungen. Ein Lieferantenstamm, der im Vorjahr korrekt war, kann im neuen Berichtsjahr eine veraltete Nummer liefern. In einer belastbaren AP-Pipeline wird deshalb nicht nur die Warennummer aus der Lieferantenrechnung ermittelt, sondern gegen das aktuelle Warenverzeichnis validiert. Eine Nummer, die dort nicht mehr existiert, ist kein harmloser Schreibfehler, sondern ein Korrekturfall vor Abgabe der Meldung.

Der häufigste Zwischenfall ist der 6-stellige HS-Code. Außereuropäische Lieferanten, Konzernlieferanten oder Versanddokumente geben oft nur diesen weltweit harmonisierten Code an. Die deutsche Eingangsmeldung verlangt aber den 8-Steller der Kombinierten Nomenklatur. Die fehlenden zwei Stellen werden über die Hierarchie unterhalb des 6-Stellers gefunden: erst das Kapitel, dann die Position, dann die Unterposition, dann die konkrete Warennummer. Bei Standardwaren gibt es häufig nur eine plausible Untergliederung. Bei Waren mit unterschiedlicher Materialzusammensetzung, Verwendung oder technischer Ausführung muss die Fachseite entscheiden, welche Untervariante tatsächlich passt.

Fehlt der Code vollständig, führt der Weg über die Online-Suche im Warenverzeichnis für die Außenhandelsstatistik. Ausgangspunkt ist die Warenbeschreibung der Position, nicht die interne Artikelnummer. Eine Beschreibung wie "Edelstahlschrauben M8" liefert bessere Treffer als "SKU-18472". Die Stichwortsuche grenzt das Kapitel ein; die hierarchische Navigation prüft anschließend, ob Material, Funktion und Ausführung zur Warennummer passen. Bei mehrdeutigen Treffern entscheidet nicht der ähnlichste Text, sondern die zolltarifliche Einordnung der Ware: Material bei Textilien und Metallen, Verwendungszweck bei Maschinenkomponenten, Zusammensetzung bei chemischen Erzeugnissen.

Nach dem ersten Lookup gehört die gefundene Warennummer in die eigenen Stammdaten. Das verhindert, dass dieselbe Warenart im nächsten Berichtsmonat erneut gesucht wird, und macht die monatliche Meldung kontrollierbarer. In der Praxis bilden sich nach zwei oder drei Monatsläufen stabile Lieferanten- und Materialcluster: dieselben Komponenten, dieselben Warengruppen, dieselben Codes. Die Stammdatenpflege ersetzt den Lookup nicht, sie macht ihn wiederholbar. Zum Jahreswechsel bleibt trotzdem eine Aktualisierungsprüfung nötig, weil ein gültiger Code aus Dezember im Januar entfallen sein kann.

Übermittlung — eSTATISTIK.core (XML) oder IDEV, und die Umstellung ab Januar 2027

Für die Übermittlung an das Statistische Bundesamt gibt es zwei Arbeitslogiken. eSTATISTIK.core ist der maschinelle Weg: Ein ERP, ein Außenhandelsmodul oder ein Drittsystem erzeugt die Meldedatei im INSTAT/XML-Format und überträgt sie über das Erhebungsportal. Das passt zu Volumenmeldern, die jeden Monat viele Positionen melden und deren Prozess ohnehin auf einer strukturierten Tabelle aus Rechnungs-, Liefer- und Stammdaten beruht. Wer eSTATISTIK.core aus Lieferantenrechnungen befüllen will, braucht daher zuerst ein sauberes Positionsraster, nicht nur den Rechnungsbetrag auf Kopfebene.

IDEV ist der manuelle Weg. Die Sachbearbeitung meldet sich im Erhebungsportal an und erfasst die Positionen über das Webformular. Für wenige Positionen pro Monat ist das pragmatisch: Die Zeit für eine XML-Pipeline rechnet sich nicht, und ein Erstmelder kann das Verfahren zunächst verstehen, bevor es automatisiert wird. Die manuelle Intrastat-Meldung in IDEV ist aber kein gutes Zielbild für mehrere hundert Positionen, weil jede Korrektur, jede Warennummer und jede Massenangabe erneut händisch in der Maske landet.

Dazwischen steht ein Bestandsverfahren, das viele Unternehmen noch kennen: der INSTAT/XML-Upload über die IDEV-Oberfläche. Dieser Pfad läuft über den Bezugszeitraum 2026 hinaus nicht weiter. Ab Bezugszeitraum Januar 2027 müssen INSTAT/XML-Dateien über eSTATISTIK.core gesendet werden; die übrigen IDEV-Formulare und kleine CSV-Importe sind davon getrennt zu betrachten. Wer 2026 eine neue Dateiübermittlung aufsetzt oder wegen eines ERP-Updates testen muss, sollte den Testlauf nicht mehr um den alten IDEV-Upload herum planen.

Als Entscheidungsregel genügt meist das monatliche Positionsvolumen. Unter etwa 30 bis 50 Positionen und bei unregelmäßiger Meldepflicht ist IDEV manuell vertretbar, sofern die Daten vor der Eingabe sauber vorbereitet sind. Bei wiederkehrenden Meldungen mit wachsender Lieferantenstruktur amortisiert sich die XML-Pipeline schnell: Die Feldlogik aus dem Mapping wird einmal definiert, Monatsläufe werden wiederholbar, und Plausibilitätsfehler lassen sich vor Abgabe im Datenbestand prüfen.

Strukturierte Eingangsformate ändern nur die Eingangsseite. Wenn Lieferanten XRechnung oder ZUGFeRD senden, sind Warenbeschreibung, Mengen, Nettowerte und teilweise Produktcodes bereits maschinenlesbar; der Empfangsprozess für XRechnung und ZUGFeRD einrichten behandelt diese Vorstufe. Die Intrastat-Ausgabeseite bleibt dieselbe: Die Pipeline muss am Ende Positionen mit Warennummer, Eigenmasse, statistischem Wert und den übrigen Meldefeldern liefern, die anschließend in INSTAT/XML oder in die IDEV-Maske gehen.

Bei überwiegend PDF-basierten Lieferantenstapeln ist automatisierte Datenextraktion aus Lieferantenrechnungen der praktische Zwischenschritt zwischen Dokument und Meldedatei. Invoice Data Extraction verarbeitet PDF- und Bilddateien, extrahiert Daten auf Rechnungs- und Positionsebene nach einer natürlichsprachlichen Anweisung und gibt die Ergebnisse als strukturierte XLSX-, CSV- oder JSON-Datei aus. Für den Intrastat-Prozess heißt das: Warennummern aus Tabellenköpfen oder Positionszeilen, Eigenmasse aus uneinheitlichen Spalten und Ursprungscodes wie DE, CN oder US werden in ein einheitliches Exportformat gebracht. Das ERP oder Außenhandelsmodul erzeugt daraus anschließend die INSTAT/XML-Datei; die Extraktion selbst liefert die strukturierte Datenbasis dafür.

Frist zum 10. Arbeitstag, Berichtigungsmeldung und Konsequenzen bei Verspätung

Die Eingangsmeldung für einen Berichtsmonat muss spätestens am 10. Arbeitstag des Folgemonats beim Statistischen Bundesamt eingegangen sein. Die Frist hängt nicht vom Übermittlungsweg ab: eSTATISTIK.core, IDEV-Webformular und Dateiübermittlung folgen derselben Abgabedisziplin. Eine Dauerfristverlängerung aus der Umsatzsteuer hilft hier nicht weiter; Intrastat läuft nach eigenem Kalender.

Für den Berichtsmonat Januar liegt der Stichtag im Februar, in der Praxis meist um die Monatsmitte. Entscheidend ist nicht eine pauschale Datumsregel, sondern der konkrete Intrastat-Fristkalender für das jeweilige Jahr. AP-Teams sollten deshalb einen eigenen Monatsabschlusskalender führen, der den 10. Arbeitstag als festen Intrastat-Meilenstein enthält. Knapp werden vor allem Monate, in denen Feiertage, Urlaubszeiten und später Rechnungseingang zusammenfallen, etwa der Meldelauf nach April oder Dezember.

Eine Berichtigungsmeldung wird fällig, wenn nach der Abgabe ein Fehler sichtbar wird, der bereits im Zeitpunkt der ursprünglichen Meldung angelegt war. Typische Auslöser sind eine korrigierte Warennummer des Lieferanten, ein vertauschtes Ursprungsland, eine später eingegangene Frachtkostenrechnung, die den statistischen Wert verändert, oder eine falsch zugeordnete Art des Geschäfts. Korrigiert wird nicht der ganze Monatslauf neu, sondern die betroffene Anmeldeposition im bereits abgegebenen Berichtsmonat.

Operativ sollte die Berichtigungsmeldung denselben Datenpfad nutzen wie die ursprüngliche Meldung. In einer XML-Pipeline bleibt die ursprüngliche Meldung referenzierbar, die fehlerhafte Position wird mit den korrigierten Feldern erneut erzeugt und über eSTATISTIK.core eingereicht. Bei manueller IDEV-Erfassung wird die Korrektur in der Maske des betreffenden Berichtsmonats nachvollzogen. Wichtig ist, den Auslöser zu dokumentieren: Lieferantenkorrektur, Speditionsrechnung, Stammdatenänderung oder interne Buchungskorrektur.

Bei verspäteter oder unterlassener Meldung folgen zunächst Rückfragen oder Mahnungen des Statistischen Bundesamts. Bleiben Verstöße gegen die Auskunftspflicht bestehen, kann daraus ein Ordnungswidrigkeitenverfahren werden; § 19 AHStatG sieht dafür einen Bußgeldrahmen bis zu 50.000 Euro vor. Für die Praxis ist der wichtigere Punkt der Prozessschaden: Ein verspäteter Lauf muss nachgeholt werden, Korrekturen binden dieselben Fachleute erneut, und die nächste Monatsmeldung startet mit ungeklärten Altfehlern.

Eine Lieferantenrechnung, zwei Outputs — Umsatzsteuer zur Finanzverwaltung und Eingangsmeldung an Destatis

Eine innergemeinschaftliche Eingangsrechnung treibt zwei getrennte Outputs. Für die Umsatzsteuer wird der innergemeinschaftliche Erwerb nach §1a UStG in der Finanzbuchhaltung erfasst und in der Umsatzsteuer-Voranmeldung gegenüber der Finanzverwaltung erklärt. Für Intrastat entsteht aus derselben Rechnung eine Eingangsmeldung an das Statistische Bundesamt. USt-IdNr.-Prüfung und BZSt-nahe Meldeprozesse können im Umfeld der EU-Warenbewegung eine Rolle spielen, sind aber nicht die Intrastat-Eingangsmeldung selbst. Zwei Ausgaben, unterschiedliche Behördenlogik, ein Eingabedokument.

Die Datenanforderungen überschneiden sich nur teilweise. Die umsatzsteuerliche Buchung braucht Lieferant, USt-IdNr., Rechnungsdatum, Nettobetrag, Buchungsperiode und den errechneten Steuerbetrag. Die Intrastat-Position braucht zusätzlich das Feldraster aus dem Mapping: Warennummer, Ursprungsland, Versendungsland, Eigenmasse, besondere Maßeinheit, statistischer Wert, Art des Geschäfts, Verkehrszweig, Beförderungsbedingung und Empfängerregion. Kopfwerte reichen für die USt-Buchung; Intrastat verlangt die Positionsdaten.

Genau dort entsteht in vielen Unternehmen doppelte Arbeit. Die Finanzbuchhaltung erfasst die Rechnung zunächst kopfzeilenbasiert für die Umsatzsteuer. Später zieht das Außenhandels- oder Compliance-Team dieselbe PDF erneut heran, diesmal auf Positionsebene für die Eingangsmeldung. Jede zweite Erfassung erhöht das Fehlerrisiko: Ein Lieferant wird anders geschrieben, ein Nettowert wird aus einer korrigierten Rechnung übernommen, eine Warennummer landet nur in der Intrastat-Tabelle und nie im Artikelstamm.

Die Detailanforderungen an Reverse-Charge-Belege nach §13b UStG sind im separaten Leitfaden zur Reverse-Charge-Rechnung nach §13b UStG behandelt; hier geht es um den angrenzenden §1a-Erwerb und die Prozessfolge aus derselben Eingangsrechnung. Wenn die AP-Pipeline die Eingangsrechnung ohnehin positionsgenau liest, sollten Kopf- und Positionsdaten gemeinsam gespeichert werden. Aus derselben Erfassung werden dann die USt-Buchung und die Intrastat-Eingangsmeldung gespeist, statt dass zwei Teams denselben Beleg mit unterschiedlichen Tabellen noch einmal anfassen.

Die praktische Zielarchitektur ist deshalb nicht ein zusätzliches Intrastat-Silo, sondern eine gemeinsame Rechnungsdatenbasis. Kopfebene für Buchhaltung und Umsatzsteuer, Positionsebene für Warenstatistik, Zoll- und Außenhandelsabgleich. Die Behördenschritte bleiben getrennt, aber die Datenpflege beginnt einmal: bei der Lieferantenrechnung.