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

Die beiden nationalen E-Rechnungsformate XRechnung und ZUGFeRD sind technisch unterschiedlich aufgebaut, und nur bei XRechnung kommen die eingebauten n8n-Nodes Extract From File und XML ohne Zusatzbaustein an die strukturierten Daten. Ein Workflow, der jeden Anhang wie eine gewöhnliche PDF behandelt, greift beim zweiten Format zu kurz; ein Workflow, der die Daten ungeprüft an DATEV weiterreicht, übernimmt auch fehlerhafte Rechnungen.

Was das Gesetz von wem und ab wann verlangt, steht hier bewusst nicht. Fristen und Ausnahmen 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, wie n8n es ausliest, wie Sie es gegen die Norm prüfen und wie die Daten Richtung DATEV kommen. Alle Angaben zu n8n-Nodes, zum KoSIT-Validator und zur DATEV E-Rechnungsplattform sind an der jeweiligen Dokumentation, am Quellcode und an den verlinkten Projekten geprüft, Stand 28. September 2026.

Was im Postfach ankommt

Dieser Beitrag behandelt die beiden nationalen Formate, die das BMF-Schreiben vom 15. Oktober 2025 nennt: 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 Unterschied, auf den es ankommt: 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. Zulässig sind daneben weitere Formate nach der Norm EN 16931 und unter bestimmten Voraussetzungen vereinbarte Formate wie EDI; welches zulässige Format verwendet wird, entscheiden nach dem BMF-Schreiben die Vertragsparteien.

ZUGFeRD kennt laut FeRD fünf Profile (MINIMUM, BASIC WL, BASIC, EN 16931 (COMFORT) und EXTENDED) und dazu das Referenz-Profil XRECHNUNG. Technisch unterscheiden sie sich im Umfang der mitgelieferten Felder: BASIC WL enthält keine Rechnungspositionen, MINIMUM auf Positionsebene nur die Referenz des Käufers und keine Aufschlüsselung der Umsatzsteuer. Ihr Workflow bekommt dann weniger Struktur, als die PDF-Ansicht vermuten lässt. Nach dem BMF-Schreiben vom 15. Oktober 2025 fällt ZUGFeRD ab Version 2.0.1 unter die zulässigen E-Rechnungsformate, ausgenommen die Profile MINIMUM und BASIC-WL; Ihr Workflow sollte diese beiden erkennen und gesondert behandeln.

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 und was der Unterschied für n8n bedeutet

	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
Prüffrage für Ihren Eingang	Kommen XML-Dateien ohne PDF an?	Kommen PDFs mit eingebetteter XML-Datei an?

Der Unterschied klingt technisch, bestimmt aber, welchen der drei Wege unten Sie zuerst bauen müssen: Eine reine XRechnung lässt sich mit den eingebauten n8n-Nodes einlesen. Bei einer ZUGFeRD-Datei erreicht die Extract-From-File-Node die eingebettete XML nicht, und genau darum geht es in diesem Beitrag.

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, wenn Sie das Format „Resolved“ wählen oder die Option „Download Attachments“ aktivieren. Die Extract-From-File-Node liest ihn über die Operation „Extract From Text File“ als reinen Text ein; eine eigene XML-Operation hat der Node nicht, und die n8n-Dokumentation des XML-Node empfiehlt genau diesen Zwischenschritt für XML in einer Binärdatei. Der anschließende XML-Node wandelt den Text in ein JSON-Objekt um, mit dem der Rest des Workflows normal weiterarbeitet. Eine XRechnung kann in zwei Syntaxen vorliegen, UBL und UN/CEFACT CII, die dieselben Daten unter verschiedenen Pfaden ablegen. Planen Sie die Feldzuordnung deshalb für beide; die Tabelle weiter unten zeigt sie für die wichtigsten Felder.

Dieser Weg kommt ohne Zusatz-Node und ohne externe Abhängigkeit aus. Deshalb lohnt es sich, den Absender einer E-Rechnung frühzeitig zu fragen, in welchem Format er liefert: XRechnung erspart Ihnen den gesamten nächsten Abschnitt.

Weg 2: ZUGFeRD per E-Mail, wenn die Extract-From-File-Node nicht an die eingebettete XML kommt

Kommt stattdessen eine ZUGFeRD-Datei an, greift die naheliegende Lösung zu kurz: Die PDF-Operation der Extract-From-File-Node liest den Seitentext der Rechnung, nicht die separat eingebettete XML-Datei, in der die eigentlichen strukturierten Daten liegen. Im n8n-Quellcode liest die zuständige Funktion nur Seitentext und Metadaten des Dokuments aus. 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 steht das Auslesen eingebetteter PDF-Anhänge in einem Thread von März bis Dezember 2025 als offener Funktionswunsch.

Drei Bausteine kommen infrage.

Ein Community-Node. n8n-nodes-einvoice extrahiert laut Projektbeschreibung Rechnungsdaten aus ZUGFeRD-, XRechnung-, Factur-X- und EN-16931-Dateien und gibt auf Wunsch auch die rohe eingebettete XML aus. Stand 28. September 2026 liegt er in Version 0.1.2 vom 6. Januar 2025 vor, unter MIT-Lizenz und mit einer Mindestanforderung von n8n 1.72.x; eine neuere Version ist seitdem nicht erschienen. Anders als die DATEVconnect-Nodes aus dem Beitrag zur DATEV-Anbindung steht dieser Node nicht im Verzeichnis der von n8n verifizierten Community-Nodes. Community-Nodes haben laut n8n-Dokumentation 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 vor den produktiven Einsatz: Code lesen, in einer Testinstanz prüfen, dann erst gegen echte Belege laufen lassen. Unverifizierte Community-Nodes lassen sich laut n8n-Dokumentation nur auf einer selbst gehosteten Instanz installieren, über die Oberfläche nur mit Owner- oder Admin-Rolle. Auf n8n Cloud stehen nur von n8n verifizierte Community-Nodes zur Verfügung, die Owner oder Admins der Instanz installieren; ob sie angezeigt werden, steuert der Owner im Cloud-Admin-Panel.

Ein Code-Node mit eigener Bibliothek, nur selbst gehostet. Auf einer selbst gehosteten Instanz können Sie im Code-Node externe npm-Module nutzen, wenn Sie sie über die Umgebungsvariable NODE_FUNCTION_ALLOW_EXTERNAL freigeben; für natives Python gilt Entsprechendes, wenn das Runner-Image die Module enthält und freigibt. Damit lässt sich eine Bibliothek einbinden, die eingebettete Dateien aus PDF-Dokumenten ausliest. Auf n8n Cloud geht das laut n8n-Dokumentation nicht: Der JavaScript-Code-Node kann dort keine externen npm-Module laden, der Python-Code-Node keine Bibliotheken importieren, auch nicht aus der Standardbibliothek. Wie wenig belastbar Umwege darum herum sind, zeigt der genannte Community-Thread: Ein Python-Skript, das die XML mit Bordmitteln aus dem PDF löste, lief im Oktober 2025 auf n8n Cloud und scheiterte im Dezember 2025 unter n8n 1.123.4 an gesperrten Modul-Importen.

Ein externer Dienst. Ein Konvertierungsdienst oder ein eigenes kleines Programm außerhalb von n8n löst die eingebettete XML aus der PDF, bevor n8n sie weiterverarbeitet. Das ist sinnvoll, wenn Sie weder einen unverifizierten Node noch freigeschaltete Module in Ihrer Instanz betreiben wollen und stattdessen einen Dienst mit eigenem Vertrag dazwischenschalten.

Weg 3: Peppol-Netzwerk über einen Peppol-Dienstleister, wenn Sie es mit einem Geschäftspartner vereinbaren

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; kommen Ihre E-Rechnungen als Anhang einer E-Mail an und haben Sie mit Ihren Lieferanten keinen anderen Übermittlungsweg vereinbart, brauchen Sie es nicht. Peppol wird praktisch relevant, sobald ein wichtiger Geschäftspartner es als Empfangs- oder Versandkanal mit Ihnen vereinbaren will.

Für die Anbindung schließen Sie einen Vertrag mit einem Peppol-akkreditierten Dienstleister (in der Peppol-Terminologie Access Point), 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 Rechnungsdaten über die Schnittstelle des Anbieters ab, sofern er eine API oder Webhooks anbietet. Die Extraktionsprobleme aus Weg 2 entfallen, wenn der Anbieter die Rechnung als XML-Datensatz ausliefert und nicht als PDF mit eingebetteter XML.

Dieselben Felder, zwei Syntaxen: die Zuordnung für Ihren Workflow

Egal über welchen Weg die XML kommt: Ihr Workflow muss in beiden Syntaxen dieselben Felder finden. Eine XRechnung liegt in UBL oder CII vor, die eingebettete XML einer ZUGFeRD-Rechnung in CII. Die folgende Tabelle ordnet die Felder, die für eine Buchung gebraucht werden, ihrem Ort in beiden Syntaxen zu. Grundlage sind die offiziellen Schematron-Prüfregeln zur EN 16931 (Release validation-1.3.16), in denen jede Geschäftsregel den Pfad des Feldes benennt. UBL-Pfade gelten ab dem Wurzelelement Invoice, CII-Pfade mit ram: ab rsm:SupplyChainTradeTransaction; …/ steht für eine Ebene, die die Prüfregeln nicht ausschreiben.

Feld (Kennung nach EN 16931)	UBL	CII
Rechnungsnummer (BT-1)	cbc:ID	rsm:ExchangedDocument/ram:ID
Rechnungsdatum (BT-2)	cbc:IssueDate	rsm:ExchangedDocument/ram:IssueDateTime/udt:DateTimeString
Währung (BT-5)	cbc:DocumentCurrencyCode	ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode
Name des Verkäufers (BT-27)	cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName	ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:Name
Umsatzsteuer-Aufschlüsselung (BG-23)	cac:TaxTotal/cac:TaxSubtotal	ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax
Gesamtbetrag mit Umsatzsteuer (BT-112)	cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount	…/ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:GrandTotalAmount
Fälliger Zahlbetrag (BT-115)	cac:LegalMonetaryTotal/cbc:PayableAmount	…/ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:DuePayableAmount

Die Präfixe (cbc:, cac:, ram: usw.) sind die Kürzel der Prüfregeln; in einer konkreten Datei können sie anders lauten oder fehlen. Zwei praktische Folgen für n8n: Ein Switch-Node, der am Namen des Wurzelelements erkennt, ob eine UBL-Rechnung (Invoice, bei Gutschriften CreditNote) oder eine CII-Rechnung (CrossIndustryInvoice) vorliegt, führt beide Syntaxen auf dasselbe Ausgabeschema zusammen, bevor ein Folgeschritt die Daten sieht. Und Elemente mit Attributen, etwa Beträge mit Währungsangabe in UBL, legt der XML-Node mit den Standardeinstellungen als Objekt ab: Weil die Option „Merge Attributes“ im n8n-Quellcode standardmäßig eingeschaltet ist, wird das Attribut eine eigene Eigenschaft (etwa currencyID), der Wert steht unter _. Unter $ landen Attribute erst, wenn Sie „Merge Attributes“ ausschalten. Testen Sie die Zuordnung an echten Dateien Ihrer Lieferanten, bevor Sie sich auf sie verlassen.

Vor der Übergabe: E-Rechnungen gegen die Norm prüfen

Dass eine Datei sich einlesen lässt, heißt nicht, dass sie der Norm entspricht. Eine Rechnung, deren Gesamtbetrag nicht der Summe aus Nettobetrag und Umsatzsteuer entspricht, lässt sich einwandfrei in JSON verwandeln; die Prüfregeln zur EN 16931 lehnen genau diesen Fall ab (Regel BR-CO-15). Ein Prüfschritt vor der Übergabe fängt solche Fälle ab.

Das Werkzeug dafür stellt die KoSIT bereit, die auch den Standard XRechnung betreut: einen Validator mit der Validatorkonfiguration XRechnung. Der Validator ist Open Source (Apache-Lizenz 2.0), läuft auf Java und lässt sich per Kommandozeile, als Bibliothek oder als HTTP-Dienst betreiben, Stand 28. September 2026 in Version 1.6.3 vom 20. August 2026. Die Konfiguration in der Version 2026-08-31 (veröffentlicht am 2. September 2026) prüft gegen die EN 16931 und gegen XRechnung 3.0.2 und enthält Prüfszenarien für XRechnung in UBL und CII sowie für reine EN-16931-Rechnungen in UBL und CII; Gutschriften in UBL (Wurzelelement CreditNote) haben eigene Szenarien. Welches Szenario greift, entscheidet die Profilkennung in der Datei. Das EN-16931-Szenario für CII erwartet genau die Kennung urn:cen.eu:en16931:2017, die das ZUGFeRD-Profil EN 16931 trägt. Die ZUGFeRD-Profile BASIC und EXTENDED tragen eine erweiterte Profilkennung (laut der Referenzbibliothek factur-x etwa urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) und treffen in dieser Konfiguration kein Szenario; der Validator akzeptiert sie dann nicht. Leiten Sie sie gesondert weiter oder ergänzen Sie ein eigenes Szenario. Dasselbe gilt für Rechnungen im Format Peppol BIS Billing 3.0, deren Kennung auf #compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 endet: Sie treffen in dieser Konfiguration ebenfalls kein Szenario. Für sie stellt die KoSIT eine eigene Validatorkonfiguration bereit. Prüfen Sie außerdem an echten Dateien Ihrer Lieferanten, ob jede davon ein Szenario trifft, bevor Sie den Prüfschritt scharf schalten.

Für n8n ist der HTTP-Dienst die passende Form. Laut Dokumentation nimmt er eine einzelne XML-Datei per POST im Body entgegen und antwortet mit Statuscode 200, wenn die Datei nach der Konfiguration akzeptabel ist, und mit 406, wenn nicht; im Body kommt laut Quellcode des Dienstes der Prüfbericht als XML zurück. Im Workflow heißt das:

1. Der HTTP-Request-Node schickt die XML-Datei selbst, also vor der Umwandlung in Text und JSON, mit dem Body-Typ „n8n Binary File“ an den Validator. Bei ZUGFeRD ist das die zuvor extrahierte, eingebettete XML aus Weg 2; liegt sie danach nur als Text vor, macht der Node Convert to File mit der Operation „Convert to Text File“ wieder eine Datei daraus.
2. Die Optionen „Include Response Headers and Status“ und „Never Error“ sind eingeschaltet. Ohne „Never Error“ wertet der Node jede Antwort außerhalb des 2xx-Bereichs als Fehler, und der Workflow bricht bei 406 ab, statt zu verzweigen.
3. Ein If-Node leitet 200 in die Übergabe und jeden anderen Statuscode in eine Prüfliste für die Buchhaltung, zusammen mit der Antwort des Validators (bei 406 und 422 dem Prüfbericht). Aus dem Bericht lässt sich die Rückfrage an den Lieferanten formulieren.

Zwei Einschränkungen gehören in die Planung: Der HTTP-Dienst hat laut Dokumentation keine eingebaute Zugriffskontrolle, er gehört also hinter einen Proxy oder in ein internes Netz, und seine Weboberfläche ist nach Angabe der KoSIT nicht für den Produktivbetrieb gedacht. Auf n8n Cloud brauchen Sie zusätzlich einen Ort, an dem der Dienst läuft und von der Cloud-Instanz aus abgesichert erreichbar ist. Ob eine Rechnung, die der Validator ablehnt, steuerlich trotzdem genügt, ist keine technische Frage; klären Sie das mit Ihrer Steuerberatung.

Was danach passiert: die Übergabe an DATEV

Alle drei Wege enden mit denselben strukturierten, geprüften Daten in n8n, ausgenommen die gesondert geleiteten Rechnungen, etwa ZUGFeRD in den Profilen BASIC und EXTENDED: Rechnungsnummer, Betrag, Steuersatz, Lieferant, Belegdatum. Wie diese Daten weiter in die Buchhaltung kommen, behandelt unser Beitrag zur DATEV-Anbindung im Detail: über das öffentlich dokumentierte DATEV-Format als Datei, über die 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. Wie sich die Schritte davor und danach einordnen, vom Kontierungsvorschlag über die Freigabe bis zum Zahlungsabgleich, zeigt unsere Übersicht zur Buchhaltungs-Pipeline vom Beleg bis zur Buchung.

Arbeitet Ihre Buchhaltung mit DATEV Unternehmen online, gibt es auch einen Weg ohne eigene Extraktion: Das DATEV E-Rechnungspostfach als Teil der DATEV E-Rechnungsplattform empfängt E-Rechnungen per E-Mail, über Peppol oder über das TRAFFIQX-Netzwerk, validiert sie nach EN 16931, stellt XRechnung- und ZUGFeRD-Daten dar und leitet empfangene E-Rechnungen automatisiert an DATEV Unternehmen online weiter. Der Empfang ist laut DATEV-Preisangabe grundsätzlich und unabhängig vom Übertragungsweg kostenfrei, die Registrierung ebenfalls (Stand 28. September 2026). Archivieren lassen sich die Rechnungen im Postfach selbst nicht; dafür verweist DATEV auf Belege online in DATEV Unternehmen online.

Welcher Weg zu Ihnen passt, entscheiden vier Prüffragen:

Prüffrage	Wenn ja	Wenn nein
Arbeitet Ihre Buchhaltung oder Kanzlei mit DATEV Unternehmen online?	Die DATEV E-Rechnungsplattform kommt als Empfangsweg infrage.	Die automatische Weiterleitung der Plattform zielt auf DATEV Unternehmen online; planen Sie die Übergabe über einen der Wege aus dem DATEV-Beitrag.
Sollen die Rechnungsdaten außer in DATEV noch in andere Systeme fließen, etwa ins ERP, in einen Bestellabgleich oder eine Freigabe?	Sie brauchen die Daten in n8n, also eine eigene Extraktion nach Weg 1 bis 3.	Die Plattform kann den Empfang allein abdecken.
Kommen bei Ihnen ZUGFeRD-Rechnungen an?	Planen Sie einen der Bausteine aus Weg 2 ein; auf n8n Cloud fallen der unverifizierte Community-Node und der Code-Node-Weg weg.	Für den strukturierten Teil des Eingangs genügt Weg 1.
Wollen Sie die Normprüfung selbst betreiben?	Planen Sie den KoSIT-Validator als Dienst ein, samt Absicherung.	Prüfen Sie, ob die Validierung der DATEV-Plattform für Ihren Eingang genügt.

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, lohnt sich der Aufwand für Weg 2 zuerst. Überwiegt reine XRechnung, reicht Weg 1 allein für den größten Teil des Volumens. Und bevor Sie überhaupt bauen: Klären Sie mit der Tabelle oben, ob die Daten außer in DATEV noch irgendwohin müssen. Wenn nicht, ist die DATEV E-Rechnungsplattform der kürzere Weg.

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, statt sie stillschweigend zu verwerfen. Dasselbe gilt für E-Rechnungen, die der Validator ablehnt.

Eine falsch oder unvollständig eingelesene Rechnung kann in der Buchhaltung unauffällig weiterlaufen, während eine nicht automatisierte sichtbar liegen bleibt. Ein Workflow, der Belege in DATEV einspeist, gehört deshalb zu den Fällen, in denen sich Monitoring von Anfang an lohnt, nicht erst, wenn eine falsch zugeordnete Zahl im Jahresabschluss auffällt.

Zur Aufbewahrung: Nach den GoBD in der Fassung vom 14. Juli 2025 genügt bei E-Rechnungen die Aufbewahrung des strukturierten Teils. Den PDF-Teil einer ZUGFeRD-Rechnung müssen Sie nur zusätzlich aufbewahren, wenn er zusätzliche oder abweichende Informationen enthält, die für die Besteuerung von Bedeutung sind, etwa Buchungsvermerke; die XML-Datei darf nicht durch eine Formatumwandlung verloren gehen. Für den Workflow heißt das: Die Originaldatei nicht verwerfen und nicht umwandeln, sondern zusammen mit den ausgelesenen Daten ablegen. Einzelfälle klären Sie mit Ihrer Steuerberatung.

FAQ

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

Nur teilweise. Die PDF-Operation des Extract-From-File-Node liest den Seitentext der Rechnung, nicht die eingebettete XML-Datei, in der die eigentlichen strukturierten Daten stecken. Für den Zugriff auf die eingebettete XML reichen die Nodes Extract From File und XML nicht aus; infrage kommen ein unverifizierter Community-Node, auf einer selbst gehosteten Instanz ein Code-Node mit freigeschalteter Bibliothek oder ein externer 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; die Profile MINIMUM und BASIC WL zählen nach dem BMF-Schreiben vom 15. Oktober 2025 nicht zu den zulässigen E-Rechnungsformaten.

Wie prüfe ich, ob eine eingehende E-Rechnung der Norm EN 16931 entspricht?

Mit einer Validierungsanwendung. Die KoSIT stellt dafür einen Open-Source-Validator mit einer Konfiguration für XRechnung und EN 16931 bereit, der sich als HTTP-Dienst betreiben lässt: n8n schickt ihm die XML-Datei und verzweigt nach dem Statuscode der Antwort. Für die ZUGFeRD-Profile BASIC und EXTENDED enthält die Standardkonfiguration kein Prüfszenario. Wer mit DATEV Unternehmen online arbeitet, kann E-Rechnungen auch über das DATEV E-Rechnungspostfach empfangen, das sie nach Angabe von DATEV nach EN 16931 validiert.

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 Sie ihn mit einem Geschäftspartner vereinbaren: Dann bezieht n8n die Rechnungsdaten über die Schnittstelle des Peppol-Dienstleisters, sofern er eine anbietet, 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.