ZUGFeRD 2.5 and Factur-X: What ERP Vendors Need to Ship Before the May 20, 2026 Release

The Forum für elektronische Rechnung Deutschland (FeRD) and Forum National de la Facture Électronique (FNFE-MPE) confirmed on April 9, 2026 that ZUGFeRD 2.5 and the matching Factur-X version will be released on May 20, 2026. The release follows the January 15, 2026 update that shipped ZUGFeRD 2.4 / Factur-X 1.08 with sub-line management. Three weeks out, the technical scope is settled enough that ERP vendors should be planning, not waiting.

This is a pre-release brief for engineering and compliance teams shipping hybrid invoice issuance into German and French markets. It covers what's actually changing at the data-model level, where the breaking edges are, and what to put on the sprint board before customers start receiving 2.5 invoices.

What ZUGFeRD 2.5 Adds

Three changes drive the release.

Native gross invoice support. A gross invoice presents total amounts without itemized tax breakdowns at the line level. The book trade, publishing, and petroleum sectors have used this pattern for decades, often because retail price regulation or tax-included pricing leaves no room for a per-line VAT decomposition on the printed invoice. ZUGFeRD 2.3 and 2.4 had no native data model for this — issuers had to either restructure the invoice into a synthetic itemization or fall back to non-EN 16931 formats. Version 2.5 adds the structured fields needed to encode "total including tax, no per-line VAT" at the schema level, and the validation rules now treat it as a first-class case rather than an exception.

EN 16931 code list alignment. The European standard refreshes its reference code lists every six months — country codes, currency codes, unit-of-measure codes, VAT category codes, payment means codes. ZUGFeRD 2.5 adopts the latest published set. Code-list drift is a common source of silent rejections: an invoice that was valid in March can fail Schematron in May because the recipient's parser was updated to the newer list. Aligning ZUGFeRD with the upstream code lists removes a class of "your XML is technically valid but my system rejects it" tickets.

ViDA-ready fields. EN 16931-1:2026, ratified by CEN on March 18, 2026, expanded the core invoice model to support the ViDA Digital Reporting Requirements: invoice coding, multiple-order references, early-payment-discount terms, late-payment charges, and broader exempt-supply handling. ZUGFeRD 2.5 maps these fields into the format's CII XML structure so ERP vendors can start populating them as customers and tax authorities begin to require them.

What Stays the Same

Everything else. ZUGFeRD remains a hybrid format — a PDF/A-3 container with an embedded XML payload — and the syntax is still UN/CEFACT Cross Industry Invoice. The profile lattice (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, plus the bilateral German XRechnung CIUS profile) is unchanged. PDF/A-3 embedding rules, the XMP metadata block, and the namespace declarations all carry over from 2.4.

This is important because it bounds the integration impact. ERP vendors do not need to rewrite their PDF/A-3 generator, swap their XML serializer, or change how they embed the XML attachment. The work is in the data model and the validation rule sets, not the transport layer.

Compatibility Matrix

The forward-compatibility story is good: 2.5 readers handle 2.3 and 2.4 invoices without modification. The backward-compatibility story is a soft "yes" — older parsers will accept 2.5 invoices syntactically because the schema additions are extensions, but they will silently drop the new fields, and a 2.5 invoice that depends on gross-invoice semantics will not be reconstructable on a 2.3 reader.

This is what FeRD calls "additive evolution." It is not a hard breaking release in the SemVer sense — but it is a breaking change for any ERP vendor whose customer base sends invoices into systems that have not been upgraded.

Where the Breaking Edges Are

Three places to look.

Schematron rule sets. The EN 16931 BR-* rules and the country-specific BR-DE-* / BR-FR-* extensions are versioned alongside the format. A validator running 2.4 rule sets against a 2.5 invoice that uses gross-invoice fields will likely fire false positives — for example, BR-CO-* rules that expect a sum of line VAT amounts to equal the document VAT amount will fail when there are no line VAT amounts to sum. Validation engines need both the new schema and the new rule set, deployed together.

Parser libraries. Open-source projects like Mustang typically publish 2.5-compatible releases within days of FeRD's announcement, but production releases can lag by weeks while edge cases are tested. Plan your dependency upgrade as a separate step from your own integration work — do not couple them.

Recipient-side integrations. If you ship ERP-to-ERP flows where one of your customers sends and another receives, you need both ends upgraded before either can use 2.5-only features. The conservative play is to keep emitting 2.4 invoices until your install base has rolled forward, then flip the switch per customer or per recipient.

What ERP Vendors Should Ship by May 20

A short, ordered list. None of this is optional if you are issuing ZUGFeRD invoices into the German or French markets.

1. Pin your current ZUGFeRD parser version explicitly. Whatever you use today (Mustang, ph-ubl, your own), pin to a known version so the May 20 community release does not auto-upgrade and break unrelated builds.

2. Add a 2.5-aware validator path in CI. Set up a parallel validation pipeline that runs incoming invoices through both the 2.4 and 2.5 rule sets. Track which invoices behave differently between them. This is your dataset for the rollout decision.

3. Map the gross-invoice trigger. Identify which of your customers issue invoices into book trade, publishing, or petroleum. They are the candidate set for 2.5 — everyone else can stay on 2.4 for the rest of 2026 without functional loss.

4. Schema-test against the EN 16931-1:2026 fields. Even if your customers do not need invoice coding or repeated orders today, the German and French tax authorities will start asking for them as ViDA Pillar 1 implementation begins. Adding the fields to your data model now is cheaper than retrofitting them after a customer is rejected.

5. Update PDF/A-3 metadata correctly. ZUGFeRD 2.5 invoices carry a different conformance level identifier in the XMP metadata block. Some PDF readers cache the metadata and will mis-classify a 2.5 invoice as 2.4 if the metadata is not regenerated.

6. Document the 2.5 cutover for your customers. Most ERP vendors do not generate invoices in a vacuum — they sit in front of a procurement or AR team that needs to know when something changed. A two-line release note ("we now emit ZUGFeRD 2.5 by default; you can opt back to 2.4 in settings") prevents the support flood.

How This Interacts with the German and French Mandates

Germany's B2B reception mandate has been live since January 1, 2025 and accepts any EN 16931-compliant format, which means ZUGFeRD 2.3, 2.4, and 2.5 are all accepted on the receiving side. The January 1, 2027 sending mandate for businesses with prior-year turnover above €800,000 will also accept any compliant version. There is no German requirement to upgrade to 2.5.

France's pilot transitions to specifications version 3.1 in June 2026, ahead of the September 1, 2026 mandatory go-live for large and mid-sized companies. The Plateforme de Dématérialisation Partenaire (PDP) and Portail Public de Facturation (PPF) accept Factur-X, UBL, and CII inputs. Factur-X 1.08 (the current version) is accepted; the next version released alongside ZUGFeRD 2.5 will be accepted at go-live. France has historically required PDPs to support a rolling window of at least the latest two minor versions, which means 2.4 will continue to function on the network through at least 2027.

The pragmatic interpretation: the May 20 release is not a deadline. It is a new capability — gross invoices, ViDA fields, refreshed code lists — that ERP vendors should adopt when their customer base hits the use case, not before.

The Standards Bodies and Where to Watch

FeRD maintains ZUGFeRD on the German side. They publish the schema, profile guides, and reference XSDs. FNFE-MPE publishes Factur-X on the French side; the documents are functionally equivalent to ZUGFeRD with French-language framing. The Mustang project on GitHub is the de facto open-source reference implementation and tracks releases closely. The KoSIT XRechnung repositories publish the BR-DE Schematron rules as separate artifacts; these need to be paired with a matching ZUGFeRD version when validating.

For ERP vendors who want to monitor the release without subscribing to multiple newsletters, the FeRD release page typically posts the official artifacts within hours of the announcement. The validators on the public test portals (e.g. KoSIT's XRechnung Prüftool, the AIFE qualification environment in France) are usually updated within two weeks.

Frequently Asked Questions

When will ZUGFeRD 2.5 be released?

May 20, 2026. The Forum für elektronische Rechnung Deutschland (FeRD) and FNFE-MPE confirmed the date in a joint announcement on April 9, 2026. The release will include the matching Factur-X version on the French side.

What's new in ZUGFeRD 2.5 compared to 2.4?

Three substantive additions. First, native support for gross invoices — invoice totals without per-line VAT decomposition, used in book trade, publishing, and petroleum sectors. Second, alignment with the latest EN 16931 reference code lists (country codes, currency codes, unit codes, VAT category codes). Third, ViDA-ready fields aligned with EN 16931-1:2026: invoice coding, multiple-order references, early-payment-discount terms, late-payment charges, and expanded exempt-supply handling. The XML syntax (CII), the PDF/A-3 container, and the profile structure are unchanged.

Will ZUGFeRD 2.4 invoices still be accepted after May 20, 2026?

Yes. Both Germany's January 2025 reception mandate and France's September 2026 sending mandate accept any EN 16931-compliant format, which includes ZUGFeRD 2.3, 2.4, and 2.5. There is no regulatory deadline forcing a migration to 2.5. The upgrade decision is driven by use case (gross invoices, ViDA fields), not compliance.

Does ZUGFeRD 2.5 break existing ERP integrations?

Not at the syntax level. The PDF/A-3 container, CII XML structure, and profile lattice are preserved, so existing serializers, embedders, and parsers do not need to be rewritten. The breaking edges are in the validation rule sets — Schematron rules updated for gross-invoice handling can fire false positives on older rule sets — and in dependency versions, where parser libraries need to be upgraded together with rule sets. ERP vendors that pin both their parser and their Schematron version together will avoid most of the rollout pain.

Is Factur-X the same as ZUGFeRD 2.5?

Functionally yes, semantically yes — and structurally identical. Factur-X is the French branding of the bilateral standard maintained jointly by FeRD and FNFE-MPE. The XML schemas, profiles, and validation rules are the same. The differences are documentation language (French vs. German), the publishing organization, and minor terminology in profile names. A Factur-X invoice and a ZUGFeRD invoice at the same version are byte-compatible.

What is a gross invoice and why does ZUGFeRD 2.5 add support for it?

A gross invoice presents totals including tax without itemizing VAT at the line level. The format is required in industries where retail prices are tax-included and per-line VAT decomposition is not commercially meaningful — book trade (where book prices are regulated), publishing, and parts of petroleum distribution. Earlier ZUGFeRD versions required workarounds: synthesizing line-level VAT to satisfy the schema, or falling back to non-EN 16931 formats. Version 2.5 adds the structured fields and validation rules to encode gross invoices natively.

What should ERP vendors do before May 20?

Pin parser library versions, add a 2.5-aware validator path in CI, identify customers in book trade / publishing / petroleum (the gross-invoice candidate set), schema-test against EN 16931-1:2026 fields, update PDF/A-3 XMP metadata correctly, and prepare a customer release note. A full integration upgrade is not required by the release date — only the readiness to handle 2.5 invoices arriving from upstream parties.

Building structured e-invoicing into your ERP product? Invoice Navigator validates EN 16931 / BR-DE / BR-FR rule sets across ZUGFeRD 2.3, 2.4, and 2.5 from a single API — no per-version SDK swap. See how it works →

Related: ZUGFeRD vs XRechnung — Technical Comparison · Germany E-Invoicing 2026: Complete Guide · France September 2026 Mandate · E-Invoice Schematron Rules Explained