Warenwirtschaft, DATEV und Shopware verbinden: Schnittstellen ohne Chaos

Ein Shopware-Shop läuft, die Warenwirtschaft verwaltet Bestände und Aufträge, DATEV kümmert sich um Buchhaltung und Steuererklärung. Getrennt funktioniert jedes System gut. Verbunden entsteht oft das Gegenteil: doppelt gebuchte Rechnungen, falsche Bestände im Shop, Steuersätze, die zwischen den Systemen nicht zusammenpassen, und ein Buchhalter, der am Monatsende CSV-Dateien von Hand nachbearbeitet. Dieser Artikel zeigt, wo die Integration üblicherweise kippt, was eine saubere Schnittstelle wirklich kostet und wie ein Projekt in der Praxis abläuft.

Das Grundproblem: drei Systeme, ein Datensatz, viele Widersprüche

Jede Bestellung erzeugt Daten, die an mehreren Stellen gebraucht werden: der Shop kennt Kunde, Artikel und Preis, die Warenwirtschaft muss Bestand reservieren und Versand auslösen, DATEV braucht am Ende einen buchungsfähigen Beleg mit korrektem Steuerschlüssel. Sobald diese drei Systeme nicht direkt miteinander sprechen, entsteht eine vierte Instanz: der Mensch, der Daten manuell überträgt. Genau dort beginnt das Chaos — nicht bei der Software selbst, sondern beim Medienbruch dazwischen.

Typische Symptome, die uns in Gesprächen mit Online-Händlern immer wieder begegnen:

• Bestände im Shop stimmen nicht mit der Warenwirtschaft überein, weil der Abgleich nur einmal täglich oder gar manuell läuft.
• Rechnungen tauchen doppelt in DATEV auf, weil sowohl der Shop als auch die Warenwirtschaft Belege exportieren.
• Steuersätze für Auslandsgeschäfte (One-Stop-Shop, Reverse-Charge) werden im Shop korrekt berechnet, aber falsch oder gar nicht in die Buchhaltung übernommen.
• Retouren erzeugen Buchungen, die in der Warenwirtschaft ankommen, aber nicht in DATEV, sodass die Zahlen am Jahresende nicht zusammenpassen.

Keines dieser Probleme liegt an einem einzelnen Anbieter. Sie entstehen, weil die Schnittstelle zwischen den Systemen nicht als eigenständiges Projekt behandelt wurde, sondern als Nebensache beim Shop-Launch.

Die drei Player im Überblick

Shopware

Shopware (Hersteller: Shopware AG, Schöppingen) ist eine der meistgenutzten E-Commerce-Plattformen im deutschsprachigen Raum, in den Versionen Shopware 5 (Legacy) und Shopware 6 (aktuelle Architektur mit REST-API und Plugin-System). Für Integrationen relevant ist vor allem die Shopware 6 Admin-API sowie der Store-API-Layer, über den externe Systeme Bestellungen, Bestände und Preise auslesen und schreiben können.

Warenwirtschaft: JTL-Wawi, Xentral, weclapp & Co.

Im deutschen Mittelstand dominieren einige Namen: JTL-Wawi (JTL-Software GmbH, Saarbrücken) ist bei kleineren und mittleren Online-Händlern verbreitet und bringt einen eigenen Shopware-Connector mit. Xentral (Augsburg) und weclapp (Cloud-ERP mit Sitz in Erfurt/Frankfurt) positionieren sich als Cloud-ERP mit breiterem Funktionsumfang inklusive Finanzbuchhaltung. Daneben gibt es plentymarkets (Kassel) als Multichannel-Lösung und billbee für kleinere Marktplatz-Händler. Für größere Unternehmen kommen SAP Business One oder Microsoft Dynamics 365 Business Central infrage. Jedes dieser Systeme hat ein eigenes Datenmodell für Artikel, Lager und Aufträge — und keines davon ist von Haus aus identisch mit dem Shopware-Modell.

DATEV

DATEV eG (Nürnberg) ist die zentrale Software- und IT-Dienstleistungsgenossenschaft für Steuerberater, Wirtschaftsprüfer und Rechtsanwälte in Deutschland. Für Unternehmen relevant sind vor allem der DATEV-Format-Export (Buchungsstapel, ASCII- bzw. XML-Format für die Übergabe an den Steuerberater), DATEV Unternehmen online als Cloud-Schnittstelle zum Belegaustausch sowie zertifizierte Schnittstellen, die im DATEV-Marktplatz (datev-marktplatz.de) gelistet sind. Eine Warenwirtschaft, die “DATEV-Export” wirbt, meint in der Regel: Sie kann Buchungssätze in einem Format erzeugen, das ein Steuerberater ohne manuelle Nacharbeit importieren kann.

Wege der Integration: von Standard-Connector bis Custom-Middleware

Es gibt grundsätzlich drei Ansätze, und die Wahl entscheidet über Preis, Wartungsaufwand und Fehleranfälligkeit:

1. Native Connectors. JTL-Wawi bringt einen fertigen Shopware-Connector mit, Xentral und weclapp bieten offizielle Schnittstellen zu Shopware 6 an. Diese Lösungen decken Standardfälle ab: Bestellungen, Artikel, Bestände, teils auch Zahlungsabgleich. Sie sind die günstigste Variante, stoßen aber an Grenzen, sobald Sonderlogik dazukommt — etwa individuelle Rabattstaffeln, mehrstufige Steuerlogik für EU-Auslandsverkäufe oder Marktplatz-Anbindungen neben dem eigenen Shop.

2. iPaaS/Middleware-Plattformen. Tools wie Actindo oder branchenspezifische Integrationsplattformen setzen sich zwischen die Systeme und übernehmen Mapping und Transformation der Daten. Das lohnt sich, wenn mehr als zwei Systeme verbunden werden sollen (z. B. Shop, Warenwirtschaft, Versanddienstleister, Marktplätze, DATEV gleichzeitig).

3. Individuelle API-Integration. Wenn Standard-Connectoren an ihre Grenzen stoßen — etwa weil die Warenwirtschaft ein Nischenprodukt ist, weil mehrere Vertriebskanäle zusammengeführt werden müssen oder weil die Buchungslogik komplex ist (unterschiedliche Steuersätze, Gutscheine, Teilzahlungen, Storno-Ketten) — bleibt nur der Weg über eine eigene Middleware, die direkt mit den APIs beider Systeme spricht und die Buchungslogik dazwischen kapselt.

Die Entscheidung zwischen diesen drei Wegen sollte nicht am Preis der Erstinstallation hängen, sondern an der Frage, wie oft sich Ausnahmefälle wiederholen. Ein Shop mit reinem B2C-Geschäft in Deutschland kommt oft mit einem Standard-Connector aus. Ein Shop mit B2B-Kunden, Auslandsversand und mehreren Vertriebskanälen braucht in der Regel früher oder später eine individuelle Lösung.

GoBD und DSGVO: die zwei Leitplanken, die niemand ignorieren darf

Zwei rechtliche Rahmenbedingungen bestimmen, wie eine Schnittstelle gebaut werden darf — nicht nur, wie sie technisch funktioniert.

GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) sind ein Schreiben des Bundesministeriums der Finanzen (aktuelle Fassung über bundesfinanzministerium.de abrufbar) und verlangen unter anderem: Buchungsbelege müssen unveränderbar, nachvollziehbar und für zehn Jahre aufbewahrt werden; ein Änderungsprotokoll muss erkennbar machen, wer wann was verändert hat. Für eine Schnittstelle bedeutet das konkret: Wenn eine Bestellung aus Shopware in die Warenwirtschaft und von dort nach DATEV läuft, muss die Kette nachvollziehbar bleiben — keine stillen Überschreibungen von Belegdaten, keine Lücken zwischen Storno und Neubuchung.

DSGVO greift, sobald personenbezogene Daten (Name, Adresse, Zahlungsdaten der Kunden) zwischen Systemen fließen. Zuständig ist bundesweit der BfDI (Bundesbeauftragte für den Datenschutz und die Informationsfreiheit) sowie die jeweilige Landesdatenschutzbehörde. Praktisch heißt das: Ein Auftragsverarbeitungsvertrag (AVV) mit jedem beteiligten Cloud-Dienst gehört zur Integration dazu, nicht als nachträgliche Formalie, sondern von Anfang an — insbesondere wenn Middleware-Anbieter oder Cloud-ERPs im Ausland hosten.

Beide Punkte sind kein Grund, ein Projekt zu verzögern, aber sie gehören ins Lastenheft, bevor die erste Codezeile geschrieben wird. Nachträglich eine Schnittstelle GoBD-konform zu machen, ist deutlich teurer als sie von vornherein so zu bauen.

Was die Integration kostet: Richtwerte mit Scope

Die folgenden Zahlen sind Marktrichtwerte für Integrationsprojekte im deutschsprachigen Raum — keine Festpreise, sondern eine Orientierung. Der tatsächliche Preis hängt von Systemauswahl, Datenvolumen und Sonderlogik ab.

Der größte Kostentreiber ist selten die technische Anbindung selbst, sondern die Anzahl der Sonderfälle: Mehrere Steuersätze pro Land, Teilzahlungen, Gutscheinlogik, Marktplatz-Aufträge neben dem eigenen Shop — jeder dieser Fälle verlängert das Mapping und damit das Budget.

Ablauf eines Integrationsprojekts: Schritte und Dauer

Ein realistischer Projektablauf gliedert sich in vier Phasen, unabhängig davon, ob ein Standard-Connector oder eine individuelle Lösung gebaut wird:

1. Datenmodell-Analyse (3–7 Tage). Welche Felder existieren in Shopware, welche in der Warenwirtschaft, wie sieht die Buchungslogik in DATEV aus? Hier zeigt sich meist schon, wo Konflikte entstehen — etwa wenn der Shop Brutto-, die Warenwirtschaft aber Nettopreise führt.
2. Mapping und Testkonzept (1–2 Wochen). Festlegen, welches Feld wohin fließt, welche Steuerschlüssel welchen Fällen zugeordnet werden, wie Stornos und Retouren behandelt werden.
3. Entwicklung und Testlauf (2–6 Wochen, je nach Komplexität). Anbindung bauen, mit echten (anonymisierten) Testdaten prüfen, Fehlerfälle simulieren — insbesondere doppelte Buchungen und Bestandskonflikte bei parallelen Bestellungen.
4. Go-Live mit Parallelbetrieb (1–2 Wochen). Die neue Schnittstelle läuft parallel zum bisherigen manuellen Prozess, bis beide Seiten über mehrere Buchungszyklen hinweg übereinstimmen. Erst danach wird der manuelle Prozess abgeschaltet.

Wer diese Phase 4 überspringt, weil der Zeitdruck hoch ist, handelt sich in der Regel genau das Chaos ein, das die Integration eigentlich beseitigen sollte.

Typische Fehlerquellen, die zu Chaos führen

• Steuerschlüssel-Mapping wird einmalig gemacht und nie aktualisiert. Ändert sich ein Steuersatz oder kommt ein neues Land dazu (z. B. durch OSS-Verfahren), bleibt die Zuordnung veraltet, bis jemand die Differenz in der Buchhaltung bemerkt.
• Bestandsabgleich läuft nur in eine Richtung. Der Shop meldet Bestellungen an die Warenwirtschaft, aber Rückbuchungen bei Retouren oder manuellen Korrekturen im Lager fließen nicht zurück — der Shop verkauft Ware, die es nicht mehr gibt.
• Keine Idempotenz bei wiederholten Übertragungen. Schlägt eine Übertragung fehl und wird automatisch wiederholt, ohne dass das System erkennt, dass der Auftrag schon einmal übertragen wurde, entstehen doppelte Buchungssätze.
• Middleware ohne Monitoring. Eine Schnittstelle, die niemand beobachtet, fällt oft erst auf, wenn der Steuerberater am Monatsende nach fehlenden Belegen fragt — nicht wenn sie tatsächlich ausfällt.
• GoBD-Anforderungen erst nachträglich berücksichtigt. Wird die Unveränderbarkeit von Belegen nicht von Anfang an mitgedacht, bedeutet eine spätere Nachbesserung oft einen kompletten Umbau der Datenhaltung.

Wie wir das angehen

Bei Pazl bauen wir Integrationsprojekte nach demselben Muster wie jedes andere Softwareprojekt: mit einem Angebot nach dem Erstgespräch, einem Lastenheft, das beide Seiten unterschreiben, und einem Festpreis, der erst nach Freigabe dieses Lastenhefts feststeht — nicht vorher geschätzt und später nachverhandelt. Für kleinere Anbindungsprojekte liegt der Einstieg bei 3.000–6.000 €, größere Middleware-Vorhaben werden individuell kalkuliert, abhängig von der Anzahl der Sonderfälle im Mapping.

Während der Entwicklung zeigen wir wöchentlich den Stand — bei einer Schnittstelle heißt das konkret: Wir demonstrieren live, wie eine Testbestellung durch Shop, Warenwirtschaft und Buchungsexport läuft, statt erst am Ende ein fertiges System zu präsentieren. Nach Abnahme gilt eine Garantie von sechs Monaten auf das Gelieferte; Korrekturen innerhalb des vereinbarten Lastenhefts sind darin enthalten, ohne zusätzliche Rechnung. Die Rechte am Code gehen nach vollständiger Zahlung an den Kunden über. Kosten für Server, Domains und SSL-Zertifikate trägt der Kunde direkt — wir bauen die Schnittstelle, aber die Infrastruktur bleibt in Ihrer Hand.

Ähnliche Integrationsmuster kennen wir aus anderen Projekten unseres Teams: In einem Fall haben wir eine Bestell-App an das Warenwirtschaftssystem eines Herstellers angebunden, sodass Bestellungen automatisch ins ERP liefen und sich Preise sowie Lagerbestände ohne manuelles Übertragen synchronisierten — genau das Muster, das auch bei einer Shopware-Warenwirtschaft-Anbindung gefragt ist. In einem anderen Projekt haben wir Fuhrpark-Monitoring, Dokumentenfluss und Finanzkennzahlen in einer einzigen ERP-Struktur gebündelt, die zuvor über mehrere getrennte Tabellen und Systeme verteilt war. Der Kern ist in beiden Fällen derselbe wie bei Shopware/Warenwirtschaft/DATEV: verschiedene Datenmodelle so verbinden, dass am Ende ein durchgängiger, nachvollziehbarer Datensatz steht statt drei widersprüchliche.

Checkliste vor dem Start

Bevor Sie eine Agentur oder einen internen Entwickler beauftragen, klären Sie intern:

• Welche Warenwirtschaft ist im Einsatz, und gibt es dafür bereits einen offiziellen Shopware-Connector?
• Wie viele unterschiedliche Steuerfälle kommen vor (Inland, EU-Ausland, Drittland, B2B-Reverse-Charge)?
• Läuft der Verkauf nur über den eigenen Shop, oder kommen Marktplätze dazu, die ebenfalls in die Warenwirtschaft einfließen müssen?
• Wer bei Ihnen im Haus — oder beim Steuerberater — prüft, ob der DATEV-Export tatsächlich GoBD-konform ankommt?
• Ist ein AVV mit jedem beteiligten Cloud-Dienst vorhanden, sofern personenbezogene Daten fließen?

Fazit

Eine Schnittstelle zwischen Shopware, Warenwirtschaft und DATEV wird nicht chaotisch, weil eines der Systeme schlecht wäre, sondern weil die Verbindung dazwischen als Nebensache behandelt wird. Wer vorab klärt, welches Datenmodell führend ist, wie Steuerfälle gemappt werden und wie GoBD-Anforderungen technisch umgesetzt werden, spart sich die Nacharbeit, die sonst jeden Monat aufs Neue anfällt. Ob ein Standard-Connector reicht oder eine individuelle Middleware nötig ist, entscheidet sich an der Zahl der Sonderfälle — nicht am Budget für die Ersteinrichtung. Wenn Sie eine bestehende Schnittstelle überprüfen oder ein neues Integrationsprojekt planen möchten, erreichen Sie uns unter hello@pazl.ai oder über pazl.ai.