Since January 2025 every business in Germany has to be able to receive e-invoices (XRechnung XML, or ZUGFeRD / Factur-X, which is a PDF with the same kind of XML inside). Many small companies get them by email and still type the numbers into a spreadsheet or their accounting tool, even though the XML already contains every value exactly.
I built a workflow for that part:
- Gmail Trigger on a label, one item per XML or PDF attachment
- reads XRechnung in UBL and CII syntax, and the XML embedded in ZUGFeRD / Factur-X PDFs
- writes each valid invoice as a row to Google Sheets (seller, VAT ID, invoice number, dates, net, VAT, gross, VAT breakdown, IBAN, payment terms, lines) and optionally files the original in Drive
- sends everything else to a Slack channel and a Review tab, with the reason
Everything comes from the XML, so there is no AI step and no OCR. The parsing happens in Code nodes without any modules, so it needs no NODE_FUNCTION_ALLOW_BUILTIN and no community nodes. It was run on n8n 2.43.
What it checks before a row is written:
- required fields (invoice number, dates, seller, buyer, totals, VAT breakdown, lines)
- lines, net, VAT, gross and amount due add up, compared in whole cents
- VAT breakdown adds up to the VAT total, and each rate matches its amount
- IBAN length and checksum
- duplicates against the sheet (same seller and invoice number)
- an IBAN that differs from earlier invoices of the same seller goes to review
- ZUGFeRD MINIMUM / BASIC WL and ZUGFeRD 1.0 go to review, since they are not full EN 16931 invoices
I tested it against the official KoSIT validator with the XRechnung configuration: the validator accepts all 86 invoices of the XRechnung test suite, and the workflow accepts 85 of them (the one with third-party payments, an XRechnung extension, goes to review). Broken copies with wrong totals, a wrong VAT breakdown, a missing invoice number or a bad IBAN all go to review.
It is not a full validation (the KoSIT validator checks several hundred rules, this checks the amounts and the fields a bookkeeper needs), and it is not tax advice.
Workflow, README and tests: n8n-ai-email-triage/workflows/e-rechnung at main · mick-gsk/n8n-ai-email-triage · GitHub
Questions for anyone dealing with this:
- Where do your e-invoices end up after they arrive: lexoffice, sevDesk, DATEV, a spreadsheet, something else? A step that pushes them into one of those would be the obvious next thing.
- Do you get them as email attachments, or mostly through supplier portals and download links?
- If you have an e-invoice that this workflow reads wrongly or rejects, I’d like to see what breaks (with the personal data removed).