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äufeGenau 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 existiertFü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
