What applies from when
Only as much as the IT side needs for a frame. Whether and when the rules bite for your firm, the turnover threshold, the exceptions for small businesses or tax-exempt services: that is your tax adviser’s work, not ours. The rules themselves are in the Federal Ministry of Finance’s questions and answers (in German).
- Since 1 January 2025, German businesses have had to be able to receive e-invoices. The recipient’s consent is no longer needed.
- Until 31 December 2026, invoices between German businesses may still be sent on paper or as a PDF, if the recipient agrees.
- From 1 January 2027, firms with more than €800,000 turnover in the previous year must issue e-invoices. From 1 January 2028, every firm must.
- An e-invoice is a structured data format under the EN 16931 standard, in Germany mostly XRechnung and ZUGFeRD. A PDF by email is not an e-invoice, however good it looks; the Berlin chamber of commerce files it under “other invoice”.
The duty covers invoices between businesses inside Germany. Invoices to consumers and abroad are not affected, nor are small-amount invoices and tickets. What that means for your matters, projects or fee notes in detail is for your tax adviser.
XRechnung or ZUGFeRD?
Both meet the standard, and most programs can do both. The difference is what a person sees. An XRechnung is a pure XML file: perfect for accounting software, unreadable to the eye until a program displays it. ZUGFeRD is a PDF with the same XML file inside: the clerk sees the familiar invoice, the software reads the structured part. Public-sector clients mostly require XRechnung, often with a routing ID of the recipient that has to go on the invoice. Between businesses, ZUGFeRD is the friendlier path day to day, because nothing people see changes.
For IT that means: both formats have to arrive, be read and be archived, and the firm’s software has to produce the format your recipients require.
What that means for IT: four things
Intake
An e-invoice arrives as an XML file, usually by email, sometimes through a supplier’s portal. Your firm needs one mailbox every supplier knows and someone reads, invoices@ say, and a path from there into bookkeeping or to the tax adviser that doesn’t rely on somebody forwarding attachments by hand. In Microsoft 365 that is a shared mailbox with fixed permissions, a deputy rule, and a forward or a pick-up by the accounting software.
Two things tend to go wrong. Spam and virus filters like to block XML attachments wholesale; the rules have to let e-invoices through and still inspect them, because an XML attachment is also a favourite way in for malware. And invoices land in personal mailboxes and sit there while the person is on leave or has left the firm. A supplier still using the old address gets a friendly reply with the new one, automatically.
Archive
The structured part of the e-invoice, the XML file, has to be kept unchanged and in its original form for the whole statutory retention period. A mailbox is not an archive: it gets tidied, migrated, deleted, and a rule that removes old mail after two years removes the invoice with it.
What you need is a store that changes nothing and loses nothing: in your document system, in the accounting software itself, or in Microsoft 365 with retention rules that prevent deletion before the period ends. With it comes a procedural description of how invoices arrive, are checked, booked and archived, who may do what, and what happens on an error. IT supplies the technical part of that description; your tax adviser the tax part.
The firm’s software
You issue e-invoices from the software you write invoices with today: practice management, the office’s billing, accounting. DATEV, RA-MICRO, Advoware, Lexware and the large office and ERP systems have modules or updates for XRechnung and ZUGFeRD; some require a new version, an add-on or a different licence, and some older installations sit on a server that won’t take the update any more.
So for IT: check the version and the licence, schedule the update with the vendor, set the permissions (who creates, who approves, who sends), and run a test with your tax adviser before the first real invoice goes out. The test is where the master data shows itself: VAT ID, routing ID, bank details, payment terms. An e-invoice with wrong master data cannot be corrected with a pen.
Security
A change in how invoices work is a fraudster’s favourite season. “Our bank details have changed” lands with unusual credibility, and a forged XML invoice looks like any other; a PDF might have given itself away by a crooked template, an XML file does not.
Three rules your firm needs before January: a new bank account is always confirmed through a known channel, never through the email that announces it; mailbox rules that redirect or delete invoices are monitored, because that is how fraud with a taken-over account begins; and the people who handle invoices know what the fraud looks like, because they have seen it once.
What we set up
- The invoice mailbox as a shared mailbox with permissions, a deputy and the route into bookkeeping, and filter rules that inspect XML attachments instead of blocking them.
- The store with retention rules, in Microsoft 365 or the document system, and the technical part of the procedural description.
- The vendor’s update of the firm’s software, the permissions, the test run with the tax adviser.
- The rules against invoice fraud, the monitoring of mailbox rules, and the short briefing for the people who handle invoices.
The questions to ask your IT
- Which mailbox do our e-invoices land in, who reads it, and where do they go from there?
- Where does the XML file live after booking, and for how long does it stay unchanged?
- Which version of our software issues e-invoices, and is it installed?
- What happens when an invoice arrives with new bank details?
- Who holds the procedural description, and when was it last touched?
Before January: the order
Intake and archive first, because you already have to receive today. Then the software, with the test run in December, not January. The fraud rules alongside, because fraud doesn’t wait for the deadline. And a date for each, ahead of your own deadlines.
Questions we get
Is a PDF by email still enough?
Until the end of 2026, yes, if the recipient agrees. From 2027 no longer for firms above the turnover threshold, from 2028 for nobody in domestic business between firms. You already have to be able to receive e-invoices today, whatever you issue yourself.
Is an ordinary email mailbox enough for receiving?
For receiving, yes. The problem is not the receiving but what happens next: who reads the mailbox, how the invoice gets into bookkeeping, and where the XML file stays for the coming years. A mailbox answers none of those questions.
Do we need new software?
Usually not. The software you write invoices with today can do it in a current version, as a rule. What you need is the update, the add-on or licence where required, and a test run. It becomes new software only if your vendor won’t add e-invoicing at all.
What about invoices to private clients or abroad?
The duty covers supplies between businesses inside Germany. For consumers and recipients abroad the old way stays. Whether one of your invoices falls under the duty is a question for the tax adviser, not for IT.
For how long do we have to keep e-invoices?
For the statutory retention period for invoices, and in a way that leaves the structured part unchanged. The period itself is your tax adviser’s to name; IT makes sure that nothing gets deleted, altered or forgotten in the next migration during that time.