Wer einen Online-Shop betreibt und im Hintergrund mit SAP Business One arbeitet, kennt die Reibung: Artikel werden im ERP gepflegt und trotzdem im Shop noch einmal eingegeben, Preise weichen voneinander ab, Bestände stimmen nur bis zum nächsten Wareneingang, und jede Onlinebestellung wird von Hand ins ERP übertragen. Eine saubere SAP-Business-One-Anbindung an Shopware beseitigt diese Doppelarbeit, indem Artikel, Preise, Bestände, Aufträge und Belege automatisch zwischen beiden Systemen fließen. SAP Business One ist mit über 83.000 Kunden (SAP) und rund 1,2 Millionen Nutzern (SAP) in mehr als 170 Ländern (SAP) eines der meistgenutzten Mittelstands-ERP der Welt - und Shopware im DACH-Raum eine verbreitete Plattform dafür, dieses ERP online verkaufsfähig zu machen. Dieser Praxisleitfaden zeigt, über welche Schnittstellen die Anbindung technisch läuft, welche Objekte in welche Richtung synchronisiert werden und worauf es im Betrieb ankommt.
Warum SAP Business One und Shopware zusammengehören
SAP Business One richtet sich an kleine und mittelständische Unternehmen. Rund 61 Prozent der Installationen entfallen laut Branchenanalysen auf Firmen mit weniger als 100 Mitarbeitern (laut Branchenanalysen), und jährlich kommen etwa 3.000 Neukunden hinzu (SAP). Genau diese Unternehmen betreiben zunehmend einen Online-Shop und stehen vor der Frage, wie das ERP als führendes System und der Shop als Verkaufskanal zusammenspielen. Im ERP liegt die Wahrheit über Artikel, Preise, Kunden und Bestände sowie über die kaufmännischen Belege. Der Shop ist der Ort, an dem daraus Umsatz wird. Ohne Anbindung pflegen Mitarbeiter beide Seiten getrennt, was Zeit kostet und Abweichungen erzeugt.
Dass sich der Aufwand lohnt, zeigt die Marktentwicklung. Im B2B verteilt sich die Kaufreise nach der Rule of Thirds: Auf jeder Stufe bevorzugt etwa ein Drittel der Kunden persönlichen Kontakt, ein Drittel Remote-Kommunikation und ein Drittel digitalen Self-Service (McKinsey, B2B Pulse). Einkäufer nutzen inzwischen durchschnittlich zehn Kanäle entlang einer Kaufentscheidung (McKinsey), und 34 Prozent des gesamten B2B-Umsatzes entstehen bereits über Self-Service-E-Commerce und Remote-Interaktionen (McKinsey). Der deutsche B2B-Internethandel über Shops und Marktplätze erreichte zuletzt 509 Milliarden Euro mit einem Zuwachs von sieben Prozent (IFH Köln); über diese Kanäle realisieren Großhandel und Hersteller 12,1 Prozent ihrer Gesamtumsätze (IFH Köln), und für das Folgejahr wird ein weiteres Plus von 6,3 Prozent erwartet (IFH Köln). Gemessen am gesamten deutschen B2B-Online-Handel von rund 1,67 Billionen Euro (Statista/IFH Köln) ist da noch erheblicher Spielraum. Zugleich wären 73 Prozent der B2B-Einkäufer bereit, mehr als 50.000 US-Dollar pro Bestellung online abzuwickeln (McKinsey). Ein Shop, der sauber an SAP Business One angebunden ist, bedient dieses digitale Drittel, ohne die anderen beiden auszuschließen und ohne dass jemand Bestellungen abtippt.
39 Prozent der B2B-Einkäufer geben inzwischen mehr als 500.000 US-Dollar pro Bestellung über Self-Service-E-Commerce oder Remote-Interaktion aus, gegenüber 28 Prozent zwei Jahre zuvor (McKinsey). Und 60 Prozent der selbsternannten Marktführer berichten für 2025 von zweistelligem Umsatzwachstum, gegenüber nur 21 Prozent der Nachzügler (McKinsey). Der gemeinsame Nenner der Gewinner sind durchgängige, kanalübergreifende Prozesse - und die beginnen bei sauberen Stammdaten aus dem ERP.
Der teuerste Teil einer fehlenden Anbindung ist selten sichtbar, weil er sich über den Alltag verteilt: eine Preispflege im ERP, die verspätet im Shop ankommt; ein ausverkaufter Artikel, der online weiter bestellbar ist; eine Onlinebestellung, die zwei Tage später manuell als Auftrag erfasst wird. Wer die Grundlagen einer ERP-Integration zwischen Shopware und SAP verstanden hat, weiß, dass die eigentliche Arbeit nicht im Datenaustausch liegt, sondern in der Frage, welches System für welches Feld führend ist. Das gilt im B2B-E-Commerce noch stärker als im Endkundengeschäft, weil hier kundenindividuelle Preise und Konditionen im Spiel sind.
Die zwei Wege in SAP Business One: Service Layer und DI-API
SAP Business One bietet zwei technische Zugänge, über die eine Integration Daten lesen und schreiben kann. Beide haben ihre Berechtigung, und in der Praxis werden sie häufig kombiniert. Die Wahl entscheidet nicht nur über den Aufwand, sondern auch über Betrieb, Skalierung und die Frage, unter welchem Betriebssystem die Integrationskomponente läuft.
Service Layer (REST/OData)
Die moderne, REST-basierte Schnittstelle. Sie stellt die Geschäftsobjekte von SAP Business One über das OData-Protokoll (Version 4) als HTTP-Endpunkte bereit, arbeitet zustandslos mit JSON und lässt sich lastverteilt betreiben. Für neue Anbindungen in der Regel die erste Wahl, weil sie sich sauber in eine service-orientierte Architektur einfügt und ohne Windows-Komponenten auskommt.
DI-API (COM)
Der ältere, COM-basierte Zugang. Er läuft nur unter Windows, ist eng an die Anwendungslogik gekoppelt und deckt einige Spezialfälle ab, die der Service Layer je nach Version nicht vollständig abbildet. Bestehende Integrationen nutzen ihn oft; für neue Projekte spielt er meist nur dort eine Rolle, wo eine Funktion über den Service Layer nicht erreichbar ist.
Für den DACH-Mittelstand ist außerdem relevant, dass SAP Business One in zwei Datenbankvarianten existiert - der klassischen SQL-Variante und der Variante auf SAP HANA. Der Service Layer steht in beiden zur Verfügung, unterscheidet sich aber im Detail bei einzelnen Endpunkten und bei der Abfragesyntax. Eine belastbare Anbindung berücksichtigt diese Unterschiede von Anfang an, statt sie später als Sonderfall nachzuziehen.
Welche Objekte synchronisiert werden
Eine SAP-B1-Anbindung an Shopware dreht sich um fünf Kernobjekte, die den Warenfluss vom ERP in den Shop und die Belege vom Shop zurück ins ERP abbilden. Entscheidend ist nicht nur, dass ein Objekt synchronisiert wird, sondern in welche Richtung, welches System dabei führt und wie aktuell die Daten sein müssen.
| Objekt | Richtung | Führendes System | Typische Frequenz |
|---|---|---|---|
| Artikel / Stammdaten | SAP zu Shop | SAP Business One | Bei Änderung / stündlich |
| Preise und Preislisten | SAP zu Shop | SAP Business One | Bei Änderung / täglich |
| Bestände | SAP zu Shop | SAP Business One | Nahezu in Echtzeit |
| Kunden und Kundengruppen | Beide Richtungen | je nach Feld | Bei Änderung |
| Aufträge | Shop zu SAP | Shopware (Entstehung) | Bei Bestellung |
| Rechnungen und Belege | SAP zu Shop | SAP Business One | Nach Belegerstellung |
Die Artikelsynchronisation ist der Kern. Aus dem ERP kommen Artikelnummer, Bezeichnung, Steuersatz, Gewicht, Maßeinheiten und Warengruppen; im Shop entstehen daraus Produkte mit Medien, SEO-Texten und Kategoriezuordnung. Sobald ein Artikel Varianten hat - Größe, Farbe, Gebinde -, entscheidet das Mapping darüber, ob im Shop ein sauberes Variantenprodukt oder ein Wildwuchs einzelner Artikel entsteht. Wie sich das ohne Duplicate Content bei Produktvarianten lösen lässt, ist eine eigene Disziplin, die früh im Mapping-Konzept mitgedacht gehört.
Bestände sind das Feld mit der höchsten Aktualitätsanforderung. Ein Lagerbestand, der nur einmal täglich synchronisiert wird, führt zu Überverkäufen und Stornos. Deshalb werden Bestände idealerweise ereignisgesteuert übertragen, sobald sich im ERP eine Buchung ändert. Auf dieser Basis lässt sich auf der Produktseite auch ein belastbares Lieferdatum als Conversion-Hebel ausweisen, statt nur auf Lager oder nicht verfügbar zu zeigen. Preise sind im B2B selten ein einzelner Wert: SAP Business One verwaltet Preislisten, Kunden- und Mengenrabatte sowie Sonderpreise, die im Shop je nach Kundengruppe oder eingeloggtem Kunden greifen müssen. Die Anbindung überträgt deshalb nicht den Preis, sondern die Preislogik - inklusive der Frage, ob netto oder brutto geführt wird.
Richtung und Frequenz: Push, Pull und Events
Nicht jedes Objekt braucht dieselbe Aktualität, und nicht jede Übertragung sollte in beide Richtungen laufen. Drei Muster haben sich bewährt: geplante Batch-Läufe für Massendaten wie den nächtlichen Katalogabgleich, ereignisgesteuerte Übertragung für zeitkritische Felder wie Bestände und ein direkter Pull für selten genutzte Detaildaten, die erst bei Bedarf geladen werden.
Shopware liefert über Webhooks Ereignisse wie eine neue Bestellung, auf die die Middleware reagieren kann, ohne den Shop permanent abzufragen. Wie sich eine solche ereignisgesteuerte Shop-Integration mit Webhooks sauber aufbaut, entscheidet über Last und Zuverlässigkeit. Wichtig ist die klare Trennung: Ein neuer Auftrag entsteht im Shop und wird ins ERP geschrieben; Preise und Bestände entstehen im ERP und werden in den Shop geschrieben. Läuft ein Feld versehentlich in beide Richtungen, überschreiben sich die Systeme gegenseitig - eine der häufigsten Ursachen für scheinbar unerklärliche Datenabweichungen.
Nicht alles muss in Echtzeit laufen. Ein Artikeltext darf stündlich aktualisiert werden, ein Bestand sollte es innerhalb von Sekunden. Die Faustregel: Je direkter ein Feld eine Kaufentscheidung oder einen Storno auslöst, desto höher die nötige Aktualität. Alles andere gehört in geplante Läufe, die das ERP nicht unnötig belasten.
Middleware oder Direktanbindung?
Technisch lässt sich Shopware direkt mit dem Service Layer verbinden. In einfachen Szenarien mit wenigen Objekten und geringer Frequenz kann das ausreichen. Sobald jedoch mehrere Objekte, Fehlerbehandlung, Wiederholungen und Protokollierung ins Spiel kommen, entsteht faktisch eine Middleware - die Frage ist nur, ob sie geplant ist oder als gewachsenes Skript.
| Aspekt | Direktanbindung | Middleware |
|---|---|---|
| Einstieg | Schneller, weniger Komponenten | Höherer Initialaufwand |
| Fehlerbehandlung | Im Shop-Plugin verankert | Zentral mit Queue und Retry |
| Mehrere Systeme | Schwer erweiterbar | ERP, PIM, Versand anschließbar |
| Nachvollziehbarkeit | Verteilt | Zentrales Protokoll je Vorgang |
| Lastspitzen | Direkt auf das ERP | Durch Queue entkoppelt |
| Wartung | Bei jedem Update prüfen | Klar getrennte Zuständigkeit |
Ob eine dedizierte Integrationsschicht sinnvoll ist, hängt von Objektzahl, Frequenz und Zahl der beteiligten Systeme ab; die Abwägung vertiefen wir im Artikel zur Middleware in der E-Commerce-Integration. Für die reine Zweisystem-Anbindung von SAP Business One an Shopware ohne weitere Kanäle kann eine schlanke Direktverbindung genügen. Wer aber Marktplätze, Versanddienstleister oder ein PIM ergänzen will, fährt mit einer Middleware meist ruhiger, weil die Integrationslogik dann an einer Stelle liegt und nicht in jedem Endsystem dupliziert wird.
Stammdaten-Mapping und das Prinzip des führenden Systems
Das Herz jeder Anbindung ist das Mapping - die Übersetzung zwischen der Datenwelt von SAP Business One und der von Shopware. Der Artikelschlüssel (ItemCode im ERP, Produktnummer im Shop) muss eindeutig aufeinander abgebildet sein, damit ein Artikel über Jahre wiedererkannt wird. Dasselbe gilt für Steuerklassen, Preislisten, Kundengruppen, Zahlungsbedingungen und die Nummernkreise der Belege. Jedes dieser Felder braucht eine bewusste Entscheidung, welches System es führt.
Die wichtigste Regel jeder Integration: Für jedes Datenfeld gibt es genau ein System, das die Wahrheit hält. Wenn ein Rabatt sowohl im Shop als auch in SAP Business One gepflegt werden kann, entstehen Abweichungen, die im schlechtesten Fall zu einem falschen Preis im Warenkorb führen. Wo Zuständigkeiten überlappen, entstehen erfahrungsgemäß genau die Fehler, die im Betrieb am schwersten zu finden sind.
Dieselbe Mapping-Disziplin gilt für jedes ERP. Wer parallel Microsoft Dynamics 365 Business Central an Shopware anbindet, steht vor denselben Fragen mit anderer Terminologie - und ein Unternehmen, das mehrere Warenwirtschaften betreibt, sollte das Mapping so anlegen, dass die Regeln pro Quelle sauber getrennt bleiben. Ein durchdachtes Mapping ist damit weniger eine technische als eine kaufmännische Aufgabe: Es bildet ab, wie das Unternehmen tatsächlich Preise bildet, Kunden segmentiert und Belege führt.
Fehlerbehandlung, Idempotenz und Monitoring
Eine Integration ist ein produktives System mit eigenen Ausfallszenarien: Das ERP ist im Wartungsfenster nicht erreichbar, eine Bestellung schlägt beim Schreiben fehl, ein Netzwerkfehler unterbricht einen Batch. Damit daraus kein Datenverlust wird, gehören Wiederholungen mit ansteigendem Abstand (Backoff), eine Warteschlange für fehlgeschlagene Vorgänge (Dead-Letter) und Idempotenz zum Standard - dieselbe Nachricht darf mehrfach ankommen, ohne einen Auftrag doppelt anzulegen.
Ebenso wichtig ist Sichtbarkeit. Ohne Protokoll je Vorgang, ohne Kennzahlen zu Durchsatz und Fehlerquote und ohne Alarmierung bei Rückstau bleibt eine Integration eine Blackbox, die im Zweifel niemand rechtzeitig als Ursache erkennt. Eine gute Anbindung zeigt jederzeit, welcher Auftrag wann in welchem Zustand war und wo ein Vorgang hängt.
Ein verlorener Katalogeintrag lässt sich beim nächsten Lauf nachziehen - eine verlorene Bestellung nicht. Deshalb gehören Auftrags- und Belegdaten in ein durchdachtes Sicherungskonzept, das auch die Integrationsschicht einschließt. Was dabei zu beachten ist, behandeln wir im Artikel zu Backup und Disaster Recovery im Online-Shop. Eine pauschale Zusage absoluter Ausfallsicherheit wäre unseriös; erreichbar ist ein hohes Schutzniveau mit definierten Wiederanlaufzeiten.
Typische Stolperfallen bei der SAP-B1-Anbindung
Viele Probleme einer SAP-B1-Integration sind wiederkehrend und lassen sich mit einem sauberen Konzept von vornherein vermeiden. Diese Punkte tauchen in der Praxis besonders häufig auf:
- Netto oder brutto verwechselt: SAP Business One und der Shop müssen dieselbe Grundlage führen. Ein Mix aus Netto-Preisliste und Brutto-Anzeige erzeugt Rundungsfehler, die sich erst im Checkout zeigen.
- Nummernkreise nicht abgestimmt: Wenn Auftrags- und Belegnummern zwischen Shop und ERP kollidieren oder doppelt vergeben werden, wird die Zuordnung im Nachhinein mühsam. Die Vergabe gehört klar geregelt.
- Varianten unsauber abgebildet: Aus einem Variantenartikel im ERP werden im Shop schnell viele Einzelprodukte, wenn das Mapping die Struktur nicht kennt - mit Folgen für Navigation und SEO.
- Zahlarten und Konditionen nicht gemappt: Zahlungsbedingungen aus dem ERP und Zahlarten im Shop sind zwei Welten. Ohne Mapping landet eine Onlinezahlung im ERP ohne passende Belegzuordnung.
- ERP durch zu häufige Abfragen belastet: Ein Bestandsabruf im Sekundentakt für zehntausende Artikel bringt das ERP unter Last. Ereignisse und Caching entlasten hier deutlich mehr als kürzere Intervalle.
- Kein Testsystem: Wer Mapping und Fehlerbehandlung direkt am Produktivsystem erprobt, riskiert falsche Bestände und Belege. Ein getrenntes Test-Mandat gehört zum Projekt.
- Teillieferungen und Belegfluss ignoriert: Aus einem Auftrag werden im ERP oft mehrere Lieferungen und Rechnungen. Der Shop sollte diesen Belegfluss abbilden, damit der Kunde im Konto den echten Stand sieht.
So gehen wir bei der Integration vor
Am Anfang steht keine Zeile Code, sondern eine Bestandsaufnahme: Welche Objekte müssen fließen, in welche Richtung, mit welcher Frequenz, und welches System führt welches Feld? Aus dieser Landkarte entsteht das Mapping-Konzept, danach die Wahl zwischen Service Layer und DI-API sowie die Entscheidung für oder gegen eine Middleware. Erst dann folgt die individuelle Entwicklung, begleitet von einem Testsystem, auf dem Artikel, Preise, Bestände und ein kompletter Bestell- und Belegdurchlauf geprüft werden, bevor das erste echte Produkt online geht.
Ob eine schlanke Direktverbindung oder eine ausbaufähige Integrationsschicht die richtige Wahl ist, hängt von Ihrer Systemlandschaft ab - und von den Kanälen, die perspektivisch dazukommen sollen. Wenn Sie prüfen möchten, wie sich Ihr Shop an SAP Business One anbinden lässt und welche weiteren Schnittstellen sinnvoll dazugehören, sprechen wir gern über Ihr Vorhaben - von der Prozessaufnahme über das Mapping bis zum stabilen Betrieb. Kontaktieren Sie uns für eine erste Einschätzung Ihrer bestehenden Systeme.
Dieser Artikel basiert auf Daten aus: SAP (Kennzahlen zu SAP Business One, Stand Ende 2025 - über 83.000 Kunden, rund 1,2 Millionen Nutzer, mehr als 170 Länder, etwa 3.000 Neukunden pro Jahr), McKinsey (B2B Pulse Survey - Rule of Thirds, durchschnittlich zehn Kanäle, 34 Prozent des B2B-Umsatzes über Self-Service und Remote, 39 Prozent gegenüber 28 Prozent bei Bestellungen über 500.000 US-Dollar, 60 Prozent der Marktführer mit zweistelligem Wachstum gegenüber 21 Prozent der Nachzügler) IFH Köln (B2B-Marktmonitor - 509 Milliarden Euro B2B-Internethandel, plus sieben Prozent, 12,1 Prozent Umsatzanteil, Prognose plus 6,3 Prozent) und Statista/IFH Köln (rund 1,67 Billionen Euro B2B-Online-Handel in Deutschland). Der Anteil von rund 61 Prozent der Installationen bei Firmen mit weniger als 100 Mitarbeitern beruht auf Auswertungen der Install-Base (laut Branchenanalysen). Die genannten Zahlen beziehen sich auf unterschiedliche Erhebungszeiträume und können je nach Zeitpunkt und Marktsegment abweichen.
Für neue Anbindungen ist der Service Layer in der Regel die erste Wahl, weil er REST-basiert, zustandslos und ohne Windows-Komponenten betreibbar ist und sich gut in eine service-orientierte Architektur einfügt. Die DI-API bleibt sinnvoll, wenn eine bestimmte Funktion über den Service Layer je nach Version nicht erreichbar ist oder eine bestehende Integration bereits darauf aufbaut. In der Praxis werden beide Wege gelegentlich kombiniert.
Bestände und Preise entstehen im ERP und werden in den Shop geschrieben - SAP Business One ist hier das führende System. Aufträge dagegen entstehen im Shop und werden ins ERP übertragen. Diese Trennung ist wichtig: Läuft ein Feld versehentlich in beide Richtungen, überschreiben sich die Systeme gegenseitig, was zu schwer auffindbaren Abweichungen führt.
Nicht zwingend. Für eine einfache Zweisystem-Anbindung mit wenigen Objekten und geringer Frequenz kann eine schlanke Direktverbindung genügen. Eine Middleware lohnt sich, sobald mehrere Objekte, robuste Fehlerbehandlung, Wiederholungen, Protokollierung oder weitere Kanäle wie Marktplätze, Versand oder ein PIM ins Spiel kommen. Dann liegt die Integrationslogik an einer Stelle statt verteilt in jedem Endsystem.
SAP Business One verwaltet Preislisten, Kunden- und Mengenrabatte sowie Sonderpreise. Die Anbindung überträgt nicht einen einzelnen Preis, sondern die Preislogik: Preislisten werden auf Kundengruppen und eingeloggte Kunden im Shop abgebildet, Staffeln und Sonderpreise entsprechend zugeordnet. Wichtig ist, dass Netto- oder Bruttoführung in beiden Systemen übereinstimmt, damit im Checkout keine Rundungsdifferenzen entstehen.
Das hängt vom gewählten Muster ab. Bei ereignisgesteuerter Übertragung, die auf eine Buchung im ERP reagiert, sind Bestände typischerweise innerhalb von Sekunden bis wenigen Minuten aktuell. Bei rein geplanten Batch-Läufen entspricht die Aktualität dem Intervall. Weil ein veralteter Bestand zu Überverkäufen und Stornos führt, empfiehlt sich für dieses Feld die höchste sinnvolle Aktualität, während unkritische Daten in seltenere Läufe gehören.
Ja. Der Service Layer steht in beiden Datenbankvarianten zur Verfügung, unterscheidet sich aber im Detail bei einzelnen Endpunkten und in der Abfragesyntax. Eine belastbare Anbindung berücksichtigt diese Unterschiede von Anfang an. Welche Variante bei Ihnen im Einsatz ist, klären wir zu Projektbeginn, damit das Mapping und die Abfragen dazu passen.