Warum das zählt. Der Bitkom-Befund zu ERP als Rückgrat für KI- und E-Commerce-Datenflüsse macht eines deutlich: Ein Shop ohne ERP-Wahrheit verkauft Bestände, die es nicht mehr gibt. Die Architekturentscheidung — Plugin, Middleware oder native Integration — entscheidet, ob das Wachstum trägt oder die Synchronisation zur Schuldenlast wird.
Wann diese Sichtweise passt — und wann nicht
Sie passt, wenn:
-
Bestände zwischen Shop und Marktplätzen auseinanderlaufen und Übersold-Fälle auftreten;
-
Online-Listenpreis und ausgehandelter B2B-Preis miteinander kollidieren;
-
Retouren manuell zwischen Shop und Finanzbuchhaltung übersetzt werden.
Sie passt weniger, wenn:
-
der Shop reiner D2C-Einzelkanal mit einem Lager bleibt;
-
kein nennenswerter Umsatz über Marktplätze läuft;
-
die Steuerlogik EU-OSS-frei und national bleibt.
Drei Architektur-Entscheidungen, die Sie nicht aufschieben können
Die Methodikfrage steht vor der Produktfrage: Welche dieser drei Entscheidungen trägt der heutige Stack — und ab wann nicht mehr?
1. Plugin, Middleware oder native ERP-Integration. Ein Plugin oder Konnektor trägt typischerweise bis etwa 5.000 Bestellungen pro Monat in einem Vertriebskanal. Sobald Multi-Channel, Multi-Lager oder EU-OSS-Steuerlogik dazukommen, wird die Übersetzungsschicht selbst zur Disziplin — das ist der Moment für Middleware (iPaaS). Übersteigt die Bestandswahrheit oder Konsolidierung die Tiefe einer iPaaS, wird die native ERP-Integration die einzig belastbare Option.
2. Kanalkonflikt und B2B-Preisdisziplin. Online-Listenpreis und ausgehandelter Verkaufspreis dürfen sich nicht widersprechen. Das ERP muss die Preiskondition aus den Kundenstammdaten ableiten — sonst entstehen Margenleckagen, die erst Monate später im Reporting sichtbar werden. Die Disziplin entscheidet sich an der Preisfindung, nicht am Shop-Frontend.
3. Finanzintegration. Datev- oder SAP-FI-Mapping vom Shop-Datenmodell ist der häufigste versteckte Showstopper. EU-OSS-Steuerlogik, Retouren-Buchung und Refund-Workflows müssen sauber abgeleitet sein — sonst tauchen die Kosten erst im Audit auf.
Typischer Fehler
Ein D2C-Online-Händler im Saarland mit 12.000 Bestellungen pro Monat verkaufte über drei Marktplätze auf Plugin-Stack. Der Bestand zwischen Shop und Marktplätzen lief auseinander; zwei Prozent der Bestellungen gingen in der Synchronisation verloren. Bis zum Mid-2026-Cutover summierte sich der Übersold-Schaden auf einen sechsstelligen Betrag, plus 1,5 Vollzeitstellen für manuelle Nachbuchung. Die Umstellung auf Middleware kam vierzehn Monate zu spät.
Aus über 1.200 begleiteten Auswahlprojekten zeigt sich: Den Inflection-Punkt erkennt man in Volumen, Channel-Zahl und Übersold-Rate — nicht im Feature-Vergleich.
Was Sie als Nächstes tun
Wenn Sie prüfen möchten, ob Ihre Shop-ERP-Architektur das nächste Wachstum trägt:
-
Bestandsverfügbarkeit: Messen Sie drei Monate die Übersold-Quote zwischen Shop und Marktplätzen.
-
Preiskondition: Dokumentieren Sie, wo Online-Listenpreis und B2B-Verhandlungspreis aktuell kollidieren.
-
Retouren-Abrechnung: Zählen Sie die manuellen FiBu-Buchungen pro Woche.
Wir prüfen mit Ihnen, ob Ihre Shop-ERP-Architektur das nächste Wachstum trägt — und benennen den Inflection-Punkt anhand Ihrer eigenen Zahlen.
FAQ
Ein Plugin-Konnektor trägt typischerweise bis etwa 5.000 Bestellungen pro Monat in einem Vertriebskanal. Darüber wachsen Synchronisationsfehler und Übersold-Risiko schneller, als sich das Plugin-Modell skalieren lässt — der Inflection-Punkt liegt zwischen Multi-Channel-Eintritt und EU-OSS-Pflicht.
Plugin passt im D2C-Einzelkanal-Modell mit einem Lager und nationaler Steuerlogik. Middleware wird sinnvoll, sobald Multi-Channel, Multi-Lager oder EU-OSS-Steuerlogik ins Spiel kommen. Der Umstieg ist die Methodikfrage, nicht die Produktauswahl.
Die FiBu-Anbindung ist der häufigste versteckte Showstopper. Datev- oder SAP-FI-Mapping muss vom Shop-Datenmodell sauber abgeleitet sein — inklusive EU-OSS-Steuerlogik, Retouren-Buchung und Refund-Workflow. Sonst tauchen die Kosten erst im Audit auf.
