E-Rechnung per Schnittstelle an das ERP anbinden: Ein technischer Leitfaden

Kurz & knapp: Nicht jedes Unternehmen nutzt SAP oder Microsoft Dynamics – zahlreiche Branchenlösungen und individuell gewachsene ERP-Systeme benötigen einen eigenen Weg zur E-Rechnungsfähigkeit. In der Praxis haben sich dafür drei grundlegende Integrationsmuster etabliert: middleware-basierte Konnektoren, API-basierte Anbindungen an spezialisierte Rechnungsdienste sowie klassischer Dateiaustausch per Batch-Verfahren. Welches Muster passt, hängt von der technischen Offenheit des vorhandenen ERP-Systems und dem Rechnungsvolumen ab.

Warum die ERP-Anbindung für viele Unternehmen zur zentralen Frage wird

Seit dem 1. Januar 2025 müssen alle Unternehmen in Deutschland elektronische Rechnungen empfangen können, ab dem 1. Januar 2027 greift die Ausstellungspflicht für Unternehmen mit einem Vorjahresumsatz über 800.000 Euro, ab dem 1. Januar 2028 gilt sie universell für den inländischen B2B-Bereich. Grundlage ist das Wachstumschancengesetz mit der Änderung des § 14 UStG. Während für die großen ERP-Plattformen wie SAP oder Microsoft Dynamics eigene Compliance-Werkzeuge existieren, sieht die Situation für viele Branchenlösungen, Nischensoftware oder selbst entwickelte Warenwirtschaftssysteme anders aus: Hier gibt es häufig keine fertige, herstellerseitige E-Rechnungsfunktion. In diesen Fällen führt der Weg über eine technische Schnittstelle – entweder zu einer spezialisierten Cloud-Lösung oder zu einem individuell entwickelten Konnektor.

Grundprinzip: Trennung von ERP-Kernprozess und Formaterzeugung

Das zentrale Architekturprinzip bei einer Schnittstellenlösung besteht darin, die eigentliche Formaterzeugung – also die Umwandlung interner Rechnungsdaten in XRechnung oder ZUGFeRD – nicht zwingend im ERP-System selbst umzusetzen, sondern an eine dafür spezialisierte Komponente auszulagern. Das ERP-System liefert die Rechnungsdaten in einem beliebigen strukturierten Format – etwa als CSV, JSON oder über eine Datenbankabfrage – an diese Komponente, die daraus ein normkonformes, validiertes E-Rechnungsdokument erzeugt und anschließend zurückgibt oder direkt versendet. Dieser Ansatz reduziert den Eingriff in den ERP-Kern auf ein Minimum und macht die Lösung unabhängiger von individuellen Anpassungen im Kernsystem.

Integrationsmuster 1: Middleware und Konnektor-Services

Bei diesem Muster übernimmt eine zwischengeschaltete Middleware die komplette Übersetzungsarbeit. Sie liest Rechnungsdaten aus dem ERP-System aus – häufig über dessen ohnehin vorhandene Exportschnittstellen oder eine Datenbankanbindung –, mappt die Felder auf die Struktur des EN-16931-Standards, validiert das Ergebnis und kümmert sich um den Versand, etwa per E-Mail oder über das Peppol-Netzwerk. Middleware-Lösungen eignen sich besonders für Unternehmen, die mehrere unterschiedliche Systeme im Einsatz haben (zum Beispiel getrennte Systeme für Fakturierung und Warenwirtschaft) und eine zentrale Stelle für die gesamte Rechnungslogistik schaffen möchten.

Integrationsmuster 2: API-basierte Anbindung an einen Rechnungsdienst

Alternativ lässt sich ein spezialisierter E-Rechnungsdienst über eine Programmierschnittstelle (API) direkt in eigene Anwendungen oder in das ERP-System integrieren. Das ERP-System sendet die Rechnungsdaten über einen API-Aufruf an den Dienst, der daraus das gewünschte Format erzeugt, validiert und je nach Konfiguration auch den Versand übernimmt. Dieses Muster bietet sich an, wenn Entwicklerressourcen vorhanden sind, um eine eigene Anbindung zu programmieren, oder wenn das ERP-System bereits über offene Schnittstellen für ausgehende Webservice-Aufrufe verfügt. Der Vorteil liegt in der engeren Integration und oft schnelleren Verarbeitung im Vergleich zu dateibasierten Verfahren.

Integrationsmuster 3: Dateibasierter Batch-Austausch

Für Unternehmen mit begrenzten Entwicklungsressourcen oder älteren ERP-Systemen ohne moderne API bleibt oft der klassische Weg über den Dateiaustausch. Dabei exportiert das ERP-System Rechnungsdaten in regelmäßigen Abständen als Datei (zum Beispiel CSV oder ein strukturiertes Exportformat) in ein definiertes Verzeichnis. Eine externe Komponente – ein lokal installiertes Tool oder ein Cloud-Dienst mit Verzeichnisüberwachung – verarbeitet diese Dateien periodisch, erzeugt daraus die E-Rechnungen und übernimmt Validierung und Versand. Dieses Verfahren ist technisch einfacher umzusetzen, arbeitet aber nicht in Echtzeit und eignet sich daher eher für Unternehmen mit überschaubarem, planbarem Rechnungsvolumen.

Eingangsseite: Verarbeitung empfangener E-Rechnungen

Neben der Ausgangsseite muss auch der Empfang berücksichtigt werden. Eingehende XRechnungen oder ZUGFeRD-Dateien müssen eingelesen, die enthaltenen Daten extrahiert und im Idealfall automatisiert in einen Buchungsvorschlag für die Kreditorenbuchhaltung überführt werden. Auch hier lässt sich eine Schnittstellenlösung nutzen: Ein Dienst empfängt die eingehende Datei, parst die enthaltenen Daten und übergibt sie strukturiert an das ERP-System, wo sie im Rahmen des bestehenden Freigabeprozesses weiterverarbeitet werden. Wichtig ist dabei, dass nicht nur formal valide, sondern auch inhaltlich vollständige Daten übernommen werden, damit eine sinnvolle Eingangsrechnung prüfen-Logik im ERP greifen kann.

Kriterien für die Auswahl des richtigen Integrationsansatzes

Schritt-für-Schritt: Vorgehen bei der Anbindung

1. Ist-Analyse: Welche Schnittstellen (Export, API, Datenbankzugriff) bietet das vorhandene ERP-System bereits?
2. Volumenabschätzung: Wie viele Ein- und Ausgangsrechnungen fallen täglich oder monatlich an?
3. Integrationsmuster wählen: Middleware, API oder Batch-Austausch je nach technischer Ausgangslage.
4. Dienstleisterauswahl: Vergleich spezialisierter Anbieter hinsichtlich Formatunterstützung, Validierung und Peppol-Anbindung.
5. Mapping definieren: Zuordnung der ERP-internen Felder zu den Pflichtfeldern des EN-16931-Standards.
6. Testphase: Validierung erzeugter Rechnungen gegen offizielle Prüfwerkzeuge wie den KoSIT-Validator.
7. Pilotbetrieb und Rollout: Schrittweise Ausweitung mit begleitender Fehleranalyse.

Praxisbeispiel: Havelbrück Fenstertechnik GmbH

Die fiktive Havelbrück Fenstertechnik GmbH, ein Fensterhersteller mit rund 90 Mitarbeitenden, setzt ein branchenspezifisches ERP-System ein, das keine native E-Rechnungsfunktion mitbringt. Das IT-Team prüfte zunächst, welche Exportmöglichkeiten das System bietet, und stellte fest, dass ein regelmäßiger CSV-Export der Rechnungsdaten technisch bereits möglich war. Statt einer aufwendigen Eigenentwicklung entschied sich das Unternehmen für einen Cloud-Dienst, der diese Exportdateien automatisiert einliest, daraus normkonforme XRechnungen erzeugt, gegen das Schema validiert und per E-Mail oder Peppol an die Kunden versendet. Für die Eingangsseite wurde derselbe Dienst genutzt, um eingehende E-Rechnungen zu parsen und die extrahierten Daten als Importdatei an das ERP-System zurückzuspielen, wo sie in den bestehenden Freigabeprozess einflossen. Nach einer mehrwöchigen Testphase mit Abgleich gegen den offiziellen Validator ging die Lösung in den Regelbetrieb.

Typische Fehler bei der Schnittstellenanbindung

Ein häufiger Fehler besteht darin, das Mapping der Rechnungsfelder zu oberflächlich zu testen und Sonderfälle wie Rabatte, mehrere Steuersätze auf einer Rechnung oder Sammelpositionen zu übersehen, die dann erst im produktiven Betrieb zu Validierungsfehlern führen. Ein weiterer Fehler ist die fehlende Fehlerbehandlung: Wird eine Rechnung vom Empfänger oder vom Validator abgelehnt, muss es einen klaren Prozess geben, wie diese Fehlermeldung zurück ins ERP-System und zu einem verantwortlichen Sachbearbeiter gelangt. Auch die Frage der GoBD-konformen Archivierung wird bei reinen Schnittstellenlösungen manchmal vernachlässigt, obwohl die strukturierten Daten über die gesamte Aufbewahrungsfrist von acht Jahren verfügbar bleiben müssen.

Sicherheits- und Betriebsaspekte

Da Rechnungsdaten sensible Geschäftsinformationen enthalten, sollte bei jeder Schnittstellenlösung auf verschlüsselte Übertragungswege, saubere Zugriffsrechte und Nachvollziehbarkeit (Protokollierung) geachtet werden. Bei Cloud-basierten Diensten ist zudem zu prüfen, wo die Daten verarbeitet und gespeichert werden und ob dies mit den eigenen Datenschutz- und Compliance-Anforderungen vereinbar ist. Für den Dauerbetrieb empfiehlt sich außerdem ein Monitoring, das fehlgeschlagene Übertragungen oder Validierungsfehler automatisch meldet, damit Probleme nicht erst bei einer Zahlungserinnerung des Kunden auffallen.

Skalierung bei wachsendem Rechnungsvolumen

Eine Schnittstellenlösung, die für ein kleines Rechnungsvolumen konzipiert wurde, stößt bei wachsendem Geschäft schnell an Grenzen. Ein täglicher Batch-Export etwa, der ursprünglich für wenige Dutzend Rechnungen ausreichte, kann bei mehreren Hundert Belegen pro Tag zu spürbaren Verzögerungen zwischen Rechnungserstellung und tatsächlichem Versand führen. Unternehmen, die mittelfristig ein wachsendes Volumen erwarten, sollten die gewählte Architektur deshalb von Beginn an so auslegen, dass sich der Verarbeitungstakt erhöhen oder von einem Batch- auf ein API-basiertes Verfahren umgestellt werden lässt, ohne das gesamte Mapping und die Validierungslogik neu entwickeln zu müssen. Ein modularer Aufbau, bei dem Formaterzeugung, Validierung und Versand als getrennte, austauschbare Bausteine konzipiert sind, erleichtert eine solche spätere Skalierung erheblich.

Hybride Architekturen in der Praxis

In vielen realen Projekten ist die Wahl nicht ausschließlich auf eines der drei Muster beschränkt. Häufig entsteht eine hybride Architektur: Für hochvolumige Standardkunden wird eine API-basierte Echtzeitanbindung genutzt, während für seltener beauftragte Geschäftspartner ein einfacherer Batch-Export ausreicht. Auch die Kombination aus einer zentralen Middleware für die Formaterzeugung und einer schlanken API-Schicht für die Statusrückmeldung an das ERP-System ist verbreitet. Wichtig ist, dass eine solche hybride Lösung nicht organisch und unkontrolliert wächst, sondern von Anfang an bewusst als Architektur mit klaren Verantwortlichkeiten geplant wird – sonst entstehen mit der Zeit mehrere parallele, schwer wartbare Sonderwege für einzelne Kunden oder Belegarten.

Umgang mit Formatänderungen und Weiterentwicklung des Standards

Der EN-16931-Standard sowie die nationalen Spezifikationen für XRechnung und ZUGFeRD werden regelmäßig weiterentwickelt und in neuen Versionen veröffentlicht. Eine Schnittstellenlösung sollte deshalb nicht als einmaliges Projekt, sondern als dauerhaft zu pflegender Bestandteil der IT-Landschaft verstanden werden. Wer auf einen spezialisierten externen Dienstleister setzt, verlagert diese Pflege in der Regel automatisch dorthin, da Formatänderungen zentral im Dienst nachgezogen werden. Wer stattdessen eine Eigenentwicklung betreibt, sollte organisatorisch sicherstellen, dass jemand im Unternehmen regelmäßig neue Versionen der Spezifikationen und Änderungen an offiziellen Validierungswerkzeugen wie dem KoSIT-Validator verfolgt und die eigene Implementierung entsprechend anpasst, um dauerhaft normkonform zu bleiben.

Fazit

Auch ohne SAP oder Microsoft Dynamics lässt sich E-Rechnungsfähigkeit zuverlässig über eine Schnittstelle an nahezu jedes ERP-System anbinden. Entscheidend ist die Wahl des passenden Integrationsmusters – Middleware, API-Anbindung oder Batch-Austausch – abhängig von technischer Offenheit des Systems, Rechnungsvolumen und vorhandenen Entwicklungsressourcen. Wer frühzeitig eine saubere Ist-Analyse durchführt und Sonderfälle im Mapping konsequent testet, kann die gesetzlichen Fristen 2027 und 2028 mit überschaubarem Risiko einhalten.

Häufig gestellte Fragen

Brauche ich zwingend eine Programmierschnittstelle in meinem ERP-System?

Nein, auch ohne moderne API lässt sich über einen dateibasierten Batch-Austausch eine funktionierende E-Rechnungslösung realisieren, sofern das System Exportdateien erzeugen kann.

Wie unterscheidet sich eine Middleware-Lösung von einer direkten API-Anbindung?

Middleware übernimmt die gesamte Übersetzungslogik zentral für mehrere Systeme, während eine API-Anbindung meist eine engere, direkte Integration in eine einzelne Anwendung darstellt.

Können wir eine Schnittstellenlösung selbst entwickeln?

Grundsätzlich ja, sofern ausreichend Entwicklerressourcen vorhanden sind. In der Praxis ist die Nutzung eines spezialisierten Dienstleisters oft schneller und pflegeärmer, da dieser Formatänderungen zentral pflegt.

Was passiert, wenn eine erzeugte Rechnung nicht valide ist?

Sie sollte vor dem Versand automatisch gegen den offiziellen Validator geprüft werden. Fehlerhafte Rechnungen müssen zurück an einen zuständigen Sachbearbeiter im ERP gemeldet werden.

Wie hängen Schnittstellenanbindung und Archivierung zusammen?

Die strukturierten Rechnungsdaten müssen unabhängig vom gewählten Integrationsweg über die gesetzliche Frist von acht Jahren GoBD-konform archiviert werden, was bei der Architektur mitgeplant werden sollte.

Eignet sich eine Batch-Lösung auch für hohe Rechnungsvolumina?

Bedingt. Bei sehr hohen Volumina oder dem Wunsch nach Echtzeitverarbeitung ist eine API-basierte Anbindung meist die geeignetere Wahl.

Wie testen wir die Korrektheit unserer erzeugten Rechnungen?

Am zuverlässigsten über den von der KoSIT bereitgestellten offiziellen Validator, der Rechnungen gegen das XRechnung-Schema prüft.