Germany’s E‑Invoicing Rules for 2027: Where XRechnung and ZUGFeRD Fit

On August 4, 2026, the Forum for Electronic Invoicing Germany released ZUGFeRD 2.5.2, a corrective update that takes effect September 1 and includes refreshed validation artifacts. The release arrives only a few months before Germany’s first general transition period for mandatory domestic B2B e‑invoicing closes at the end of the year.

For covered transactions performed on or after January 1, 2027, an issuer whose total turnover exceeded €800,000 in the preceding calendar year generally can no longer fall back on paper or an ordinary PDF. That deadline applies to issuing invoices; it does not launch the entire regime. Businesses established in Germany have already needed to be able to receive an e‑invoice since January 2025.

The deadline follows the transaction

Through December 31, 2026, every issuer may still use paper or, with the recipient’s consent, another electronic format such as a basic PDF. For transactions performed in 2027, that option generally remains available only if the issuer’s prior-year total turnover did not exceed €800,000. Certain EDI arrangements also retain a transition through the end of 2027. Starting in 2028, the turnover-based transition is gone for covered domestic B2B transactions.

Statutory exceptions remain. They include low-value invoices up to a gross amount of €250, qualifying transportation tickets, and services supplied by businesses using Germany’s small-business VAT scheme. B2C transactions and many VAT-exempt supplies under Section 4 nos. 8 through 29 of the German VAT Act are outside the same issuance requirement. The reception rule is broader: even a business exempt from issuing e‑invoices under the small-business rule must be able to receive them. A mailbox is sufficient for tax-law purposes, but it does not provide a complete review, approval, and retention process.

XRechnung and ZUGFeRD are implementation choices, not an exclusive mandate

German VAT law defines an e‑invoice by its structure. It must use a structured electronic format that supports electronic processing. A PDF without structured invoice data is classified as another type of invoice, even when it is delivered electronically. The format may follow the EN 16931 family of European standards or be agreed between the parties if the required VAT data can be extracted correctly and completely into a conforming or interoperable format.

XRechnung and ZUGFeRD are common ways to meet that requirement. The Federal Ministry of Finance identifies XRechnung and ZUGFeRD 2.0.1 or later as qualifying examples, except for the ZUGFeRD MINIMUM and BASIC-WL profiles. KoSIT currently publishes XRechnung 3.0.2, while FeRD released ZUGFeRD 2.5.2 in August 2026. Those current specifications do not turn the format names into the law’s only permitted options.

Version, syntax, profile, and transmission method still have to match the receiving system. For a new interface, those choices should be documented with the trading partner and tested with current validation artifacts rather than inferred from the broad tax-law acceptance of a format family. This is an implementation recommendation, not an additional statutory requirement.

In a hybrid invoice, XML is authoritative

XRechnung consists of structured XML data without an accompanying PDF rendering, so human review requires a viewer. ZUGFeRD packages embedded XML together with a visual PDF/A-3 document. If the two parts of a hybrid invoice disagree, the structured data controls. The structured section must also contain the VAT-required information with enough detail to support electronic processing; an unstructured attachment may add supporting material but cannot replace the required invoice data. A sound implementation should therefore generate the PDF view and XML from one verified source of invoice data. That design recommendation reduces the opportunity for two independently maintained representations to diverge, but it is not a separate legal format rule.

Validation belongs in the invoice workflow

The Ministry of Finance distinguishes technical format defects from violations of a format’s business rules. A file that fails the structured-format requirements because of a technical format defect is treated as another electronic invoice format. Validation is not, by itself, a condition for tax recognition, but the ministry recommends it as a way to surface missing mandatory fields and inconsistent values.

Before the first mandatory outbound invoice, an end-to-end test should establish:

• which transactions and statutory exceptions the process must classify;
• which version, syntax, and, where applicable, ZUGFeRD profile both parties can process;
• whether master data, service details, tax values, payment information, and references reach the structured invoice intact;
• how validation failures, rejections, and corrections return to the business workflow without a manual PDF detour;
• how the original received file is displayed, protected, and retained together with its structured content.

For VAT purposes, a copy of each incoming and outgoing invoice must be retained for eight years. At minimum, the structured part of an e‑invoice has to remain intact in its original form. Issuers above the turnover threshold therefore need the production workflow operating before their first covered 2027 transaction. Smaller issuers can use the extended transition through 2027, but they already participate in their customers’ and suppliers’ receiving processes today.

 

Note: This assessment is not a substitute for a review of the specific case.