Two Peppol Q3 2026 Cutovers Left — And What Breaks Silently If You Miss Them

Between now and 31 August 2026, two Peppol network changes go mandatory. A third — the widely-covered 1 August legacy XRechnung deprecation — has already passed, and it was narrower than most pre-cutover coverage suggested. This post walks through what actually happened on 1 August, and then the two changes that still need attention: 17 August 2026 (Peppol BIS Billing 3.0 May 2026 Release + Dutch NPa SI-UBL 2 / NLCIUS artefacts become mandatory) and 31 August 2026 (OpenPeppol SML → in-house DNS migration).

Both remaining cutovers sit upstream of the Schematron and XSD you already run against outbound invoices. An invoice that passes your local validator can still be rejected at the network layer if your integration relies on stale validation artefacts or a stale SML DNS suffix.

If you own an ERP or B2B SaaS pipeline that emits Peppol invoices, this is a version-pin and routing-config fortnight.

The days-until table

Cutover	Date	Days out (from 12 Aug 2026)	What changes at the network
Legacy XRechnung ≤ 2.1 deprecation (retrospective)	1 Aug 2026	–11 (passed)	Peppol stopped accepting XRechnung profile versions up to and including 2.1. XRechnung 2.2 and 2.3 remain accepted until at least 2027.
Peppol BIS Billing 3.0 May 2026 Release + Dutch NPa SI-UBL 2 / NLCIUS artefacts	17 Aug 2026	5	EN 16931 validation rules move to v1.3.16; new PEPPOL-COMMON-R052; Danish CVR format tightening under PEPPOL-COMMON-R042; new EAS/ICD code 0245 for Slovak DIČ; NL UNSPSC dual-version support; DK-R-008 change for Giro accounts.
OpenPeppol SML → in-house DNS migration	31 Aug 2026	19	Access Points must switch DNS lookup suffixes to the new OpenPeppol-managed domain. Silent routing failure if missed.

Days-until values are relative to 12 August 2026. Both remaining cutovers are hard dates, not soft-landing windows.

Retrospective — the 1 August 2026 legacy XRechnung deprecation was narrower than the pre-cutover coverage suggested

Pre-cutover coverage — including our own 29 July preview — framed the 1 August change as a broad legacy XRechnung profile deprecation on the Peppol network. This week's confirmation from multiple German-language sources narrows the scope significantly.

What actually happened: only XRechnung versions up to and including 2.1 were removed from the Peppol network on 1 August 2026. Versions 2.2 and 2.3 remain accepted on the network until the new EN 16931 base is published, and in any case no earlier than 2027. See XStandards Einkauf on deprecated XRechnung Versionen for the authoritative German reference, and docnova.ai's summary for the English-language briefing.

Impact revision: most integrator ERP stacks were already on XRechnung 3.0 or later by mid-2026, so the network-rejection risk on 1 August was concentrated in a specific tail of legacy 2.1 deployments — small vendors, industry-vertical distributions, forked German localisations. If your outbound corpus for the past two weeks shows no unexplained CustomizationID-related rejections against the German BR-DE rule pack, the 1 August event passed cleanly for you.

The migration recommendation stands regardless. KoSIT and multiple national infrastructures continue to recommend moving to XRechnung 3.0.1 (or the editorially-different-but-technically-compatible 3.0.2) immediately. Luxembourg's B2G infrastructure, for example, is stopping acceptance of XRechnung 2.2 and 2.3.1 on 1 October 2026 — a country-level version floor imposed independently of the Peppol network decision. See invoice-portal.de on the Luxembourg XRechnung 3.0 October 2026 deadline. If you serve Luxembourg B2G buyers, that deadline is 50 days out from today and is a separate action.

What this reframe changes for the rest of this post: the two remaining cutovers matter more, not less. The 1 August event was surgical; the 17 August and 31 August events are network-wide.

Cutover 1 — Peppol BIS Billing 3.0 May 2026 Release + Dutch NPa SI-UBL 2 / NLCIUS become mandatory (17 August 2026)

What changes. The Peppol BIS Billing 3.0 May 2026 Release (published on docs.peppol.eu/poacc/billing/3.0/upcoming/) and the Dutch NPa's May 2026 validation artefacts for SI-UBL 2 and NLCIUS move from optional to mandatory across Access Points on 17 August 2026. From that date the receiving AP is contractually required to enforce the new ruleset. See VATupdate's brief on the May 2026 NPa Validation Artefacts and Peppol AGID Italy's May Release 2026 note.

What's in it — the rule-level diff.

• EN 16931 validation rules updated to v1.3.16. This is a minor-version bump on the shared Schematron ruleset the whole EN 16931 ecosystem uses. Individual rule severities and message texts change; new rules land; a handful of previously-warn-level rules move to error. The change list is enumerated on the docs.peppol.eu upcoming-release page.
• Danish CVR identifier tightening (PEPPOL-COMMON-R042). The CVR number must be 8 characters with no DK prefix. ERPs that historically emitted DK12345678 in the endpoint identifier or supplier identification will fail this rule.
• New PEPPOL-COMMON-R052 for Danish Chamber of Commerce. A dedicated rule targeting the Chamber of Commerce identifier structure. If your ERP has a Danish master-data flow that populates this field automatically, verify the format matches the new rule's expected pattern.
• NL UNSPSC dual-version support. The Dutch NPa artefacts now accept UNSPSC classifications in both versions 9.05.01 and 26.08.01. This is an expansion, not a restriction — but pipelines that were reactive-emitting the newer version to preempt validator complaints should re-check that the emitted version aligns with what receivers can actually process downstream.
• New EAS/ICD code 0245 for Slovak DIČ. The Electronic Address Scheme catalog gains a code for the Slovak tax identifier. ERPs routing invoices to Slovak buyers should transition from any fallback scheme (e.g., a generic ICD) to 0245 where the buyer's identifier is a DIČ.
• DK-R-008 change for Giro accounts. The Danish payment-means Giro account rule tightens. If you emit PaymentMeans with a Giro account structure and don't validate against the current DK-R-008 spec, invoices to Danish buyers with Giro payment terms are the first that will bounce.

Why it silently breaks integrations. Every rule in that list is enforceable by a Schematron validator today, but only if the validator is running the May 2026 artefacts. An ERP that pins to a Q4 2025 or Q1 2026 KoSIT-validator snapshot, or an on-prem Peppol integrator's bundled Schematron cache from earlier this year, will pass the same invoice that the receiving AP will reject. This is the classic "green build, red network" split.

What to check before 17 August. Pull the current SI-UBL 2 / NLCIUS / BIS Billing 3.0 artefact bundle from docs.peppol.eu, run it against your outbound corpus for the past 90 days, and rank the failures by frequency. The high-frequency ones tell you where your ERP's code-list mapping needs an update; the low-frequency ones tell you where you have specific customers whose master data is now non-compliant. Both classes need fixes before the mandatory date — the ERP change usually ships faster than the customer-data cleanup, so start the customer conversations now.

Where the "safety layer" framing matters. The May 2026 release also includes revised guidance on the attachment-compliance section (BT-125 AdditionalDocumentReference), separately relevant to the Belgian construction-sector mandate that took effect 1 January 2026. If you have Belgian construction customers, that separate rule stack rides on top of the BIS 3 update — a pre-transmission validator should be running both.

Cutover 2 — OpenPeppol SML → in-house DNS migration (31 August 2026)

What ends. The OpenPeppol Service Metadata Locator (SML) — the DNS-based discovery layer that Access Points use to look up where to route a given Participant Identifier — completes its move from its historical external DNS provider to an OpenPeppol-managed, in-house service. The DNS suffix changes.

The migration is two-phase: the AP Provider SML registration API endpoint updates completed on 31 May 2026, and the AP Provider DNS lookup domain migration is mandatory on 31 August 2026. See the OpenPeppol Confluence page on SML Insourcing, the Peppol AGID Italy SML migration note, and the EU DG DIGIT blog post from 16 May 2026 for the authoritative timeline.

Why it silently breaks integrations. SML lookup is a plain DNS resolution. There is no OAuth handshake, no HTTP status code, no application-layer error. If your AP is hard-coded to the old DNS suffix, the DNS resolver returns NXDOMAIN, and the AP concludes that the receiving Participant Identifier does not exist on the network. From the sending ERP's perspective, the invoice was accepted by the AP for processing and then quietly failed with "recipient not registered." From the receiving buyer's perspective, no invoice arrived at all. Neither side sees a validation error, because the failure happens before validation runs.

The compound failure is worse than a rejection: unlike an invoice rejection, a routing failure doesn't produce an MLR (Message Level Response). Some AP implementations retry a few times and then drop the invoice into a dead-letter queue with a generic error. Some log the DNS failure and continue. Very few surface a customer-actionable notification.

The fix depends on where the DNS suffix lives. If you self-host an Access Point (SMP + AP stack), the DNS suffix is in your SMP configuration and your outbound-AP configuration, and the change is yours to schedule. If you use a hosted Peppol provider (Storecove, Pagero, Basware, ecosio, etc.), the fix lives with them — but "we assume our provider will handle it" is not a compliance artefact. Ask them for the migration timeline in writing, and log the response.

What to test before 31 August. The OpenPeppol Confluence page publishes the new DNS suffix and the transition guidance. Send a canary invoice to a known-good Participant Identifier through your outbound AP with the new DNS suffix configured on a staging environment. Confirm the invoice arrives and generates a positive MLR. Then flip production during a low-traffic window and monitor for NXDOMAIN spikes.

The pattern both remaining cutovers share

Both are network-level changes, not content-level changes. Your ERP can render a perfectly conformant UBL invoice, run it through your on-prem Schematron pass, get a clean report — and still see a receiving AP reject or silently drop it, because the ruleset version or the DNS suffix your integration relies on has moved.

This is exactly the class of failure a local validator can't catch, because a local validator doesn't know what the network is going to accept tomorrow. The countermove is version-tracking discipline: pin your Schematron artefacts to a specific published bundle, track the release cadence for each bundle upstream, and re-validate your outbound corpus against every new bundle before it goes mandatory. See why validators are not enough for the boundary between passing a validator and actually being safe to transmit.

What ERP vendors should do this fortnight

Confirm 1 August is behind you cleanly. If your outbound corpus for the past two weeks shows no CustomizationID-related rejections against the German BR-DE rule pack, the retrospective is complete. If you are seeing them, they're concentrated on the XRechnung 2.1-and-below tail — bump those customers to 3.0.1 or 3.0.2 without waiting.

Pull the May 2026 BIS 3 / SI-UBL 2 / NLCIUS artefact bundle from docs.peppol.eu and run it against 90 days of outbound XML — before 17 August. Rank failures by frequency. Fix the ERP-side mapping issues (CVR prefix stripping, EAS/ICD code 0245 for Slovak DIČ, DK-R-008 Giro account structure) at the code level. Start customer-data conversations for master-data issues that need the customer to update their records.

Confirm in writing which of the following is true for every Peppol path you own — before 31 August. Either you self-host the SML lookup and have scheduled the DNS suffix change, or your Peppol provider has confirmed the migration timeline. "We assume it'll happen" is not a compliance artefact — the tax administration and your customer's compliance team will both want the dated confirmation.

Instrument for routing failures separately from validation failures. If your ERP's Peppol integration only surfaces validation errors, you're blind to Cutover 2. Log the SML resolution result, the SMP lookup result, and the transmission-attempt result as three distinct events. Alert on unexpected NXDOMAIN or SMP-not-found responses at the ERP layer, not just in the AP logs.

Diarize the November 2026 release now. The Peppol network runs on a spring/autumn release cadence. The November 2026 release will drop while you're focused on 2027 planning. Set the next artefact-bundle re-validation for early Q4, and repeat every six months.

FAQ

What actually happened on 1 August 2026 with XRechnung on the Peppol network?

Peppol removed acceptance for XRechnung versions up to and including 2.1 on 1 August 2026. XRechnung versions 2.2 and 2.3 remain accepted on the network until the new EN 16931 base is published, and in any case no earlier than 2027. Most integrator ERP stacks were already on XRechnung 3.0 or later by mid-2026, so the impact was concentrated on a specific tail of legacy 2.1 deployments — not the broad deprecation some pre-cutover coverage suggested. The migration recommendation is still to move to XRechnung 3.0.1 or 3.0.2 immediately, particularly if you serve Luxembourg B2G buyers, where the country-imposed version floor lands on 1 October 2026.

What is the Peppol BIS Billing 3.0 May 2026 Release?

The May 2026 Release is the semi-annual update to the Peppol BIS Billing 3.0 profile published on docs.peppol.eu/poacc/billing/3.0/upcoming/. It bundles the EN 16931 validation rule set at version 1.3.16, adds new PEPPOL-COMMON rules (notably R042 for Danish CVR and R052 for the Danish Chamber of Commerce), adds EAS/ICD code 0245 for the Slovak DIČ, and revises several country-specific rules including the Danish Giro payment-means rule (DK-R-008). Access Points are required to enforce it from 17 August 2026.

When does the Peppol SML DNS migration happen?

The migration is two-phase. The AP Provider SML registration API endpoint updates completed on 31 May 2026. The AP Provider DNS lookup domain migration is mandatory on 31 August 2026. From that date, OpenPeppol operates the Service Metadata Locator DNS service in-house rather than through the historical external provider, and Access Points must have switched their configured DNS suffix to the new OpenPeppol-managed domain. The transition detail is published on the OpenPeppol Confluence SML Insourcing page.

What happens if my Access Point doesn't update the SML DNS suffix?

DNS lookups for Participant Identifiers return NXDOMAIN, so the AP concludes the recipient is not registered on the Peppol network. Outbound invoices fail routing before any validation runs. Because the failure happens at DNS-resolution time, there is no MLR — the sending ERP and the receiving ERP both see silence unless the AP is instrumented to surface DNS-level failures as a distinct error class.

What is EN 16931 v1.3.16, and what changed from the previous version?

EN 16931 v1.3.16 is the current version of the shared Schematron ruleset for the European e-invoicing standard, deployed as part of the Peppol BIS Billing 3.0 May 2026 Release. The version bump includes rule-severity changes (some previously-warn rules become errors), new rules, and message-text updates. For the exact rule-by-rule diff, consult the Peppol BIS Billing upcoming-release page.

Do these Peppol changes affect the French PA network?

The French PA (Plateforme Agréée) network is not a Peppol network in the same sense — France uses its own directory and routing infrastructure keyed off SIREN (EAS scheme 0009). However, the underlying invoice format still has to conform to EN 16931 with CIUS-FR overlays, and cross-border invoices from French issuers to Peppol-connected buyers will transit both networks. The v1.3.16 EN 16931 changes apply everywhere the standard is used. Note also that the French mandate goes live on 1 September 2026 — 20 days out — under a DGFiP soft-landing that is transport-lenient but VAT-substance-strict.

What is the difference between a Schematron rejection and a routing failure?

A Schematron rejection means the invoice XML was received, parsed, and evaluated against the ruleset — and one or more rules failed. The receiving AP returns an MLR with a specific rule identifier (BR-CO-15, PEPPOL-COMMON-R042, etc.), and the sending ERP can act on it. A routing failure happens before parsing: the AP couldn't find the recipient at all, or the recipient's SMP couldn't be resolved. There is no MLR. Instrumentation for the two is different and must be handled distinctly.

Where do I find the authoritative source for each of these cutovers?

For the May 2026 BIS 3 release: docs.peppol.eu/poacc/billing/3.0/upcoming/ and the VATupdate brief. For the Dutch NPa SI-UBL 2 / NLCIUS artefacts: the NPa's own publication and the same VATupdate brief. For the SML DNS migration: the OpenPeppol Confluence page on SML Insourcing and the EU DG DIGIT blog post from 16 May 2026. For the 1 August XRechnung deprecation retrospective: XStandards Einkauf and docnova.ai.