E-invoicing in Germany: what CFOs and CIOs need to know before January 2027

France went live on 1 September. For three years it absorbed all the attention in this space: the platforms, the directory, the lifecycle statuses, the acronyms that changed name twice. Germany, meanwhile, legislated quietly, set the dates, published the guidance, and has been waiting ever since.

That quietness is the problem. A French project announced itself. The German one does not, because there is nothing to connect to, nobody to be certified by, and no government system to fail against. So it reads like a document-format change, gets an IT line rather than a programme line, and arrives in the fourth quarter of 2026 as a surprise.

Here is the briefing I would want on one page if I sat in a German CFO, CIO or CTO chair right now.

What Germany actually decided

Three dates, and one of them has already passed.

1 January 2025 — receiving. Every domestic business has had to be able to receive a structured e-invoice since the start of 2025. There was no transition period for this and there is no threshold. If a supplier sends you an EN 16931 invoice today, you are obliged to accept it. In practice, a great many companies met this with an inbox and a promise.

1 January 2027 — issuing, above EUR 800,000. If your prior-year turnover exceeds EUR 800,000, every domestic B2B invoice you issue must be a structured e-invoice. Paper and PDF stop being valid invoices for VAT purposes.

1 January 2028 — issuing, everyone. The threshold disappears. All domestic B2B invoicing is structured, save the statutory exemptions.

Two details that get missed. First, the EUR 800,000 test looks at the issuer’s prior-year turnover, so a mid-sized German subsidiary of a large group can be in the 2027 wave while the group treats it as a small entity. Check it per legal entity, not per group. Second, existing EDI arrangements are only protected until 31 December 2027. If your German entities exchange invoices over long-standing EDI links with major customers, that is not an exemption, it is a runway — and it ends on the same day the second wave starts.

What is out of scope: B2C, small-value invoices under EUR 250 gross, transport tickets, invoices from Kleinunternehmer, and supplies to non-business recipients. Everything else is in. The dates and scope are also on our Germany e-invoicing mandate page.

The model: nobody is standing in the middle

This is where Germany diverges from almost everyone else, and where the planning mistakes start.

There is no central platform. No clearance. No accredited-provider regime. No transaction data flowing to the tax authority when you invoice a customer. Germany went post-audit: you and your customer exchange the invoice through whatever channel you agree — Peppol, an EDI link, a provider network, an API, or plain email — and the Finanzamt only ever sees it if it asks.

Germany has also explicitly deferred the transaction reporting system it once discussed. There is no national Meldesystem on the legislative track, and the government has signalled it will not build one ahead of the EU’s own digital reporting requirements under ViDA, which start for cross-border trade on 1 July 2030. Plan for the mandate that exists.

Two consequences follow, and they pull in opposite directions.

The good one: the integration surface is smaller than France’s. No certification, no lifecycle status model to implement, no directory registration, no e-reporting flows. If your only mandate were Germany’s, this would be a modest piece of work.

The bad one: there is no system to tell you that you got it wrong. In a clearance country, a malformed invoice is rejected within seconds and you know about it. In Germany, a malformed invoice is accepted, posted, paid — and then surfaces in an audit two or three years later, when your customer’s input VAT deduction on it is challenged and your commercial relationship becomes an accounting problem. Silence is not confirmation.

XRechnung or ZUGFeRD, and why you may need both

Germany permits any format that meets EN 16931. In practice that means two.

XRechnung is pure structured XML. It is the format of the German public sector, it is unambiguous, and a human cannot read it without a viewer. ZUGFeRD (from version 2.0.1, excluding the MINIMUM and BASIC-WL profiles) is a hybrid: a normal-looking PDF with the structured XML embedded inside it. The recipient’s AP system reads the XML; the recipient’s AP clerk reads the PDF.

The instinct is to pick one. The realistic answer for a company with a mixed customer base is that you will need to produce both, because the choice is not yours — it is your customer’s. Public sector customers and large corporates with mature AP automation will ask for XRechnung. Mid-market customers whose AP process still runs on a person looking at a document will be far better served by ZUGFeRD, and will tell you so.

One piece of the October 2025 BMF guidance deserves a slide of its own: in a hybrid invoice, the structured data is the authoritative part. If the XML and the PDF disagree, the XML wins. That sounds academic until you consider how many D365 invoice layouts carry information — a discount note, a corrected address, a project reference — that was added to the printed document and never made it into the data model. From 2027, that is not a cosmetic mismatch. It is a wrong invoice.

What the tax authority actually requires of you

Three things, none of them technical, all of them easy to underestimate.

The structured file is the original, and you keep it for eight years. Unchanged, complete, legible, in its original form. Archiving the PDF rendering of a ZUGFeRD invoice is not archiving the invoice. If your current retention design is “the document management system keeps the printout”, it needs revisiting.

Validation is effectively expected. The BMF distinguishes three classes of defect — format errors at syntax level, business rule errors at semantic level, and missing statutory content — and all three can cost the recipient the input VAT deduction until corrected. The guidance urges technical validation and says the results should be documented and retained. Read plainly: validate before you send, validate what you receive, and keep the evidence.

Your process documentation matters more than it did. How invoices are received, validated, posted and corrected is now an audit artefact. Most groups have this for the paper world and not for the structured one.

What Dynamics 365 F&O gives you, and what it does not

The honest version, because this is where budgets are set wrongly.

Microsoft gives you XRechnung generation. The German localisation produces XRechnung version 3 and later through Electronic Reporting, using the Sales Invoice DE and Project Invoice DE format configurations — which are themselves built on the Peppol and UBL configurations, so the underlying model is standard and portable. You can attach a PDF rendering. Microsoft also runs the Electronic Invoicing service within Globalization Studio, and shipped a unified e-invoicing integration framework in 2026 that gives providers one data contract to build against instead of one connector per country.

Microsoft does not give you three things. It does not generate a ZUGFeRD hybrid PDF out of the box — embedding EN 16931 CII XML into a PDF/A-3 with the right metadata is not part of the standard localisation. It does not transmit your invoices: Electronic Reporting writes the file to a destination, and Microsoft is not a Peppol access point or a network operator. And it does not read your vendors’ inbound e-invoices into AP for you in any complete way.

So the German project is a small standard core plus three decisions: how invoices leave the system, which formats you support, and what happens to the ones arriving from your suppliers.

That is the approach we take, and it is deliberately unglamorous. We build on standard Electronic Reporting wherever the standard reaches, so upgrades stay boring. Where it does not reach — ZUGFeRD hybrid output, pre-submission validation, provider handshakes, status handling, AP intake — we add light custom code designed to survive One Version updates, rather than a fork of the localisation that someone has to re-merge twice a year. On transmission we are provider-agnostic: if you have already chosen a Peppol access point or a service provider, we integrate to it; if your customers are happy with email and you have no network relationship, we can do that too, because Germany permits it.

If you are still on AX

AX 4.0, AX 2009 and AX 2012 will receive no German localisation update for this, ever. The mandate applies to the company, not to the software it happens to run, so the obligation lands on you exactly as it lands on a D365 customer — without a vendor building the format for you.

The upgrade conversation is a separate one and it does not fit before January 2027. What does fit is a retrofit: generate EN 16931-compliant XML from the invoice data already in AX, exchange it with Peppol or your provider, and track the outcome against the invoice record inside AX. That is what our eInvoicing for Dynamics AX solution does, and it is the pragmatic answer for a group that intends to move to D365 in 2028 or 2029 but has to be compliant in 2027.

Germany is not France, and the difference cuts both ways

If your group has just been through the French go-live, resist the urge to reuse the plan. France gave you accredited platforms, a directory, e-reporting flows and a mandatory lifecycle status model; the compliance burden was heavy but the system told you where you stood. Germany gives you a format, a deadline and silence.

The reusable parts are real, though, and if you have just done France you are further ahead than you think: your EN 16931 generation layer, your master data clean-up, your validation discipline and your archiving design all carry over. What does not carry over is the assumption that a platform will catch your mistakes.

Why 2026 is the work year

Count backwards from 1 January 2027 and you have sixteen weeks. Not a year. Sixteen weeks, two of which are Christmas.

You need a provider decision, or a decision not to use one. You need a contract and a connection, which is procurement plus integration — rarely less than six to eight weeks in a group that has a purchasing process, and that alone is half of what is left. You need your master data right, because missing VAT IDs, wrong country codes, unmapped units and tax categories are the single largest cause of rejections and the longest lead-time item in any of these projects. You need both formats built and agreed with your top customers, which means asking them, which means waiting for their answers. Then you need a genuine test cycle: real invoices, real customers, credit notes, partial deliveries, intercompany, project invoices, prepayments, foreign currency, reverse charge.

That last one is what gets skipped, and it is the one that matters. Every e-invoicing project I have seen fail did so on a scenario nobody tested — a correction invoice with no clean reference to the original, a project invoice whose line structure does not survive EN 16931, an intercompany flow where the legal entity’s own VAT registration was never maintained.

December 2026 is not a testing window. It is a code-freeze and a Christmas break. Which means the work has to start this month or next.

If your German entities are below EUR 800,000 and land in the 2028 wave, you have a genuine year and you should use it deliberately rather than repeat this exercise next September.

How we can assist

Dr Dynamics is an independent D365 F&O advisory and delivery practice, and e-invoicing is one of the things we do repeatedly rather than occasionally — France, Belgium, Italy, Poland, Norway, and now Germany. For a German mandate that means a short impact assessment against your actual F&O or AX configuration, a format and provider decision you can defend to your auditor, XRechnung and ZUGFeRD output, validation before submission, an AP intake design, and an archive that holds the structured original for eight years.

The approach and architecture are set out on our solution pages: eInvoicing for Dynamics 365 Finance & Operations and eInvoicing for Dynamics AX.

There is still — just — enough time to build an integration to your provider and test every scenario properly before January. By November there will not be. Book a 30-minute call and we will tell you honestly how much runway you have left.