Subiekt GT und nexo PRO mit E-Commerce integrieren: So automatisieren Sie Ihren Handel

Subiekt GT und nexo PRO E-Commerce Integration scheitert selten an der ersten Verbindung. Meist scheitert sie an einer falschen Architekturentscheidung. Wer Shop, Marktplätze oder B2B-Logik anbinden will, kauft keinen bloßen Datentransfer, sondern ein Betriebsmodell für Preise, Bestand, Aufträge und Fehlerfälle. Die eigentliche Entscheidung fällt deshalb nicht bei Plugin oder API, sondern bei der Frage, wie viele Kanäle, wie viel Preislogik und wie viele Ausnahmen das Setup nach dem Go-live tragen muss. Für einfache Abläufe kann Subiekt GT reichen. Sobald Mehrkanal, Varianten oder kundenspezifische Preise dazukommen, wird eine billige Kopplung schnell zum Dauerprovisorium. nexo PRO ist dann oft die robustere Basis, aber nicht in jedem Bestandssystem automatisch die wirtschaftlichste Wahl.

Wann Subiekt GT reicht und wann Middleware oder nexo PRO die bessere Wahl ist

Viele Teams behandeln die Shop-Anbindung wie ein reines Verbindungsproblem. Genau dort beginnt der Fehler. Verbinden lässt sich fast alles. Entscheidend ist, welches System bei Preisen, Bestand, Kunden und Belegstatus führt und was passiert, wenn diese Daten fachlich nicht deckungsgleich sind.

Ein schlanker Konnektor reicht, wenn die Lage wirklich einfach ist: ein Shop, ein Lager, Standardpreise, keine komplizierten Varianten, keine B2B-Sonderlogik. In so einem Setup kann das ERP die führende Quelle für Artikel, Preise und Verfügbarkeit sein, während der Shop primär Bestellungen annimmt und Inhalte ausspielt.

Ab dem zweiten Kanal kippt die Rechnung oft. Dann müssen Status übersetzt, Dubletten verhindert, Preisregeln je Kanal kontrolliert und Fehler reproduzierbar verarbeitet werden. Middleware ist in solchen Setups keine Komfortschicht, sondern Schadensbegrenzung. Wer sie aus Kostengründen streicht, verschiebt Aufwand nur in den Betrieb.

nexo PRO wird vor allem dann interessant, wenn E-Commerce nicht bei einem einzelnen Shop stehenbleibt. Der Unterschied zeigt sich nicht in der Demo, sondern bei Änderungen: neue Preislogik, zusätzliche Felder, weitere Kanäle, geänderte Variantenstruktur. In einer sauberen Architektur wird das an einer Stelle angepasst. In einer Kette aus Plugin, Skript und manueller Korrektur verteilt sich derselbe Eingriff über mehrere Systeme.

Subiekt GT bleibt trotzdem wirtschaftlich, wenn die bestehende Umgebung stabil ist und die Prozesse diszipliniert geführt werden. Ein neues Shopsystem allein ist kein Grund für einen ERP-Wechsel. Kritisch wird es erst, wenn GT dauerhaft umgangen werden muss: Zusatzskripte für Varianten, manuelle Preisnacharbeit, wiederkehrende Bestandskorrekturen oder Sonderlogik für Aufträge. Dann bezahlen Sie nicht mehr für Integration, sondern für das Umfahren struktureller Grenzen.

In Mehrkanal-Projekten taucht ein Muster immer wieder auf: Der günstige Einstieg wirkt im Einkauf vernünftig, weil der erste Shop schnell online geht. Einige Monate später landen Preisabweichungen, Teilversandfälle und Bestandskonflikte im Backoffice, weil die Kopplung nur Standardfälle sauber abbildet. Genau dort wird aus einer kleinen Anfangsinvestition ein dauerhaftes Betriebsproblem.

Wer heute schon weiß, dass Marktplätze, B2B-Portale oder ein zweiter Shop folgen, sollte die Entscheidung nicht nach dem ersten Monat treffen. Eine Integration, die nur den Erstimport sauber beherrscht, ist operativ wenig wert. Relevant ist, wie sich das Setup bei Rücksendungen, Preisänderungen, Teillieferungen und fehlerhaften Webhooks verhält. Dort trennt sich eine tragfähige Lösung von einer Demo.

So muss die Integrationsarchitektur für Shop und ERP aufgebaut sein

Die wichtigste Regel ist banal und wird trotzdem ständig verletzt: Jedes kritische Feld braucht genau ein führendes System. Ohne diese Festlegung entstehen Konflikte, die später als Synchronisationsfehler erscheinen, in Wahrheit aber Modellierungsfehler sind.

Für die meisten Setups ist die Aufteilung klar. Das ERP führt kaufmännische Stammdaten wie SKU, EAN, Einheit, Steuerkennzeichen, Basispreise, Preislisten, Lagerbezug und Kundentyp. Der Shop oder ein PIM führt Langtexte, Bilder, Kategoriesortierung und SEO-Felder. Wer diese Ebenen vermischt, baut sich unnötige Konflikte in den Alltag. Mehr zu solchen Schnittstellenmustern findet sich auch im Bereich Integrationen und APIs.

Beim Bestand zählt nicht der physische Lagerwert, sondern die verfügbare Menge. Das ist kein sprachliches Detail, sondern eine fachliche Grenze. Wenn Reservierungen, Sicherheitsbestand oder freigegebene Zuläufe fehlen, verkauft der Shop Bestände, die operativ nicht verfügbar sind.

verfügbar = physischer Bestand - Reservierungen - Sicherheitsbestand + freigegebene Zuläufe

Genau hier scheitern viele billige Anbindungen. Sie übertragen Rohbestand, weil das technisch leicht ist. Fachlich ist das falsch.

Varianten sind der zweite klassische Bruchpunkt. Im Shop existieren Eltern-Kind-Strukturen mit Attributen, Bildern und Sichtbarkeit. Im ERP zählt die verkaufbare Position. Jede verkaufbare Variante braucht deshalb einen eindeutigen, systemübergreifenden Schlüssel. Wenn Größe oder Farbe im Shop separat verkauft wird, im ERP aber nur ein Sammelartikel existiert, ist der Bestandsabgleich schon vor dem Start unzuverlässig.

Bei Preisen reicht ein einzelnes Feld ebenfalls nicht. Relevant sind Netto oder Brutto, Steuerklasse, Währung, Rundung, Aktionslogik und Kundengruppe. In B2B-Setups sollte die Preisquelle fast immer im ERP liegen. Zwei gleichberechtigte Preisquellen klingen flexibel, produzieren aber regelmäßig falsche Aufträge.

Kurz gesagt: Zwei Preisquellen sind kein Feature.

Der Auftragsfluss muss hart definiert sein: Shop sendet Auftrag mit externer Bestellnummer, die Integration prüft Idempotenz, das ERP legt den Beleg an, kundenrelevante Status gehen zurück. Nicht jede interne ERP-Stufe gehört in den Shop. Kunden brauchen Klarheit, keine Abbildung interner Prozessschritte.

Shop: bezahlt -> ERP: Auftrag anlegen, Zahlung vormerken
ERP: versendet -> Shop: versandt
ERP: teilweise versendet -> Shop: nur zurückschreiben, wenn Teilversand sauber unterstützt wird
Shop: storniert -> nur automatisch, solange noch kein Folgebeleg existiert

Für die technische Umsetzung lohnt ein Blick in die offiziellen Quellen von InsERT, etwa zu Subiekt GT und Subiekt nexo PRO. Dort wird schnell sichtbar, welche Erweiterungswege vorgesehen sind und wo Zusatzlogik außerhalb des ERP nötig wird.

Datenfluss, Warteschlangen und Wiederholungen sauber planen

Eine belastbare Subiekt GT Shop Anbindung oder ein nexo-PRO-Setup braucht nicht nur Feldmapping, sondern auch einen kontrollierten Transportweg. Bestellungen, Bestandsupdates und Preisänderungen sollten nicht als lose Einzelaufrufe ohne Protokollierung laufen. Besser ist ein Modell mit Warteschlange, Zustellstatus und Wiederholungslogik.

Der Grund ist simpel: Shops, Middleware und ERP reagieren nicht immer gleichzeitig. Netzwerkfehler, Zeitüberschreitungen oder kurz gesperrte Datensätze sind normal. Wenn die Integration in solchen Momenten keinen Retry-Mechanismus mit eindeutiger Ereignis-ID hat, entstehen Lücken oder Dubletten.

{
  "event_id": "ord-2026-04-100045",
  "event_type": "order.created",
  "source": "shop",
  "external_order_no": "100045",
  "created_at": "2026-04-20T10:15:00Z"
}

Praktisch heißt das: Jede Nachricht braucht einen eindeutigen Schlüssel, einen Zeitstempel und einen verarbeitbaren Status wie pending, processed oder failed. Ohne diese Basiselemente wird Fehleranalyse im Betrieb unnötig teuer.

Sauber wird das erst mit einer klaren Trennung zwischen Transportfehler und Fachfehler. Ein HTTP-Fehler beim Senden ist etwas anderes als eine Bestellung mit unbekannter SKU oder fehlender Steuerklasse. Wer beides in denselben Fehlertopf wirft, kann weder priorisieren noch automatisiert wiederholen. Für Teams, die solche Muster häufiger bauen, ist auch API-Integration im E-Commerce kein Frontend-Thema, sondern vor allem Prozesskontrolle.

Mapping-Regeln dokumentieren, bevor die erste Zeile Logik gebaut wird

Viele Projekte verlieren Zeit, weil technische Teams zu früh mit Feldzuordnungen beginnen. Erst muss klar sein, welche fachliche Bedeutung ein Feld wirklich hat. Ein Beispiel: Das Shop-Feld status=paid bedeutet nicht automatisch, dass im ERP eine Zahlung final verbucht werden darf. Je nach Zahlungsart kann das nur eine Zahlungsbestätigung des Providers sein, nicht der buchhalterische Abschluss.

Dasselbe gilt für Kundendaten. Ein Shop-Konto ist nicht automatisch ein sauberer Debitor. Firmenname, USt-IdNr., Lieferadresse, Rechnungsadresse und Ansprechpartner müssen in eine ERP-Struktur übersetzt werden, die Belege und spätere Kommunikation sauber trägt. Wer diese Zuordnung erst nach dem ersten Import diskutiert, hat den Projektablauf falsch herum aufgesetzt.

Ein robustes Mapping-Dokument enthält mindestens diese Punkte:

• Quellsystem und Zielsystem je Feld oder Objekt
• Transformationsregel, etwa Netto-zu-Brutto, Rundung oder Standardwert
• Pflichtfeldprüfung vor dem Schreiben ins Zielsystem
• Fehlerreaktion, also Abbruch, Rückstellung oder manuelle Prüfung

Das klingt trocken. Im Betrieb spart genau diese Disziplin die meisten Eskalationen.

Ein Punkt wird fast immer zu spät geklärt: die Versionierung von Mapping-Regeln. Sobald Preislogik, Steuerbehandlung oder Variantenstruktur geändert werden, muss nachvollziehbar bleiben, nach welcher Regel ein Auftrag importiert wurde. Ohne diese Spur wird jede spätere Fehleranalyse zur Rekonstruktion aus Logdateien und Einzelwissen.

Wo Shop-Anbindungen im Betrieb wirklich scheitern

Die meisten Integrationen brechen nicht beim ersten Export, sondern in Randfällen. Deshalb sind hübsche Demo-Synchronisationen als Kaufargument fast wertlos.

Doppelte Aufträge entstehen oft durch wiederholte Webhooks oder verspätete Antworten. Wenn dieselbe externe Bestellnummer nicht als eindeutiger Schlüssel gespeichert wird, legt das ERP denselben Auftrag mehrfach an. Technisch ist die Gegenmaßnahme simpel: Idempotenz. Operativ wird sie erstaunlich oft vergessen. Für HTTP-Verarbeitung reichen die Grundlagen zu Statuscodes und Wiederholungen aus der HTTP-Dokumentation von MDN völlig aus.

Falsche B2B-Preise sind fast immer ein Prioritätsproblem. Der Shop zeigt einen Aktionspreis, das ERP erwartet eine individuelle Preisliste, zusätzlich greift ein Kundenrabatt. Ohne feste Regel wird der Auftrag entweder falsch importiert oder im Backoffice korrigiert. Beides kostet.

Ein konkretes Muster aus dem Betrieb: Im technischen Großhandel mit rund 8.000 Artikeln und zwei Verkaufskanälen war nicht der Erstimport das Problem, sondern die Preis- und Statuslogik. Die eigentliche Reibung lag nicht in der Lizenz, sondern in mehreren Abstimmungsrunden zu Varianten, Teilversand und B2B-Konditionen, bevor der Rollout überhaupt sauber freigegeben werden konnte.

Teilversand wird regelmäßig unterschätzt. Viele Shops können versandt oder nicht versandt, aber keinen echten Teilversand. Wenn das ERP eine Bestellung in zwei Lieferungen aufteilt, kippt der Shop-Status schnell in eine fachlich falsche Darstellung. Dann sieht der Kunde abgeschlossen, obwohl Positionen offen sind.

Storno nach Folgebeleg ist der nächste Klassiker. Ein Kunde storniert im Shop, während im ERP bereits kommissioniert oder fakturiert wurde. Wer hier bidirektional und blind synchronisiert, produziert Belegchaos. Die Regel muss hart sein: automatische Stornos nur bis zu einem definierten Prozesspunkt, danach manueller Prüffall.

Ein Muster, das in echten Integrationen ständig auftaucht: Nicht der Datenimport verursacht die meiste Reibung, sondern Reservierungen, Varianten und Statusübersetzung. Teams investieren gern zuerst in sichtbare Synchronisation. Die eigentlichen Kosten entstehen später in den unsichtbaren Ausnahmen.

Wenn diese Regeln fehlen, hilft kein schönes Frontend. Dann ist eine ERP-nahe Umsetzung meist sinnvoller als ein allgemeines Shop-Setup. Wer an dieser Stelle zu generisch einkauft, kauft oft doppelt.

Typische Randfälle, die vor dem Go-live getestet werden müssen

Viele Abnahmen sind zu freundlich. Es wird ein Artikel angelegt, eine Testbestellung importiert, ein Versandstatus zurückgeschrieben. Das beweist fast nichts. Eine belastbare API Integration für E-Commerce muss mit absichtlich unangenehmen Fällen geprüft werden.

1. Bestellung mit Rabatt und Gutschein: Prüfen, ob Summen, Steuer und Positionswerte im ERP fachlich korrekt ankommen.
2. Bestellung mit Firmenkunde: Prüfen, ob Debitor, Preisgruppe und Rechnungsadresse sauber zugeordnet werden.
3. Teilweise lieferbare Bestellung: Prüfen, ob Reservierung, Teilversand und Restmenge konsistent bleiben.
4. Storno nach Zahlungsfreigabe: Prüfen, bis zu welchem Prozesspunkt Automatik erlaubt ist.
5. Wiederholter Webhook: Prüfen, ob der Auftrag exakt einmal angelegt wird.
6. Bestandsänderung unter Last: Prüfen, ob neuere Werte nicht von älteren Updates überschrieben werden.

Wer diese Fälle nicht testet, verschiebt Qualitätssicherung in den Live-Betrieb. Das ist keine Agilität, sondern Nachlässigkeit.

Zusätzlich sollte mindestens ein Test mit absichtlich fehlerhaften Daten laufen. Eine unbekannte Variante, eine fehlende Steuerzuordnung oder eine ungültige Zahlungsart zeigt schneller als jede Demo, ob die Integration kontrolliert scheitert oder still falsche Daten erzeugt. Saubere Schnittstellenarchitektur erkennt man nicht daran, dass alles grün ist, sondern daran, dass Fehler geordnet behandelt werden.

Betriebsmodell, Monitoring und Fehlerbehandlung sind Teil der Integration

Eine Integration ist nicht fertig, wenn Daten fließen. Belastbar wird sie erst, wenn Fehler sichtbar, zuordenbar und reproduzierbar behandelt werden können. Gerade beim Bestandsabgleich zwischen ERP und Shop reicht ein stilles Scheitern über Nacht, um am nächsten Morgen falsche Verfügbarkeiten im Shop zu haben.

Mindestens drei Ebenen sollten überwacht werden: technische Zustellung, fachliche Validierung und zeitliche Verzögerung. Technische Zustellung meint, ob ein Ereignis überhaupt verarbeitet wurde. Fachliche Validierung prüft, ob etwa eine Bestellung wegen fehlender Steuerklasse oder unbekannter Variante zurückgestellt wurde. Zeitliche Verzögerung zeigt, ob ein Prozess zwar läuft, aber zu langsam ist, um operativ noch brauchbar zu sein.

Ein sauberes Monitoring braucht keine überladene Plattform. Schon ein kompaktes Dashboard mit Fehlertyp, Anzahl offener Vorgänge, ältestem Fehler und letzter erfolgreicher Synchronisation bringt mehr als zehn verstreute Logdateien. Für Teams mit mehreren Kanälen lohnt zusätzlich ein täglicher Abgleichbericht für Bestände, offene Aufträge und Preisabweichungen.

In Projekten mit wachsendem Volumen zeigt sich immer wieder derselbe Fehler: Es wird in die Erstintegration investiert, aber nicht in den Betrieb. Dann hängt die Stabilität an einer Person, die Logdateien lesen kann. Ausfälle, Vertretung und Fehleranalyse hängen dann an Einzelwissen statt an dokumentierten Prozessen. Genau dadurch steigen Betriebsrisiken, weil Störungen nicht reproduzierbar bearbeitet werden und jede Abwesenheit zur Eskalation werden kann.

Validierungsregeln vor dem Schreiben ins ERP

Gerade beim Auftragsimport aus dem Onlineshop sollten Daten nicht blind ins ERP geschrieben werden. Vor dem Anlegen eines Belegs sind Prüfungen nötig, die fachliche Schäden verhindern. Dazu gehören mindestens:

• Existiert jede SKU im ERP und ist sie verkaufbar?
• Ist die Steuerlogik vollständig, insbesondere bei abweichenden Lieferländern?
• Ist die Zahlungsart zulässig und korrekt auf ERP-Logik gemappt?
• Ist der Kunde eindeutig zuordenbar oder muss ein neuer Debitor angelegt werden?
• Ist die Bestellung idempotent und wurde nicht bereits verarbeitet?

Fehlt eine dieser Prüfungen, landet der Fehler später tiefer im Prozess, oft erst bei Versand oder Rechnung. Dann ist die Korrektur teurer, weil bereits Folgebelege oder Kundenkommunikation existieren.

Für anspruchsvollere Setups lohnt zusätzlich eine fachliche Vorprüfung gegen definierte Geschäftsregeln. Dazu gehört etwa, ob ein B2B-Kunde ohne gültige Preisgruppe bestellen darf, ob ein Auftrag mit negativer Marge blockiert werden soll oder ob bestimmte Zahlungsarten für bestimmte Länder ausgeschlossen sind. Solche Regeln gehören nicht in manuelle Nacharbeit, sondern in die Integrationslogik.

Worauf Sie vor der Entscheidung wirklich achten sollten

Die Kosten hängen seltener von der Artikelzahl ab als von der Zahl der Ausnahmen. Ein großer Katalog mit sauberen Stammdaten ist oft leichter integrierbar als ein kleiner Shop mit chaotischen Varianten, Sonderpreisen und manuellen Belegumwegen.

Vor der Entscheidung zwischen Konnektor, Middleware und Systemwechsel sollten vier Punkte geklärt sein: eindeutige Identifikatoren, Variantenmodell, Verfügbarkeitslogik und Preisquelle. Wenn einer dieser Punkte offen bleibt, verschieben Sie Aufwand nur in den Betrieb.

Die sinnvolle Reihenfolge ist klar. Zuerst Identifikatoren und Varianten. Danach Bestandslogik. Dann Auftragsimport mit Dublettenprüfung und Statusmapping. Content-Synchronisation, Bilder oder Marketingfelder kommen später. Viele Teams machen es umgekehrt, weil Bestellungen sichtbarer wirken. Das ist ein Fehler.

Für die Kaufentscheidung reicht am Ende ein nüchterner Filter: Bleiben Prozesse einfach und einkanalig, kann GT mit schlanker Anbindung wirtschaftlich sauber bleiben. Wachsen Kanäle, Preislogik und Ausnahmen, ist Middleware meist die vernünftigere Investition. Steht ein neues Setup mit Ausbauplänen an, ist nexo PRO oft die robustere Basis als ein später geflickter GT-Unterbau.

Die unbequeme Kaufempfehlung lautet deshalb: Wenn Sie heute schon wissen, dass B2B-Preislogik, mehrere Kanäle oder tiefe Prozessautomatisierung kommen, ist ein billiger Konnektor meist die falsche Entscheidung. Er spart am Anfang Budget und verbrennt es später im Betrieb. Darüber kann man streiten. In der Praxis ist genau das aber der häufigere Verlauf.

Entscheidungsrelevant ist am Ende nicht die niedrigste Einstiegssumme, sondern die Frage, ob Ihr Setup bei zwei oder mehr Kanälen, kundenspezifischen Preisen oder einer spürbaren Ausnahmequote stabil bleibt. Wenn Preislogik kanalabhängig ist, Teilversand vorkommt oder Bestände nicht nur aus einem simplen Lagerwert bestehen, sollte die Auswahl auf Architektur und Fehlerbehandlung fallen, nicht auf den billigsten Erstanschluss.