Implementing XRechnung & ZUGFeRD in Your ERP

In short: you implement XRechnung and ZUGFeRD by having your ERP system generate the structured invoice data to EN 16931 directly from the order, validate it technically before sending, transmit it via the right channel (Peppol, email or portal) and then archive it unalterably. Both formats are legally permitted – the difference lies in their technical shape and in the recipient. This article shows you the practical implementation in a vendor-neutral way: from format and profile, through generating and receiving, to validation and audit-proof archiving. We deliberately leave out the pure deadlines of the mandate – this is about the how.

Implementing XRechnung & ZUGFeRD: the EN 16931 standard

An e-invoice in the legal sense is not a PDF image but a machine-readable, structured data set. The common denominator of both formats is the European standard EN 16931. It defines what is known as the semantic data model – that is, which fields an invoice must contain and what they mean. XRechnung and ZUGFeRD are two permitted expressions of this model.

XRechnung – pure XML

The XRechnung is a purely structured XML data set without a visual view. It is the national expression (CIUS) of EN 16931 and the standard in the public sector (B2G). Without suitable software it is barely readable for humans – that is by design, because it is made for automated processing. XRechnung comes in two syntaxes: UBL and UN/CEFACT CII. Your ERP should handle both, because recipients expect different variants.

ZUGFeRD – a hybrid format with profiles

ZUGFeRD combines image and data: it is a PDF/A-3 file with embedded XML. A human sees the familiar invoice, the software reads the structured part. What matters is the profile, because not every one meets the legal requirements:

Note: profiles from BASIC onwards count as a valid e-invoice; only MINIMUM and BASIC-WL fail to meet the standard and are fine merely for internal purposes. For full field depth, choose at least EN 16931 (Comfort). Format and transport channel are also separate decisions – more on that shortly.

Generating and sending e-invoices in the ERP

Invoices arise from your orders, items and customer data – which is why the e-invoice is at its core an ERP topic. A modern system generates the structured data set directly from the order processing workflow, instead of you entering data twice. The prerequisite is clean master data: VAT ID, IBAN, correct units of measure and tax codes must be right, otherwise the data set becomes faulty and is rejected by the recipient.

Leitweg-ID for invoices to public authorities (B2G)

If you send to public sector clients, you need the Leitweg-ID. It uniquely addresses the specific authority within the administration and is a mandatory field for B2G invoices – without it the invoice will not be delivered. You get the ID from the client; store it in the customer master record so it is automatically carried into every invoice. If it is missing or incorrectly structured, validation already fails.

Peppol as a transport channel

Peppol is not a format but a secure European network through which documents are exchanged via what are known as access points. You send your XRechnung or ZUGFeRD file to your access point, which delivers it to the recipient's – in a standardized, cross-border way. Alongside Peppol, email and authority portals remain permitted channels. The important thing is the separation: the format (XRechnung/ZUGFeRD) answers the question of what you send, the transport channel (Peppol, email, portal) answers how.

Receiving and automatically processing e-invoices

Receiving is the other half of the implementation – and in practice often the more demanding one. Your ERP should not just store inbound XRechnung and ZUGFeRD but read them out and pre-book them: invoice number, amount, tax, supplier and line items automatically move into invoice verification, ideally with a match against the purchase order and goods receipt.

To do this, set up a defined inbound channel – such as a dedicated email address for invoices only, or a Peppol receiving point. That way every document lands in the same, controlled process instead of scattered across mailboxes. With ZUGFeRD the rule is: the embedded XML data set is authoritative, not the visible PDF. If the two differ, the structured part takes legal precedence – which is why your system should always process the XML.

Validation: check before the invoice goes out

An e-invoice that contains formal errors is rejected by the recipient or in the authority portal. That is why validation belongs firmly in the outbound process. It is checked against a machine rule set (Schematron) of EN 16931 and – for XRechnung – against the additional national business rules.

Typical sources of error that validation reveals:

• Missing mandatory fields – e.g. Leitweg-ID for B2G, VAT ID for reverse charge, or the IBAN.
• Arithmetic inconsistency – the sum of the line items does not match the invoice total or the tax shown.
• Wrong codes – invalid units, tax categories or payment terms.
• Format violations – incorrect date or number formats in the XML.

Many ERP systems already validate at the point of generation; in addition, there are free official checking tools, such as the KoSIT validator. Build the check in so that a faulty invoice cannot be sent at all – that saves returns and reminders.

Audit-proof archiving under GoBD

E-invoices are subject to the GoBD and must be kept in an audit-proof way – a printout is not enough. Audit-proofness means that the document is stored in its original format, unalterable, complete and reproducibly legible at any time over the statutory period. With ZUGFeRD the embedded XML is mandatory; the plain PDF is not enough.

Concretely, for the ERP implementation this means:

• Keep the original format: the received or sent XML or ZUGFeRD file is archived 1:1, not converted into another format.
• Unalterability: the document is stored read-only; any change creates a new version and is logged in the audit trail.
• Link to the booking: document and accounting record reference each other, so an auditor can trace the transaction completely.
• Retention period: in Germany, invoices must be retained under commercial and tax law (invoices since 2025: eight years); store the deadline per document type.

Record the entire process in your procedural documentation – from capture, through validation and sending, to deletion after the deadline expires. During a tax audit it is the proof that your process is compliant.

What to look for when choosing a system

Whether your existing system or a candidate from the ERP directory covers e-invoicing cleanly comes down to a few concrete questions:

• Does it generate XRechnung and ZUGFeRD natively – and in the legally compliant profile (EN 16931)?
• Can it automatically read out and pre-book incoming e-invoices, not just file them?
• Is a validator integrated that checks before sending?
• Does it support the desired transport channel, in particular a Peppol access point?
• Does it archive in an audit-proof way in the original format with an audit trail?

Cloud and commerce systems like xentral, weclapp or Odoo today treat the e-invoice as a standard feature; others rely on add-on modules or a connected invoicing service provider. Use the ERP comparison to check candidates specifically against these points. When shop, shipping and financial accounting mesh cleanly and Peppol is to be connected, a well-thought-out integration pays off rather than a quick isolated solution.

Conclusion

Implementing XRechnung and ZUGFeRD is less a format problem than a process topic. Both formats meet EN 16931 – but ZUGFeRD only from the BASIC profile onwards (MINIMUM and BASIC-WL are not enough). The practical path runs through clean master data and the Leitweg-ID for authorities, native generation from the order, validation before sending, the right transport channel (often Peppol) and audit-proof archiving in the original format. Once you set this chain up cleanly in your ERP, you win twice: you are compliant and you permanently save effort and errors through automated invoicing processes. For a binding assessment of your tax situation, your tax advisor remains the right address in case of doubt – this article is no substitute for legal advice.