Germany e-invoicing in 2027: the €800,000 transition rule explained

What actually changes on 1 January 2027

Germany’s e-invoicing rules are already in force. The Growth Opportunities Act revised section 14 of the German VAT Act for supplies carried out after 31 December 2024, and the new definition has applied since 1 January 2025. Under that definition, an electronic invoice is a structured electronic document that can be processed electronically. A conventional PDF is classified as an “other invoice”, even though it is delivered digitally.

The operational break on 1 January 2027 comes from the transition provisions, not from a new mandate being adopted on that date. Section 27(38)(1) permits every issuer to use paper, or a non-structured electronic format with the recipient’s consent, for supplies performed from 1 January 2025 through 31 December 2026. That broad permission expires at the end of 2026.

For supplies performed during 2027, the fallback splits by issuer. An entrepreneur whose total turnover in the preceding calendar year did not exceed €800,000 may continue using paper or, with recipient consent, an ordinary electronic format until 31 December 2027. A non-qualifying EDI arrangement also receives a separate transition through 2027. An issuer above the turnover threshold cannot rely on the small-issuer extension for an in-scope domestic B2B supply.

The exact dates must remain distinct. The law was promulgated in March 2024; the revised invoice rules began to apply on 1 January 2025; the Ministry refreshed its FAQ on 23 March 2026; the broad transition ends on 31 December 2026; the final turnover and EDI transitions end on 31 December 2027. None of those milestones should be described as a proposal or consultation.

The €800,000 test belongs to the invoice issuer

The most common interpretation error is to apply the €800,000 threshold to the buyer, the value of the invoice or the supplier’s global group. Section 27(38)(2) refers to the total turnover, calculated under section 19(2), of the entrepreneur issuing the invoice in the preceding calendar year. The legal entity and the relevant year must therefore travel with the decision.

For a supply performed in 2027, the relevant turnover period is generally 2026. A multinational buyer may receive a qualifying structured invoice from one German supplier and a legally permitted PDF from another, even where the purchases look identical. The difference is the exact issuing entrepreneur’s statutory position, not the buyer’s procurement category or risk tier.

The buyer will not always hold the supplier’s statutory turnover calculation. That creates a governance question rather than permission to guess. For suppliers that continue sending ordinary PDFs during 2027, procurement or accounts payable should define proportionate evidence: the issuing legal entity, the calendar year tested, the asserted turnover band, the person making the assertion, the date and the expiry. A permanent “small supplier” flag is not defensible because legal entities, ownership and turnover can change.

Avoid demanding audited accounts from every supplier simply to receive an invoice. The evidence burden should be proportionate to invoice volume, materiality and the risk of disruption. But an unrecorded email or a group-level sales estimate is not a repeatable control. The status should expire before the 2028 cutover or earlier if the billing entity changes.

Who is affected—and which invoices can remain outside the structured rule

The core issuing duty concerns supplies from one entrepreneur to another entrepreneur for the recipient’s business where both parties are established in Germany within the statutory test. Establishment can arise through a registered office, place of management or a fixed establishment involved in the transaction. German VAT registration by itself does not automatically make a foreign business German-established for this purpose.

The Federal Ministry of Finance says that a foreign entrepreneur registered for German VAT but without a German fixed establishment may state that fact on the invoice. A recipient exercising ordinary commercial care may rely on that statement. In enterprise systems, that conclusion should not be stored as a timeless country flag: it is a transaction-linked assertion about the issuing entity and the establishment involved in the supply.

Consumer invoices are outside the domestic B2B rule, and many VAT-exempt supplies listed in section 4(8)–(29) do not create the same VAT invoice duty. Separately, the Ministry identifies cases where an invoice may remain an “other invoice” even where an invoice is required: qualifying low-value invoices up to €250 gross, tickets treated as invoices, supplies by entrepreneurs using the small-business exemption, supplies to legal persons not acting as entrepreneurs and specified property-related supplies to consumers.

“Outside the B2B mandate” does not mean “no invoice obligations”. VAT, civil-law, sectoral and public-procurement requirements can still apply. Germany’s B2G rules also operate alongside the VAT rules rather than underneath them. A transaction may have a VAT transition right yet still need an electronic invoice because the customer is a public authority and a separate procurement rule applies.

• Use supply date as a controlling field; invoice receipt date alone is insufficient.
• Separate German establishment from German VAT registration.
• Bind every exception to the exact supplier, transaction type, reason and effective period.
• Distinguish B2B VAT rules from B2G channel and threshold requirements.
• Represent uncertain cases as review states, not as a generic PDF-allowed flag.

The recipient cannot wait until 2027

German-established businesses have needed to be able to receive an e-invoice since 1 January 2025. The Ministry says there are no general recipient-side exceptions to that capability, including for entrepreneurs using the small-business regime. An email inbox is sufficient as a minimum transport channel. That is a legal floor, not an adequate enterprise operating model.

An inbox does not explain whether the structured file is quarantined, scanned, validated, rendered, matched to a purchase order, compared with supplier master data, posted, routed for approval and archived without alteration. It also creates a human-factors problem: a reviewer may approve a familiar PDF image while the accounting system consumes different values from an embedded XML file.

For a hybrid invoice such as a qualifying ZUGFeRD document, the structured data is the leading component when it conflicts with the visual layer. The Ministry recommends independently visualising the XML. Accounts payable should therefore show reviewers the fields that will actually be booked—supplier, recipient, tax identifier, invoice number, issue date, supply date, taxable amount, VAT rate, VAT amount, currency, buyer reference and payment instructions—and raise a controlled exception when the visual and structured layers diverge.

The original payload should remain immutable. Rendering, normalisation and mapping are processing steps with their own versions and timestamps. If a supplier sends a PDF by email and the same liability through a structured channel, shared deduplication is essential; otherwise the migration can create duplicate obligations rather than remove manual work.

XRechnung, ZUGFeRD, PDF and EDI do not have the same legal status

Germany’s domestic B2B VAT rule does not prescribe one transmission network. The Ministry lists email, an electronic interface, shared access to a central storage location, physical media and portal download as possible transport methods. The parties still need a workable commercial channel, but delivery over a digital channel does not make the document a qualifying e-invoice.

The central legal question is structure. Section 14 requires a structured electronic format that enables electronic processing. One route is conformity with the European e-invoicing standard and the syntaxes referenced under Directive 2014/55/EU. Another is an agreed format from which the VAT-required information can be extracted correctly and completely into, or interoperably with, an EN 16931-compliant format.

The Ministry identifies XRechnung and ZUGFeRD from version 2.0.1, excluding the MINIMUM and BASIC-WL profiles, as formats that meet the VAT requirements. XRechnung is structured XML without an inherent visual PDF. A qualifying ZUGFeRD file combines structured XML with a human-readable PDF/A-3 layer. That hybrid presentation can help users, but it does not reverse the precedence of the XML when the layers disagree.

Validation is useful but it is not the complete legal decision. A validator can detect malformed XML, missing mandatory elements or inconsistent business rules. The Ministry states that validation is not itself an immediate condition for tax recognition. It also cannot establish that the supplier is the intended legal entity, that the VAT identifier belongs to that entity or that a bank-account change is authorised.

Structured invoicing makes supplier identity a stronger dependency

Structured invoices reduce rekeying, but they also move unreliable master data faster. If the wrong legal entity, VAT identifier or address is embedded in XML, automated systems can reproduce that error across posting, tax reporting, payment approval, audit evidence and analytics before a person sees it.

Section 14 requires the full name and address of supplier and recipient, the supplier’s tax number or VAT identification number, issue date, unique invoice number, description, supply date, taxable amount, VAT rate and VAT amount or exemption reference. The Ministry says all VAT-required information must appear in the structured part; a pointer to an unstructured attachment is not enough for a legally required field.

Procurement and accounts payable should compare the supplier legal name in XML with the approved vendor master, resolve the relevant company or registry identifier, associate the VAT ID with the same legal entity, compare the address with onboarding evidence, authenticate payment details independently and confirm that the purchase order uses the same contracting entity.

These are separate claims. A file can be structurally valid while containing an unknown VAT ID. A VAT ID can relate to a real group company while the invoice names another entity. The supplier can be correctly identified while newly changed bank details remain unapproved. One green badge cannot explain those differences to an auditor or a payment approver.

If VIES or another authority service is used, keep the submitted number, normalised number, response, source, time and any reference as a separate evidence object. An invalid result, unavailable service or name mismatch requires the workflow to distinguish input, registration, service and identity issues. None of those outcomes proves that a company is fictitious.

• Legal entity match: does the invoice identify the approved contracting supplier?
• VAT evidence: what did the relevant authority service return, and when?
• Format validity: does the document meet the applicable structure and business rules?
• Commercial match: does it agree with the purchase order and receipt or service approval?
• Payment approval: are beneficiary and bank details independently authorised?

A practical enterprise operating model

Start with transaction scope. The rules engine should evaluate supplier establishment, recipient establishment, business purpose, supply date, invoice requirement, exemption category, gross amount, issuer small-business status, issuer preceding-year turnover band and any separate B2G obligation. Its output should be a reasoned state—structured required, transition allowed, other-invoice exception or outside domestic B2B scope—not a free-text note.

Then validate the original document before posting. Quarantine unsafe files, preserve the received payload, calculate an integrity hash, extract the structured data and record the validator version and time. Separate fatal structural errors from non-fatal warnings and from business mismatches. The supplier owns content corrections; the transport provider owns delivery faults; tax owns scope; the ERP team owns mapping; accounts payable owns purchase-order and receipt exceptions.

Resolve the company and tax identifiers before permitting straight-through processing. Normalise identifiers without discarding what the supplier submitted. Link each response to its source and timestamp. A cached company-data record, a registry record and an authority VAT response answer different questions and should never be relabelled as one another.

Match commercial and payment evidence only after the document and entity are understood. A valid XML schema should not bypass three-way matching, duplicate detection, segregation of duties or bank-change authentication. Finally, archive the original structured invoice, relevant attachments, validation evidence, processing events and corrections. The Ministry states that at least the structured component must be retained intact in its original form for the eight-year VAT retention period.

How Germany e-invoicing implementations fail

The largest risks sit between legal scope, supplier master data and invoice operations. A successful test transmission proves only that one file reached one endpoint. It does not prove the programme can classify every supplier, absorb corrections, reconcile hybrid data, prevent duplicate booking or preserve defensible evidence during an outage.

A 90-day readiness plan for finance, tax, procurement and data teams

The purpose of a 90-day plan is not to declare the programme finished. It is to turn a legal deadline into a testable operating model with named owners, representative invoice traffic and measurable exceptions. Start with the largest German invoice flows and the suppliers most likely to rely on 2027 transitions.

Questions enterprise buyers should ask vendors and suppliers

Procurement should turn regulatory claims into acceptance criteria. A provider that says it is “Germany-ready” should identify the exact formats, profiles, rule sets, evidence exports and exception workflows it supports today. Anything dependent on future German reporting legislation should be labelled as roadmap, not delivered compliance.

The enterprise decision: redesign the control, not just the file

Germany’s 2027 milestone is a control redesign. Structured invoices can reduce rekeying and accelerate matching, but automation multiplies the consequences of poor entity data, incorrect tax identifiers and weak exception governance. The economic benefit only appears when the document can move through a reliable, evidence-backed process.

A defensible design keeps five conclusions separate: transaction scope, format validity, supplier identity, authority VAT evidence and payment approval. A supplier can pass one and fail another. That separation gives tax, procurement, AP and audit a shared record without pretending that XML validation makes the entire transaction compliant or safe to pay.

For global groups, Germany should be one country policy inside a reusable control framework. France, Poland and other markets use different networks, clearance models, reporting duties and outage rules. The common layer is company and invoice identity: who supplied, who bought, which identifier was submitted, what source supported it, when it was checked and what changed before payment.

The immediate management test is concrete: can the business explain why a PDF received for a 2027 supply was accepted, identify the issuing legal entity, show the time-bound evidence for the exception, prove which data layer was booked and retrieve the original document? If not, the programme is not ready even if the gateway can receive XML.

• List every German entity that issues or receives B2B invoices.
• Map supply date, not only invoice date and receipt date.
• Separate German establishment from German VAT registration.
• Record turnover-transition evidence against the exact issuing entity.
• Add expiry dates to every 2027 transition override.
• Support qualifying XRechnung and ZUGFeRD profiles.
• Preserve the original structured invoice intact for the required retention period.
• Show the structured data to reviewers and flag visual differences.
• Keep company identity, authority VAT evidence and format validation separate.
• Test credit notes, corrections, self-billing, advances and final invoices.
• Set a hard removal date for turnover-based transition logic on 1 January 2028.
• Review current official guidance before changing production tax logic.