Germany’s 2027 E-Invoicing Deadline: What Groups With a German Subsidiary Need to Do Now
From 1 January 2027, German companies with more than €800,000 turnover must issue structured e-invoices. If your group owns a German subsidiary, its ERP has about three months left to get ready.
Your group finished the Belgian Peppol project in January. The French entity went through its own reform in September. And somewhere in the group structure there is a German subsidiary that still sends its customers a PDF by email, because nobody has told it otherwise. Germany e-invoicing in 2027 is the next deadline, and for many mid-sized groups it is the one that has had the least attention.
From 1 January 2027, German companies whose turnover in the previous year exceeded €800,000 must issue structured e-invoices to their German business customers. Everyone else follows on 1 January 2028. That leaves roughly one quarter, with a year-end close in the middle of it. Below is who is caught, what counts as an e-invoice, and what the ERP behind that German entity has to do before the first invoice of 2027.
What changes for Germany e-invoicing in 2027
Germany has been phasing this in since 2025. The steps, as summarised by Avalara in September 2026 and by the European Commission’s eInvoicing country page, are:
Since 1 January 2025: every business established in Germany must be able to receive a structured e-invoice. This part already applies.
From 1 January 2027: businesses with more than €800,000 turnover in the previous calendar year must issue structured e-invoices for domestic B2B sales. Paper and plain PDF are no longer allowed for them.
From 1 January 2028: the obligation extends to all remaining businesses, and the transition allowance for older EDI formats that do not meet the European standard ends.
The threshold is measured per legal entity on its prior-year turnover, not per group. A small German sales company in a large group can therefore land either side of it. Check the 2026 figure for each German entity rather than assuming.
Does it apply to your subsidiary?
The mandate covers invoices between businesses that are both established in Germany. That point matters for foreign groups. According to Avalara, a German VAT registration alone does not make a company established in Germany; it takes a registered office, place of management or a fixed establishment that takes part in the sale. So in practice:
A German GmbH selling to German customers: in scope, and very likely over the threshold.
A Belgian or Dutch company that is only VAT-registered in Germany, for example for a warehouse or distance sales: probably not in scope for issuing, but check the fixed establishment question.
Cross-border sales from Germany to Belgium or the Netherlands: not covered by the German domestic mandate. The Belgian side has its own rules, and Belgium’s 2028 e-reporting plan adds more.
A PDF is not an e-invoice
This is where most surprises come from. Under the German rules, an e-invoice is a structured data file that follows the European standard EN 16931. The two formats German customers will expect are XRechnung, which is pure XML, and ZUGFeRD, which embeds the same XML inside a PDF so a person can still read it. Peppol BIS Billing 3.0 is also accepted. A PDF generated from your ERP’s invoice layout and sent by email is not an e-invoice, however professional it looks.
That means the change is not in the email server. It is in the ERP: the invoice has to be produced from data that is complete and correct enough to fill a structured file, every time, without anyone fixing it by hand.
What the ERP has to do before 1 January
In our ERP and integration work, the technical format is rarely the hard part. Most current ERPs, or a connector sold for them, can produce XRechnung or ZUGFeRD. The work sits around it.
Clean the master data. A structured invoice needs complete customer VAT numbers, addresses, payment terms and, for public customers, routing identifiers. Gaps that a human reader ignored will now reject the invoice.
Decide the format per customer. Some large German customers will ask for XRechnung through a portal, others for ZUGFeRD by email, others for Peppol. Record the choice on the customer card, not in someone’s head.
Check credit notes, corrections and recurring invoices. These are the flows that were set up years ago and that nobody tests. They have to produce valid files too.
Test with real customers in November. Send test invoices to your five largest German customers and get a confirmation that they can read them.
Agree the fallback. If a file is rejected on 5 January, who sees it, who fixes it, and how quickly does the customer get a valid invoice?
Archive the structured file, not only the PDF. The XML is the legal invoice now, and it has to be kept.
Why this lands on the application team
In most mid-sized groups we meet, the German entity has no application manager of its own. Its ERP is run from the head office, often in another country and another language, by a team that just finished Belgian Peppol and is now asked to do the same for Germany under a different set of rules. That is not a reason to panic, but it is a reason to name one person who owns the German change end to end, with a plan and a test list, rather than treating it as a ticket in the queue.
If that person does not exist, an interim application manager can take it, deliver it, and hand it back to the team with documentation. That is how we covered a key application role for Culligan Austria for six months while the internal team was trained up.
The bottom line
Germany e-invoicing for 2027 is a data and process change dressed up as a format change. If your German subsidiary had more than €800,000 turnover this year, its invoices to German business customers must be structured from 1 January. Check the threshold per entity, clean the customer data, test with real customers before December, and keep the change away from the year-end close. The groups that treat it as a small IT ticket will find out in the first week of January.
Comments
Loading comments…