E-Invoicing From 1 January 2027: Why Your 2026 Turnover Decides It and the Threshold Is Not the Figure in Your Accounts

The date everyone repeats is 1 January 2027. The figure that actually decides whether it applies to you is being produced right now, in the financial year you are currently trading through. And it is not the revenue line in your accounts. That is the part almost every summary of the German e-invoicing rules leaves out, and it is the part that determines whether you have four months of work ahead of you or sixteen.

What the statute actually orders

It helps to start with the structure, because most coverage inverts it. Under section 14(2) sentence 2 no. 1 of the German VAT Act, where a business supplies another business for that business’s enterprise and both are established in Germany, the invoice is to be issued as an electronic invoice. That is the rule, and it is already in force. Paper and PDF are not the default that ends in 2027; they are an exception that is being withdrawn in stages.

The definition sits one paragraph earlier and is precise. An electronic invoice is one issued, transmitted and received in a structured electronic format permitting electronic processing. An invoice in any other electronic format, or on paper, is an “other invoice”. A PDF sent by email is electronic in the everyday sense and an “other invoice” in the statutory one. This single distinction accounts for a large share of the companies that believe they are already compliant.

The staircase, taken from the text

The exception lives in section 27(38), and it has three limbs rather than the two that usually get reported.

From 1 January 2028 all three limbs are gone and the obligation applies without regard to size or transmission method.

The threshold is not the figure in your accounts

Section 27(38) no. 2 does not say “turnover”. It says total turnover within the meaning of section 19(2), and that provision defines something narrower than the revenue most managing directors would quote from memory. Two differences decide borderline cases.

First, section 19(2) measures the sum of taxable supplies calculated on consideration actually received. It follows cash in, not invoices issued. A company that raised large invoices in December 2026 and was paid in February 2027 carries those amounts differently here than in an accrual-based revenue line.

Second, and more often decisive: supplies of fixed assets are expressly left out of account. Sell a machine, a vehicle or a property in 2026 and the proceeds appear in your profit calculation while remaining outside total turnover under this provision. For a company trading somewhere near EUR 800,000, a single disposal is enough to move it across the line in the accounts and not in the statute.

The practical instruction that follows is narrow and worth acting on: if you are anywhere within roughly ten percent of the threshold, have the figure calculated under section 19(2) specifically, rather than read off a management report. It is a question for your tax adviser, it takes minutes to answer, and the answer determines whether your deadline is January 2027 or January 2028.

The EDI limb almost nobody mentions

The third limb of section 27(38) is the most useful provision in the entire transition for a certain kind of company, and it is routinely omitted from summaries. Businesses transmitting invoices by electronic data interchange under Recommendation 94/820/EC may continue to use a non-conforming format until 31 December 2027 with the recipient’s consent, and this limb carries no turnover condition at all.

For an automotive or retail supplier with EDI links grown over fifteen years, that is the difference between a controlled migration and an emergency project. The exception exists precisely because those connections work, are deeply embedded in both parties’ systems, and cannot sensibly be replaced on the same timetable as a small company switching on a new invoicing module. If this describes you, the relevant deadline is a year later than you have probably been told.

The duty that has been running for twenty months

While attention sits on issuing, the obligation that is already binding is the one on the receiving side. Since 1 January 2025 every German-established business must be able to receive an e-invoice, and no transition period applies to it.

The reason is visible in the drafting. Section 27(38) permits an invoice to be transmitted or issued in a deviating form. It says nothing about receipt, and therefore confers no right to refuse. The Federal Ministry of Finance puts it plainly in its published questions and answers: no exceptions are provided for the ability to receive. Small businesses permanently exempt from issuing are explicitly still required to accept.

What this means in practice is unglamorous and entirely fixable. A supplier is entitled to send you an XRechnung today. If it lands in a shared mailbox that nobody has configured to parse it, and it is treated as an unreadable attachment, the invoice was validly issued and you are the one with the problem. The minimum standard is a monitored address that reliably receives such files and a defined route from there into your accounting.

Eight years, and the structured part must survive

Section 14b(1) requires invoices to be retained for eight years and, in the sentence that carries the weight, requires that they meet the requirements of section 14(3) sentence 1 for the entire period: authenticity of origin, integrity of content, legibility. The Ministry adds that the structured part must remain intact in its original form.

Two failure modes follow, and both are archiving problems rather than invoicing problems. The obvious one: an incoming XRechnung is rendered to PDF for readability and only the rendering is filed, which means the governing record was never retained. The subtler one concerns ZUGFeRD, where the structured data sits inside the PDF. If a document management system re-writes the file on ingestion, normalises it to PDF/A, or strips embedded attachments, the result looks identical on screen and has lost the part that makes it an invoice in the statutory sense.

This is worth testing rather than assuming. Take one ZUGFeRD invoice that has been through your archive, extract it again and confirm the XML is still there. It is a fifteen-minute check that either confirms your setup or surfaces a problem now, at a point where the affected volume is small.

The determination the statute asks you to make

Section 14(3) contains a requirement that reads like boilerplate and is not. Each business itself determines how authenticity of origin, integrity of content and legibility are ensured, and this may be achieved by any internal control procedure creating a reliable audit trail between invoice and supply.

Note what that does and does not demand. It does not prescribe software, a certification, or a particular architecture; the wording is deliberately permissive. What it does require is a determination, made by you, capable of being described. In most mid-sized companies the procedure exists and functions, invoices are matched against order and goods receipt every day, but nobody has ever written down how. The obligation is not to build something new. It is to record what already happens, in one page, before somebody asks.

What the next four months are for

• Establish which deadline is yours. Ask your tax adviser for total turnover under section 19(2), not the revenue figure. If you use EDI, the third limb may apply regardless and move you to 2028. Everything else depends on this answer, so get it first.
• Test receiving before you build sending. Have a supplier send you a real XRechnung and follow it end to end. This is already binding, unlike the issuing side, and it is the cheapest test in the whole project.
• Verify the archive keeps the structured part. Pull one ZUGFeRD file back out and check the embedded XML survived. If it did not, you have an archiving configuration to fix, not an invoicing system to replace.
• Write the internal control procedure down. One page describing how invoice, order and goods receipt are matched. You are documenting existing practice, not designing a new process.
• Check your master data before the format. Structured invoices fail on missing recipient identifiers, wrong tax numbers and inconsistent unit codes, not on the XML itself. Data quality that a human reader silently corrected becomes a rejection once the recipient is a machine.

Conclusion

The e-invoicing obligation is unusual among current compliance deadlines in being entirely predictable: no delegated acts pending, no omnibus procedure that might move it, a date fixed in statute. What varies is which date applies to you, and that turns on a figure calculated under a provision most people have never read, in a year that is still running. Establish that first, then test the receiving side that has been binding since 2025, then check that your archive keeps the part of the file that matters. The software question is real but comes last, and it is smaller than the process and master data questions that sit in front of it. If you want to know where your invoicing chain would actually break, that is what a first conversation is for, and the wider groundwork is set out in IT strategy in the mid-market.

Frequently asked questions on the 2027 e-invoicing obligation