Wer Bestellungen aus einem Onlineshop automatisch in Lexware warenwirtschaft übernehmen will, landet früher oder später bei openTRANS. Das ist ein XML-Format für Geschäftsdokumente wie Bestellungen, und Lexware bietet über den Bereich eCommerce einen Import für solche Dateien an. Auf dem Papier klingt das nach einer sauberen Lösung: Der Shop schreibt eine Datei, Lexware liest sie ein, fertig.
Wir haben zwischen März und September 2026 für einen Kunden ein WordPress-Plugin entwickelt, das Bestellungen aus WooCommerce im openTRANS-Format für Lexware warenwirtschaft premium exportiert. Dabei sind wir auf eine ganze Reihe von Problemen gestoßen. Manche ließen sich im Export lösen, einige nur mit Umwegen, und einige gar nicht, weil der Import in Lexware schlicht nicht mehr hergibt. Dieser Bericht fasst zusammen, was wir dabei gelernt haben. Er richtet sich an Shopbetreiber, die eine solche Anbindung planen, und an Entwickler, die vor derselben Aufgabe stehen.
Warum wir openTRANS gewählt haben
Den Ausschlag für openTRANS gab ein vorhandenes Plugin. Im WordPress-Verzeichnis gibt es mit „Order Export to Lexware for WooCommerce – OpenTRANS“ ein kostenloses Plugin, das genau diesen Weg geht, und aufgurnd der Rückmeldungen zu diesem Plugin nahmen wir an, dass Dritte darüber bereits Bestellungen erfolgreich in Lexware eingelesen hatten. Wir sind weiterhin davon ausgegangen, dass der Auftragsexport über openTRANS grundsätzlich funktioniert und nur noch an die Anforderungen des Kunden angepasst werden muss.
Das stimmte leider nur zum Teil. Die Dateien des Plugins lassen sich zwar importieren, ebenso solche aus unserer eigenen Implementierung, sie haben aber diverse Schwächen, die wir in den folgenden Abschnitten beschreiben. Im Quelltext der aktuellen Version 1.7.3 fehlt die Angabe zur Zahlungsart, sodass Lexware jede Bestellung als Barzahlung anzeigt. Versandkosten werden über eine Nebenleistung übergeben und hängen damit an einem passenden Namen und an einem einzigen Steuersatz. Rabatte stecken in den Stückpreisen. Ein Plugin, das Bestellungen scheinbar problemlos nach Lexware bringt, ist also kein Beleg dafür, dass die Aufträge dort auch vollständig und korrekt ankommen. Das zeigt sich erst, wenn man die importierten Aufträge Feld für Feld mit dem Shop vergleicht und plötzlich über weitere Ungereimtheiten und Ärgernisse stolpert.
Eine Spezifikation aus dem Jahr 2009
Die einzige technische Beschreibung, die Lexware für den Import veröffentlicht, ist das PDF „Spezifikation des Bestellformates (openTRANS)“. Das Dokument trägt die Versionsnummer 1.1 und den Stand 20.10.2009. Es bezieht sich auf die Lexware warenwirtschaft ab Version 9 und verweist für die Details auf den openTRANS-Standard 1.0, der aus dem Jahr 2001 stammt. Eine neuere Fassung haben wir nicht gefunden.
Das aktuelle Handbuch zu Lexware eCommerce, Ausgabe 2026, beschreibt den Import von Bestellungen über die „Standard Shopschnittstelle“ im openTRANS-Format und verspricht für den Aufbau der Importdatei eine technische Spezifikation im Anhang.
Wer daraufhin zum Anhang blättert, findet dort ein Glossar. Kurz davor beschreibt das Handbuch zwar ausführlich das XML-Format für den Artikelkatalog, also die Daten, die Lexware an den Shop übergibt. Eine Beschreibung der Importdatei für Bestellungen im openTRANS-Format sucht man dagegen im gesamten Handbuch vergeblich. Das Glossar ist allerdings auf seine Weise aufschlussreich. Unter dem Stichwort „Browser“ erfährt der Leser, die bekanntesten und populärsten Browser seien der Microsoft Internet Explorer und der Netscape Navigator. Ja wirklich …
Netscape Navigator und Internet Explorer kann man nun wahrlich nicht brandneue Software nennen und dieser Passus im Handbuch lässt zumindest erahnen, dass gewisse Punkte schon sehr lange nicht mehr angefasst und aktualisiert wurden. Zur Spezifikation von 2009 passt das Glossar zeitlich recht gut, zu einem Handbuch mit der Jahreszahl 2026 eher weniger.
Das allein wäre noch kein Problem, wenn das Dokument vollständig und korrekt wäre. Im Laufe des Projekts haben wir aber mehrfach festgestellt, dass das tatsächliche Verhalten der Software von der Beschreibung abweicht oder dass die Beschreibung Fragen offen lässt, die sich nur durch Ausprobieren klären lassen. Ein Beispiel: Laut Tabelle in der Spezifikation gilt eine Bestellung ohne Angabe zur Zahlungsart als „Rechnung“. In der Praxis zeigte Lexware in diesem Fall „Barzahlung“ an.
Das richtige Format finden
Unsere erste Version erzeugte Dateien nach openTRANS 2.1, der aktuellen Fassung des Standards. Lexware meldete beim Import lediglich, es seien keine Aufträge eingelesen worden, ohne einen Hinweis auf die Ursache. Zum Laufen brachten wir den Import erst, als wir uns an einer Exportdatei des oben genannten Plugins orientierten, die sich nachweislich in Lexware einlesen ließ, und die Struktur Element für Element nachbauten.
Dabei zeigte sich, dass Lexware eine eigene Auslegung von openTRANS 1.0 erwartet. Mehrere Bestellungen stehen entgegen dem Standard in einer gemeinsamen Datei. Ein Vermerk zum Steuergebiet (tax_area) ist Pflicht. Die Mengeneinheit muss als „1“ angegeben werden statt mit dem im Standard üblichen Code, und die Steuer wird als absoluter Betrag übergeben. Die Lieferantenadresse, die der Standard vorsieht, ignoriert Lexware vollständig. Einiges davon steht in der Spezifikation, einiges ergab sich erst aus dem Vergleich mit der funktionierenden Datei.
Zahlungsarten: angezeigt, aber nicht übernommen
In der ersten Fassung stand die Zahlungsart als freier Vermerk in der Datei. Lexware wertet diesen Vermerk nicht aus, und so erschien jede importierte Bestellung als Barzahlung, auch wenn der Kunde per PayPal bezahlt hatte. Die Spezifikation sieht dafür ein eigenes Element PAYMENT vor, in dem die Zahlungsart über Zahlencodes aus einer UN/ECE-Liste angegeben wird, etwa 10 für Rechnung, 25 für Vorkasse oder 52 für Nachnahme.
Wir haben das mit Testimporten nachgemessen. Lexware kennt genau acht Varianten. Jeder andere Code landet als „Barzahlung“ mit angehängter Codenummer. Eine Zahlungsart „Online“ oder „PayPal“ lässt sich über den Import überhaupt nicht erzeugen, deshalb mussten PayPal-Zahlungen auf „Vorkasse“ abgebildet werden.
Schwerer wiegt, was danach kam. Die korrekt übergebene Zahlungsart erscheint zwar im Importfenster, wird beim Übernehmen in den Auftrag aber nicht in das Feld für die Zahlungsart geschrieben. Sie steht anschließend nur noch als Text in der Nachbemerkung. Auf Nachfrage im Lexware-Forum bestätigte ein Lexware-Mitarbeiter dieses Verhalten mit dem Satz „Das lässt sich leider nicht ändern.“ Die Zahlungsart muss also bei jedem Auftrag von Hand gesetzt werden, egal wie sauber die Importdatei aufgebaut ist. Man fasst es nicht, denn bei fünf Aufträgen pro Tag mag das noch angehen, bei 200 ganz sicher nicht.
Versandkosten und gemischte Steuersätze
Versandkosten übergibt man laut Spezifikation als Vermerk mit dem Namen der Versandart und dem Betrag. Lexware macht daraus nur dann eine Auftragsposition, wenn in der Verwaltung eine sogenannte Nebenleistung mit exakt demselben Namen existiert. Im Shop unseres Kunden hieß die Versandart „Versandkostenpauschale“, in Lexware hieß die Nebenleistung „Versandkosten“. Die Folge war, dass der Versandbetrag nur als Text in der Nachbemerkung auftauchte und in der Auftragssumme fehlte. Eine Fehlermeldung gab es dazu nicht. Bei kostenlosem Versand erzeugte der Betrag 0,00 außerdem bei jeder Bestellung eine überflüssige Zeile in der Nachbemerkung.
Den Namen konnten wir im Plugin über eine Zuordnungstabelle anpassen. Ein anderes Problem ließ sich auf diesem Weg nicht lösen: Eine Nebenleistung bekommt ihren Steuersatz aus ihrer Kontoeinstellung in Lexware. Im Sortiment des Kunden gibt es Waren mit 7 Prozent und Waren mit 19 Prozent Umsatzsteuer. Enthält ein Warenkorb beides, müssen die Versandkosten anteilig auf beide Steuersätze aufgeteilt werden, und das kann eine einzelne Nebenleistung nicht abbilden. Den Weg über die Nebenleistung haben wir deshalb aufgegeben.
Die Versandkosten werden jetzt wie gewöhnliche Artikel importiert. In Lexware sind dafür zwei Stammartikel angelegt, „V7“ für den Versandanteil mit 7 Prozent und „V19“ für den Anteil mit 19 Prozent. Das Plugin schreibt für jeden Steuersatz, der in den Versandkosten einer Bestellung vorkommt, eine eigene Position mit der passenden Artikelnummer und dem Nettobetrag in die Datei. Den Preis aus dem Artikelstamm überschreibt Lexware dabei mit dem importierten Betrag, sodass die Artikel selbst keinen festen Preis brauchen. Bei einem gemischten Testauftrag mit 7,95 Euro Versandkosten kamen so zwei Positionen an, 5,11 Euro netto zu 19 Prozent und 2,84 Euro netto zu 7 Prozent, passend zum Verhältnis der Warenwerte. Summe und Steuer stimmten mit dem Shop überein.
Eine Voraussetzung dafür liegt im Shop. WooCommerce berechnet bei einem gemischten Warenkorb die gesamten Versandkosten mit 19 Prozent, eine anteilige Aufteilung ist dort ohne Erweiterung nicht einstellbar. Diese Aufteilung liefert erst das Plugin Germanized mit der Einstellung für eine aufgeteilte Steuerberechnung bei Versandkosten und Gebühren. Außerdem muss die Versandart im Shop als steuerpflichtig eingestellt sein, sonst gibt es keine Versandsteuer, die sich aufteilen ließe. Die Lösung funktioniert zuverlässig, ist aber in der Spezifikation nicht vorgesehen, und man muss sie sich selbst zusammensuchen.
Nur Stammartikel, keine Feldzuordnung
Lexware übernimmt ausschließlich Positionen, deren Artikelnummer als Stammartikel angelegt ist. Findet der Import zu einer Nummer keinen Artikel, bricht er das Anlegen des Auftrags ab. Eine Möglichkeit, im Importdialog Felder oder Artikelnummern umzuschlüsseln, gibt es in der Warenwirtschaft selbst nicht. Die Zuordnung ist fest verdrahtet. Wer Artikelnummern im Shop anders führt als in Lexware, muss das vor dem Import lösen, entweder im Exportprogramm oder mit einem zusätzlichen Werkzeug eines Drittanbieters. Wir haben das Problem an der Quelle gelöst: Eine eigene Software überträgt die Artikeldaten aus Lexware in den Shop und verwendet dabei die Lexware-Artikelnummern, sodass beide Systeme mit denselben Nummern arbeiten. Dann klappt es problemlos.
Rabatte kennt das Format nicht
In der Spezifikation gibt es kein Element für Rabatte oder Gutscheine. In unserer ersten Lösung haben wir den Rabatt deshalb in die Stückpreise eingerechnet und zusätzlich als Text in der Nachbemerkung vermerkt. Das führte zu Abweichungen. Lexware kennt den regulären Preis aus dem Artikelstamm, vergleicht ihn mit dem übergebenen Preis und errechnet daraus eigene Rabattwerte, die weder netto noch brutto zum Shop passten. Dazu kamen Rundungsdifferenzen: Elf Stück zu einem gerundeten Stückpreis von 24,33 Euro ergeben 267,63 Euro, im Shop standen für dieselbe Position 267,61 Euro.
Die Spezifikation räumt Rundungsfehler bei der Umrechnung zwischen Netto- und Bruttopreisen selbst ein. Im Beispiel des Dokuments wird aus einem Bruttoauftrag über 115,00 Euro nach dem Import ein Rechnungsbetrag von 114,99 Euro, mit dem Hinweis, dass der Betrag eigentlich 115,00 lauten müsste. Eine Lösung bietet das Dokument dafür nicht an, es ist allerdings steuerlich auch nicht relevant, da solche Rundungsfehler passieren können, das weiß auch das Finanzamt.
Der Weg, den Anwender im Lexware-Umfeld für Rabatte beschreiben, ist ein eigener Rabattartikel mit negativer Menge. Ein negativer Preis ist dabei keine gute Idee, denn in einem Forenbeitrag von 2025 wird berichtet, dass Lexware Rechnungen mit negativen Positionspreisen nicht als E-Rechnung im ZUGFeRD-Format versendet. Wir haben das Plugin entsprechend umgebaut: Artikel werden zum regulären Preis übergeben, der Rabatt folgt je Steuersatz als eigene Position mit der Menge -1. Ob der openTRANS-Import eine negative Menge in jedem Fall sauber übernimmt, ist nirgends dokumentiert. Zum Zeitpunkt dieses Artikels steht der Test im laufenden Betrieb noch aus.
Adressen: Hausnummer und Kundenzuordnung
Lexware warenwirtschaft führt Straße und Hausnummer in getrennten Feldern. Die Importspezifikation kennt für die Adresse aber nur ein Feld STREET, und auch openTRANS 1.0 selbst hat kein Element für die Hausnummer. Straße und Hausnummer kommen also zwangsläufig gemeinsam in einem Feld an. Eine automatische Trennung beim Import, wie sie gelegentlich behauptet wird, konnten wir weder in der Praxis beobachten noch in einer Dokumentation belegt finden. Wer die Hausnummer im eigenen Feld haben will, trennt sie nach dem Import von Hand.
Auch die Zuordnung zu einem Kunden ist Handarbeit. Beim Import wählt der Bearbeiter aus, ob die Bestellung einem vorhandenen Kunden zugeordnet oder ein neuer Kunde angelegt wird. Die E-Mail-Adresse aus der Bestellung hilft dabei als Suchbegriff, eine automatische Zuordnung löst sie nicht aus.
Einige weitere Einschränkungen haben wir nicht selbst nachgemessen, sie stehen aber in der Zuordnungstabelle der Spezifikation. Laut Spezifikation füllt der Import bei einem vorhandenen Kunden nur Stammdatenfelder, die noch leer sind, und überschreibt nie etwas. Zieht ein Stammkunde um und bestellt mit neuer Adresse, bliebe in den Kundenstammdaten demnach die alte Anschrift stehen. Das Länderkürzel aus der Datei wird laut Tabelle nicht umgesetzt, aus „DE“ wird also nicht „Deutschland“. Bei der Lieferadresse stehen hinter E-Mail-Adresse, Telefon und Fax jeweils die Worte „Wird nicht übernommen“. Und fehlt die Lieferadresse in der Datei, legt Lexware der Spezifikation zufolge keine an und verwendet dafür auch nicht die Rechnungsadresse.
Wo zusätzliche Informationen landen
Viele Shops sammeln im Bestellprozess Angaben, die im Auftrag sichtbar sein sollen, zum Beispiel eine Ausführung oder einen Sonderwunsch, den der Kunde für einen einzelnen Artikel auswählt. openTRANS sieht dafür Vermerke direkt an der einzelnen Position vor. Lexware zeigt diese Vermerke nach dem Import nirgends an. Der einzige Ort, an dem freier Text zuverlässig ankommt, ist die Nachbemerkung des Auftrags, also der Textblock unter der Positionsliste. Dort sammeln sich deshalb Kundenkommentar, Positionsangaben, Zahlungsart und Rabatthinweise.
Dabei gäbe es einen passenderen Platz. Sowohl im Importfenster als auch im fertigen Auftrag hat Lexware ein Feld „Auftragsinformationen“. Befüllen lässt es sich über den Import nicht, die Spezifikation nennt kein Element dafür. Welchen Zweck das Feld im Importfenster haben soll, wenn es dort grundsätzlich leer bleibt, konnten wir nicht herausfinden, und eine Erklärung dazu haben wir auch in den Handbüchern nicht gefunden. Der Support reagiert auf Fragen zugeknöpft.
Was am Ende Handarbeit bleibt
Nach allen Anpassungen am Export funktioniert die Übergabe von Artikeln, Preisen, Steuersätzen und Versandkosten zuverlässig. Bei jedem einzelnen Auftrag bleiben in Lexware trotzdem mehrere Handgriffe übrig: den Kunden zuordnen oder anlegen, die Zahlungsart setzen, bei Bedarf die Hausnummer aus dem Straßenfeld lösen und den Auftrag übernehmen. Bei einer Handvoll Bestellungen am Tag ist das zu bewältigen. Am Exportformat liegt dieser Aufwand nicht, die Grenzen setzt der Import in Lexware. Wer höhere Stückzahlen hat, muss die Handarbeit entweder in seine Planung einrechnen oder auf die kostenpflichtigen Anbindungen der Lexware-Partner und anderer Anbieter zurückgreifen. Diese Lösungen sind nicht billig, und für kleine Shops mit wenigen Bestellungen rechnen sie sich nach unserer Einschätzung kaum. Andererseits ist gerade in kleinen Betrieben die Zeit oft knapper als das Geld, und dann kann ein solches Angebot trotz des Preises die bessere Wahl sein.
Einordnung
Der openTRANS-Import wirkt wie eine Funktion, die vor langer Zeit eingebaut und seitdem kaum weiterentwickelt wurde. Die Dokumentation ist 17 Jahre alt, Abweichungen zwischen Beschreibung und Verhalten werden nicht korrigiert, und auf Nachfrage heißt es, bestimmte Dinge ließen sich nicht ändern. Gleichzeitig gibt es einen Markt von Drittanbietern, die Anbindungen zwischen Shopsystemen und Lexware verkaufen. Lexware selbst verweist auf seiner Website für die Shopanbindung an einen Partner. Solche Anbindungen holen die Bestellungen direkt aus dem Shop, und laut den Produktbeschreibungen gehören automatische Kundenanlage und die Zuordnung von Zahlungsarten zum Funktionsumfang. Das sind ziemlich genau die Punkte, an denen der eingebaute Import scheitert. Auch in Foren wird Shopbetreibern mit Importproblemen zu solchen Lösungen geraten. Anzumerken ist an dieser Stelle, dass manche der teilweise recht teuren externen Lösungen ebenfalls mit Problemen zu kämpfen haben, beispielsweise funktioniert ein Tool, das Aufträge per csv importiert, nur dann, wenn in der csv die Lexware-Kundennummer übergeben wird, und die hat man üblicherweise im Webshop nicht.
Aus unserer Sicht liegt die Vermutung nahe, dass Lexware wenig Interesse daran hat, die eingebaute Schnittstelle so weit zu verbessern, dass diese Dienstleistungen überflüssig würden. Belegen lässt sich das selbstverständlich nicht, und es mag auch schlicht an fehlenden Ressourcen für ein Randthema liegen, aber für uns bleibt ein Geschmäckle, zumal die eCommerce-Schnittstelle ausdrücklich beworben wird und im Handbuch steht.
Im Lexware-Shop steht bei Lexware warenwirtschaft pro und premium in der Liste der Funktionen eine „Offene Standard-Shop-Schnittstelle zwischen eigenem Webshop und Lexware warenwirtschaft“. Das Handbuch betont außerdem, dass Lexware eCommerce im Leistungsumfang der Warenwirtschaft enthalten ist. Wer das liest, geht verständlicherweise davon aus, dass sich ein beliebiger Webshop über einen offenen Standard an die Warenwirtschaft anbinden lässt und die Bestellungen dort vollständig ankommen. Nach unseren Erfahrungen trifft das nur eingeschränkt zu. Die Schnittstelle beruht auf einer Spezifikation von 2009, die im Handbuch versprochene technische Beschreibung fehlt, die Zahlungsart geht beim Übernehmen verloren, und Kundenzuordnung sowie Adresskorrekturen bleiben Handarbeit. Für die eigentliche Shopanbindung verweist Lexware auf seiner Website dann an einen kostenpflichtigen Partner. Diese Werbung ist unserer Meinung nach fast schon irreführend zu nennen.
Für Anwender ist das Ergebnis dasselbe: Die kostenlose Schnittstelle trägt nur ein Stück weit, und für den Rest zahlt man mit Handarbeit oder mit einem Zusatzprodukt.
Fazit
Eine Anbindung von WooCommerce an Lexware warenwirtschaft über openTRANS ist machbar und spart gegenüber dem Abtippen von Bestellungen viel Zeit. Man sollte allerdings nicht erwarten, dass die Spezifikation das Verhalten der Software vollständig beschreibt. Jede Annahme über den Import muss mit echten Testaufträgen geprüft werden, und einige Grenzen lassen sich mit keinem Export der Welt umgehen, weil Lexware die Daten beim Übernehmen verwirft oder gar nicht erst einliest. Wer eine solche Anbindung plant, sollte vorher klären, welche Angaben im Auftrag wirklich automatisch ankommen müssen und welche Handgriffe pro Bestellung akzeptabel sind.
Wenn Sie vor einer ähnlichen Aufgabe stehen und wissen möchten, was in Ihrem Fall möglich ist, sprechen Sie uns gerne an.
Quellen
Lexware: „Spezifikation des Bestellformates (openTRANS)“, Version 1.1, Stand 20.10.2009. https://download.lexware.de/pub/portal/service/Spezifikation%20des%20Bestellformates%20(openTRANS)%20pro.pdf
Lexware: „Benutzerhandbuch Lexware eCommerce für Lexware warenwirtschaft“, Ausgabe 2026. https://www.lexware.de/fileadmin/support/handbuecher/2026/handbuch_ecommerce_pro.pdf
openTRANS-Spezifikation Version 1.0, 7.9.2001. http://www.lutzgruppe.de/pdfform/openTRANS_V1_0.pdf
WordPress.org: „Order Export to Lexware for WooCommerce – OpenTRANS“, Version 1.7.3. https://wordpress.org/plugins/order-export-to-lexware-opentrans-for-woocommerce/
vendidero: „Steuerberechnung für Versandkosten und Gebühren“, Dokumentation zu Germanized für WooCommerce. https://vendidero.de/doc/woocommerce-germanized/steuerberechnung-fuer-versandkosten-und-gebuehren
lex-forum.net: „Rabatte als gesonderte Position/Artikel auf Rechnung“, April/Mai 2025. https://lex-forum.net/t/rabatte-als-gesonderte-position-artikel-auf-rechnung/18650
lex-forum.net: „eRechnungs-Versand mit Negativ-Positionen“, März 2025. https://lex-forum.net/t/erechnungs-versand-mit-negativ-positionen/18346
lex-blog.de: „Lexware warenwirtschaft pro / premium 2023 – Neuerungen“, 6. November 2022 (Hausnummernfeld). https://lex-blog.de/2022/11/06/lexware-warenwirtschaft-pro-premium-2023/
Shopware Community Forum: „Wie importiere ich Kunden von Shopware nach Lexware?“. https://forum.shopware.com/t/wie-importiere-ich-kunden-von-shopware-nach-lexware/101684
Lexware-Shop: „Lexware warenwirtschaft premium“, Produktseite mit Funktionsliste. https://shop.lexware.de/lexware-warenwirtschaft-premium
Lexware: „sync4: Schnittstelle zu Ihrem Online-Shop“. https://www.lexware.de/sync4/