Die PDF-Rechnungen, die eure Abteilungen ohnehin schreiben, als ZUGFeRD oder XRechnung verschicken

Ich leite das Backoffice eines Facility-Dienstleisters mit zwei operativen Abteilungen. Beide schreiben ihre Rechnungen in Word — seit fünfzehn Jahren dieselben Vorlagen, Tabstopps inklusive —, exportieren nach PDF und mailen sie raus. Als unser größter Kunde ankündigte, ab nächstem Jahr nur noch E-Rechnungen anzunehmen, waren die ersten Angebote, die ich bekam, Angebote für den Austausch des ganzen Rechnungsprozesses. In den Abteilungen wollte das niemand, und ehrlich gesagt ich auch nicht.

Also behalten die Abteilungen ihre Word-Vorlagen. Geändert hat sich nur die Adresse, an die sie das PDF schicken. Jede Abteilung hat jetzt ein eigenes Postfach; dieser Workflow überwacht es, zieht den Text aus dem PDF, liest die Rechnung mit einem kleinen Regelwerk — Nummer, Daten, Positionen, Summen, das Adressfeld; eine JSON-Datei, kein Code — und übergibt das Ergebnis an invoice-api.xhub, das validiert und ein ZUGFeRD-PDF/A-3 erzeugt (oder eine XRechnung, je Abteilung einstellbar). Die E-Rechnung geht an den Käufer, das Quell-PDF in einen Archivordner, und eine JSON-Zeile in eine Logdatei, die ich greppen kann.

Zwei Dinge, die ich vor dem Import sagen würde.

Die Kundentabelle in Load Master Data ist nicht optional. Ich habe einen Nachmittag gebraucht, um zu akzeptieren, dass weder die Mailadresse des Käufers noch seine Leitweg-ID irgendwo auf unseren Rechnungen stehen — mussten sie ja nie. Also pflegt man eine kleine Tabelle: Käufername wie gedruckt, Mailadresse, Leitweg-ID. Ein Käufer, der nicht drinsteht, bleibt in der Prüfung hängen, und ich bekomme eine Mail. Das ist Absicht.

Und es ist keine KI drin. Ich habe es zuerst mit einem Sprachmodell versucht. Es hat die Rechnungen gut gelesen, und ab und zu hat es sie ein bisschen falsch gelesen — was bei Rechnungen der schlimmstmögliche Fehler ist. Unsere PDFs kommen jedes Mal aus denselben Word-Vorlagen, also reicht ein Regelwerk, es kostet pro Beleg nichts, und dieselbe Datei liefert bei jedem Lauf dasselbe Ergebnis. Ändert eine Abteilung ihre Vorlage, brechen die Regeln laut — der Beleg landet im Fehlerpfad mit einer Mail zurück an den Absender — und ich passe drei Zeilen in einer JSON-Datei an. Das nehme ich jederzeit lieber als leises Fast-richtig.

Was du brauchst

• Zwei Community-Nodes: n8n-nodes-invoice-api-xhub (Version 1.1.3 oder neuer — ältere verschlucken bei einem 422 den Feldnamen) fürs Validieren und Erzeugen, und n8n-nodes-pdf2invoice-api-xhub fürs Lesen des PDF-Texts, das Zusammenbauen der Rechnung und den Dublettenschutz — läuft lokal und braucht keine Credentials
• n8n-nodes-pdf2invoice-api-xhub ist noch nicht auf npm veröffentlicht (geprüft am 15.09.2026): über „Settings → Community Nodes → Install" ist er heute nicht zu bekommen, und ohne ihn bricht der Import dieses Workflows mit „unknown node" ab. Der Quellcode liegt offen unter github.com/xhubio/n8n-nodes-pdf2invoice-api-xhub — bis zur Veröffentlichung baust du ihn dort selbst und legst ihn auf einer selbst gehosteten Instanz in ~/.n8n/nodes ab; auf n8n Cloud ist das nicht möglich
• Einen invoice-api.xhub-API-Key
• IMAP-Zugangsdaten je Postfach und SMTP zum Versenden
• Auf selbst gehostetem n8n müssen die Ausgabeverzeichnisse aus den Stammdaten existieren und in N8N_RESTRICT_FILE_ACCESS_TO stehen

Was er nicht tut

Kein OCR — ein gescanntes PDF wird erkannt und mit klarem Grund abgewiesen. Kein Peppol — die E-Rechnung geht als Mailanhang raus. Die Vier-Augen-Freigabe (Request Release per Mail, zwei Buttons) ist drin, aber standardmäßig aus; wer will, dass jemand freigibt, bevor etwas rausgeht, schaltet den Knoten ein. Was er seit der letzten Überarbeitung tut: ein Dublettenschutz — kommt dasselbe Dokument zweimal an, erkennt er es am Inhalts-Hash im Log der Abteilung, bevor überhaupt etwas erzeugt wird, und schickt es kein zweites Mal. Und das mitgelieferte Regelwerk liest das Beispiel-PDF; die Muster passt du an dein eigenes Layout an — das ist die ganze Idee.