Operations & WaWi · 9 min
JTL Shopify Anbindung 2026: Connector vs. Custom-Lösung
JTL-Wawi + Shopify 2026: Was der Standard-Connector kann, wo er versagt (B2B-Preise, Multi-Lager, Sammelrechnung) und wann eine eigene Middleware günstiger ist.
JTL + Shopify ist der DACH-Standard-Stack — mit konkreten Grenzen
Für Shops mit irgendetwas jenseits einfacher Abläufe stößt der Standard-JTL-Shopify-Connector aber an Grenzen, die innerhalb der JTL-Community bekannt sind, aber selten auftauchen, bevor ein Projekt mittendrin steckt. Dieser Artikel kartiert, wo der Connector dich abdeckt, wo die offiziellen Add-ons helfen, und wo die realistische Antwort ein Stück Custom-Middleware ist, das zwischen den beiden Systemen sitzt und genau den Sonderfall abbildet, den dein Geschäft braucht.
Was der Standard-JTL-Shopify-Connector leistet
- Artikelstammdaten — Produkte, Varianten, Beschreibungen, Bilder, Kategorien, Grundpreise.
- Bestände — Lagerbestand pro SKU, synchronisiert im geplanten Intervall (nicht in Echtzeit).
- Bestellungen — Bestellungen fließen aus Shopify in JTL-Wawi zur Kommissionierung, zum Packen und zur Rechnungsstellung.
- Kunden — Kundenstammdaten, mit den unten genannten Einschränkungen.
- Basispreislisten — Katalogpreis; ein Standardpreis je Artikel.
- Bestellstatus — sobald JTL versendet, fließen Status und Tracking zurück nach Shopify.
Für einen Einzellager-, überwiegend-B2C-, Einzelpreislisten-Betrieb deckt das etwa 80 % der operativen Arbeit ab. Der Connector ist im JTL-Ökosystem gut dokumentiert und für die meisten mittelgroßen DACH-Shops die richtige Wahl. Die 20-%-Lücke ist das Thema des Rests dieses Artikels.
Wo der Connector an seine Grenzen kommt
Kundenspezifische B2B-Preise. JTL-Wawi verwaltet Kundenpreisstufen nativ im Back Office. Der Standard-Shopify-Connector schiebt diese Pro-Kunde-Preise aber nicht im Maßstab in Shopify-B2B-Kataloge. Shops mit mehr als ~20 verhandelten B2B-Preislisten pflegen die Kataloge in Shopify am Ende manuell oder bauen eine eigene Preissynchronisations-Schicht.
Mehrlager-Bestandsverteilung. JTL kann Multi-Lager-Fulfillment gut. Shopify-Standorte funktionieren auch. Aber die Routing-Logik — „diese Bestellung aus Lager A, wenn der Artikel dort verfügbar ist, sonst Lager B, mit diesen regionalen Prioritäten" — wird vom reinen Bestands-Sync selten sauber abgedeckt. Der Connector synchronisiert typischerweise aggregierten Bestand, nicht pro Standort.
Sammelrechnung für B2B. JTL-Wawi kann Sammelrechnungen nativ erzeugen. Aber die Orchestrierung — welche Shopify-Bestellungen in welche Sammelrechnung kommen, wann die Periode geschlossen wird, wie die fertige Rechnung zum Kunden gelangt — ist operativer Kitt, den der Connector nicht mitliefert.
Variantenattribute / Merkmale-Mapping. JTLs Merkmale lassen sich ohne explizite Konfiguration nicht 1:1 auf Shopify-Metafelder mappen. Für Shops mit reicher Attribut-Taxonomie (Fashion, Technik) wird das zur Pflegelast.
Echtzeit-Bestand für schnelldrehende SKUs. Geplanter Sync (typischerweise alle paar Minuten) reicht für die meisten Shops. Shops, die schnelldrehende SKUs gleichzeitig über Shopify + stationären Handel + Marktplätze verkaufen, laufen in Oversells, die geplanter Sync nicht verhindern kann.
Custom-Workflows in Rechnungsstellung oder Compliance. Die B2B-E-Rechnungspflicht ab 2027 erfordert XRechnung/ZUGFeRD-Ausgabe. JTL erzeugt das Format, aber die Trigger-Logik (welche Shopify-Bestellung braucht strukturierte Ausgabe, welche nicht) liegt an der Schnittstelle, die der Connector nicht nativ besitzt.
Drei Wege, wenn der Connector nicht reicht
1. JTL-Connector + kostenpflichtige Add-ons / Partner-Connectoren. Ein kleines Ökosystem von JTL-Servicepartner-Connectoren (etwa für B2B-Preislisten, Multi-Lager-Logik) erweitert den Standard. Geringeres Risiko, aber du stapelst Anbieter und addierst Monatsgebühren — und die Add-ons decken selten genau den Sonderfall deines Betriebs ab.
2. Workflow aus Shopify in JTL verlagern. Rechnungen in JTL stellen (nicht in Shopify), B2B-Portal-Logik im JTL-Shop statt in Shopify abbilden, etc. Funktioniert für Shops, in denen Shopify im Wesentlichen ein B2C-Frontend ist. Funktioniert nicht, wenn Shopify B2B die strategische Fläche ist — dann führst du wieder zwei Storefronts.
3. Custom-Middleware zwischen JTL und Shopify. Ein Stück Code, das zwischen den beiden Systemen sitzt und genau die Transformationen abbildet, die dein Geschäft braucht: kundenspezifische Preissynchronisation, Pro-Standort-Bestand, Sammelrechnungs-Orchestrierung, strukturierte Rechnungs-Trigger. Festpreis-Custom-Entwicklung, Quellcode gehört dir, keine Per-Order-Gebühren danach.
Welcher Weg richtig ist, hängt davon ab, welche Grenzen du triffst. Für eine oder zwei punktuelle Lücken sind Partner-Connectoren meist die richtige Wahl. Bei drei oder mehr — oder bei einer einzigen, tief geschäftsspezifischen Lücke — amortisiert sich Custom-Middleware schnell.
Wie Custom-JTL-Shopify-Middleware aussieht
Kundenspezifische B2B-Preissynchronisation. Preislisten aus JTL-Wawi lesen, in Shopify-B2B-Kataloge (oder als kundenbezogene Preis-Overrides) pushen, bei JTL-Änderungen synchron halten. Oft der größte einzelne Hebel für DACH-Großhandels-Shops.
Pro-Standort-Bestand mit Routing-Logik. Bestand pro JTL-Lager ziehen, in Shopify pro Standort ausweisen und Routing-Regeln anwenden (regionale Priorität, Fallback-Lager). Löst das Oversell-Problem und die „aus dem nächsten Lager versenden"-Anforderung in einem Zug.
Trigger für strukturierte Rechnungen. Erkennen, welche Shopify-Bestellungen XRechnung/ZUGFeRD-Ausgabe brauchen (B2B mit deutschem Empfänger, gültige USt-IdNr), passende Metadaten an JTL übergeben, sodass JTL das richtige strukturierte Format erzeugt, und Ergebnis in den Bestelldatensatz zurückschreiben. Setzt die Wachstumschancengesetz-Anforderung sauber auf.
Sammelrechnungs-Orchestrierung. Shopify-Bestellungen in Perioden-Buckets je B2B-Kunde gruppieren, am Periodenende Sammelrechnung in JTL anstoßen und die fertige Rechnung (mit Archivierung) an den Kunden zurückspielen.
Varianten-/Merkmale-Mapping. Expliziter Mapping-Layer zwischen JTL-Merkmalen und Shopify-Metafeldern, mit Bulk-Import-Flows, damit die Attribut-Taxonomie zwischen beiden Systemen nicht auseinanderläuft.
Nichts davon ist ein JTL-Ersatz oder ein Shopify-Neubau — es sind chirurgische Kitt-Stellen, die genau die operative Realität abbilden, die der Standard-Connector nicht trifft.
Kostenmodell: Wann sich Custom-Middleware rechnet
Stack-Ansatz (JTL-Connector + 2–3 Partner-Add-ons + manuelle Operations): typischerweise 350–900 €/Monat an Connector- und Partner-App-Gebühren, plus 5–15 Stunden/Monat manueller Back-Office-Arbeit für die Fälle, die die Connectoren nicht abdecken. Auf das Jahr inkl. Personalkosten: 8–20 Tsd €/Jahr.
Custom-Middleware für denselben Umfang (Preissync + Multi-Lager + Trigger für strukturierte Rechnungen + Sammelrechnung): typischerweise 12–28 Tsd € als Festpreis. Hosting und kleine Wartung danach: 60–180 €/Monat. Der Break-Even gegen den Stack-Ansatz liegt in 18–24 Monaten, und ab Jahr zwei wächst die Ersparnis weiter, weil Connector-Add-ons weiter Gebühren addieren und die manuellen Stunden nicht verschwinden.
Die Entscheidung ist im Kern keine Technologiefrage — sie ist eine Frage, wie operativ kritisch die konkrete Lücke ist. Wenn dein Team wöchentlich denselben Schmerz patcht, ist Middleware die richtige Wahl. Wenn der Connector dich mit ein, zwei manuellen Workarounds pro Monat abdeckt, reicht der Stack. Die meisten Shops merken innerhalb von sechs Monaten echten Betriebs auf JTL + Shopify, wozu sie gehören.
FAQ
Häufige Fragen
Was deckt der Standard-JTL-Shopify-Connector ab?+
Artikelstammdaten, Varianten, Grundpreise, Bestände (aggregiert, geplanter Sync), Bestellungen aus Shopify in JTL-Wawi, Kundenstammdaten und Bestellstatus-Updates zurück nach Shopify. Für die meisten mittelgroßen DACH-Shops mit einem Lager und einer Preisliste ist er die richtige Wahl. Nativ nicht abgedeckt: kundenspezifische B2B-Preise im Maßstab, Pro-Standort-Bestandsrouting, Sammelrechnungen und Trigger für strukturierte Rechnungen.
Wann brauche ich Custom-JTL-Shopify-Middleware statt des Standard-Connectors?+
Wenn du auf drei oder mehr operative Lücken stößt, die der Connector nicht abdeckt — oder auf eine einzige, tief geschäftsspezifische Lücke, die du wöchentlich manuell patchst. Typische Auslöser: 50+ verhandelte B2B-Preislisten, Multi-Lager-Fulfillment mit Routing-Regeln, regelmäßige Sammelrechnungen oder die ab 2027 greifende strukturierte B2B-E-Rechnungspflicht.
Kann JTL-Wawi die B2B-E-Rechnungspflicht (XRechnung/ZUGFeRD) erfüllen?+
Ja. JTL-Wawi kann XRechnung- und ZUGFeRD-konforme Rechnungen nativ erzeugen. Die Hürde ist die Trigger-Logik — zu erkennen, welche Shopify-Bestellungen strukturierte Ausgabe brauchen, und die richtigen Metadaten an JTL zu übergeben. Genau dieser Trigger sitzt an der Schnittstelle zwischen Shopify und JTL und ist einer der häufigsten Gründe, warum für die 2027er-Frist Custom-Middleware gebaut wird.
Was kostet eine individuelle JTL-Shopify-Integration?+
Ein typischer Middleware-Umfang (Preissync + Pro-Standort-Bestand + Trigger für strukturierte Rechnungen + Sammelrechnung) liegt als Festpreis-Build bei 12–28 Tsd €, danach 60–180 €/Monat für Hosting und Wartung. Für Shops ab 1.500 Bestellungen/Monat mit aktiven operativen Lücken liegt der Break-Even gegenüber Connector-Add-ons und manuellen Stunden typischerweise in 18–24 Monaten.
Kann ich JTL-Wawi + Shopify ganz ohne Connector betreiben?+
Technisch ja — beide Systeme haben APIs. Operativ nein, außer du hast sehr geringes Bestellvolumen oder einen Entwickler im Team: Manuelle Bestellungseingabe in JTL skaliert nicht über wenige Bestellungen pro Tag hinaus, und Bestandsabweichungen zwischen den Systemen führen zu Oversells. Der Standard-JTL-Shopify-Connector ist der Default-Startpunkt für jedes echte Volumen; Custom-Middleware erweitert ihn, ersetzt ihn nicht.