Creating e-invoices: XRechnung and ZUGFeRD
The expensive part of the switch is not the file format. It is the question of where the mandatory fields are supposed to come from — a form that grew over years has never printed most of them.
From the SAP form to a standard-compliant invoice
There are three realistic routes for outgoing invoices. First, the SAP standard: current S/4HANA releases bring their own electronic invoicing functions. That is the cleanest route — if your release supports it and you want to follow the operating model that comes with it. Second, a creation route that builds on your existing SAP forms and derives the structured data from them. Third, creation outside SAP that merges a finished invoice PDF with the corresponding invoice data.
Routes two and three are ours. Both run in your own data centre, both work without changing the SAP release, and both leave the layout untouched. From the existing invoice form you get an XRechnung as a pure XML file or a ZUGFeRD document as a PDF/A-3 with embedded invoice data. Dispatch continues on the familiar route: by e-mail out of SAP or as an export into a directory that your middleware collects.
The route outside SAP is more than a fallback. It helps wherever invoices do not come from the leading system: from a legacy system, from an industry solution, from a billing program nobody wants to touch any more. It works on a single file as well as on an entire directory and can be hooked in behind the regular output run, so that ordinary invoice printing automatically produces e-invoices.
Our role is that of an adviser with our own toolbox: we look at your document types, your forms and your recipient structure, tell you which of the three routes will hold — and then implement it. For the product view on SAP forms and e-invoicing, see formular-tools.de (German).
At a glance
- XRechnung as XML or ZUGFeRD as PDF/A-3
- Builds on existing SAP forms — no layout rebuild
- Also for invoices created outside SAP
- Runs in your own data centre, without a cloud service
- Single document, batch or hooked into the output run
- Validation of the result before the invoice leaves the building
Why this matters
What a formally invalid outgoing invoice costs.
- The recipient rejects it — the payment term keeps running
- Errors do not hit one document, they hit the whole invoice run
- Rework ties up exactly the people already tied up in the month-end close
- Rebuilding a form shortly before a deadline is the most expensive scenario of all
- Noticing only at the first customer complaint means negotiating from the weaker position
The real effort: mandatory fields
This decides whether the switch takes two weeks or a quarter.
- EN 16931 requires fields that were never printed on paper
- Buyer reference and routing ID for public-sector buyers
- Tax category and rate per line item, not just in the total
- Units of measure as standardised codes instead of free text
- Payment terms and bank details in structured form
- Establishing where these values live in SAP is consulting work, not technology
From the SAP form
The route for everything invoiced out of SAP as usual.
- Existing invoice forms stay exactly as they are
- Create XRechnung or ZUGFeRD per recipient
- Dispatch by e-mail from SAP or export into a directory
- Two output paths, one form: electronic with a letterhead background, print still on pre-printed stationery
- Also runs on older SAP releases
From an existing PDF
The route for everything that does not come from the leading system.
- An existing invoice PDF plus the invoice data becomes the ZUGFeRD document
- The result is a valid PDF/A-3 for long-term retention
- Single file, directory or hooked into a running process
- Also for systems that will never produce an e-invoice themselves
- For end users, additionally the simple route via the context menu
Where PDF/A-3 fails in practice
Experience from implementation — the obstacles nobody plans for.
- A PDF that looks good and prints cleanly is nowhere near a PDF/A-3
- Non-embedded fonts, transparency in logos and a missing colour profile break conformance
- Some conversion tools abandon PDF/A generation silently and still deliver a file — the existence of output proves nothing
- The stamped conformance level has to match the content: the stricter level requires a Unicode mapping for every font
- Which is why real validation belongs at the end of the process, not a thumbs-up
Validate before dispatch
Set it up once, then never discuss it again.
- Validate the first documents of every document type individually
- After that, automated samples per invoice run
- Validation in your own building, without upload to an online service
- Machine-readable result for hooking into the output run
- Go to: ZUGFeRD Validator
Frequently asked questions
Do we have to rebuild our SAP forms?
Usually not. Creation builds on the existing form; the layout stays unchanged. What actually takes work is the origin of the mandatory fields: details such as buyer reference, tax category per line item or standardised units of measure often appear nowhere in the form because they were never printed. Closing those gaps is the real project content — and the reason we look first.
Does this work on SAP ECC or an older S/4HANA?
Yes, that is exactly what our routes are for. They build on existing forms and released interfaces and require no release upgrade. If your S/4HANA release already brings SAP’s own electronic invoicing functions, we will tell you that too — then the standard route is the better one.
Do we need a cloud service or a portal?
No. Creation and validation run in your own data centre. A portal or access point only becomes relevant if your recipient prescribes a particular transmission route — a public invoice receipt platform or a Peppol network, for example. Creating the invoice itself is independent of that.
Can we produce XRechnung and ZUGFeRD in parallel?
Yes, and in most cases that is exactly what makes sense. Public-sector buyers usually require XRechnung, commercial recipients are better served by ZUGFeRD because they still receive a readable PDF. Which format a recipient gets then becomes a master-data question, not a programming question.
What about invoices that do not come from SAP at all?
That is what the second route is for: an existing invoice PDF is merged with the invoice data into a ZUGFeRD document. The tool works on single files, on whole directories, or hooks in behind an existing output run — including for systems that will never create an e-invoice themselves.
How long does such a switch take?
That depends almost entirely on the field question, not on the technology. If the mandatory details exist in SAP and are unambiguous, the technical part is manageable. If details are missing or held as free text, master-data and customising work is added. A short upfront analysis of your document types gives a reliable answer.
Does this match your project?
Talk directly to our consultants — no detours.