E-invoicing with SAP: XRechnung and ZUGFeRD
The obligation to issue electronic invoices is not a file-format question, it is a process question. Treat it as a format and you end up with a PDF that carries XML — and exactly the same manual effort as before.
Three tasks that deserve to be kept apart
In domestic German B2B business every company must be able to receive electronic invoices. For issuing them, transitional rules apply: paper and plain PDF invoices remain admissible for a limited period with the recipient’s consent, and somewhat longer for smaller issuers than for large ones. After that the obligation applies to everyone. The deadlines are set out in German VAT law — the tax assessment of your individual case belongs with your tax adviser, the technical and procedural implementation with us.
In practice the subject splits into three tasks that rarely share an answer: creating and sending invoices, validating what you create or receive, and processing incoming invoices so the structured data actually gets used. Each task has its own route — and its own page here.
What often gets confused: XRechnung is a pure XML invoice; it is not looked at, it is read. ZUGFeRD is a hybrid — a human-readable PDF in the long-term format PDF/A-3 with the same structured data embedded as XML. Both satisfy the European standard EN 16931 and both therefore count as electronic invoices in law. ZUGFeRD and the French Factur-X are the same format under two names; a document in the EN 16931 profile is simultaneously a valid Factur-X document.
Our starting point is SAP: we come from SAP consulting, not from the e-invoicing portal business. So we talk about your document types, your forms, your approval process and your retention first — and about file formats afterwards. For the technical depth on SAP forms, see formular-tools.de (German).
At a glance
- XRechnung (pure XML) and ZUGFeRD (PDF/A-3 with XML) under control
- Outbound: e-invoices from your existing SAP forms
- Validation: locally on your own machines, no upload to an online service
- Inbound: read the XML, check against SAP, pre-enter
- Usable on premise — including on older SAP releases
- Guidance rather than product selling: process first, tool second
Why this matters
What happens if the subject is left to sit.
- A formally invalid invoice is rejected — the payment term keeps running
- Recipient complaints arrive weeks later and then affect a whole invoice run
- Receiving e-invoices and printing them meets the obligation and forfeits the benefit
- Input VAT deduction depends on a proper invoice — right format, correctly retained
- A late switch hits the invoice run in live operation, not in project calm
Creating e-invoices
Outbound: the SAP form becomes a standard-compliant invoice.
- Keep existing forms instead of rebuilding the layout
- XRechnung as XML or ZUGFeRD as PDF/A-3
- Also on older SAP releases and without a cloud service
- Dispatch by e-mail or export into a directory
- Go to: Creating e-invoices
Validating e-invoices
Verified rather than hoped for — and without uploading your invoices.
- PDF/A container and invoice XML in a single pass
- EN 16931 business rules and the German XRechnung requirements
- From Outlook, from Windows Explorer or in batch
- Report in the browser, one card per file checked
- Go to: ZUGFeRD Validator
Processing incoming invoices
Inbound: actually use the structured data.
- Read values from the XML instead of guessing them from an image
- Check purchase order and supplier live against SAP
- Pre-enter as a parked supplier invoice
- Release and posting stay in the SAP standard
- Go to: Incoming invoices
XRechnung or ZUGFeRD?
The question at the start — and the recipient answers it.
- Public-sector buyers generally require XRechnung, often with a routing ID
- In B2B, ZUGFeRD is more convenient: the recipient still sees a normal PDF
- Both satisfy EN 16931 — it is not a matter of right and wrong
- ZUGFeRD and Factur-X are the same format, which saves a second route into France
- Usually it makes sense to be able to produce both and decide per recipient
And retention?
The part that gets considered last during a switch.
- Invoices must be retained in the form in which they were created or received
- For XRechnung the XML is the original, for ZUGFeRD the PDF/A-3 with its embedded data
- A printout or scan of it does not replace the original
- Filing designed for the German GoBD requirements — the procedural documentation stays with you
- More on Audit-proof archiving
Frequently asked questions
What is the difference between XRechnung and ZUGFeRD?
XRechnung is a pure XML invoice with no visual component — it is read by machines. ZUGFeRD is a hybrid: a human-readable PDF in the long-term format PDF/A-3 with the same structured data embedded as XML. Both implement the European standard EN 16931 and therefore qualify as electronic invoices. Which one you need is decided by the recipient: public-sector buyers usually require XRechnung, ZUGFeRD is more common in B2B.
Is a PDF sent by e-mail already an e-invoice?
No. A PDF without structured data counts as an “other” invoice, not an electronic one in the sense of the standard. Only when the invoice data travels in a structured format according to EN 16931 — as an XRechnung or embedded in a ZUGFeRD PDF — is it an e-invoice.
Are ZUGFeRD and Factur-X the same thing?
Yes. The German and French initiatives maintain the same format jointly; the embedded XML file has an identical structure. A ZUGFeRD document in the EN 16931 profile is simultaneously a valid Factur-X document. That is useful when French recipients are involved — it saves building a second creation route.
Do we need a cloud service for this?
Not necessarily. Creation, validation and inbound processing can run entirely in your own data centre. For many companies that is the deciding criterion: invoices contain trade secrets and personal data and should not leave the building merely to be converted into a format or checked.
Does this work without an SAP release upgrade?
In most cases, yes. The routes we use build on your existing forms and released interfaces and also run on older SAP releases. Whether that holds for your landscape is something we clarify up front — a look at your document types, forms and dispatch route is enough.
Where should we start?
With the inbound side. Being able to receive is already mandatory, and the invoices arriving are at the same time the best illustration of what your own outgoing invoices will have to satisfy. Outbound follows — with a trial run against a validator before the first invoice goes to a customer.
Does this match your project?
Talk directly to our consultants — no detours.