E-Rechnungen automatisiert einlesen: die drei realistischen Wege mit n8n

Eingehende E-Rechnungen kommen in zwei Formaten an, die technisch unterschiedlich aufgebaut sind – und nur eines davon lesen die eingebauten n8n-Nodes vollständig. Ein Workflow, der jeden Anhang wie eine gewöhnliche PDF behandelt, greift beim zweiten zu kurz.

Was das Gesetz von wem und ab wann verlangt, steht hier bewusst nicht. Fristen, Ausnahmen und Formatanforderungen beantworten das BMF-Schreiben, die IHK-Übersichten und Ihre Steuerberatung; die Primärquellen sind unten verlinkt. Dieser Beitrag behandelt die Technik: was im Postfach ankommt und wie n8n es verarbeitet. Alle Angaben zu n8n-Nodes sind, soweit abrufbar, an der öffentlichen n8n-Dokumentation und den verlinkten Projekten geprüft, Stand 9. September 2026.

Was im Postfach ankommt

Für die Verarbeitung sind zwei Formate entscheidend: XRechnung, eine reine XML-Datei ohne visuelle Darstellung, und ZUGFeRD, ein Hybridformat aus lesbarer PDF-Datei (PDF/A-3) mit eingebetteter XML. Für einen Workflow ist das der entscheidende Unterschied: Bei XRechnung ist die Datei selbst bereits die Datenstruktur; bei ZUGFeRD liegen die strukturierten Daten in einer eingebetteten Datei, die im sichtbaren PDF-Text nicht auftaucht.

ZUGFeRD kennt mehrere Profile – MINIMUM, BASIC WL, BASIC, EN 16931 (auch COMFORT genannt), EXTENDED und das Sonderprofil XRECHNUNG. Technisch unterscheiden sie sich im Umfang der mitgelieferten Felder: In den kleineren Profilen fehlen Positionsdaten, Ihr Workflow bekommt dann weniger Struktur, als die PDF-Ansicht vermuten lässt. Welche Profile als vollständige E-Rechnung gelten, steht in der unten verlinkten Profilübersicht.

Rechnen Sie außerdem damit, dass ein Teil des Eingangs weiterhin als gewöhnliche PDF oder auf Papier ankommt. Welche Fälle ausgenommen sind, führt die Übersicht der IHK Frankfurt unten auf; für den Bau zählt nur eines: Prüfen Sie an Ihren letzten zwanzig Eingangsrechnungen, wie groß dieser Anteil ist, und planen Sie einen Auffangzweig ein.

Zwei Formate, ein Unterschied, der für n8n entscheidend ist

	XRechnung	ZUGFeRD
Aufbau	Reine XML-Datei, keine visuelle Darstellung	PDF/A-3-Datei mit eingebetteter XML
Für Menschen lesbar	Nein – braucht ein Anzeigeprogramm	Ja – die PDF-Ebene ist die Rechnung, wie man sie kennt
Für Maschinen lesbar	Direkt – die Datei ist bereits die Datenstruktur	Nur über die eingebettete XML, nicht über den PDF-Text
Wo Sie das in unseren Projekten häufiger sehen	Öffentliche Auftraggeber, größere Konzerne	Handwerk, Mittelstand

Der Unterschied klingt technisch, entscheidet aber darüber, welchen der drei Wege unten Sie zuerst bauen müssen: Eine reine XRechnung lässt sich mit n8n-Bordmitteln vollständig einlesen. Eine ZUGFeRD-Datei nicht – und das ist keine Kleinigkeit, sondern der Kern dieses Beitrags.

Die drei realistischen Wege, eingehende E-Rechnungen in n8n zu verarbeiten

Weg 1: Reine XRechnung per E-Mail – mit Bordmitteln lösbar

Kommt die XRechnung als .xml-Datei im Anhang, reicht eine kurze Kette eingebauter Nodes. Der Email-Trigger (IMAP) lädt den Anhang als Binärdaten; die Extract-From-File-Node liest ihn über die Operation „Extract From Text File“ als reinen Text ein – eine dedizierte XML-Operation hat der Node nicht, aber XRechnung ist im Kern eine Textdatei, und diese Operation genügt dafür. Der anschließende XML-Node wandelt den Text in ein JSON-Objekt um, mit dem der Rest des Workflows normal weiterarbeitet.

Dieser Weg kommt ohne Zusatz-Node und ohne externe Abhängigkeit aus. Er ist der Grund, warum es sich lohnt, den Absender einer E-Rechnung frühzeitig zu fragen, in welchem Format er liefert – XRechnung spart Ihnen den gesamten nächsten Abschnitt.

Weg 2: ZUGFeRD per E-Mail – die eingebettete XML ist mit Bordmitteln nicht erreichbar

Kommt stattdessen eine ZUGFeRD-Datei an, greift die naheliegende Lösung zu kurz: Die PDF-Operation der Extract-From-File-Node liest die sichtbare Textebene der Rechnung – exakt das, was ein Mensch beim Öffnen der PDF sieht –, nicht die separat eingebettete XML-Datei, in der die eigentlichen strukturierten Daten liegen. Ein PDF/A-3-Dokument kann Dateien enthalten, ohne dass sie im sichtbaren Text auftauchen; genau das macht ZUGFeRD-Rechnungen für Menschen lesbar und für ein PDF-Text-Tool zugleich unvollständig auslesbar. In der n8n-Community ist das Auslesen eingebetteter PDF-Anhänge selbst als offener Wunsch nach mehr Funktionsumfang dokumentiert, kein gelöstes Kernfeature.

Zwei Bausteine schließen diese Lücke. Der eine ist ein Community-Node, n8n-nodes-einvoice, der Rechnungsdaten aus ZUGFeRD-, XRechnung-, Factur-X- und EN-16931-Dateien extrahiert – Stand 9. September 2026 in Version 0.1.2, unter MIT-Lizenz, mit 10 Sternen auf GitHub und einer Mindestanforderung von n8n 1.72.x. Anders als die von n8n verifizierten DATEVconnect-Nodes im Beitrag zur DATEV-Anbindung ist dieser Node nicht von n8n geprüft: Laut n8n-Dokumentation hat jeder installierte Community-Node vollen Zugriff auf die Maschine, auf der n8n läuft, und die Installation eines unverifizierten Pakets bedeutet, unverifizierten Code aus einer öffentlichen Quelle auszuführen. Für ein Modul, das Rechnungsdaten verarbeitet, gehört diese Abwägung – Code lesen, in einer Testinstanz prüfen, dann erst gegen echte Belege laufen lassen – vor den produktiven Einsatz. Ein weiterer praktischer Punkt: Unverifizierte Community-Nodes wie dieser lassen sich grundsätzlich nur auf einer selbst gehosteten n8n-Instanz mit Admin-Rechten installieren. Auf n8n Cloud stehen ausschließlich die wenigen von n8n selbst geprüften Community-Nodes zur Verfügung, die ein Instanz-Owner im Cloud-Admin-Panel freischaltet – der hier beschriebene Node gehört nicht dazu.

Der andere Baustein ist ein externer Konvertierungsdienst oder eine eigene Bibliothek außerhalb von n8n, die die eingebettete XML vor der Übergabe an n8n aus der PDF löst – sinnvoll, wenn Sie den Community-Node aus Sicherheits- oder Support-Gründen nicht einsetzen wollen und stattdessen einen Dienst mit eigenem Vertrag und eigener Haftung dazwischenschalten.

Weg 3: Peppol-Netzwerk über einen Access-Point-Anbieter – wenn ein Kunde oder Lieferant es verlangt

Peppol ist ein internationales Netzwerk für den strukturierten Austausch von Geschäftsdokumenten. Für den deutschen B2B-Bereich ist es einer von mehreren möglichen Übertragungswegen; in unseren Projekten kommen E-Rechnungen bisher als Anhang einer E-Mail an. Peppol wird praktisch relevant, sobald ein wichtiger Geschäftspartner es als Empfangs- oder Versandkanal voraussetzt, etwa weil er selbst grenzüberschreitend tätig ist oder mit öffentlichen Auftraggebern arbeitet.

Für die Anbindung schließen Sie einen Vertrag mit einem zertifizierten Access-Point-Anbieter, der Rechnungen für Sie über das Netzwerk sendet und empfängt. Technisch ändert das den Einstiegspunkt für n8n grundlegend: Statt eine E-Mail mit Anhang zu verarbeiten, ruft n8n die strukturierten Daten über die API oder den Webhook des Anbieters ab – die Extraktionsprobleme aus Weg 2 entfallen, weil der Anbieter die Datei bereits in strukturierter Form ausliefert, nicht als PDF mit eingebetteter XML.

Was danach passiert: die Übergabe an DATEV

Alle drei Wege enden mit denselben strukturierten Daten in n8n – Rechnungsnummer, Betrag, Steuersatz, Lieferant, Belegdatum. Wie diese Daten weiter in die Buchhaltung kommen, ist eine eigene Frage, die unser Beitrag zur DATEV-Anbindung im Detail behandelt: über das öffentlich dokumentierte DATEV-Format als Datei, über die kostenpflichtigen DATEV-Datenservices oder über DATEVconnect, wenn DATEV im eigenen Haus läuft. Die Extraktion aus diesem Beitrag liefert die Eingabedaten für genau diesen nächsten Schritt – sie ersetzt ihn nicht.

Für den Mittelstand heißt das

Bauen Sie nicht zuerst die vollständige Infrastruktur für alle drei Wege. Prüfen Sie stattdessen an Ihren letzten zwanzig Eingangsrechnungen, welches Format tatsächlich überwiegt: Kommt schon heute vorwiegend ZUGFeRD von Ihren Lieferanten an – was in unseren Projekten im Mittelstand der häufigere Fall ist –, lohnt sich der Aufwand für Weg 2 zuerst. Überwiegt reine XRechnung, etwa weil Ihre Kunden öffentliche Auftraggeber sind, reicht Weg 1 allein für den größten Teil des Volumens.

Was in keinem der drei Wege verschwindet, ist der Auffangzweig: Ein Teil des Eingangs kommt weiter als einfaches PDF oder auf Papier – welche Fälle das betrifft, führt die Übersicht der IHK Frankfurt unten auf. Ein Workflow, der nur strukturierte Formate kennt, muss diese Belege erkennen und in die bestehende, weniger automatisierte Bearbeitung zurückgeben – nicht stillschweigend verwerfen.

Und weil eine falsch oder unvollständig eingelesene Rechnung in unserer Erfahrung in der Buchhaltung teurer ist als eine, die gar nicht erst automatisiert wurde: Ein Workflow, der Belege in DATEV einspeist, gehört zu den Fällen, in denen sich Monitoring von Anfang an lohnt – nicht erst, wenn eine falsch zugeordnete Zahl im Jahresabschluss auffällt.

Klären Sie außerdem mit Ihrer Steuerberatung, welche Fassung Sie aufbewahren müssen – die strukturierte Originaldatei, die PDF-Ansicht oder beides (die GoBD-Fassung des BMF ist unten verlinkt). Für den Workflow heißt das in jedem Fall: Die Originaldatei nicht verwerfen, sondern zusammen mit den ausgelesenen Daten ablegen.

FAQ

Kann ich eine ZUGFeRD-Rechnung mit den eingebauten n8n-Nodes einlesen?

Nur teilweise. Die PDF-Operation des Extract-From-File-Node liest die sichtbare Textebene der Rechnung, nicht die eingebettete XML-Datei, in der die eigentlichen strukturierten Daten stecken. Für den vollständigen Zugriff auf die eingebettete XML brauchen Sie einen zusätzlichen Baustein – etwa einen unverifizierten Community-Node oder einen externen Konvertierungsdienst.

Was ist der Unterschied zwischen XRechnung und ZUGFeRD?

XRechnung ist eine reine XML-Datei ohne visuelle Darstellung. ZUGFeRD ist ein Hybridformat: eine für Menschen lesbare PDF-Datei mit einer eingebetteten XML-Datei für die maschinelle Verarbeitung. ZUGFeRD kennt mehrere Profile, die sich im Umfang der mitgelieferten Felder unterscheiden; welche davon als vollständige E-Rechnung gelten, steht in der unten verlinkten Profilübersicht.

Brauche ich Peppol, um E-Rechnungen mit n8n zu verarbeiten?

Nicht zwingend. Eine XRechnung oder ZUGFeRD-Datei aus dem Postfach verarbeitet n8n ohne Peppol. Der Kanal wird relevant, wenn ein Kunde oder Lieferant ihn voraussetzt: Dann holt n8n die strukturierten Daten über die API des Access-Point-Anbieters ab, statt einen E-Mail-Anhang auszupacken.

Was mache ich mit Rechnungen, die weiter als PDF oder auf Papier ankommen?

Bauen Sie einen Auffangzweig. Ein Workflow, der nur strukturierte Formate kennt, muss diese Belege erkennen und in die bisherige Bearbeitung zurückgeben, statt sie stillschweigend zu verwerfen. Wie groß der Anteil ist, zeigt ein Blick auf die letzten zwanzig Eingangsrechnungen.