Wer einen Magento-Shop übernimmt, erbt fast immer auch dessen Steuerkonfiguration – und die ist selten sauber. Veraltete Steuersätze, doppelt angelegte Tax Classes, Regeln, die niemand mehr zuordnen kann. Gerade jetzt, mit dem Magento-2-Support-Ende im Hinterkopf und laufenden Updates auf Adobe Commerce 2.4.x, lohnt ein Blick in den Steuerbereich: Fehler hier kosten nicht nur Conversion, sondern im Zweifel auch Geld bei der Betriebsprüfung.
Die Steuerlogik von Magento 2 und Adobe Commerce beruht auf drei Bausteinen: Product Tax Classes (welche Steuerart gilt für ein Produkt), Customer Tax Classes (wer kauft – Endkunde, B2B, Händler mit USt-IdNr.) und Tax Rules, die beides mit einem Steuersatz und einem Land oder einer Region verknüpfen. Erst diese Verknüpfung entscheidet, welcher Satz im Checkout gezogen wird.
Wie funktioniert die Einrichtung von Tax Classes und Tax Rules?
Der Einstieg läuft über Stores → Tax Rules im Admin-Panel. Dort legt eine Regel fest, welche Produkt- und Kundenklasse mit welchem Tax Rate kombiniert wird. Wichtig für deutsche Händler: Die Steuersätze selbst pflegt Magento unter Stores → Tax Zones and Rates – für Deutschland also 19 und 7 Prozent, dazu die reduzierten Sätze für Österreich, Frankreich und alle weiteren Lieferländer. Wer OSS-konform verkauft, braucht je EU-Land den korrekten Satz; seit der E-Commerce-Reform 2021 ist das keine Kür, sondern Pflicht.
Bei Shops mit mehreren tausend SKUs und Auslandsverkäufen wird die manuelle Pflege schnell zur Fehlerquelle. Hier hilft der Import-Export-Mechanismus: Unter System → Import/Export Tax Rates lassen sich Steuersätze als CSV einspielen und sichern. Das ist der sauberste Weg, um etwa bei einer EU-weiten Satzanpassung alle Ländersätze in einem Rutsch zu aktualisieren – statt einzeln durch die Admin-Maske zu klicken.
Warum scheitern Magento-Steuerkonfigurationen im Alltag?
Die häufigste Fehlerquelle liegt nicht im Regelwerk, sondern in der Berechnungsgrundlage. Unter Stores → Configuration → Sales → Tax entscheidet die Einstellung Tax Calculation Based On, ob Versandadresse, Rechnungsadresse oder Shop-Ursprung maßgeblich sind. Für B2C-Verkäufe in der EU ist die Versandadresse korrekt. Steht dort versehentlich „Shipping Origin“, zieht der Shop durchgehend den deutschen Satz – auch bei Lieferung nach Österreich mit 20 Prozent.
Zweiter Klassiker: Preise, die inklusive Steuer gepflegt sind, aber als Netto-Preise interpretiert werden. Die Einstellung Catalog Prices: Including Tax muss zur Datenhaltung passen. Ein Mismatch zeigt sich sofort im Warenkorb – der Gesamtbetrieb stimmt nicht mehr, die Kaufabbruchrate steigt messbar.
Ein weiterer Punkt betrifft die Anzeige: Unter Price Display Settings lässt sich festlegen, ob Katalog- und Versandpreise brutto, netto oder beides erscheinen. Für deutsche B2C-Shops ist die Brutto-Anzeige rechtlich vorgegeben. B2B-Händler mit gemischtem Publikum sollten die Kundengruppen-Funktion nutzen, statt pauschal netto zu zeigen.
Import, Export und die Grenzen von Bordmitteln
Der CSV-Import deckt Standardfälle gut ab, hat aber Lücken: Komplexe Szenarien wie mehrere Jurisdiktionen je Land, ZIP-basierte Sätze für US-Verkäufe oder automatische Satz-Updates bei Gesetzesänderungen bildet Magento nativ nicht ab. Hier setzen Extensions an – etwa Avalara AvaTax oder Vertex, die Steuersätze in Echtzeit berechnen und bei Satzänderungen automatisch nachziehen. Für reine EU-Shops mit überschaubarem Sortiment reichen die Bordmittel; wer in die USA oder nach Großbritannien expandiert, sollte den Schritt früher planen als später.
Praktischer Rat für den nächsten Wartungstermin: Exportiert die aktuellen Tax Rates als CSV, bevor ihr irgendetwas anfasst. Die Datei ist die einzige vollständige Dokumentation eurer Steuerlogik – und im Fehlerfall das schnellste Rollback. Wer parallel an einer Migration zu Adobe Commerce Cloud oder einem Shopware-Umzug arbeitet, sollte die Steuerregeln ohnehin als eigenes Workstream-Paket behandeln, nicht als Fußnote des Produktimports.