Datenfluss zwischen Shop, ERP und Buchhaltung planen: Schnittstellen prüfen

Wenn der Shop wächst und die Datenflüsse nicht mitkommen

Wachsende Onlineshops kennen dieselben Probleme: manuelle Prozesse in Lager, Einkauf und Rechnungsstellung kosten Zeit und sind fehleranfällig. Echtzeit-Transparenz über Bestände, Lagerbewegungen und Margen fehlt. Shop, Versand, Buchhaltung und Reporting stehen als einzelne Tools ohne stabile Datenflüsse nebeneinander.

Bei überschaubarem Volumen genügen oft Excel-Listen, manuelle Workflows und instabile Schnittstellen. Mit mehr Bestellungen, Produkten und zusätzlichen Vertriebskanälen steigen die Anforderungen an Prozesse, Lager und Buchhaltung deutlich. Systeme mit begrenzten Erweiterungsmöglichkeiten bei Prozessen, Integrationen oder Datenstrukturen werden zum Engpass.

Entscheidend ist, ob das ERP Abläufe proaktiv automatisiert oder nur Bestellungen verwaltet. Antworten liefern nicht Funktionslisten, sondern die eigenen Datenflüsse: Richtung, Frequenz und Auslöser jedes Austauschs.

In den Vergleich gehören neben Funktionen, Automatisierung und Skalierung auch Preislogik und Kostenstruktur. Die Buchhaltung ist in dieser Kette kein Nebenprodukt, sondern ein eigener Empfänger von Daten.

Als ERP-Systeme für solche Setups erscheinen unter anderem SAP, MS Business Central, ProMode und SelectLine. Billbee und Afterbuy werden häufig in standardisierten Setups eingesetzt und unterstützen grundlegende Abläufe rund um Bestellungen und Versand; plentyONE fokussiert die Anbindung mehrerer Marktplätze und Vertriebskanäle.

Auf der Empfängerseite Buchhaltung gilt ein eigenes Formatregime: Die QR-Rechnung ist seit Juni 2020 in Umlauf und hat am 1. Oktober 2022 die Schweizer Einzahlungsscheine endgültig abgelöst. Belege, die dort ankommen, folgen damit anderen Vorgaben als Bestellungen im Shop.

Wer besitzt welche Daten? Zuständigkeiten vor der Technik klären

Vor jeder Schnittstellentechnik steht die Zuständigkeit: Für jeden Datentyp gibt es genau eine Quelle. Produktstammdaten liegen im ERP, Aktualisierungen des Bestellstatus kommen aus dem Shop.

Daraus ergeben sich die Flussrichtungen. Produktdaten, Preise und Lagerbestände gehen vom ERP in den Shop. Bestellungen, Statusänderungen und Neukundenregistrierungen laufen vom Shop ins ERP und teilweise zurück.

Im SIGVARIS-Beispiel basiert der Shop auf Magento Commerce und ist als B2B-Shop ausgelegt: Nur ein angemeldeter Benutzer kann Bestellungen ausführen. Die Produkte werden per XML aus SAP eingespeist und über ein eindeutiges Attribut dem jeweiligen Ländershop zugeteilt, pro Land mit einer zeitlichen Dimension «ab» und «bis».

Die Registrierung eines Neukunden im Shop wird nach SAP übertragen, dort einer Kundengruppe zugewiesen und beim nächsten Abgleich der Kundendaten im Shop aktualisiert. Ab dann kann der Kunde mit Login und Passwort bestellen.

Doppelerfassung entsteht, wo derselbe Datentyp in zwei Systemen gepflegt wird – bei Preisen, Beständen und Adressdaten. Fehlt ein festgelegter Besitzer, werden Korrekturen an zwei Orten vorgenommen, und die Systeme laufen auseinander. Steht der Besitzer fest, ist klar, welche Seite einer Schnittstelle schreiben darf und welche nur liest.

Bei Shopify-Integrationen gilt diese Regel konkret: Produktstammdaten liegen im ERP, Aktualisierungen des Bestellstatus kommen von Shopify. Eine einzige Quelle pro Datentyp verhindert doppelte Pflege.

Zur Stammdatenhoheit gehören auch Mengenregeln: Die Mindestbestellmenge eines Produkts ist im SIGVARIS-Shop in allen Ländershops identisch. Solche Werte gehören zur führenden Quelle ERP, sonst müssten sie je Ländershop einzeln nachgeführt werden.

Vom Bestelleingang bis zum Buchhaltungsbeleg: Datenfluss aufnehmen

Der erste Arbeitsschritt ist eine IST-Aufnahme. Geprüft werden gemeinsam die aktuelle Systemlandschaft und die bestehende ERP-Konfiguration. Alle Datenflüsse werden abgebildet und die Integrationsanforderungen festgelegt. Dokumentiert wird, welche Information wann zwischen welchen Systemen ausgetauscht werden muss.

Aufzunehmen sind mindestens: Bestellungen und Bestellstatus, Kunden- und Adressdaten, Lagerbestände und Lagerbewegungen, Preise, Produktaktualisierungen, Rechnungsstellung sowie die Übergabe der Belege an die Buchhaltung.

Pro Datenfluss werden vier Angaben festgehalten: Startgrund (Ereignis oder Zeitintervall), Laufrichtung, Takt und Format. Bei Produktdaten kommt hinzu, ob sie landes- oder kanalspezifisch gelten und ob sie einen Gültigkeitszeitraum tragen. Bei SIGVARIS werden Produkte über ein eindeutiges Attribut dem Ländershop zugeordnet und mit «ab» und «bis» pro Land geführt.

Die Übergabe an die Buchhaltung ist ein eigener Datenfluss. Sie wird mit Startgrund, Richtung, Rhythmus und Format erfasst, wie jeder andere Fluss. Für Shops mit Schwerpunkt auf Warenwirtschaft und Buchhaltung wird SelectLine häufig gewählt; E-Commerce-Prozesse werden als Teil des Gesamtsystems integriert.

Für die Belegübergabe gibt die Schweiz ein Format vor: Die QR-Rechnung besteht aus einem Zahlteil und einem Empfangsschein; der Swiss QR Code enthält alle Zahlungsinformationen in digitaler Form. Die Guidelines richten sich an Rechnungssteller, an Finanzinstitute und an Entwickler von Rechnungssteller- und Rechnungsempfänger-Software.

Das Feld Rechnungsinformationen ergänzt die üblichen Zahlungsinformationen und erlaubt der Business-Software des Rechnungsempfängers, Zuordnung und Prüfung der Rechnung zu automatisieren. Die Syntaxdefinition (S1) wird von der Arbeitsgruppe ERP der Swico definiert und gepflegt; den Validator stellt die Swico zur Verfügung.

Als weitere Wege im Zahlungsverkehr stehen eBill – die Spezifikation zur Nutzung des alternativen Verfahrens im Swiss QR Code, Version 1.1 vom 3. Februar 2020 – und die Kunde-Bank-Meldungen für Überweisungen (pain.001), Version 2.9 vom 20. November 2020, bereit.

Versionen gehören in die Planung: Die Schweizer Implementation Guidelines QR-Rechnung Version 2.3 gelten seit dem 22. November 2025. Version 2.4 gilt ab dem 14. November 2026; die strukturierte Adresse (Adresstyp «S») ist für November 2026 vorgesehen.

Strukturierte Belegdaten erhöhen den Automatisierungsgrad der Kreditoren-Buchhaltung, weil sich viele Daten aus dem Swiss QR Code auslesen lassen. Run my Accounts liest Buchung und Zahlung aus und lädt die Zahlung zur Freigabe durch den Kunden ins E-Banking.

Wer die Buchhaltung erst nach der Integration einbezieht, plant einen Fluss ohne Endpunkt. Deshalb steht die Belegübergabe von Beginn der IST-Aufnahme an in der Liste der Datenflüsse.

Ergebnis ist eine dokumentierte IST-Aufnahme. Sie dient später als Vergleichsbasis: Erst mit ihr lässt sich beurteilen, ob eine neue Integration einen Engpass tatsächlich beseitigt oder nur verschiebt.

Schnittstellen prüfen: API, Dateiaustausch und Synchronisationsrhythmus

Für die Anbindung eines Shops an ein ERP gibt es zwei Grundvarianten. Die native API des Shopsystems verbindet den Shop direkt mit dem ERP; umgesetzt wird sie über vorgefertigte Standardlösungen oder einen individuell entwickelten Konnektor. Alternativ werden strukturierte Dateiformate – meist XML – per FTP mit Push und Pull periodisch ausgetauscht.

Der Dateiaustausch kennt zwei kombinierbare Betriebsarten. Über den Tag wird in kurzen Perioden – etwa jede Stunde – inkrementell exportiert, nachts folgt ein Voll-Export. Dieses Verfahren gilt als sehr robust und fehlertolerant.

Es eignet sich für mittelgrosse Dateien, beispielsweise für 5 bis 10'000 Kunden und 10 bis 30'000 Produkte. Die kurzen Intervalle halten die Daten aktuell, der nächtliche Voll-Export korrigiert Abweichungen, die sich über den Tag aufgebaut haben. Der Nachteil: Echtzeit ist es nicht, und ein Fehler in einem Lauf wirkt bis zum nächsten.

Als eigenes Muster kommt die intervallbasierte Synchronisation dazu. Sie hält den Lagerbestand im Shop präzise und führt die Bestelldaten im ERP ohne Verzögerung nach.

Die Anbindung kann einseitig oder bidirektional ausgelegt sein. Bei der SIGVARIS AG wurde der Bestellvorgang vollständig und bidirektional an SAP angebunden. Die Bestellabwicklung ist dadurch zu 100 Prozent automatisiert – bei über 17'000 Artikeln im Shop.

Als Faustregel für die Auswahl gilt: ereignisnahe, feingranulare Änderungen wie Statuswechsel einzelner Bestellungen sprechen für die API. Umfangreiche Stammdatenmengen sprechen für den periodischen Dateiaustausch.

Shopify stellt dafür eine native API bereit. what.digital integriert Shopify über diese API in ERP-Systeme, entweder mit vorgefertigten Standardlösungen oder einem individuell entwickelten Konnektor.

Next AG setzt für SAP-Schnittstellen auf strukturierte Dateiformate, meist XML, die per FTP mit Push und Pull periodisch ausgetauscht werden. Über den Tag wird in kurzen Perioden inkrementell exportiert, nachts folgt ein Voll-Export.

DevQon GmbH baut bidirektionale Schnittstellen zwischen Magento und Kernsystemen.

Zur Schnittstellenprüfung gehört auch die Belegstrecke: der Swiss QR Code als Format, das Feld Rechnungsinformationen und die Syntaxdefinition (S1), die die Arbeitsgruppe ERP der Swico pflegt. Sie läuft neben der Bestell- und Produktschnittstelle und wird separat abgenommen.

Zu prüfen sind damit drei Muster und deren Kombination: die native API, der periodische Dateiaustausch per FTP und die intervallbasierte Synchronisation. Welches Muster trägt, entscheiden Volumen und Art der Änderung – nicht die Länge einer Funktionsliste.

Vor der Entwicklung: API-Dokumentation und Datenstrukturen beidseitig analysieren

Die Schnittstellen-Analyse ist ein eigener Arbeitsschritt vor der Entwicklung. Analysiert werden das ERP-System, die API-Dokumentation und die Datenstrukturen auf beiden Seiten. Ergebnis ist ein konkreter Architekturplan mit klaren Datenflüssen, den die Verantwortlichen vor jeder Entwicklung sehen und abnehmen.

Festgehalten werden die Feldzuordnungen zwischen Shop- und ERP-Strukturen, Pflichtfelder und zulässige Wertebereiche, die Fehlerantworten der API sowie der Zeitpunkt der Abnahme. Die DevQon GmbH analysiert das ERP-System, die API-Dokumentation und die Datenstrukturen auf beiden Seiten; diese Schnittstellen-Analyse ist kostenlos und unverbindlich. Unabhängig davon ist der Schritt günstig im Verhältnis zur danach folgenden Entwicklung.

Der Nutzen liegt in Fehlern, die hier auffallen und später Geld kosten: ein Feld, das im ERP nicht existiert, eine Statusänderung, die der Shop nicht zurückmeldet, oder ein Datentyp, für den zwei Systeme gleichzeitig als führend angenommen wurden. Wird ohne diese Prüfung entwickelt, werden Annahmen über Datenstrukturen zur Grundlage des Codes. Korrekturen werden nachträglich entsprechend teurer.

Auf der Belegseite prüft dieselbe Analyse die Feldzuordnung der Rechnungsinformationen nach der Syntaxdefinition (S1). Für die Umstellung der QR-Rechnung, etwa auf die strukturierte Adresse, stellt die SIX Merkblätter bereit; die SIX führt zudem ein Validierungsportal, die Swico den Validator für die Syntaxdefinition (S1).

Die Abnahme des Architekturplans vor der Entwicklung ist fester Bestandteil des Vorgehens. Wer Datenstrukturen erst im Code prüft, zahlt die Korrektur später.

Integrationsarchitektur und Projektplan festlegen

Aus der Analyse entstehen die Integrationsarchitektur und ein detaillierter Projektplan mit klaren Meilensteinen und festen Zeitvorgaben. Code und Dokumentation werden zentral und versioniert abgelegt – etwa in einem GitHub-Repository. So bleibt jede Änderung nachvollziehbar und existiert nicht nur auf dem Rechner einer einzelnen Person.

In der Schweiz sind es meist kleinere und mittlere Unternehmen mit gewachsenen Systemlandschaften. Die verbreiteten ERP-Systeme werden über vorgefertigte Standardlösungen oder individuelle Konnektoren angebunden. Das Spektrum reicht von SAP-Installationen bei grösseren Unternehmen bis zu flexiblen Lösungen für KMU.

Die Betriebsform des ERP gehört in die Architekturentscheidung. Wird das ERP ausschliesslich als SaaS-Lösung angeboten und über den Browser genutzt, entfällt eine lokale Installation; Dateipfade und Serverdienste im eigenen Netz stehen für den Austausch dann nicht zur Verfügung. Läuft das ERP lokal, kann der periodische Dateiaustausch auf eigenen Systemen abgewickelt werden. Diese Frage entscheidet mit, ob API, Dateiaustausch oder eine Kombination sinnvoll ist.

Neben SAP erscheinen unter anderem MS Business Central, ProMode und SelectLine. ProMode wird ausschliesslich als SaaS-Lösung angeboten und ist ohne lokale Installation über den Browser nutzbar; Kunden sitzen unter anderem in der Schweiz. Einzelhandelskunden betreiben Webshops, die über Schnittstellen an ProMode angebunden sind.

SelectLine wird häufig gewählt, wenn Warenwirtschaft und Buchhaltung im Schwerpunkt liegen; E-Commerce-Prozesse sind Teil des Gesamtsystems. Billbee und Afterbuy unterstützen in standardisierten Setups grundlegende Abläufe rund um Bestellungen und Versand; plentyONE fokussiert die Anbindung mehrerer Marktplätze und Vertriebskanäle.

Die Rechnungsstellung gehört in dieselbe Architekturentscheidung: Wird im ERP fakturiert, muss die Software die gültige Version der Implementation Guidelines QR-Rechnung unterstützen. Seit dem 22. November 2025 gilt Version 2.3, ab dem 14. November 2026 Version 2.4.

ERP-Systeme im Vergleich: Stärken und Einsatzgebiete

Testen, Go-live und Betrieb: Fehlerfälle und Schulung mitplanen

Nach der Entwicklung wird zuerst intern nach einem definierten QA-Prozess getestet. Danach folgt die Testphase beim Unternehmen selbst, mit Unterstützung bei der Fehlerbehebung. Erst wenn die Tests bestätigen, dass alles wie gewünscht funktioniert, wird die Integration bereitgestellt. Ab dann werden Leistung, Zuverlässigkeit und Sicherheit überwacht.

Zum Go-live gehören eine vollständige Integrationsdokumentation und Schulungen für das Team, damit die Datenflüsse im Alltag überprüfbar bleiben.

Überprüfbar heisst konkret: Im Betrieb müssen ein Systemausfall und ein abgebrochener Export erkannt werden. Vor dem Go-live werden die Fehlerfälle benannt: nicht angekommene Bestellung, ausgefallener API-Aufruf, abgebrochener FTP-Lauf, widersprüchliche Bestände zwischen Shop und ERP. Dazu wird festgelegt, wer sie erkennt, wie ein Lauf neu ausgelöst und wie nach einem Ausfall abgeglichen wird. Der nächtliche Voll-Export bereinigt aufgelaufene Abweichungen.

Auf der Belegseite kommen eigene Fehlerfälle dazu: eine Rechnung, deren Rechnungsinformationen die Buchhaltungssoftware nicht zuordnen kann, oder eine Validierung, die an der Version der Guidelines scheitert. Die SIX stellt dafür ein Validierungsportal bereit, die Swico einen Validator für die Syntaxdefinition (S1).

what.digital führt Entwicklung und Testen intern nach einem QA-Prozess durch, übergibt danach für die Testphase und unterstützt bei der Fehlerbehebung. Nach bestandenen Tests wird die Integration bereitgestellt und Leistung, Zuverlässigkeit und Sicherheit überwacht.

Prüfpunkte für die eigene Planung