Key takeaways
- XRechnung is pure XML, ZUGFeRD is a PDF with embedded XML. Both meet the requirements; which format is used is normally decided by the recipient.
- Business Central provides the groundwork for electronic documents. For the German market an extension or a third-party solution is usually added, depending on version and requirements.
- Peppol is the transmission route, not the format. Access runs through an Access Point; for invoices to public sector bodies it is normally the intended channel.
- Most rejected documents fail on missing master data rather than on the format: routing ID, order number, complete payment and tax details.
- Inbound invoicing holds the larger saving and is still usually the last part anyone touches.
Format first: XRechnung or ZUGFeRD
Both formats carry the same structured data under the European norm EN 16931. The difference is the packaging. XRechnung is a pure XML file with no visual component: perfectly machine-readable, useless to a human without a viewer. ZUGFeRD puts the same data inside a PDF/A-3 and stays readable on screen like a familiar invoice.
In practice that means you rarely choose the format yourself. Public sector bodies in Germany generally require XRechnung. In B2B the format follows what the recipient can process, and many recipients state it in their supplier guidelines. Being able to produce both saves the argument.
- XRechnung: XML, mandatory towards public sector bodies
- ZUGFeRD: PDF with embedded XML, widely used in B2B
- Both satisfy the e-invoice requirements — a PDF sent by email does not
What Business Central provides and what gets added
Business Central treats electronic documents as a first-class concept: document formats, sending profiles per business partner, and the mapping of which document leaves by which route. The framework is there. What is specifically needed for the German market depends on your release and your requirements — often an extension for the German formats is added, and in more complex cases a specialised third-party solution.
The honest recommendation: settle this against your actual version before planning a project. The feature set has moved considerably across recent release waves, and a statement that was correct a year ago may be out of date. Anyone still on Dynamics NAV does not have these built-in capabilities at all and should count e-invoicing as one of the reasons to move.
Peppol is the route, not the format
Peppol is often mistaken for an invoice format. It is in fact a network: sender and recipient each connect through an Access Point, and documents travel between the parties through those points in a standardised, traceable way. The format carried inside is a separate question.
For invoices to public sector bodies, Peppol is normally the intended channel. In B2B, email and supplier portals remain common alongside it, and many companies end up serving all three routes in parallel depending on what each customer requires. Planning for that from the start saves rebuilding later.
Where documents actually fail
When an e-invoice is rejected, the format is rarely the reason and the data almost always is. The recipient validates automatically, and anything missing shows up immediately — unlike a PDF, which a human will wave through with gaps if pushed.
That is why the most demanding part of an e-invoicing project is usually master-data work rather than technology. These points are worth checking before the first document goes out:
- Routing ID (Leitweg-ID) for public sector recipients — without it the document is rejected
- The customer's order or purchase number, carried cleanly in the document
- Complete payment details including IBAN and payment terms
- Correct tax codes, especially for reverse charge and exempt transactions
- Units and quantities in the coding the norm expects
Inbound invoices: the overlooked lever
Almost every project starts with outbound invoices, because that is where the obligation is visible. The money is in inbound. A structured incoming invoice can be read automatically, matched against the purchase order and the goods receipt, and routed for approval — without anyone retyping line items.
The benefit grows with document volume and is noticeable even when only some suppliers deliver structured data. It makes sense to start with the suppliers who send the most documents and let the rest follow as they have to switch anyway.
Frequently asked questions
- No. A PDF is not an e-invoice in the legal sense because it cannot be read in a structured way. A format under EN 16931 is required — in Germany primarily XRechnung or ZUGFeRD. ZUGFeRD looks like a PDF and is one, but additionally carries the data as embedded XML.
- Not necessarily. In pure B2B, e-invoices can also be exchanged by email or through supplier portals. Peppol becomes relevant as soon as public sector bodies are involved or larger customers specify it as the channel. Since access can be added later, it is not a decision that has to be locked down at the start.
- Not with built-in functionality. Dynamics NAV does not know the current generation of electronic document formats and no longer receives corresponding extensions. In practice two routes remain: put an external solution in front of the ERP, or treat e-invoicing as the trigger for planning the move to Business Central that is due anyway.
- The technical setup of formats and dispatch routes is manageable. The time goes into everything around it: cleaning up master data, exchanging test documents with the most important business partners, automating inbound invoices and training the finance team. A few weeks is realistic rather than months — provided the master data is in reasonable shape.
- The structured data set is the original and must be retained unaltered and in an audit-proof way. With ZUGFeRD the embedded XML is part of that — printing the PDF or regenerating it is not sufficient. The specific retention requirements are best clarified with your tax adviser.