Zollreform 2026: Zolldaten aus dem ERP in den Shop

Die Zollbefreiung für Sendungen mit geringem Wert stammt aus einer Zeit, in der die Abfertigung kleiner Pakete mehr Verwaltungsaufwand verursachte als sie Einnahmen brachte. Mit der Verordnung (EU) 2026/382 hat der Rat das Kapitel V des Titels II der Zollbefreiungsverordnung (EG) Nr. 1186/2009 gestrichen – also genau jene Artikel 23 und 24, die Sendungen bis 150 Euro Sachwert von Zöllen befreit hatten (Rat der Europäischen Union, Verordnung (EU) 2026/382). An ihre Stelle tritt bis zum 1. Juli 2028 eine feste Abgabe von 3 Euro je Artikel in Sendungen, deren Sachwert 150 Euro nicht überschreitet. Danach greift für Fernverkäufe der reguläre Zolltarif – unabhängig vom Warenwert.

Der Hintergrund ist nüchtern: Rund eine Milliarde E-Commerce-Käufe erreichen die EU jedes Jahr, und die Kommission erwartet aus der Reform des E-Commerce-Zolls etwa eine Milliarde Euro zusätzliche Zolleinnahmen pro Jahr (Europäische Kommission, Generaldirektion Steuern und Zollunion). Eine ältere Untersuchung im Auftrag der Kommission hatte gezeigt, dass bei Postsendungen rund 50 Prozent (Europäische Kommission) der geschuldeten Einfuhrabgaben und rund 65 Prozent (Europäische Kommission, Generaldirektion Steuern und Zollunion) der Einfuhrumsatzsteuer nicht erhoben wurden, während Expressdienste nahezu vollständig abrechneten. Die digitale Zollabwicklung hat den ursprünglichen Grund für die Befreiung entwertet: Elektronische Daten liegen heute für jede Sendung vor, unabhängig vom Wert.

Zeitgleich kommt eine zweite Pflicht, die in der Diskussion um die 3 Euro gern untergeht: Für Waren aus Fernverkäufen müssen Produkt-Identifikatoren an den Zoll übermittelt oder bereitgestellt werden. Freiwillig ist das seit dem 1. Juli 2026 möglich, verbindlich wird es zum 1. November 2026; im freiwilligen Zeitfenster sind keine Sanktionen vorgesehen (Europäische Kommission, Generaldirektion Steuern und Zollunion). Gemeint sind nicht die Zolltarifnummern, sondern operative Kennungen: die vom Verkäufer oder Marktplatz vergebene Artikelkennung, die nicht standardisierte Herstellerkennung und – sofern vorhanden – eine standardisierte Kennung wie die europäische Artikelnummer oder die ISBN. Wer seinen Artikelstamm ohnehin gerade anfasst, plant dieses Feld sinnvollerweise gleich mit ein.

Zolldaten haben eine unangenehme Eigenschaft: Sie werden von mehreren Systemen gleichzeitig gebraucht, aber in unterschiedlicher Form. Die Zollanmeldung will einen codierten Datensatz, die Handelsrechnung einen lesbaren Text, der Versanddienstleister ein Etikettenformat. Wer für jeden Empfänger ein eigenes Mapping baut, pflegt am Ende drei Wahrheiten. Sinnvoll ist der umgekehrte Weg: Das ERP bleibt führendes System, die Middleware reichert Auftrags- und Positionsdaten einmal an und bedient daraus alle Empfänger. Wie ein solches Feld-Mapping methodisch aufgebaut wird, vertieft unser Beitrag zum Daten-Mapping zwischen ERP und Shop.

Wie tief die Tarifierung reichen muss, hängt vom Datensatz der Anmeldung ab. Für den reduzierten Datensatz H7 genügt der sechsstellige Code des Harmonisierten Systems, das Ursprungsland ist dort nicht vorgesehen; H6 verlangt die achtstellige Warennummer, H1 den zehnstelligen Code samt Ursprungsland und Menge (Europäische Kommission, Generaldirektion Steuern und Zollunion). Für die Übergangsabgabe ist die Zahl der Anmeldepositionen entscheidend – und die hängt direkt daran, wie fein der Artikelstamm tarifiert ist. Ein Sortiment, das pauschal auf eine Sammelnummer gelegt wurde, erzeugt scheinbar weniger Positionen, verlagert das Risiko aber in die Prüfung durch die Zollverwaltung.

Technisch ist die Anbindung überschaubar. Was Projekte tatsächlich aufhält, ist der Zustand der Stammdaten. In gewachsenen Sortimenten sind Warennummern oft vor Jahren einmal gesetzt und seitdem nicht angefasst worden; Ursprungsländer stehen als Freitext in einer Bemerkungszeile; Nettogewichte fehlen bei Artikeln, die bislang ausschließlich im Inland versendet wurden. Diese Lücken fallen im Tagesgeschäft nicht auf und werden erst sichtbar, wenn die erste Sendung an der Grenze steht.

Gerade der letzte Punkt hat betriebswirtschaftliche Wirkung: Eine hohe Retourenquote im grenzüberschreitenden Geschäft verteuert sich, weil die Abgabe je Position nicht ohne Weiteres zurückfließt. Das verschiebt die Kalkulation und macht saubere Größen-, Bild- und Beschreibungsdaten im Shop zu einem Zollthema. Wie sich Retouren prozessual sauber zwischen Shop und ERP abbilden lassen, zeigt unser Beitrag zum RMA-Prozess für Retouren zwischen Shop und ERP. Wer parallel an Verpackungs- und Produktdaten arbeitet, findet die angrenzenden Pflichten im Beitrag zu den PPWR-Verpackungsdaten aus ERP und Shop und zum digitalen Produktpass nach der Ökodesign-Verordnung.

Der Weg zu belastbaren Zolldaten führt selten über ein großes Projekt, sondern über vier überschaubare Schritte. Entscheidend ist, mit der Bestandsaufnahme zu beginnen und nicht mit der Schnittstelle: Erst wenn bekannt ist, wie viele Artikel überhaupt vollständige Zolldaten führen, lässt sich der Aufwand seriös schätzen.

Wer die Zollfelder in eine bestehende Landschaft einfügt, bereitet den Umbau sinnvollerweise in einer getrennten Umgebung vor – Anmeldedaten lassen sich schlecht im Produktivbetrieb ausprobieren. Hinweise dazu liefert unser Beitrag zu Testumgebungen und Testdaten für ERP-Schnittstellen. Und weil Zolldaten über verschlüsselte Verbindungen an Behörden und Dienstleister gehen, lohnt parallel ein Blick auf die verkürzten Laufzeiten von Zertifikaten, die unser Beitrag zu TLS-Zertifikaten mit 200 Tagen Laufzeit in ERP-Schnittstellen einordnet. Für Häuser mit SAP-Landschaft gilt dabei dieselbe Grundregel wie überall: Die Zollfelder gehören in den Materialstamm, die Anreicherung in die Middleware.