Turn the PDF invoices your departments already write into ZUGFeRD or XRechnung

I run the back office of a facility services company with two operating departments. Both write their invoices in Word — the same templates for fifteen years, tab stops and all — export to PDF and mail them out. When our biggest customer announced that from next year they'd only accept e-invoices, the first quotes I got were for replacing the whole invoicing process. Nobody in the departments wanted that, and honestly, neither did I.

So the departments keep their Word templates. What changed is the address they send the PDF to. Each department has its own mailbox now; this workflow watches it, pulls the text out of the PDF, reads the invoice with a handful of regular expressions — number, dates, line items, totals, the address block — and hands the result to invoice-api.xhub, which validates it and generates a ZUGFeRD PDF/A-3 (or XRechnung, chosen per department). The e-invoice goes to the buyer, the source PDF goes into an archive folder, and one JSON line goes into a log file I can grep.

Two things I'd point out before you import it.

The customer table in Load Master Data is not optional. It took me an afternoon to accept that neither the buyer's e-mail address nor their Leitweg-ID is anywhere on our invoices — they never had to be. So you maintain a small table: buyer name as printed, e-mail, Leitweg-ID. A buyer who isn't in it stops in the check and I get a mail. That's deliberate.

And there is no AI in here. I tried an LLM first. It read the invoices fine, and once in a while it read them slightly wrong, which for invoices is the worst possible failure mode. Our PDFs come out of the same Word templates every time, so regex is enough, it costs nothing per document, and the same file gives the same result every run. If a department changes its template, the parser breaks loudly — the document lands in the error path with a mail back to the sender — and I adjust three lines. I'll take that over silent almost-right.

What you need

• The community node n8n-nodes-invoice-api-xhub (version 1.1.3 or newer — older ones swallow the field name on a 422)
• An invoice-api.xhub API key
• IMAP credentials for each mailbox and SMTP for sending
• On self-hosted n8n, the output directories from master data have to exist and be in N8N_RESTRICT_FILE_ACCESS_TO

What it doesn't do

No OCR — a scanned PDF is detected and rejected with a clear reason. No Peppol — the e-invoice goes out as a mail attachment. The four-eyes release (Request Release by mail, two buttons) is there but switched off by default; turn the node on if someone should approve before anything leaves. What it does do since the last revision: a duplicate guard — the same document arriving twice is recognised by its content fingerprint in the department's log and is not sent a second time. And the parser shipped here reads the example PDF; you will adapt the regular expressions to your own layout, which is the whole idea.