ERP-Integration im Mittelstand: Muster, Kosten, Fehlerbilder und Beispiele aus der Praxis

Freitag, 15:40 Uhr. Im Onlineshop kommen weiter Bestellungen herein, im ERP kommt keine mehr an. Ein Zertifikat ist abgelaufen, die Schnittstelle schreibt den Fehler in eine Logdatei, die niemand liest. Am Montag stehen 140 Aufträge im Rückstand, drei Kunden haben Ware bestellt, die nicht mehr am Lager ist, und der Vertrieb telefoniert hinterher.

Das ist kein konstruierter Fall. So oder sehr ähnlich klingt der Einstieg in viele unserer Gespräche über ERP-Integration. Das ERP selbst ist selten das Problem. Das Problem sind die Strecken dazwischen: wie Daten hinein- und herauskommen, wer merkt, wenn es hakt, und wer das Ganze nach dem nächsten Update wieder geradezieht.

Dieser Leitfaden ist für Geschäftsführung, IT-Leitung und Fachbereiche im Mittelstand, die eine Anbindung planen, eine bestehende ablösen oder schlicht verstehen wollen, warum ihre Schnittstellen so viel Aufwand machen. Wenn du eher die Architekturfrage im Kopf hast, also was ins ERP gehört und was daneben, dann lies zuerst ERP im Mittelstand: Wie Individualsoftware dein ERP erweitert. Hier geht es um die Ebene darunter: die Leitungen.

Warum Integration der eigentliche Kostentreiber ist

Ein mittelständisches Unternehmen mit 100 bis 500 Mitarbeitenden betreibt selten nur ein ERP. Daneben laufen ein Onlineshop oder ein B2B-Portal, ein CRM, eine Lösung für Betriebs- oder Maschinendaten, ein Dokumentenmanagement, die Finanzbuchhaltung oder der Export zum Steuerbüro, EDI mit ein paar großen Kunden, ein Versanddienstleister, und seit 2025 ein Kanal für eingehende E-Rechnungen.

Jedes dieser Systeme ist für sich überschaubar. Teuer wird der Austausch dazwischen, aus drei Gründen:

• Jede Anbindung ist ein kleines Softwareprojekt, auch wenn sie im Angebot als Position „Schnittstelle“ auftaucht. Sie braucht Anforderungen, Tests, Betrieb und Pflege.
• Schnittstellen altern schneller als Systeme. Das ERP bekommt ein Update, der Shop eine neue API-Version, der EDI-Partner ein neues Format. Jede Änderung auf einer Seite trifft die Strecke.
• Fehler sind unsichtbar, bis sie teuer sind. Eine abgestürzte Anwendung bemerkt jeder. Eine Schnittstelle, die still nichts tut, bemerkt erst der Kunde.

Deshalb lohnt es sich, Integration nicht als technisches Detail zu behandeln, sondern bewusst zu entscheiden: welches Muster, welche Kosten, welche Absicherung.

Die sechs Integrationsmuster

Es gibt viele Produktnamen und Schlagworte, aber im Kern nur eine Handvoll Muster, wie zwei Systeme Daten austauschen. Jedes hat seinen Platz, und jedes hat einen Preis, der nicht im Angebot steht.

Dazu eine Randnotiz zu RPA, also Software-Robotern, die eine Oberfläche bedienen wie ein Mensch: Das ist kein Integrationsmuster, sondern ein Notbehelf für Systeme ohne jede Schnittstelle. Als Brücke für ein paar Monate kann das vertretbar sein. Als Dauerlösung bricht es bei jeder Änderung an einer Bildschirmmaske.

Welches Muster wann?

In der Praxis reichen vier Fragen, um die Wahl einzugrenzen:

1. Wie schnell muss es ankommen? Reicht über Nacht, ist Dateiaustausch oft die robusteste und günstigste Lösung. Muss es in Sekunden da sein, führt kein Weg an API und Ereignissen vorbei.
2. In welche Richtung fließt es? Lesen ist günstig, Schreiben teuer. Wer in das ERP schreibt, muss dessen Regeln einhalten, und das geht nur über die freigegebene Schnittstelle.
3. Wie viele Systeme hängen dran? Eine Strecke darf direkt laufen. Ab der dritten oder vierten, die alle dieselben Kunden, Artikel und Aufträge brauchen, zahlt sich eine gemeinsame Integrationsschicht aus, weil sie Anmeldung, Feldzuordnung und Fehlerbehandlung einmal statt mehrfach erledigt.
4. Was passiert, wenn die Strecke ausfällt? Wenn die Antwort „dann steht der Versand“ lautet, brauchst du Pufferung, Wiederanlauf und Alarm. Wenn sie „dann ist der Bericht morgen einen Tag alt“ lautet, nicht.

Die häufigste Fehlentscheidung ist übrigens nicht ein zu einfaches Muster, sondern ein zu großes: eine Middleware-Plattform mit Lizenz, Schulung und eigenem Betrieb für zwei Strecken, die ein sauberer API-Aufruf erledigt hätte.

Was ERP-Integration realistisch kostet

Die ehrliche Antwort auf „Was kostet eine Schnittstelle?“ lautet: Das hängt weniger von der Technik ab als von der Klarheit der Daten und der Mitarbeit des ERP-Partners. Trotzdem braucht man Größenordnungen, um ein Budget zu planen. Die folgenden Werte sind Erfahrungswerte aus Projekten im Mittelstand, keine Preisliste. Sie gelten für die Umsetzung durch einen Dienstleister, ohne Lizenzkosten für ERP oder Middleware.

Für den laufenden Betrieb solltest du jährlich mit 15 bis 25 Prozent der Erstellungskosten rechnen: Überwachung, Anpassungen an ERP- und Partner-Updates, Zertifikate, kleine fachliche Änderungen. Wer diesen Posten nicht einplant, zahlt ihn trotzdem, nur später und als Notfall.

Die Posten, die in Angeboten fehlen

Die Abweichung zwischen Angebot und Ist entsteht fast immer an denselben Stellen:

• Datenbereinigung. Dubletten im Kundenstamm, Artikel mit drei Mengeneinheiten, Freitextfelder, in denen seit Jahren Steuerungsinformation steht. In unseren Projekten frisst das regelmäßig 20 bis 40 Prozent des Aufwands, und niemand hat es angeboten.
• Stunden beim ERP-Partner. Schnittstellen müssen freigeschaltet, Berechtigungen eingerichtet, manchmal Felder ergänzt werden. Das erledigt dein ERP-Partner, nach seinem Stundensatz und seinem Kalender.
• Ein Testsystem. Viele Mittelständler haben kein ERP-Testsystem mit realistischen Daten. Ohne eines wird in Produktion getestet, und das ist teurer als jedes Testsystem.
• Lizenzen für indirekte Nutzung. Manche ERP-Hersteller berechnen Zugriffe über Drittsysteme gesondert. Bei SAP heißt das Modell Digital Access und bemisst sich an Belegen, die über Fremdsysteme entstehen. Kläre das vor der Umsetzung schriftlich, nicht nach dem ersten Audit.
• Zeit der Fachabteilung. Die Feldzuordnung kann nur jemand abnehmen, der den Prozess kennt. Diese Stunden fallen in deinem Haus an, nicht beim Dienstleister.

Ein Rechenbeispiel

Drei Mitarbeitende im Innendienst übertragen jeden Tag zusammen etwa drei Stunden Bestellungen aus dem Shop und aus E-Mails ins ERP. Bei 220 Arbeitstagen sind das 660 Stunden im Jahr. Mit einem Vollkostensatz von 45 Euro pro Stunde ergibt das rund 30.000 Euro, ohne die Kosten der Tippfehler: falsche Lieferadressen, falsche Mengen, Gutschriften.

Eine saubere beidseitige Anbindung kostet in diesem Fall vielleicht 35.000 Euro, der Betrieb 7.000 Euro im Jahr. Nach gut anderthalb Jahren ist sie bezahlt, und die drei Mitarbeitenden kümmern sich um Kunden statt um Abtippen. Rechne deinen Fall genauso: Arbeitszeit für manuelle Übertragung plus Fehlerkosten gegen Erstellung plus Betrieb. Wenn die Rechnung nach drei Jahren nicht aufgeht, ist die Excel-Liste vielleicht doch die richtige Lösung, vorerst.

Acht Fehlerbilder, an denen Integrationen scheitern

Wir werden oft gerufen, wenn eine Integration schon läuft und trotzdem Ärger macht. Die Ursachen wiederholen sich erstaunlich zuverlässig.

1. Stille Fehler. Die Schnittstelle bricht ab und schreibt das in ein Log, das niemand liest. Das ist der häufigste und teuerste Fehler, weil er Tage unbemerkt bleibt. Gegenmittel: Jede Strecke braucht eine Überwachung, die einen Menschen benachrichtigt, und zwar im Fachbereich, nicht nur in der IT. Nachrichten, die nicht verarbeitet werden konnten, landen in einer Fehlerablage, aus der man sie nach der Korrektur erneut anstoßen kann.

2. Ungeklärte Datenhoheit. Kundenadressen werden im CRM und im ERP gepflegt, beide Seiten synchronisieren in beide Richtungen, und nach einem halben Jahr weiß niemand mehr, welche Adresse stimmt. Gegenmittel: Für jedes Datenobjekt genau ein führendes System, schriftlich festgehalten. Wie so eine Datenhoheitsmatrix aussieht, steht in unserem ERP-Beitrag.

3. Doppelte Verarbeitung. Eine Nachricht wird nach einem Timeout erneut gesendet, und plötzlich stehen zwei identische Aufträge im ERP, mit zwei Lieferungen und zwei Rechnungen. Gegenmittel: Jede Nachricht trägt einen eindeutigen Schlüssel, und der Empfänger prüft, ob er ihn schon kennt. Fachleute nennen das Idempotenz, im Alltag heißt es: Zweimal senden darf nicht zweimal buchen.

4. Das ERP-Update bricht die Strecke. Nach dem Release-Wechsel heißt ein Feld anders, ein Pflichtfeld ist neu, eine Schnittstelle ist abgekündigt. Gegenmittel: Jede Strecke hat einen beschriebenen Vertrag, was sie liefert und erwartet, und automatisierte Tests, die vor jedem Update gegen ein Testsystem laufen.

5. Schreibender Zugriff auf die Datenbank. Er war schnell gebaut und hat lange funktioniert. Er umgeht aber Preisfindung, Bestandsführung, Berechtigungen und Änderungsprotokoll des ERP, und bei einem Problem lehnt der Hersteller die Unterstützung ab. Gegenmittel: Schreiben nur über freigegebene Schnittstellen, ohne Ausnahme.

6. Gleiche Felder, unterschiedliche Bedeutung. „Menge“ ist im Shop Stück, im ERP Karton zu zwölf. Der Shop rundet Preise auf zwei Stellen, das ERP rechnet mit vier. Ein Zeitstempel kommt in UTC, der andere in deutscher Ortszeit. Steuerschlüssel passen nicht zueinander. Gegenmittel: Feldzuordnung mit dem Fachbereich abnehmen, nicht nur mit der IT, und Grenzfälle wie Teillieferung, Storno und Gutschrift ausdrücklich testen.

7. Wissen in einem Kopf. Die Schnittstelle hat ein Werkstudent 2019 gebaut, oder ein ehemaliger Mitarbeiter des ERP-Partners. Dokumentation gibt es nicht, der Quellcode liegt auf einem Server, den niemand anfassen will. Gegenmittel: Quellcode in deiner Versionsverwaltung, eine Seite Dokumentation pro Strecke, eine benannte fachliche und technische Verantwortung.

8. Die Lizenzüberraschung. Die Integration läuft, dann kommt die Vermessung des ERP-Herstellers und stellt indirekte Nutzung in Rechnung. Gegenmittel: Die Frage nach Lizenzen für Zugriffe über Drittsysteme gehört in die Machbarkeitsprüfung, nicht in die Nachkalkulation.

Bemerkenswert ist, was in dieser Liste fehlt: die Wahl der Programmiersprache, des Frameworks oder der Middleware. Integrationen scheitern selten an der Technik. Sie scheitern daran, dass niemand entschieden hat, wem die Daten gehören, wer zuständig ist und wer es merkt, wenn etwas schiefgeht.

Integration mit KI umsetzen: was günstiger wird, und der Trugschluss dahinter

Ein Coding-Agent schreibt den Mapping-Code für eine Schnittstelle heute in Minuten. Der naheliegende Schluss: Dann kostet die Anbindung jetzt nur noch einen Bruchteil. Genau das ist der Trugschluss, und er ist teuer, weil er Budgets und Erwartungen an der falschen Stelle kürzt.

Wo KI die Umsetzung wirklich beschleunigt

Richtig eingesetzt, nimmt KI einem Integrationsprojekt viel Fleißarbeit ab:

• Schnittstellendoku und Feldkataloge lesen und daraus einen ersten Entwurf der Feldzuordnung erstellen, statt ihn abzutippen.
• Mapping- und Verbindungscode schreiben, also den Teil, der Felder umsetzt, Formate wandelt und Aufrufe zusammenbaut.
• Testfälle und Testdaten erzeugen, auch für Grenzfälle wie Teillieferung, Storno oder Sonderzeichen in Adressen.
• Alte Strecken verstehen. Die Regeln aus einer gewachsenen Excel-Datei oder einer undokumentierten Altschnittstelle herauslesen und als Liste aufbereiten, die der Fachbereich prüfen kann.
• Dokumentation nebenbei mitschreiben, statt sie am Ende zu streichen.

In diesen Teilen arbeiten wir mit KI-Unterstützung spürbar schneller, je nach Strecke grob 30 bis 50 Prozent.

Warum das Budget trotzdem nicht im selben Maß sinkt

Code ist nur ein Teil des Aufwands. Legt man eine typische Anbindung auseinander, sieht die Rechnung so aus:

Unterm Strich wird eine Anbindung mit KI in der Umsetzung realistisch 10 bis 20 Prozent günstiger, nicht um die Hälfte. Die 35.000 Euro aus dem Rechenbeispiel werden eher 28.000 bis 31.000 Euro. Der laufende Betrieb ändert sich kaum, denn Überwachung, ERP-Updates und Zertifikate verschwinden nicht, nur weil der Code schneller entstanden ist.

Der Trugschluss: schneller Code ist nicht schneller fertig

Gefährlicher als die überschätzte Ersparnis sind die Fehler, die KI-generierte Integrationen typischerweise mitbringen. Sie sehen alle gleich aus: Der Code läuft, die Tests sind grün, und das Problem zeigt sich erst im Betrieb.

Plausibel, aber falsch zugeordnet. Ein Modell ordnet Felder nach ihrem Namen zu. „Menge“ wird zu „Quantity“, und dass das eine Stück und das andere Karton meint, steht in keinem Feldnamen. Das ist Fehlerbild Nummer sechs, nur schneller produziert.

Erfundene oder veraltete Schnittstellen. Das Modell kennt die API-Version deines ERP nicht genau und ergänzt, was plausibel klingt: ein Feld, das es nicht gibt, einen Endpunkt, der abgekündigt ist. Das fällt erst gegen das echte System auf. Die Machbarkeitsprüfung am echten System wird mit KI also wichtiger, nicht überflüssig.

Tests, die den Irrtum bestätigen. Schreibt dieselbe KI Code und Tests aus derselben falschen Annahme, sind die Tests grün und beweisen nichts. Testfälle müssen aus echten Daten und vom Fachbereich kommen. Warum Agenten ihre eigene Arbeit nicht benoten sollten, beschreiben wir in Verifizierung & Kontrolle: Agenten benoten sich nicht selbst.

Nur der Gutfall ist gebaut. Generierter Code deckt den Normalfall gut ab. Doppelte Nachrichten, Wiederanlauf, Fehlerablage und Alarm entstehen nur, wenn jemand sie ausdrücklich verlangt. Genau diese Teile entscheiden aber über die Kosten im Betrieb, siehe Fehlerbild eins und drei.

Viel Code, kein Kopf dahinter. Wo früher eine Person die Schnittstelle gebaut und verstanden hat, entsteht jetzt in einem Nachmittag mehr Code, als jemand gelesen hat. Das verschärft Fehlerbild sieben. Jede Zeile braucht ein Review und eine benannte Verantwortung, egal wer sie geschrieben hat.

Echte Daten im Prompt. Wer zum Entwickeln echte Kundenstämme oder ERP-Auszüge in einen Cloud-Dienst kopiert, gibt Geschäftsgeheimnisse und personenbezogene Daten weiter. Gearbeitet wird mit anonymisierten Testdaten oder mit Modellen, deren Betrieb du kontrollierst. Wann sich eigener Betrieb lohnt, haben wir in Lohnt sich ein lokales KI-Setup für dein Unternehmen? durchgerechnet.

Die Faustregel

KI senkt die Kosten der Tipparbeit, nicht die Kosten der Entscheidungen. Wer dir mit KI eine Anbindung zum halben Preis anbietet, hat entweder Datenbereinigung, Abstimmung und Betrieb nicht eingerechnet, oder er spart an Fehlerbehandlung und Tests. Beides kommt später zurück, als stiller Fehler am Freitagnachmittag.

Richtig eingesetzt ist KI trotzdem ein echter Gewinn: Die gesparte Zeit gehört in die Teile, die früher aus Budgetgründen zu kurz kamen, also in Grenzfall-Tests, Überwachung und Dokumentation. Dann wird die Anbindung nicht nur etwas günstiger, sondern vor allem robuster.

Vier Fälle aus der Praxis

Die folgenden Fälle sind typische Konstellationen, wie sie uns im Mittelstand immer wieder begegnen. Sie zeigen, wie Muster, Kosten und Fehlerbilder in einem konkreten Vorhaben zusammenkommen.

1. Onlineshop und ERP

Ausgangslage: Ein Großhändler verkauft über einen B2B-Shop. Bestände und Preise werden nachts als Datei übertragen, Bestellungen per E-Mail-Export ins ERP abgetippt. Folge: Der Shop verkauft tagsüber Ware, die längst weg ist, und kundenspezifische Preise stimmen nicht.

Lösung: Bestellungen gehen per API direkt ins ERP, mit eindeutiger Bestellnummer als Schlüssel, damit ein erneuter Versand nicht doppelt bucht. Bestände meldet das ERP bei jeder Änderung als Ereignis an den Shop. Der Shop hält eine Lesekopie mit festgelegtem Höchstalter, damit er auch während eines ERP-Wartungsfensters verkaufen kann. Kundenpreise fragt der Shop live ab, weil sie zu viele Kombinationen für eine Kopie haben. Das ERP bleibt führend für Kunden, Artikel, Preise und Aufträge, der Shop für Warenkörbe und Sitzungen.

Worauf es ankam: Die Hälfte des Aufwands steckte nicht in der API, sondern in Artikeln, deren Mengeneinheiten im ERP nicht zum Shop passten.

2. E-Rechnung im Ein- und Ausgang

Ausgangslage: Seit dem 1. Januar 2025 müssen Unternehmen im Inland E-Rechnungen empfangen können. Ab dem 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz sie auch ausstellen, ab 2028 gilt das für alle. Viele Betriebe haben den Empfang zunächst pragmatisch gelöst: Die XML-Datei wird in ein PDF umgewandelt, ausgedruckt und von Hand gebucht. Damit ist die Pflicht formal erfüllt und der Nutzen verschenkt.

Lösung: Eingehende Rechnungen landen in einem zentralen Postfach, werden automatisch gegen die Formate XRechnung und ZUGFeRD geprüft, mit Bestellung und Wareneingang aus dem ERP abgeglichen und nur bei Abweichung einem Menschen zur Freigabe vorgelegt. Danach entsteht die Kreditorenbuchung über die Schnittstelle des ERP. Für den Ausgang prüfst du, ob dein ERP die Formate in der aktuellen Version selbst erzeugt. Oft genügt ein Update, manchmal fehlen Pflichtangaben im strukturierten Datensatz, weil sie bisher nur als Freitext auf dem PDF standen.

Worauf es ankam: Der automatische Abgleich mit Bestellung und Wareneingang ist der eigentliche Gewinn. Die Formatprüfung allein ist Pflicht, der Abgleich spart Arbeit.

3. Fertigung und ERP

Ausgangslage: Ein Zulieferer erfasst Maschinenzeiten und Stückzahlen in einer Lösung für Betriebsdaten. Die Rückmeldung der Fertigungsaufträge ins ERP passiert per Hand am Schichtende, oft am nächsten Morgen. Die Nachkalkulation ist dadurch ungenau, und der Vertrieb kennt den echten Auftragsstand nicht.

Lösung: Die Fertigungsaufträge kommen aus dem ERP an die Maschine, Rückmeldungen gehen als Ereignisse zurück. Wichtig ist die Verdichtung: Nicht jedes Taktsignal gehört ins ERP, sondern gemeldete Mengen, Ausschuss und Zeiten pro Arbeitsgang. Fällt die Verbindung zur Halle aus, puffert die Fertigungsseite die Meldungen und reicht sie nach, in der richtigen Reihenfolge.

Worauf es ankam: Die Absprache, welche Daten ins ERP gehören und welche in der Fertigung bleiben. Wer jedes Sensorsignal ins ERP schreibt, legt es lahm.

4. EDI mit einem Großkunden

Ausgangslage: Ein Automobilkunde verlangt Lieferabrufe und Lieferavis elektronisch, zum Beispiel über EDIFACT-Nachrichten wie DELFOR und DESADV, mit Fristen und Vertragsstrafen. Bisher kamen Abrufe als PDF.

Lösung: Ein EDI-Dienstleister übernimmt den Transport und die Übersetzung der Formate, die Anbindung an das ERP läuft als Dateiaustausch oder per API. Abrufe werden automatisch als Lieferplanpositionen angelegt, Abweichungen zum Vorabruf werden hervorgehoben. Das Lieferavis entsteht aus der Versandbuchung im ERP, nicht aus einer zweiten Erfassung.

Worauf es ankam: Die Testphase mit dem Kunden, die oft länger dauert als die Umsetzung selbst. Plane sie im Zeitrahmen ein, nicht als Puffer.

So gehst du vor: fünf Schritte

1. Schnittstelleninventar. Liste jede Strecke auf, die heute existiert, auch die manuellen. Wer liefert was an wen, wie oft, auf welchem Weg, und wer merkt es, wenn es ausbleibt. Allein diese Liste überrascht die meisten Unternehmen.
2. Datenhoheit klären. Für jedes Datenobjekt ein führendes System, schriftlich festgehalten.
3. Machbarkeit am echten System. Bevor fachliche Logik entsteht, wird bewiesen, dass das ERP die nötigen Daten über freigegebene Schnittstellen liefert und annimmt, in ausreichender Menge, ohne Lizenzüberraschung. Dein ERP-Partner sitzt hier mit am Tisch.
4. Ein Vorgang komplett in Produktion. Lieber eine Strecke von Anfang bis Ende mit echten Daten als drei halbe. Wie man diesen ersten Durchstich zuschneidet, beschreiben wir in Requirements Engineering im iterativen Zyklus.
5. Überwachung vor dem Rollout. Alarm, Fehlerablage, Wiederanlauf und Verantwortliche stehen, bevor die Strecke breit ausgerollt wird. Danach läuft vor jedem ERP-Update der Regressionstest.

Neun Fragen an deinen Dienstleister, bevor du unterschreibst

• Welches Integrationsmuster schlagt ihr vor, und warum nicht ein einfacheres?
• Wer ist für welches Datenobjekt führend, und wo steht das?
• Was passiert, wenn eine Nachricht doppelt ankommt?
• Wer wird benachrichtigt, wenn die Strecke ausfällt, und wie schnell?
• Wie wird die Strecke vor einem ERP-Update getestet?
• Welche Lizenzkosten entstehen beim ERP-Hersteller durch die Anbindung?
• Wie viel Aufwand ist für Datenbereinigung eingeplant?
• Wo setzt ihr KI ein, wer prüft die Ergebnisse, und mit welchen Daten wird gearbeitet?
• Gehören Quellcode und Dokumentation am Ende uns?

Wer diese Fragen klar beantworten kann, hat Integration schon einmal betrieben und nicht nur gebaut. Das ist der Unterschied, auf den es ankommt.