Shopware 6 ERP-Anbindung: Was Sie wissen müssen

Führendes System vor Technik

Jede robuste Integration beginnt mit einer Tabelle, nicht mit einem Token. Pro Datenobjekt — Artikelstamm, Preis, Bestand, Kunde, Bestellung, Lieferschein, Rechnung, Retoure — muss feststehen: Welches System darf den Wert schreiben, welches darf ihn nur lesen, und wie oft wird er übertragen? Erst wenn diese drei Antworten schriftlich vorliegen, hat die Schnittstelle eine fachliche Spezifikation.

In der Praxis führt das ERP typischerweise Artikelnummer, Listenpreis, Staffeln, kundenindividuelle Konditionen und Lagerbestand. Der Shop oder ein PIM führt Marketingtexte, Bilder, SEO-Felder und oft die Kategoriestruktur für die Storefront. Bestellungen entstehen im Shop und wandern ins ERP; Versandstatus und Rechnungsnummer kommen zurück. Diese Aufteilung ist kein Dogma, sondern der Regelfall im DACH-Mittelstand — Abweichungen sind erlaubt, solange sie bewusst und dokumentiert sind.

Was scheitert, ist der Satz „wir synchronisieren einfach alles in beide Richtungen“. Bidirektional ohne Führung heißt: Zwei Schreibrechte auf denselben Fakt. Ändert ein Mitarbeiter den Preis im Shop und ein anderer im ERP, gewinnt der letzte Schreibvorgang — nicht der richtige. Die Folge sind Support-Tickets, die niemand einem System zuordnen kann, weil beide Systeme „korrekt“ arbeiten und nur die Führungsregel fehlt.

Objekt, Führer, Richtung, Frequenz

Die folgende Matrix ist ein Arbeitsmodell aus Projekten mit Microtech Büro+, SAP und DATEV — keine Universalwahrheit. Passen Sie sie an Ihre Prozesse an, aber lassen Sie keine Zeile leer. Leere Zellen werden im Go-Live zu Sonderfällen, und Sonderfälle werden zu manuellen Nightmares.

Drei Integrationsmuster

Technisch lösen sich die meisten Shopware-ERP-Kopplungen in drei Mustern auf. Welches passt, hängt weniger von der Mode ab als vom ERP-API-Stand, vom Bestellvolumen und davon, wie eng der Betrieb Fehler sehen und nacharbeiten muss.

Muster eins ist Dateiaustausch über SFTP oder vergleichbare Ablage: CSV, XML oder feste Exportformate. Das ERP schreibt Dateien, ein Importjob liest sie in Shopware — oder umgekehrt. Vorteil: Viele ältere Warenwirtschaften können Dateien, auch wenn sie keine moderne REST-API haben. Nachteil: Latenz, fehleranfällige Encoding- und Spaltenprobleme und oft schwache Rückmeldungen, wenn eine Zeile scheitert.

Muster zwei ist die direkte API-Kopplung: Shopware Admin API auf der einen Seite, ERP-API auf der anderen, möglicherweise mit einem schlanken Plugin, das Entity-Events entprellt weitergibt. Das eignet sich, wenn beide Systeme stabile Endpunkte haben und die Logik überschaubar bleibt. Risiko: Timeouts und Ausfälle hängen dann direkt an Request-Ketten; ohne Warteschlange wird jeder ERP-Hänger zum Shop-Problem.

Muster drei ist Middleware: ein eigener Dienst mit Warteschlange, Mapping, Retry und Job-Protokoll zwischen Shop und ERP — oder zwischen Shop und Marktplatz. Der OBI-Connector folgt diesem Schnitt: Ein dünnes Shopware-Plugin meldet Änderungen, die eigentliche Sync-Logik liegt außerhalb und bleibt unabhängig test- und deploybar. Shopware bleibt führendes System für Katalog, Preis und Bestand Richtung Mirakl; Bestellungen und Retouren kommen per Webhook zurück. Laut Projektdokumentation lagen über 1.700 ausgeführte Sync-Jobs bei 216 gepflegten Mappings und einer Erfolgsquote von 90,7 %.

Shopware-APIs, die für ERP zählen

Die offizielle Entwicklerdokumentation von Shopware unterscheidet klar zwei HTTP-APIs. Die Admin API unter `/api/*` ist die Oberfläche für Backend-Integrationen: Produkte, Bestellungen, Kunden, Konfiguration und — über die Sync-API — Massenoperationen. Die Store API unter `/store-api/*` bedient Storefront, Headless und Warenkorb. Für ERP-Stammdaten und Bestellübergabe ist die Admin API der richtige Einstieg; die Store API ersetzt sie nicht.

Authentifizierung der Admin API erfolgt per OAuth mit Integrationszugangsdaten aus der Administration (Einstellungen → System → Integrationen). Access Key ID und Secret entsprechen `client_id` und `client_secret`; das Token holen Sie typischerweise mit `grant_type=client_credentials` unter `/api/oauth/token` und senden es als Bearer-Token. Die Store API authentifiziert sich über den Sales-Channel-Zugangsschlüssel im Header `sw-access-key` — geeignet für Storefront-Kontexte, nicht als Ersatz für eine Integrationsrolle.

Für große Schreibmengen dokumentiert Shopware die Sync-API als Bulk-Weg: Erzeugen, Aktualisieren und Löschen mehrerer Entities in einem Aufruf, etwa über `POST /api/_action/sync` mit Upsert- und Delete-Operationen. Das ist der Pfad für Importe und Abgleiche, bei denen Einzel-POSTs unzumutbar wären. Zusätzliche Request-Header steuern unter anderem, ob Flows beim Import ausgelöst werden — relevant, wenn ein Massenimport sonst Tausende E-Mails anstoßen würde.

Custom Fields sind der dokumentierte Erweiterungspunkt für Attribute, die das Standardmodell nicht kennt — etwa ERP-interne Schlüssel, GPSR-Pflichtfelder oder technische Kenndaten. Sie gehören ins Datenmodell und Mapping, nicht in Freitextbeschreibungen. Webhooks im App-Lifecycle erlauben es Apps, auf Shop-Ereignisse zu reagieren; in Plugin-Architekturen wie dem OBI-Connector erfüllen entprellte Entity-Events dieselbe Rolle Richtung Middleware. Fremdsysteme (etwa Mirakl) können umgekehrt Webhooks liefern, die Bestellungen zurückspielen — das ist dann die API des Marktplatzes, nicht die von Shopware.

Feldmapping: warum „200+“ realistisch ist

Demo-Connectors zeigen oft zehn Spalten: SKU, Name, Preis, Bestand. In einem B2B-Sortiment mit Varianten, Einheiten, Preisgruppen, Staffeln, Herstellernummern, EAN, Zolltarif, Gewicht, Verpackungseinheit, GPSR-Angaben und technischen Attributen für die Facettensuche entstehen schnell zweihundert und mehr Mapping-Einträge — pro Kanal nochmals eigene Kategorie- und Attributregeln.

Beim OBI-Connector lagen laut Projektdokumentation 216 gepflegte Mappings — Kategorie, Marke, Attribute — neben dem eigentlichen Sync von Produkt, Preis und Bestand. Das ist kein Extremfall, sondern die Größenordnung, in der Marktplatz- und ERP-Projekte landen, sobald Sortimentstiefe und Fremdsystem-Pflichtfelder ernst genommen werden. FeNau mit über 20.000 Artikeln zeigt die andere Seite derselben Medaille: Ohne konsistente Attribute finden Fachkunden das Bauteil nicht, und ohne konsistentes Mapping kann das ERP den Shop nicht füttern.

Mapping ist deshalb Projektarbeit, keine Checkbox. Es braucht Verantwortliche auf Auftraggeberseite, die Einheiten, Steuerklassen und „was ist die führende Artikelnummer“ entscheiden — und Testfälle, die echte Belege aus der Buchhaltung gegen den Shop-Preis halten. Was im Mapping fehlt, erscheint später als Support-Ticket mit dem Betreff „Preis stimmt nicht“.

Bestand: der häufigste teure Fehler

Bestand ist das Datenobjekt, bei dem falsche Sync-Frequenz sofort Geld kostet. Überverkauf entsteht, wenn der Shop einen Bestand zeigt, den das Lager nicht mehr hat — typisch bei langsamem Abgleich, fehlender Reservierung nach Bestelleingang oder wenn Marktplatz und Shop parallel denselben physischen Bestand ohne gemeinsame Führung verkaufen.

Die Führungsregel lautet in den meisten Projekten: Das ERP führt den physischen Bestand; der Shop zeigt eine daraus abgeleitete Verfügbarkeit. Sobald eine Bestellung im Shop bestätigt ist, muss die Reservierung entweder sofort ins ERP oder zumindest so markiert sein, dass ein zweiter Kanal denselben Artikel nicht noch einmal verkauft. Marktplätze verschärfen das: Jeder Kanal braucht dieselbe Quelle, sonst entsteht ein Wettlauf um denselben Lagerplatz.

Technisch heißt das: Bestandsänderungen eng takten oder eventbasiert pushen, Fehlschläge sichtbar machen und manuelle Korrekturen im ERP — nicht im Shop — vornehmen, solange das ERP führend ist. Wer Bestände „mal eben“ im Shop korrigiert, während der nächste ERP-Lauf überschreibt, produziert genau die Inkonsistenz, die die Führungsmatrix verhindern sollte.

Fehlerbehandlung: Idempotenz, Retry, Dead-Letter, Job-Log

Fremdsysteme fallen aus, Tokens laufen ab, Dateien kommen halb an, Webhooks werden doppelt zugestellt. Eine Integration ohne Fehlerstrategie ist ein Cron, der nachts still scheitert. Vier Bausteine trennen Amateur- von Betriebsfähigkeit.

Idempotenz: Derselbe Vorgang darf mehrfach empfangen werden, ohne doppelte Bestellungen oder doppelte Lagerbuchungen zu erzeugen. Praktisch heißt das stabile Schlüssel (Bestellnummer, externe IDs) und „upsert statt blind insert“. Retry mit Backoff: Transiente Fehler (Timeout, 429, Wartungsfenster) werden wiederholt; permanente Fehler (Validierung, unbekanntes Mapping) nicht endlos. Dead-Letter: Jobs, die endgültig scheitern, landen in einer Warteschlange oder Tabelle, die ein Mensch abarbeitet — nicht im Nichts. Job-Log: Jeder Sync schreibt Status, Zeit, Payload-Referenz und Fehlermeldung, einsehbar im Dashboard.

Genau dieses Betriebsmodell trägt den OBI-Connector: Jobs, Fehlerlog, manuelle Sync-Aktionen für Einzelartikel oder Kategorien, Go-Live-Panel mit Bereitschaftsprüfungen. Ohne diese Schicht bleibt die „API-Anbindung“ eine Demo, die unter Last und Sonderfällen zerbricht.

Go-Live-Checkliste

Ein ERP-Go-Live scheitert selten am Happy Path. Er scheitert an fehlenden Secrets, unvollständigen Mappings, einem Worker, der nicht läuft, oder an Testbestellungen, die niemand mit der Buchhaltung abgeglichen hat. Die folgende Liste ist die Mindestprüfung vor dem Umschalten — ergänzt um Ihr ERP-spezifisches Abnahmeprotokoll.

Kostenrahmen ohne Doppelung

Die ausführliche Kostenaufschlüsselung steht unter /ratgeber/was-kostet-shopware-shop-2026 und /kosten/onlineshop-entwicklung. Hier nur die Orientierung, die zur ERP-Frage gehört: Ein Shopware-6-B2B-Shop ohne komplexe Integration liegt bei uns netto typisch bei 25.000–60.000 €. Shop samt ERP-Integration und optionaler Marktplatz-Anbindung bei 35.000–80.000 €. Die Differenz ist der Integrationszuschlag — Schnittstellenkatalog, Führungsmatrix, Mapping, Warteschlangen, Job-Protokoll, Dashboard und Go-Live-Checkliste — nicht „noch ein Theme“.

Angebunden haben wir Microtech Büro+, SAP und DATEV. Andere Warenwirtschaften bewerten wir im Scope-Workshop; wir erfinden hier keine Connector-Preise und keine Ersparnisquoten. Lizenz des ERP, Shopware-Lizenz und Hosting bleiben separat. Verbindlich wird der Festpreis nach geklärtem Scope: Artikelanzahl, Preislogik, Anzahl Fremdsysteme und Zustand der Stammdaten.

DSGVO und GoBD: was die Schnittstelle mitträgt

Sobald Bestellungen, Kundendaten oder Belege zwischen Shop und ERP fließen, ist die Integration Teil der Verarbeitung personenbezogener Daten. Die Datenschutz-Grundverordnung (Verordnung (EU) 2016/679) verlangt unter anderem Verträge zur Auftragsverarbeitung, wenn ein Dienstleister personenbezogene Daten in Ihrem Auftrag verarbeitet (Art. 28), und Meldepflichten bei Verletzungen des Schutzes personenbezogener Daten (Art. 33). Praktisch heißt das: klare Rollen (Verantwortlicher / Auftragsverarbeiter), dokumentierte Zwecke, minimierte Felder im Sync und ein Verfahren, wer bei einem Vorfall wen informiert — nicht erst, wenn das Ticket eskaliert.

Auf der steuerlichen Seite gelten die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) in der Fassung des BMF-Schreibens vom 28. November 2019. Für die Integration relevant sind Nachvollziehbarkeit und Unveränderbarkeit von aufzeichnungsrelevanten Daten sowie die Möglichkeit, Vorgänge zu rekonstruieren. Ein Job-Log, das Bestellübergaben und Belegstatus festhält, ist deshalb nicht nur Betriebscomfort — es stützt die Nachvollziehbarkeit zwischen Shop-Bestellung und ERP-Beleg. Ob Ihre konkrete Buchführung die GoBD erfüllt, ist eine steuerliche Fachfrage; technisch liefern wir die Protokollierung und die nachvollziehbare Schnittstelle.

Beides gehört in den Scope: AV-Verträge und Löschkonzepte auf der Datenschutzseite, unveränderliche bzw. revisionssichere Belegketten und Auswertbarkeit auf der GoBD-Seite. Wer die Schnittstelle „nur technisch“ baut und Compliance nachreicht, baut zweimal.