Most companies I talk to about the German e-invoicing mandate have a clear picture of it: 2027 is when it gets serious, so there is time until then. The second half of that sentence is wrong, for a reason that is easy to miss.
Whether you have to issue e-invoices from 1 January 2027 is not decided by your revenue in 2027. It is decided by your total revenue in the preceding calendar year, which is 2026. The year that is running right now and closes in a little over three months.
Anyone who goes past 800,000 euros this year is up in January. This is not an abstract question about the future: your finance team can already judge well today whether you are approaching that threshold or will pass it.
The deadline that is already running
The staging looks the same in every overview, so here is only the part where the date matters.
Since 1 January 2025, every domestic company in Germany has had to be able to receive e-invoices for domestic B2B transactions. That applies already, with no transition period, and it applies to small businesses too. What is required is receipt, not onward processing: an email inbox is enough for that.
From 1 January 2027, the obligation to issue arrives for everyone whose total revenue as defined in § 19 (2) of the German VAT Act exceeded 800,000 euros in the preceding calendar year. For 2027, the preceding calendar year is 2026.
From 1 January 2028, the obligation to issue applies to all remaining domestic B2B transactions, regardless of revenue.
I would not bet on a postponement. The trades still call for the date to move to 2028. As the statute stands, 1 January 2027 holds. Plan against the deadlines that are in the law today.
What makes the 2027 threshold uncomfortable is that it looks backwards. By late December you can no longer influence whether it applies to you. You can only establish that it does, and then you have the holidays.
Who is affected and who is not
The mandate covers domestic B2B transactions between companies established in Germany. Invoices to private individuals are not meant, and neither are invoices abroad.
Exempt, including after 2028:
- Small-amount invoices up to 250 euros gross under § 33 UStDV. The typical trip to the builders' merchant falls under this.
- Transport tickets under § 34 UStDV.
- Small businesses under § 19 UStG, as far as issuing goes. They still have to be able to receive.
- Largely tax-exempt transactions under § 4 nos. 8 to 29 UStG, so letting, medical services or financial services, for example.
These exemptions are why a blanket answer to "does this affect us" rarely holds. A landlord with three million euros in revenue can be out of scope; a trades business with 850,000 euros is not. The question is not how big you are but which transactions you make.
What counts as an e-invoice, and what only looks like one
This is where the most common mistake sits, and it costs nothing until somebody looks.
An e-invoice in the legal sense is an invoice in a structured electronic format that allows electronic processing. The standard route runs through the European norm EN 16931. Beyond that, the parties may agree another structured format, EDI for instance, provided the legally required details can be extracted from it completely and without loss of information into a compliant format. XRechnung and ZUGFeRD are the widespread examples, but they are examples rather than an exhaustive list: what counts is the format, not the brand name.
A PDF is not an e-invoice. A scanned sheet of paper certainly is not. And, this is the part many people have not registered: ZUGFeRD is not simply ZUGFeRD.
The German finance ministry's circular of 15 October 2025 makes clear that ZUGFeRD meets the requirements only from version 2.0.1, and that the MINIMUM and BASIC-WL profiles are explicitly excluded. Neither profile carries the complete structured invoice content required for that.
In practice: if your supplier sends you ZUGFeRD MINIMUM, you have received a PDF with a data attachment, not an e-invoice. And if your own system issues ZUGFeRD MINIMUM from 2027, you are not meeting your obligation, even though the invoice says ZUGFeRD and your software calls it that.
This is a question to put to your software vendor, and the answer should contain a version number and a profile name. "We support ZUGFeRD" is not an answer.
Being able to receive is not the same as being done
Most companies solved the receiving obligation back in 2025, and many consider the topic closed. Technically they are right: the file arrives, it opens, the obligation is met.
Except that receiving is the smaller half of the job, and the cheaper one. What happens afterwards has stayed unchanged in most places: the invoice lands in a shared mailbox. Someone looks through it. Forwards it to the department. Waits for an "all good" by email. Types supplier, amount and tax rate into the accounting system. Sets the cost centre. Files the document.
The joke in that sequence: with an XRechnung, the first three fields were already sitting machine-readable in the file. They were read by a human, carried through that human's head, and typed back in. That is a media break in the middle of a process that had already arrived in digital form.
The mandate settled the format. It built nobody the path from invoice to booking.
The expensive part comes after the format
Work it out once with your own numbers. It takes five minutes and tells you more than any study.
Take the number of incoming invoices per month. Multiply by the minutes an invoice costs in human time from arrival to booking, forwarding and follow-up questions included. At two hundred invoices and twelve minutes that is forty hours a month, a quarter of a position doing nothing but carrying data from left to right.
Then add the cases where an early-payment discount lapsed because the document was in transit too long. Your finance team usually knows that figure, and it is regularly larger than expected.
What comes out is the real bill. Switching the format is a compliance exercise with a cut-off date. The process behind it is a recurring cost you pay every month, whether you measure it or not.
From that number on, e-invoicing stops being a compliance topic and becomes an automation project with a business case that either adds up or does not.
What actually needs doing before January
If you are above the threshold in 2026, or not sure, this is the order I would suggest.
First: establish the number. Ask your finance team for the expected total revenue for 2026 as defined in § 19 (2) UStG. Not the revenue from the management report, not the revenue from sales. The definition is a tax one, and the answer belongs to someone who knows it.
Second: check what your system actually issues. Not whether it "does e-invoicing", but which format, which version, which profile. Get hold of a real file and validate it against the standard; there are free validators for that. A company producing ZUGFeRD MINIMUM believes it is finished and is not.
Third: count the inbound side. How many invoices arrive per month, by which route, in which formats, from how many suppliers. Almost always the share of already structured invoices is larger than assumed, and almost always those are the ones being retyped.
Fourth, and only now: decide what gets built. Without the first three points, every decision about software is a bet.
What you do not have to do is everything at once. Outgoing and incoming invoices are two separate projects with two separate deadlines. For 2027, what counts first is that you can issue to the standard.
Where a portal is enough and where it is not
The obvious route is an invoice portal, and for a share of cases it is the right one. If you run no accounting system with a usable interface and can live with a vendor's standard workflow, buy the portal and you are done. That is not a fallback, it is the cheaper answer.
Where an ERP with an interface does exist, the maths changes. A portal there mostly solves filing and defers the rest: the document now sits in a second place, approvals still run over email, and the data still reaches the accounting system through a file somebody maintains. You have one more system and the same workflow.
The alternative is to build the path itself, into the systems you already run: read the file, check it against the purchase order or master data, route it for approval by amount and cost centre, hand it to the target system, log every step. Invoices with nothing unusual about them then pass through without anyone looking, which is what straight-through processing means. What still gets looked at is what needs a decision.
Which of the two is cheaper for you comes down to the volume profile and to whether a target system with a documented interface exists. Both are settled within a few days. So if an ERP or accounting system with an interface is already in place at your end, it is worth thinking past a portal. How I build an inbound path from the structured document through to the posting is on the page about automating invoice processing.
What this article is not
Not tax advice and not legal advice. I build the technology behind it, and I name the sources so that you and your tax adviser can work from them. Assessing your specific case, in particular the question of total revenue under § 19 (2) UStG and the question of archiving, belongs with your adviser.
The details here are current as of 9 September 2026 and rest on § 14 UStG, § 19 (2) UStG, § 27 (38) UStG, §§ 33 and 34 UStDV, and the finance ministry circular of 15 October 2025. Check them before you base a decision on them. With deadlines that can move, an article is only ever a snapshot.
