---
title: "Automating e-invoicing with XRechnung and ZUGFeRD"
description: "Automate e-invoicing: complete workflow from receipt through validation to GoBD-compliant archiving. With n8n, DATEV, and practical examples."
canonical: "https://simo-online.com/en/blog/e-rechnung-automatisieren"
---

# Automating e-invoicing with XRechnung and ZUGFeRD

Automate e-invoicing: complete workflow from receipt through validation to GoBD-compliant archiving. With n8n, DATEV, and practical examples.

- Author: SIMO GmbH
- Published: 2025-07-12
- Topic: [AI Automation](https://simo-online.com/en/blog/topic/ai-automation)

Since January 1, 2025, all domestic B2B companies are required to be able to receive e-invoices. Not someday, but now. And if you think a PDF invoice sent by email counts as an e-invoice, you are mistaken. This article shows the complete workflow: from the mailbox through validation and GoBD-compliant filing to handover to DATEV or an ERP system. Without developers, without chaos—with a system that works reliably even with 200 invoices per month.

## What has applied since January 1, 2025—and what is still changing for sending

The receiving requirement is clearly defined: [according to the BMF](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html), all domestic B2B companies have been required since January 1, 2025 to be able to receive structured e-invoices. A right to receive PDF or paper invoices in B2B no longer exists.

For sending, the situation is still somewhat more relaxed—but only temporarily. The transition periods are staggered:

- From 2027: Larger companies must send in structured format.
- From January 1, 2028: All companies must send in structured format.
- Exceptions: Small-amount invoices, transport tickets, and in some cases micro-enterprises—but these are exceptions, not the rule.

The clear recommendation: do not wait until 2028. Those who build their receiving and processing workflow properly now will save themselves the stress later and gain real time savings in the meantime.

## E-invoice vs. other invoice: what the difference costs

This point causes the most confusion in practice. A PDF invoice, even if it arrives by email, is not an e-invoice under current law. It is classified as an “other invoice.”

A genuine e-invoice is a structured, machine-readable format that enables a system to process the data directly without a person typing anything. That sounds technical, but it is the decisive difference: no manual data entry, no media breaks, no typing errors.

## XRechnung vs. ZUGFeRD: the two standards compared

Two formats dominate the German market, and both comply with the EU standard [EN 16931](https://www.peppol.nu/more-about-einvoicing/what-is-the-european-standard-for-einvoicing-en-16931/):

XRechnung is pure XML. No PDF, no attractive layout. But 100 percent machine-readable and the preferred format for government agencies and public-sector clients.

ZUGFeRD is a hybrid format: a normal PDF with embedded XML. The recipient sees a readable invoice, while the system pulls the data from the XML part. Practical for the transition, because both humans and machines can work with it.

The crucial point: With ZUGFeRD, the XML part is authoritative. If the PDF and XML differ from each other, the XML applies. This has direct implications for archiving and auditing.

## Typical incoming channels: where the invoices arrive

In practice, e-invoices come in through four channels, depending on the company’s size and setup:

## Email mailbox

Still the most common channel for midsize companies. A dedicated address (e.g., invoices@company.com) is set up, and the automation workflow monitors this mailbox via IMAP.

## Peppol network

Essentially the highway for structured invoices—standardized across Europe, primarily used in the B2G sector (government) and by larger companies.

## DATEV E-invoice mailbox

A sensible option for everyone already using DATEV. [According to DATEV, the mailbox is available free of charge until June 30, 2026](https://e-rechnungsplattform.datev.de/), after which a pay-per-use model applies (receiving remains free, sending from third-party systems then costs approximately €0.50 per outgoing invoice).

## Supplier portals

For larger clients—invoices are uploaded manually or there is an API connection.

For most trade businesses and midsize companies, the following is sufficient to start: a dedicated email mailbox plus DATEV integration. That covers 80 percent of cases.

## Validation in practice: what needs to be checked

Before an invoice enters the system, it should pass through two verification stages:

## Format verification

Is the XML even valid? Does it conform to the EN 16931 schema? A validator checks this automatically in seconds.

## Business rule verification

Are all mandatory fields populated? Are tax rates and amounts correct? Is the invoice number unique? The [BMF explicitly recommends validation as a sensible process step](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html), even though it is not a mandatory prerequisite for tax recognition.

Typical error categories from practice: missing tax ID, incorrect date format, tax amount inconsistent with net amount times tax rate. All solvable problems—but better to catch them before the handover to DATEV than after.

## GoBD and retention: what must be archived

The [GoBD requirements were recently updated](https://kpmg.com/de/de/home/themen/2025/07/bmf-gobd-zweite-aenderung.html) to explicitly address structured e-invoices. What this means specifically:

- Original XML: Must be archived unchanged, machine-readable, and traceably. The XML must not be converted to another format and stored only in that form.
- ZUGFeRD PDF: Additionally retain if it contains tax-relevant information not found in the XML. In practice: usually archive both parts.
- Audit trail: Every booking needs an audit trail—who approved what and when, which validation steps the invoice went through.
- Retention period: 10 years for tax-relevant documents.

[DATEV documents the legal requirements](https://www.datev.de/web/de/berufsgruppenuebergreifend/themen-im-fokus/e-rechnung-mit-datev/gesetzliche-regelungen) very clearly for deeper insights.

## Automation blueprint: n8n plus XML parsing plus human-in-the-loop plus DATEV

Here is the workflow that has proven effective in practice:

## Step 1: receipt

n8n monitors the dedicated invoice mailbox via IMAP trigger. Every new email with an attachment triggers the workflow.

## Step 2: format detection

Is the attachment an XML file (XRechnung) or a PDF with embedded XML (ZUGFeRD)? The XML part is extracted accordingly. Only if no structured format is present—meaning a plain PDF invoice—does AI-OCR come in as a fallback. XML-first, OCR only when necessary.

## Step 3: validation

Automatic verification against the EN 16931 schema and business rules. Errors are logged, and the invoice goes into an exception queue.

## Step 4: human-in-the-loop

Exceptions (validation errors, unknown suppliers, unusual amounts) land in a review dashboard. A human decides—not blindly, but with all information at a glance.

## Step 5: handover

Validated invoices are handed over in structured form to DATEV or the ERP. No more manual typing.

## Step 6: archiving

XML (and PDF where applicable) are stored in an audit-proof DMS with timestamp, verification log, and booking reference.

According to [DATEV](https://www.datev.de/web/de/aktuelles/e-rechnung-mit-datev/faq/), processing times for incoming invoices are reduced by up to 60 percent with this approach. The decisive point: the time savings come not from magical AI but from eliminating mindless manual work.

## Practical examples from midsize companies

## Example 1: timber construction company with 18 employees

Before: One employee spent 1 to 2 hours daily manually entering invoices into DATEV, error rate never zero.

After: The same process runs automatically with n8n plus DATEV integration, human-in-the-loop only for genuine exceptions (approximately 5 to 10 percent of invoices). The employee was freed for other tasks.

## Example 2: furniture design studio (solo plus mini-job)

Before: Clients sent XRechnung invoices, and the owner opened XML files with a text editor—without understanding the format.

After: After half a day of setup: dedicated invoice mailbox, ZUGFeRD viewer, n8n workflow for incoming invoices, GoBD-compliant filing in DMS. The format is understood and can be explained.

## Checklist: setup, operations, audit readiness

## Setup

- [ ] Dedicated invoice mailbox set up
- [ ] DATEV e-invoice mailbox activated (free until June 30, 2026)
- [ ] n8n workflow for receipt plus validation built
- [ ] Error queue and review dashboard defined
- [ ] DMS filing structure with original format established

## Operations

- [ ] Weekly check of the exception queue
- [ ] Keep supplier mapping up to date
- [ ] Adjust validation rules after BMF updates

## Audit readiness

- [ ] XML archived in original format (unchanged)
- [ ] Audit trail available for every booking
- [ ] Retention periods observed (10 years for tax-relevant documents)
- [ ] GoBD documentation of the workflow available

## Common mistakes—and how to avoid them

## Mistake 1: treating PDF as an E-invoice

Happens constantly. Solution: the workflow detects missing XML structure and flags automatically.

## Mistake 2: transforming XML instead of archiving

Anyone who converts the original XML into a different structure and only saves that has a GoBD problem. Always keep the original.

## Mistake 3: skipping validation

“It comes from a reputable supplier anyway.” Until it does not. Validation takes seconds and saves hours in troubleshooting later.

## Mistake 4: forgetting human-in-the-loop

Fully automatic sounds great until a wrong invoice gets booked. A smart exception queue is not an admission of weakness but good system design.

## Frequently asked questions

## What is an e-invoice under the new legal framework?

An e-invoice is a structured, machine-readable document that conforms to the EU standard EN 16931—meaning XRechnung (pure XML) or ZUGFeRD (PDF with embedded XML). A regular PDF invoice sent by email does not count as an e-invoice in the legal sense.

## What is the difference between XRechnung and ZUGFeRD?

XRechnung is pure XML, no visual document—exclusively for machines. ZUGFeRD combines a readable PDF with an embedded XML dataset. With ZUGFeRD, the XML part is legally authoritative.

## As a micro-enterprise, do I have to issue e-invoices?

All domestic B2B companies must be able to receive e-invoices as of January 1, 2025. For issuing, there are partial exceptions for micro-enterprises and small-amount invoices. The exact conditions can be found in the [BMF FAQ](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html).

## What do I need to consider for GoBD-compliant archiving?

The original XML must be retained unchanged, machine-readable, and with a complete audit trail. For ZUGFeRD, the PDF must additionally be archived if it contains tax-relevant information. Retention period: 10 years.

## Can I use n8n for incoming invoice processing if I am not a developer?

Yes. n8n is a visual automation platform with drag-and-drop. There are ready-made workflow templates for IMAP receipt, XML parsing, and DATEV handover.

## Conclusion: act now instead of panicking in 2028

Automating e-invoicing is not rocket science. The legal requirements have been clear since January 2025, the tools are available, and the workflow can be built in a manageable sprint. Think XML-first, validate, archive GoBD-compliantly, human-in-the-loop for exceptions—that is the recipe. Those who tackle this now will have a system that runs by 2028.

## References

- [BMF—FAQ zur E-Rechnung [in German]](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
- [DATEV E-Invoicing Platform](https://e-rechnungsplattform.datev.de/)
- [DATEV—Legal Requirements for E-Invoicing](https://www.datev.de/web/de/berufsgruppenuebergreifend/themen-im-fokus/e-rechnung-mit-datev/gesetzliche-regelungen)
- [DATEV—FAQ E-Invoicing](https://www.datev.de/web/de/aktuelles/e-rechnung-mit-datev/faq/)
- [KPMG—GoBD zweite Änderung [in German]](https://kpmg.com/de/de/home/themen/2025/07/bmf-gobd-zweite-aenderung.html)
- [EN 16931—EU Standard for E-Invoicing](https://www.peppol.nu/more-about-einvoicing/what-is-the-european-standard-for-einvoicing-en-16931/)

Rendered version: https://simo-online.com/en/blog/e-rechnung-automatisieren