40.000 Artikel, 90 Minuten Zeit, eine Saisonpreisliste. So sieht der Alltag in vielen Magento-Shops aus, wenn der Einkauf seine Konditionen als Excel-Datei schickt und die Kampagne am Montag live gehen soll. Der Magento 2 Excel-Export gehört deshalb zu den meistgesuchten Admin-Themen im deutschen E-Commerce, und zu den am schlechtesten gelösten. Denn Adobe liefert bis heute, auch 2026 in Version 2.4.8, keinen nativen XLSX-Export. Wer Produktdaten in Excel bearbeiten will, arbeitet mit Umwegen. Die Frage ist nur, mit welchem, und wie teuer die Fehler werden, wenn er schiefgeht.
Warum kann Magento 2 von Haus aus kein Excel?
Die Antwort ist technischer Natur und älter als Magento 2 selbst. Die Import-/Export-Engine der Plattform, das Modul ImportExport, serialisiert alle Entitäten als CSV. Produktattribute, Variantenzuordnungen, Tier Prices, Lagerbestände: Alles wird zeilenweise in eine kommaseparierte Datei geschrieben, weil das Format datenbanknah, streambar und versionsstabil ist. Excel-Dateien sind das Gegenteil: ein komprimiertes XML-Konstrukt mit Formatierung, Formeln und Datentyp-Magie, die bei 50.000 Zeilen gern eigene Wege geht.
Adobe hat daran nie etwas geändert, und die Begründung ist nachvollziehbar: Magento positioniert sich als Enterprise-Plattform, deren Datenhoheit bei PIM- und ERP-Systemen liegt, nicht bei Tabellenkalkulationen. Für den Mittelständler in Deutschland, dessen Lieferantenstammdaten in einer .xlsx aus dem Jahr 2019 leben, ist das eine akademische Antwort auf ein handfestes Problem.
Der CSV-Umweg, und seine drei deutschen Stolperfallen
Der naheliegende Weg: über System → Datenübertragung → Exportieren eine Produkt-CSV ziehen, in Excel öffnen, bearbeiten, wieder als CSV speichern, zurückimportieren. Theoretisch simpel, praktisch die häufigste Ursache für zerstörte Katalogdaten, die wir in Audits sehen. Drei Fallen sind dabei spezifisch deutsch.
Erstens das Trennzeichen. Ein deutsch lokalisiertes Excel erwartet Semikola als Feldtrenner und das Komma als Dezimaltrennzeichen. Magento schreibt Kommas als Trenner und Punkte in Preisen. Öffnet man die Export-Datei per Doppelklick, zerlegt Excel die Spalten nicht, oder schlimmer, es zerlegt sie falsch und verwandelt 19,99 in ein Datum. Korrekt geht es nur über den Daten-Import-Assistenten von Excel mit explizit gesetztem Trennzeichen, und das bei jedem einzelnen Durchlauf.
Zweitens die Zeichenkodierung. Magento exportiert UTF-8 ohne BOM. Deutsche Excel-Versionen interpretieren das beim Öffnen als Windows-1252, und aus „Müller & Söhne“ wird „Müller & Söhne“. Beim Zurückspeichern als „CSV (Trennzeichen-getrennt)“ schreibt Excel erneut ANSI, und der Import bricht mit kryptischen Validierungsfehlern ab oder, schlimmer, importiert korrupte Umlaute in Produktnamen und Meta-Descriptions. Für Google sichtbar, für Kunden peinlich.
Drittens die ID-Logik. Excel „hilft“ gern: Es kürzt führende Nullen bei SKUs, wandelt EANs in Exponentialschreibweise um und interpretiert Attributwerte als Zahlen. Wer eine SKU-Spalte nicht explizit als Text formatiert, matcht beim Rückimport seine Produkte nicht mehr, und legt stattdessen tausende Dubletten an.
Der gefährlichste Satz im Katalogmanagement: „Ich hab das kurz in Excel gemacht.“ Der zweitgefährlichste: „Der Import lief doch ohne Fehlermeldung durch.“
Welche Extension löst den Excel-Import zuverlässig?
Wer Excel nicht als Notlösung, sondern als festen Prozessschritt will, kommt um eine Extension nicht herum. Drei haben sich im Markt etabliert, und sie unterscheiden sich deutlich in Philosophie und Preis.
Firebear Improved Import & Export ist der de-facto-Standard. Die Extension verarbeitet XLSX direkt, mappt Spalten per Interface auf Magento-Attribute, beherrscht Cron-basierte Jobs und zieht Dateien per SFTP, Google Sheets oder REST API. Gerade die Google-Sheets-Anbindung ist 2026 der pragmatischste Weg: Der Einkauf pflegt seine Preise im Sheet, Magento zieht sie nachts validiert in den Katalog. Kostenpunkt je nach Edition und Supportlaufzeit zwischen rund 300 und 600 Euro, angesichts eines einzigen verhinderten Preisfehlers eine triviale Investition.
Xtento Product Feed / Import-Export-Module punktet bei komplexeren Szenarien: Mehrere Lieferanten mit unterschiedlichen Formaten, XSLT-Transformationen, Anbindung an WaWis. Wer im DACH-Raum mit JTL-Wawi oder plentymarkets als Warenwirtschaft fährt, landet häufig hier, weil Xtento-Profile sich sauber in bestehende Schnittstellen-Ketten einhängen lassen.
Amasty Import/Export spielt in derselben Liga, mit etwas schlichterem Mapping, aber gutem Preis-Leistungs-Verhältnis für Shops unter 20.000 SKUs.
Gemeinsam ist allen dreien: Sie validieren vor dem Schreiben. Das klingt banal, ist aber der eigentliche Wert, ein nativer Magento-Import, der nach Zeile 8.000 abbricht, lässt den Katalog in einem halbmigrierten Zustand zurück. Die Extensions rollen im Fehlerfall zurück oder protokollieren zeilengenau, was verworfen wurde.
Was gehört bei keinem Import vergessen?
Ein Produkt in Magento ist mehr als Name, Preis, SKU. Wer Excel-basiert arbeitet, muss die Datenstruktur verstehen, sonst verschiebt er Zeilen und wundert sich über leere Varianten. Die kritischen Punkte im Überblick:
- Konfigurierbare Produkte bestehen aus Eltern- und Kindzeilen. Die Zuordnung läuft über die Spalte
configurable_variations, ein einziger falscher Pipe-Separator zerstört die Variantenmatrix. - Bilder werden als Pfad relativ zu
pub/media/importreferenziert. Excel-Dateien transportieren keine Bilder; die müssen parallel per (S)FTP auf den Server. - Multiselect-Attribute und Store Views nutzen eigene Trennzeichen und Zeilenlogik. Wer mehrere Sprachversionen pflegt, braucht eine Zeile pro Store View mit leerer SKU-Spalte.
Übersehen wird außerdem gern das Verhalten bei Verhalten: Ersetzen versus Hinzufügen/Aktualisieren. „Ersetzen“ löscht das Produkt und legt es neu an, inklusive neuer Entity-ID. Alle internen Verlinkungen, Bewertungszuordnungen und Warenkorb-Regeln, die auf der alten ID hingen, sind damit futsch. Für Preisupdates ist das nie die richtige Option.
Wann hört Excel auf, die richtige Lösung zu sein?
Ehrlichkeit gehört dazu: Excel im Prozess ist ein Symptom, keine Architektur. Drei Schwellen markieren, ab wann die Tabellenkalkulation mehr kostet als sie spart.
Ab etwa 50.000 aktiven SKUs werden sowohl die Excel-Datei als auch der Import selbst träge; Memory-Limits und PHP-Timeouts auf Serverseite machen Vollimporte zum Geduldsspiel. Ab dem zweiten Vertriebskanal, Marktplätze, B2B-Portal, zweiter Shop, entsteht die klassische Excel-Spirale: drei Dateien, vier Versionen, niemand weiß, welche der Wahrheit entspricht. Und ab dem Moment, in dem Produktdaten redaktionell angereichert werden, Texte, Attribute, Medien, Übersetzungen, gehören sie ohnehin in ein PIM.
Im DACH-Markt heißen die Antworten dann Akeneo oder Pimcore, letzteres als österreichisches System mit starker Präsenz bei deutschen Mittelständlern. Beide spielen sauber nach Magento aus und machen Excel zum reinen Lesemedium, was es immer sein sollte.
Die nüchterne Rechnung für 2026: Unter 20.000 Artikeln, einem Vertriebskanal und einem disziplinierten Team reicht Firebear plus Google Sheets völlig aus, und zwar für einen Bruchteil dessen, was eine PIM-Einführung kostet. Darüber hinaus ist jeder Euro, der in Excel-Workflows gesteckt wird, ein Euro für Umwege, die man in zwölf Monaten wieder abreißt. Wer heute seine Katalogprozesse aufbaut, sollte deshalb nicht fragen, wie Excel am besten an Magento angebunden wird, sondern wie lange er es sich noch leisten will, dass die wichtigste Datenquelle des Unternehmens eine Datei namens artikel_final_NEU_v3.xlsx ist.