ERP-Schnittstellen und ERP-Integration: welche Art passt und worauf es im Betrieb ankommt

Was ist eine ERP-Schnittstelle, und was heißt ERP-Integration?

Eine ERP-Schnittstelle ist eine vom Hersteller oder vom Projekt festgelegte Stelle, über die Daten in das ERP hinein oder aus ihm heraus fließen. ERP-Integration meint das Ganze darum: welche Systeme verbunden sind, welches System welche Daten führt, wie Fehler behandelt werden und wer den Betrieb überwacht.

Steuerlich ist eine Schnittstelle kein Nebenschauplatz. Die GoBD zählen zum DV-System ausdrücklich das Hauptsystem sowie Vor- und Nebensysteme, etwa Warenwirtschaft, Fakturierung, Zahlungsverkehr, Archiv- und Dokumenten-Management-System, einschließlich der Schnittstellen zwischen den Systemen (Rz. 20). Was über eine Schnittstelle in die Buchhaltung gelangt, muss also denselben Ordnungsregeln genügen wie eine Eingabe von Hand.

Die erste Entscheidung ist deshalb fachlich, nicht technisch: Für jedes Datenobjekt (Kunde, Artikel, Preis, Auftrag, Rechnung, Buchung) steht fest, welches System es führt. Alle anderen Systeme lesen nur oder schlagen Änderungen vor. Fehlt diese Festlegung, überschreiben sich zwei Systeme gegenseitig, und keine Schnittstelle der Welt löst das.

Welche Arten von ERP-Schnittstellen gibt es?

Es gibt sechs Grundarten: APIs auf Basis von REST oder OData, SOAP-Webservices, den Austausch von Dateien, EDI-Nachrichten, Ereignisse beziehungsweise Webhooks und den direkten Datenbankzugriff. Die meisten ERP-Systeme bieten mehrere davon gleichzeitig an. SAP nennt für die ABAP-Umgebung die Protokolle OData, HTTP, RFC und SOAP für eingehende und ausgehende Kommunikation, dazu das Bereitstellen und Konsumieren von Ereignissen.

Bei SOAP lohnt ein Blick auf die Herstellerplanung. Microsoft empfiehlt für Business Central online API oder OData statt SOAP, weil sie schneller ausgeführt werden, und kündigt an, den Durchsatz für SOAP zu reduzieren und SOAP künftig abzukündigen. Eine neue Verbindung auf SOAP aufzubauen, ist dort also eine Entscheidung mit Ablaufdatum.

EDI ist die Art, bei der Ihr Kunde oder Lieferant das Format vorgibt. GS1 beschreibt EANCOM als Teilmenge des Standards UN/EDIFACT, die nur die für Geschäftsanwendungen nötigen Elemente enthält. In der Automobilindustrie führt der VDA eine eigene Liste: Die alten Flatfile-Empfehlungen VDA 4905 für Lieferabrufe und VDA 4913 für Lieferscheindaten sind dort durch die EDIFACT-basierten Empfehlungen VDA 4984 (Global DELFOR) und VDA 4987 (Global DESADV) ersetzt, wobei der VDA zu 4913 vermerkt, dass sie noch verbreitet verwendet wird. Als Übertragungsweg ersetzt OFTP2 die alte VDA 4914. openTRANS 2.1 ist ein Format für Geschäftsdokumente wie Auftrag, Lieferschein und Rechnung auf Basis von BMEcat, veröffentlicht vom Fraunhofer IAO am 02.10.2009.

Wie Bestellungen über EDI, PDF oder Mail zum Auftrag werden, steht auf der Seite zur automatisierten Auftragserfassung. Hier geht es um die Schnittstelle selbst.

Warum ist der direkte Datenbankzugriff riskant?

Schreibender Datenbankzugriff am ERP vorbei ist die riskanteste Art der Integration, weil er Prüfregeln, Berechtigungen und Protokolle des ERP umgeht. SAP stuft in seinem Modell für saubere Erweiterungen Schreibzugriffe auf SAP-Tabellen gemeinsam mit Modifikationen in die Stufe mit dem höchsten Risiko ein, die erhebliche technische Schulden erzeuge. Für die oberste Stufe nennt SAP nur öffentlich freigegebene, stabile Schnittstellen mit formalen Stabilitätszusagen.

Das Problem ist nicht nur die Technik. Ein ERP prüft beim Anlegen eines Belegs Nummernkreise, Pflichtfelder, Sperren und Folgebuchungen. Ein direkter Tabelleneintrag kennt diese Logik nicht. Die GoBD verlangen, dass durch Erfassungs-, Übertragungs- und Verarbeitungskontrollen sichergestellt ist, dass Geschäftsvorfälle vollständig erfasst und danach nicht unbefugt oder ohne Nachweis des vorherigen Zustands verändert werden können (Rz. 88).

Lesender Zugriff ist anders zu bewerten. Manche Hersteller bieten dafür selbst einen Weg an, abas zum Beispiel einen MS SQL Connector für den Export von ERP-Daten. Lesen über einen solchen dokumentierten Weg ist für Auswertungen vertretbar. Wer aber Tabellen ohne Herstellerweg liest, muss nach jedem Update prüfen, ob die Struktur noch stimmt.

Punkt-zu-Punkt oder Integrationsschicht: was passt?

Punkt-zu-Punkt reicht, solange wenige Systeme verbunden sind und jede Verbindung einen klaren Zweck hat. Eine Integrationsschicht lohnt sich, sobald mehrere Systeme dieselben Daten brauchen oder ein Fehler an einer Stelle mehrere Abläufe betrifft. Bei fünf Systemen, die alle miteinander sprechen, sind es rechnerisch bis zu zehn Einzelverbindungen, jede mit eigener Fehlerbehandlung und eigenem Protokoll.

Eine Integrationsschicht, oft Middleware oder als Cloud-Dienst iPaaS genannt, ist ein Baustein zwischen den Systemen. Er übernimmt Übersetzung der Formate, Zuordnung der Felder, Wiederholung bei Fehlern, Protokollierung und Überwachung an einer Stelle. Ob das ein gekauftes Produkt, ein Dienst beim Cloud-Anbieter oder eine schlanke eigene Anwendung ist, ist zweitrangig. Wichtig ist, dass Regeln und Protokolle zentral liegen und nicht in zehn Skripten.

Wie gehen gute Schnittstellen mit Fehlern, Wiederholungen und Dubletten um?

Eine Schnittstelle ist erst fertig, wenn feststeht, was bei einem Fehler passiert: Sie wiederholt nur, was gefahrlos wiederholbar ist, erkennt Dubletten selbst und meldet alles andere an einen Menschen. Der Normalfall ist leicht. Die Arbeit steckt in den Ausnahmen.

Die Grundlage für Wiederholungen steht in RFC 9110. Eine Methode gilt als idempotent, wenn mehrere gleiche Anfragen dieselbe Wirkung haben wie eine einzige. PUT, DELETE und sichere Methoden wie GET sind idempotent, POST nicht. Ein Client soll eine nicht idempotente Anfrage nicht automatisch wiederholen, außer er kann erkennen, dass die erste Anfrage nicht ausgeführt wurde. Genau das ist der typische Fall beim Anlegen eines Auftrags: Die Verbindung bricht ab, die Antwort fehlt, und niemand weiß, ob der Auftrag schon im ERP steht. Deshalb braucht jede anlegende Schnittstelle einen fachlichen Schlüssel, etwa die Bestellnummer des Kunden oder die Belegnummer des Vorsystems, und prüft vor dem zweiten Versuch, ob es den Beleg schon gibt.

Die Hersteller geben die Signale vor. Business Central online beantwortet zu viele Anfragen mit HTTP 429, eine zu lange Warteschlange nach acht Minuten mit 503 und eine zu lange Ausführung mit 408. Microsoft verweist ausdrücklich auf eine Wiederholungslogik mit Pause. SAP sieht in der ABAP-Umgebung für nicht idempotente Anfragen standardmäßig nur bei 408, 429 und 503 eine Wiederholung vor, für idempotente bei einer längeren Liste, darunter 500, 502, 503 und 504.

Ereignisse ersetzen keinen Abgleich. Business Central versucht laut Microsoft bei nicht erreichbarem Empfänger über 36 Stunden mehrere Zustellungen, aber nur, wenn der Empfänger mit 408, 429 oder einem 5xx-Fehler antwortet. Bei jedem anderen Code wird nicht wiederholt und das Abo gelöscht.

Was muss eine ERP-Schnittstelle protokollieren?

Eine Schnittstelle, die buchungsrelevante Daten überträgt, muss nachweisen können, was wann übertragen, abgewiesen oder geändert wurde. Die GoBD verlangen Kontrollen bei Erfassung, Übertragung und Verarbeitung und schreiben vor, dass deren Durchführung protokolliert wird (Rz. 88). Zum internen Kontrollsystem zählen sie unter anderem Zugriffsberechtigungskontrollen, Funktionstrennung, Plausibilitätsprüfungen und Abstimmungskontrollen bei der Dateneingabe (Rz. 100).

Zwei Randziffern betreffen Schnittstellen sehr direkt. Werden verdichtete Zahlen ins Hauptsystem übernommen, müssen die Einzelaufzeichnungen im Vor- oder Nebensystem erhalten bleiben (Rz. 99). Und als unzulässig nennen die GoBD ausdrücklich, Grundaufzeichnungen über eine Datenschnittstelle in ein Office-Programm zu exportieren, dort unprotokolliert zu ändern und wieder zu importieren (Rz. 109). Für jedes DV-System verlangen die GoBD außerdem eine Verfahrensdokumentation, die für einen sachverständigen Dritten in angemessener Zeit nachprüfbar ist (Rz. 151). Schnittstellen gehören dort hinein.

Praktisch heißt das: Jede Übertragung bekommt eine Kennung, einen Zeitstempel, die Zahl der Sätze, das Ergebnis und bei Ablehnung den Grund. Korrekturen laufen im Quellsystem oder in einer protokollierten Prüfstrecke, nicht in einer Datei zwischendurch. Wie lange die Protokolle aufzubewahren sind und was in Ihre Verfahrensdokumentation gehört, stimmen Sie mit Ihrer Steuerberatung ab.

• Übertragungskennung, Zeitpunkt, Quelle und Ziel
• Anzahl gesendeter, angenommener und abgelehnter Sätze
• Fachlicher Schlüssel je Beleg, zum Beispiel Belegnummer des Vorsystems
• Fehlertext des Zielsystems im Wortlaut
• Wer eine Ablehnung bearbeitet und erneut gesendet hat

Wer greift zu: Service-User, Berechtigungen und Lizenzen

Eine Schnittstelle meldet sich mit einem eigenen technischen Benutzer an, nie mit dem Konto eines Mitarbeiters, und bekommt nur die Rechte, die sie für ihre Aufgabe braucht. Die Hersteller haben dafür eigene Wege. In SAP S/4HANA Cloud Public Edition legt ein Administrator einen Kommunikationsbenutzer, ein Kommunikationssystem und eine Kommunikationsvereinbarung an. Die Vereinbarung legt fest, welches System mit welchem Benutzer welche Dienste aufrufen darf.

Für Business Central online beschreibt Microsoft die Service-zu-Service-Anmeldung über den OAuth-Client-Credentials-Ablauf für Integrationen ohne Benutzerinteraktion. Die Anwendung wird in Microsoft Entra registriert und in Business Central mit Berechtigungssätzen versehen. Den Berechtigungssatz SUPER darf sie nicht erhalten, Microsoft verlangt das Prinzip der geringsten Rechte. Die Limits gelten für Anwendungsbenutzer genauso wie für Personen.

Lizenzen sind ein eigener Prüfpunkt, kein Detail. SAP fasst im Modell Digital Access indirekten menschlichen Zugriff über Fremdsoftware, Geräte, Bots und automatisierte Systeme zusammen. Gezählt wird laut SAP nur das Anlegen von Belegpositionen in neun Belegarten, Lesen, Ändern und Löschen zählen nicht. Unbeaufsichtigte Bots von Drittanbietern brauchen danach eine zusätzliche Lizenz über Digital Access. Für Business Central verweist Microsoft für externe und nicht interaktive Zugriffe auf den Lizenzleitfaden. Welche Regel für Ihren Vertrag gilt, steht in Ihrem Vertrag, nicht auf dieser Seite. Klären Sie das vor dem Bau mit Ihrem Lizenzgeber.

Welche ERP-Verbindungen braucht ein Mittelständler typischerweise?

Die meisten Unternehmen brauchen dieselben fünf bis sechs Verbindungen: zur Buchhaltung, zum Shop, zum CRM, zum Dokumentenarchiv, zum Berichtswesen und in Gruppen zwischen mehreren ERPs. Entscheidend ist je Verbindung, welches System führt und in welche Richtung die Daten fließen.

Für die Verbindung zu DATEV gilt: Die Anbindung der DATEV-Datenservices, also der Online-APIs, steht laut DATEV jedem interessierten Softwarehersteller offen, für Prüfung und Freigabe gelten die DATEV-Schnittstellenvorgaben. Welche Wege es gibt und woran Importe scheitern, steht auf der Seite zur DATEV-Schnittstelle am ERP. Für Unternehmensgruppen ist eine Grenze von Business Central online wichtig: höchstens 300 Mandanten je Umgebung.

Was bieten SAP, Business Central, DATEV, abas und Abacus offiziell an?

Jeder große ERP-Hersteller bietet heute eine dokumentierte API und mindestens einen Datei- oder Nachrichtenweg an. Die Tabelle nennt nur, was in der Herstellerdokumentation steht. Details, Grenzen und Abläufe je System stehen auf den jeweiligen Detailseiten.

Ablauf in 7 Schritten

1. 01
   Datenhoheit festlegen

   Für jedes Datenobjekt steht fest, welches System es führt und wer es ändern darf. Das ist die Grundlage für jede Schnittstelle.

2. 02
   Weg je Verbindung wählen

   API, Datei, EDI oder Ereignis, nach den Fragen: Wie schnell, wie viel, welches Format gibt der Partner vor, was bietet der Hersteller offiziell an.

3. 03
   Fehlerfälle vor dem Normalfall klären

   Fachlicher Schlüssel gegen Dubletten, Wiederholungsregeln, Umgang mit fehlenden Stammdaten, Meldeweg an Ihr Team.

4. 04
   Technischen Benutzer und Lizenz klären

   Eigener Benutzer je Schnittstelle mit geringsten Rechten, Lizenzfrage zum indirekten Zugriff mit dem Lizenzgeber geklärt.

5. 05
   In der Testumgebung mit echten Daten prüfen

   Ein Ablauf auf echten Daten, inklusive absichtlich falscher Sätze, Lastspitze und Verbindungsabbruch.

6. 06
   Protokoll und Abgleich einschalten

   Jede Übertragung wird protokolliert, ein täglicher Mengenabgleich zwischen Quelle und Ziel deckt stille Lücken auf.

7. 07
   Dokumentieren und übergeben

   Die Schnittstelle kommt in die Verfahrensdokumentation, mit Zuständigkeit für den Betrieb.

Häufige Fragen