23 Steuergebiete in einem einzigen Checkout. Wer aus Deutschland in die EU verkauft und seit Juli 2021 die One-Stop-Shop-Regelung nutzt, bricht sich mit Magento 2 entweder die Finger an der Steuerkonfiguration — oder spart sich wöchentlich Stunden an manuellen Korrekturen. Der Unterschied liegt in einer Handvoll Einstellungen, die Adobe im Admin-Panel bewusst unscheinbar versteckt hat: Tax Classes, Tax Zones, Tax Rules. Wer diese drei Bausteine falsch verdrahtet, verkauft nach Polen mit 19 Prozent statt 23 — und zahlt die Differenz aus der eigenen Marge.
Die Magento 2 Steuerkonfiguration ist kein Setup-Thema für den ersten Shop-Tag, sondern eine laufende Disziplin. Steuersätze ändern sich (Österreich senkte 2020 temporär auf 16 beziehungsweise 5 Prozent), Lieferketten verschieben sich, der Fernverkauf-Schwellenwert von 10.000 Euro greift schneller als gedacht. Dieser Guide geht die komplette Kette durch: anlegen, verknüpfen, importieren, exportieren — mit dem DACH-Kontext, den die englischsprachigen Tutorials auslassen.
Was sind Tax Classes in Magento 2 — und warum fast jeder sie zu grob anlegt?
Tax Classes sind Etiketten, keine Steuersätze. Magento unterscheidet drei Arten: Product Tax Classes (was verkauft wird), Customer Tax Classes (wer kauft) und die Shipping Tax Class (wie die Lieferung besteuert wird). Ein Steuersatz entsteht erst, wenn alle drei in einer Tax Rule zusammentreffen.
Der klassische Fehler deutscher Händler: genau zwei Product Tax Classes — „Steuerpflichtige Güter 19%“ und „Ermäßigt 7%“. Das reicht für einen reinen B2C-Shop in Deutschland. Sobald aber digitale Produkte dazukommen (in der EU immer am Empfängerort besteuert, oft abweichende Sätze), Geschenkgutscheine (in Deutschland einzweck- oder mehrzweckbesteuert) oder Versandkosten mit gemischtem Warenkorb anteilig aufgeschlüsselt werden müssen, fehlt die Granularität. Der Umbau im laufenden Betrieb bedeutet: jede Produktzuordnung per Massenaktion oder Datenbank-Update anfassen.
Angelegt werden die Klassen unter Stores → Tax Rules → Add New Tax Rule über die Inline-Editoren, oder sauberer unter Stores → Tax Zones and Rates für die Sätze. Wer mehr als eine Handvoll Klassen pflegt, greift besser direkt zum CSV-Import — dazu gleich mehr.
Wie funktionieren Tax Rules und die Berechnungslogik dahinter?
Eine Tax Rule verknüpft drei Dinge: eine oder mehrere Tax Rates (Satz plus Land/Region/PLZ), Customer Tax Classes und Product Tax Classes. Die Berechnung selbst steuert Magento über Stores → Configuration → Sales → Tax — und dort sitzt die Einstellung, über die DACH-Händler am häufigsten stolpern: „Tax Calculation Method Based On“.
- Unit Price: Steuer pro Einzelartikel, dann summiert. Standard und fast immer richtig.
- Row Total: Steuer auf die Positionszeile inklusive Rabatt. Relevant bei Coupon-lastigen Shops.
- Total: Steuer auf die Gesamtsumme. Erzeugt bei mehreren Steuersätzen im Warenkorb regelmäßig Rundungsdifferenzen von einem Cent — genug, um DATEV-Exporte unruhig zu machen.
Dazu kommt die Frage, ob Katalogpreise inklusive oder exklusive Steuer gepflegt werden. Deutsche B2C-Shops arbeiten fast ausnahmslos mit Bruttopreisen („Catalog Prices: Including Tax“). B2B-Händler mit Netto-Preispflege müssen zusätzlich die „Apply Discount On Prices“-Logik prüfen — sonst berechnet Magento Rabatte auf Bruttobeträge, versteuert aber Netto, und die Buchhaltung fragt nach. Eine Minute Konfigurationsarbeit, die in Audits gerne mal vierstellige Korrekturen auslöst.
OSS und der DACH-Import: Steuersätze per CSV statt Klick-Marathon
Wer in 15 EU-Länder verkauft und jeden Satz per Hand unter Tax Zones and Rates einträgt, investiert einen Nachmittag und baut garantiert zwei Tippfehler ein. Der eingebaute CSV-Import unter System → Import/Export Tax Rates erledigt das in zwei Minuten — mit einer Datei in exakt fünf Spalten:
Code, Country, State, Zip/Post Code, Rate
Ein Beispiel: „AT-Standard“ für Österreich mit Country „AT“, State leer, Postcode „*“ und Rate „20.0000“. Für Frankreich 20 Prozent, Italien 22, Polen 23, die Niederlande 21 — die vollständige Liste hält die EU-Kommission vor, und seriöse Steuerberatungen wie Taxdoo oder hellotax liefern Import-Dateien gleich mit. Ermäßigte Sätze (Österreich 10/13 Prozent, Deutschland 7) bekommen eigene Zeilen mit eigenem Code.
Zwei Stolpersteine kennt der Import: Erstens überschreibt er nichts — doppelte Codes erzeugen Fehler oder Dubletten, je nach Version. Vor dem Re-Import also erst die alten Raten löschen, am schnellsten über die Datenbank-Tabelle tax_calculation_rate. Zweitens akzeptiert der Parser keine Semikola als Trennzeichen, auch wenn deutsche Excel-Installationen sie standardmäßig exportieren. Komma-getrennt, UTF-8, fertig.
Der Export am gleichen Ort liefert die aktuelle Konfiguration als CSV zurück — das einzige brauchbare Backup der Steuerlogik vor einem Update. Adobe Commerce-Nutzer sollten ihn vor jedem Minor-Release ziehen; die Tabelle tax_calculation (die Verknüpfung zwischen Rates, Rules und Classes) ist im Export allerdings nicht enthalten. Wer die Rules absichern will, kommt um einen Datenbank-Dump nicht herum.
Warum scheitern Cross-Border-Shops an den Versandsteuern?
Versandkosten folgen in Deutschland der sogenannten Nebenleistungsregel: Sie teilen das steuerliche Schicksal der Hauptleistung. Ein Warenkorb mit 19-Prozent- und 7-Prozent-Artikeln erfordert eine anteilige Aufteilung der Versandsteuer. Magento kann das — über die Einstellung „Tax Class for Shipping“ und die Calculation Settings — aber nur, wenn die Shipping Tax Class nicht pauschal auf „Standard“ steht.
Die sauberere Lösung im DACH-Raum: Extensions wie die von Mageplaza oder spezialisierte deutsche Steuer-Module, die die Versandsteuer dynamisch nach Warenkorb-Anteil splitten. Wer das ignoriert und alles mit 19 Prozent abrechnet, zahlt bei 7-Prozent-Warenkörben zu viel Umsatzsteuer ans Finanzamt — legal, aber verschenkte Marge. Umgekehrt (pauschal 7 Prozent) wird es im Rahmen einer Betriebsprüfung richtig unangenehm.
Adobe Commerce vs. Open Source: Wo endet die Bordwerkzeug-Steuerlogik?
Ehrlich gesagt: an genau der gleichen Stelle. Die Steuer-Engine ist in beiden Editionen identisch — Adobe Commerce bietet keinen einzigen Tax-Feature-Vorteil gegenüber Open Source. Der Unterschied sitzt woanders: Beide Editionen enden dort, wo echte Compliance anfängt. Keine automatische USt-IdNr-Prüfung über das VIES-System (nur über die Customer Group Zuordnung „valid/invalid“), keine OSS-Meldungen, keine Befreiungslisten für innergemeinschaftliche Lieferungen.
Für B2B-Shops im DACH-Raum führt deshalb kaum ein Weg an einem externen Steuerdienst vorbei. Avalara, Vertex oder die europäischen Alternativen hängen per API am Checkout, validieren VAT-IDs in Echtzeit und schreiben die korrekten Sätze zurück. Die Integration kostet je nach Anbieter einen dreistelligen Monatsbetrag — weniger als eine einzige steuerliche Nachforderung aus einem falsch konfigurierten Frankreich-Shop.
Was gehört auf die Checkliste vor dem nächsten Update?
Steuerkonfiguration ist kein Projekt mit Enddatum. Wer den Shop ernst nimmt, arbeitet vierteljährlich eine kurze Liste ab: Tax Rates exportieren und mit den aktuellen EU-Sätzen abgleichen, Stichproben-Checkout in drei Zielländern mit gemischtem Warenkorb, Prüfung der OSS-Umsätze gegen die 10.000-Euro-Schwelle — Magento führt diese Summe nicht automatisch, das bleibt Aufgabe des Warenwirtschafts- oder Buchhaltungssystems.
Und eine letzte Empfehlung aus der Praxis: Die komplette Tax-Konfiguration gehört dokumentiert. Nicht im Wiki-Schriftsatz, sondern als Export-CSV plus Screenshot der Calculation Settings im Deployment-Repository. Wenn nach dem nächsten Sicherheits-Patch der Checkout plötzlich Netto ausweist — und das passiert — ist der Unterschied zwischen zwanzig Minuten Fehlersuche und einem verlorenen Wochenende genau diese Datei.