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 einer Handvoll regulärer Ausdrücke — Nummer, Daten, Positionen, Summen, das Adressfeld — 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 reichen reguläre Ausdrücke, sie kosten pro Beleg nichts, und dieselbe Datei liefert bei jedem Lauf dasselbe Ergebnis. Ändert eine Abteilung ihre Vorlage, bricht der Parser laut — der Beleg landet im Fehlerpfad mit einer Mail zurück an den Absender — und ich passe drei Zeilen an. Das nehme ich jederzeit lieber als leises Fast-richtig.

Was du brauchst

• Die Community-Node n8n-nodes-invoice-api-xhub (Version 1.1.3 oder neuer — ältere verschlucken bei einem 422 den Feldnamen)
• 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-Fingerabdruck im Log der Abteilung und schickt es kein zweites Mal. Und der mitgelieferte Parser liest das Beispiel-PDF; die regulären Ausdrücke passt du an dein eigenes Layout an — das ist die ganze Idee.