n8n mit ERP verbinden: Schnittstellen vor dem Workflow klären

Eine dokumentierte API ermöglicht gezielte Lese- oder Schreiboperationen. Dafür brauchen Sie einen zugelassenen Zugang und müssen Datenmodell, Berechtigungen, Versionen und Fehlerantworten verstehen. Ein API-Zugang zum Lesen von Kontakten erlaubt nicht automatisch das Erstellen oder Verbuchen von Rechnungen.

Ein freigegebener Dateiimport oder -export kann die passendere Lösung sein, wenn das Fachsystem kontrollierte Stapel verarbeitet. Dafür müssen Format, Zeichensatz, Feldlängen, Dateinamensregeln und Importergebnis bekannt sein. Eine erfolgreich abgelegte CSV-Datei ist noch kein erfolgreich übernommener Datensatz.

Ein Anbieter- oder Partneradapter kann erforderlich sein, wenn der Hersteller einen geregelten Integrationsweg vorsieht oder die Installation besondere Module benötigt. Hier gehört der Betreiber des Adapters in die Verantwortungskette. Klären Sie, wer Änderungen der Fachsoftware prüft, Fehler untersucht und die Freigabe einer neuen Version erteilt.

Ausgangsfrage. Die Auswahl sollte mit einer einfachen Frage beginnen: Welcher Weg ist für genau diesen Datentyp und diese Aktion offiziell vorgesehen? Erst danach lohnt sich die Entscheidung, welche n8n-Nodes den Ablauf koordinieren.

Ob sich n8n mit DATEV, BMD oder bexio verbinden lässt, hängt von der konkreten offiziellen Schnittstelle ab; die Tabelle zeigt für jedes System die offizielle Ausgangsbasis und was vor dem Angebot zu klären ist.

DATEV. DATEV beschreibt Datenservices für strukturierte Daten und Belege zwischen angeschlossenen Lösungen und der DATEV-Umgebung. Die Informationen für Schnittstellenanbieter verweisen auf Anforderungen und geregelte Integration. Daraus folgt keine universelle direkte n8n-Verbindung zu jedem DATEV-Produkt. DATEV Datenservices, DATEV Schnittstellenanbieter.

BMD. BMD veröffentlicht technische Dokumentationen und Beispiele für Austauschformate. Welche davon in einem konkreten Betrieb nutzbar sind, muss mit dessen Produkt- und Installationsstand geklärt werden. Eine Dokumentationsseite ist kein Nachweis, dass ein bestimmtes Kundensystem dieselbe Schnittstelle freigeschaltet hat. BMD technische Dokumentationen.

bexio. bexio stellt eine offizielle API-Dokumentation bereit. Auch hier müssen Authentifizierung, erforderliche Berechtigungen und die konkrete Objektoperation zusammenpassen. Eine Kontaktschnittstelle beweist keine vollständige Automatisierbarkeit eines Rechnungsprozesses. bexio API.

Für alle drei Systeme. Diese Unterschiede sind für DACH-Projekte relevanter als eine pauschale Liste angeblich unterstützter ERP-Systeme. Die Namen allein sagen nichts über Tarif, Berechtigung, Mandant oder den fachlichen Abschluss einer Übertragung aus.

Gemeinsame Spezifikation. Vor dem Bau braucht das Projekt einen Vertrag zwischen Quelle und Ziel. Dieser ist kein juristisches Dokument, sondern eine gemeinsam verstandene Spezifikation des Datenaustauschs. Für jeden Datentyp werden Schlüssel, Pflichtfelder, zulässige Änderungen und verantwortliche Personen festgelegt.

Beispielregeln. Ein Kontakt kann beispielsweise folgende Regeln benötigen: Externe ID bleibt unverändert; Firmenname wird aus der freigegebenen Quelle übernommen; bestehende Rechnungsadresse wird nur nach fachlicher Bestätigung geändert; gesperrte Datensätze werden nicht automatisch reaktiviert. Bei Belegen kommen Mandant, Belegart, Währung, Dokumentreferenz und der erlaubte Bearbeitungszustand hinzu.

Steuerkennzeichen und Buchungsschlüssel. Die Bedeutung von Steuerkennzeichen oder Buchungsschlüsseln darf nicht aus einer ähnlich klingenden Feldbezeichnung geraten werden. Ein Tabellenfeld „Steuer“ kann Betrag, Satz, Kategorie oder interne Kennung meinen. Lassen Sie die fachlich zuständige Buchhaltung die Zuordnung bestimmen und mit freigegebenen Beispielen bestätigen. n8n sollte diese Entscheidung anschließend ausführen, nicht selbst neu interpretieren.

Ausgeschlossene Daten. Notieren Sie auch, welche Daten ausdrücklich nicht übertragen werden. Interne Gesprächsnotizen oder vollständige E-Mail-Verläufe gehören nicht automatisch in einen Stammdatenabgleich. Ein schlanker Datensatz ist leichter zu prüfen, zu korrigieren und über mehrere Systeme hinweg zu verfolgen.

Mandanten. In einer Gruppe mit mehreren Gesellschaften kann dieselbe Kundennummer in verschiedenen Mandanten vorkommen. Der Schlüssel muss deshalb gegebenenfalls aus Mandant und Datensatz-ID bestehen. Eine Suche nur nach 10024 könnte sonst die richtige Nummer im falschen Unternehmen finden.

Belegnummern. Auch Belegnummer und technische Dokument-ID sind nicht zwingend dasselbe. Definieren Sie, wer Nummern vergibt und ab wann eine Nummer verbindlich ist. Der Workflow sollte keine eigene Nummernlogik erfinden, wenn das Zielsystem diese führt. Für temporäre Vorgänge kann eine separate Integrationsreferenz sinnvoll sein, die später mit der endgültigen Ziel-ID verbunden wird.

Beträge und Währungen. Bei Währungen und Beträgen müssen Rundung und Format klar sein. EUR und CHF dürfen nicht allein aufgrund gleicher Zahlwerte zusammengeführt werden. Prüfen Sie Summen gegen die fachlich erwarteten Werte, ohne aus der technischen Prüfung eine steuerliche Beurteilung abzuleiten. Abweichungen werden zurückgegeben oder zur Freigabe vorgelegt.

Annahmen. Ein Dienstleistungsunternehmen möchte bereits geprüfte Eingangsbelege an sein Fachsystem übergeben. Das Beispiel ist synthetisch. Es setzt voraus, dass der Hersteller für die konkrete Installation einen geeigneten Import- oder API-Weg bestätigt hat; es behauptet keine bestimmte DATEV-, BMD- oder bexio-Operation.

Prüfung. Die Quelle liefert für den Vorgang BEL-7031 eine eindeutige Referenz, Mandant, Dokument, freigegebene Metadaten und den Namen beziehungsweise die Kennung der fachlichen Freigabe. n8n prüft Pflichtangaben, Dateilesbarkeit und die Zuordnung zum vorgesehenen Ziel. Fehlt der Mandant oder passt die freigegebene Version nicht mehr zum Dokument, wird die Übergabe gestoppt.

Übergabe und Empfangsbestätigung. Anschließend entsteht ein Übergabepaket im vereinbarten Format. Vor dem Versand wird gespeichert, welche Paketversion mit welcher Integrationsreferenz übermittelt werden soll. Der Zielaufruf oder Dateiimport liefert eine Empfangsbestätigung. Diese wird als „empfangen“ gespeichert, nicht sofort als „verbucht“.

Tatsächlicher Status. Erst eine vorgesehene Rückmeldung oder fachliche Kontrolle bestätigt den tatsächlichen Importstatus. Wurde ein Pflichtfeld abgelehnt, bleibt der Vorgang offen. Ist der Beleg übernommen, aber noch nicht fachlich freigegeben, zeigt die Arbeitsliste genau diesen Zwischenzustand. Eine fehlende Rückmeldung wird nach einer vereinbarten Frist untersucht.

Korrekturen. Wird später eine Korrektur notwendig, entsteht eine nachvollziehbare neue Version oder der fachlich vorgeschriebene Korrekturvorgang. Das Löschen und erneute Anlegen eines bereits wirksamen Belegs ist keine allgemeine technische Reparaturstrategie. Welche Korrektur zulässig ist, entscheidet das Fachverfahren mit seiner verantwortlichen Person.

Timeouts. Ein Timeout nach einer Übertragung ist besonders heikel: Das Ziel könnte die Daten bereits angenommen haben. Wiederholen Sie deshalb eine schreibende Aktion erst, wenn ihr Zustand anhand einer Referenz, einer Statusabfrage oder eines abgestimmten Prüfverfahrens geklärt ist. Falls die Schnittstelle einen eigenen Wiederholungsschutz bietet, prüfen Sie dessen genaue Gültigkeit und Reichweite.

Stapel. Bei einem Stapel mit 100 Datensätzen kann ein Teil erfolgreich sein. Der Wiederanlauf muss die offenen Einträge kennen. Ein erneuter Import aller 100 ist nur dann vertretbar, wenn das Zielverhalten ausdrücklich dafür ausgelegt ist. „Die Datei wurde verarbeitet“ ist als Ergebnis zu grob, wenn einzelne Zeilen abgewiesen wurden.

Fehler sollten in fachlich verständliche Kategorien aufgeteilt werden:

• Zugang abgelaufen
• Format ungültig
• Zuordnung unklar
• Datensatz gesperrt
• Ziel vorübergehend nicht verfügbar
• Übertragungsstatus unbekannt

Jede Kategorie braucht eine zuständige Person und eine Entscheidung zum Wiederholen. Nicht jeder Fehler löst denselben automatischen Retry aus. Derselbe automatische Retry für jeden Fehler kann Fehler vervielfachen.

Kontext für die Untersuchung. Bewahren Sie genug technischen Kontext für die Untersuchung auf, ohne vollständige Finanzdokumente in jedes Protokoll zu kopieren. Nützliche Angaben sind Vorgangskennung, Paketversion, Zielreferenz und Fehlerkategorie. Der Zugriff auf das zugrunde liegende Dokument sollte weiterhin über dessen eigentlichen Speicherort gesteuert werden.

Lesender Vergleich. Der erste Durchlauf sollte häufig nur feststellen, welche Daten sich unterscheiden. Vergleichen Sie einen abgegrenzten Bestand, ohne ihn sofort zu verändern. Daraus entsteht eine Liste mit sicheren Treffern, fehlenden Datensätzen und Konflikten. Diese Liste zeigt, ob die angenommene Datenqualität tatsächlich ausreicht.

Erste Schreibfälle. Danach testen Sie wenige ausdrücklich freigegebene Schreibfälle in einer geeigneten Testumgebung oder einem vom Betreiber genehmigten Verfahren. Fehlt eine solche Umgebung, muss das Projekt diese Einschränkung offen berücksichtigen. Produktive Buchungen als improvisierte Testdaten sind keine neutrale Probe.

Umschaltung. Für die Umschaltung braucht es einen Stichtag, einen klaren führenden Prozess und eine Regel für währenddessen eintreffende Änderungen. Der alte und der neue Weg dürfen nicht unbemerkt dieselbe Aktion ausführen. Bevor der bisherige Ablauf abgeschaltet wird, müssen Mengen und offene Ausnahmen abgeglichen sein.

Entscheidung zum Anhalten. Legen Sie für die Einführung fest, wie das Team bei einem erforderlichen Anhalten vorgeht. Zeigt der Abgleich fehlende oder falsch zugeordnete Datensätze, sollte das Team wissen, ob es neue Übergaben stoppt, lesende Prüfungen fortsetzt oder zum bisherigen Bearbeitungsweg zurückkehrt. Improvisieren Sie diese Entscheidung nicht, während sich operative Arbeit aufstaut.

Laufender Aufwand und Kosten. Eine individuelle ERP-Anbindung bleibt auch nach dem ersten erfolgreichen Lauf betreuungsbedürftig. Kalkulieren Sie neben Umsetzung und Hosting die Abstimmung mit Fachverantwortlichen, Testdaten, Herstellerzugang, eventuelle Adapterkosten und Änderungen an Datenformaten. Ein niedriger API-Aufwand kann mit hohem fachlichem Abstimmungsbedarf verbunden sein.

Herstelleränderungen. Legen Sie fest, wer Herstellerankündigungen prüft und eine geänderte Schnittstellenversion testet. Dokumentieren Sie mindestens Produktversion, verwendete Operationen, Feldvertrag, Berechtigungen, Wiederaufnahmepunkte und Ansprechpersonen. Zugangsdaten gehören in eine geeignete Geheimnisverwaltung, nicht in Beispieldateien oder Screenshots.

Erfolgsmaßstäbe. Der Erfolgsmaßstab ist nicht die Anzahl automatisch verschobener Dateien. Aussagekräftiger sind vollständig zugeordnete Vorgänge, offene Importfehler, unklare Übertragungen und die Zeit bis zur fachlichen Bearbeitung. Diese Kennzahlen zeigen, ob Arbeit tatsächlich reduziert oder nur an eine andere Stelle verschoben wurde.

Vor der Freigabe. Lassen Sie sich bestätigen, welcher offizielle Zugang genau vorgesehen ist, welche Daten gelesen und geschrieben werden dürfen und wie ein erfolgreiches fachliches Ergebnis erkannt wird. Fragen Sie nach Testmöglichkeiten, Versionswechseln, Teilfehlern, Mandantentrennung und Wiederholungen nach unklarem Ausgang.

Zur Abnahme gehören mindestens diese Fälle:

• doppelte Referenzen
• falscher Mandant
• fehlende Pflichtwerte
• gesperrte Stammdaten
• abweichende Währung
• teilweise abgewiesener Stapel
• ein Timeout nach möglicher Annahme

Erst wenn diese Fälle beherrschbar sind, sollte der Umfang wachsen. Für den nächsten Schritt reichen ein echter anonymisierter Beispielvorgang, die offizielle Schnittstellenbeschreibung und ein Gespräch mit der fachlich verantwortlichen Person.

Versionen des Feldvertrags. Für die technische Übergabe empfiehlt sich zusätzlich ein Versionsprotokoll des Feldvertrags. Notieren Sie, ab wann eine geänderte Zuordnung gilt und welche noch offenen Pakete nach der alten Regel behandelt werden. Wird beispielsweise ein Pflichtfeld ergänzt, dürfen ältere wartende Datensätze nicht stillschweigend mit einem erfundenen Ersatzwert ergänzt werden. Die Fachverantwortlichen entscheiden, ob eine Korrektur nötig ist oder eine dokumentierte Übergangsregel gilt.

Diese Seiten behandeln die Leistungsübersicht und die angrenzenden Entscheidungen zu n8n und ERP-Schnittstellen:

• n8n-Agentur: Umsetzung und Betrieb von Unternehmensworkflows
• n8n mit APIs und Webhooks verbinden: Integrationsgrundlagen
• n8n-Fehlerbehandlung: Wiederholungen ohne doppelte Aktionen
• BMD und KI: native Funktionen und verbleibende Prozesslücken
• DATEV-Dokumentenworkflow: welche Übergabe wirklich gebraucht wird
• bexio-Belege automatisieren: Vorverarbeitung und Freigabe

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.