Peppol BIS 3 Validation Rules Changed on 17 August 2026: What SAP Teams Need to Retest

OpenPeppol’s May 2026 release for Peppol BIS Billing 3.0 became mandatory on 17 August 2026. The mandatory baseline is now Billing version 3.0.21 with the updated UBL and CII validation artefacts based on EN 16931 validation release 1.3.16.

This is not only a documentation refresh. The release changes code lists, validation severities, country-specific rules, process profiles and optional envelope checks. An invoice that passed an older local validator can therefore fail at an Access Point, receiver or national implementation that has moved to the mandatory release.

What became mandatory on 17 August 2026

OpenPeppol published version 3.0.21 on 20 May 2026 and set 17 August 2026 as its mandatory-use date. The release notes identify UBL and CII validation artefacts 1.3.16, published on 10 April 2026, as the validation baseline used by the release.

Change	Why it matters operationally
Peppol BIS Billing 3.0.21	Validators and Access Points should now evaluate invoices and credit notes against the May 2026 release.
UBL and CII validation artefacts 1.3.16	Corrected EN 16931 rules can expose errors that were not detected consistently by the previous artefacts.
New billing-with-response profile	The optional process requires a separate SMP registration and makes an Invoice Response part of the collaboration.
Code-list changes	Fourteen EAS entries were removed, three ICD entries were added, and currency-list changes can invalidate hard-coded mappings or test data.
Severity changes	Selected Danish common rules changed from warning to error, while two Danish country rules became fatal.
New Dutch identifier warnings	Incorrect Dutch identifiers may still pass with warnings now, but OpenPeppol states that these rules will become fatal in a future release.
Temporary French profiles	Two France-specific profile values were added to validation for regulated and non-regulated billing flows.

Why an SAP invoice can fail without an SAP software change

Peppol conformance is enforced across a chain, not by one component. SAP may extract the business data, another component may map it to UBL or CII, a middleware validator may apply Schematron rules, and the Access Point may perform another validation before transport. The receiving Access Point or buyer can also apply the current release.

A release cutover can therefore create a failure even when no SAP transport was imported. The change may sit in the validator, code-list package, Access Point, SMP registration or receiver-side implementation. Testing only the SAP eDocument status does not prove end-to-end compatibility.

The SAP regression tests to run now

1. Prove validator-version parity

Record the version used by every validation point: developer workstation, SAP-side extension, Integration Suite flow, third-party middleware, Access Point test service and production Access Point. A validator still using Billing 3.0.20 or EN 16931 artefacts 1.3.15 should be treated as a version mismatch requiring investigation.

Run the same payload through each validator and compare rule identifiers, severity and result. A file that passes locally but fails at the Access Point is usually a version, configuration or national-rule mismatch, not a random network problem.

2. Revalidate every identifier scheme used in production

The Electronic Address Scheme list removed fourteen entries in this release. Do not assume that an identifier remains valid because it exists in SAP master data or passed last year’s tests. Extract the actual scheme IDs used for supplier endpoints, customer endpoints, legal identifiers and tax identifiers, then compare them with the current EAS and ICD lists.

Pay particular attention to mappings that derive a scheme from country, VAT number format or partner function. Hard-coded fallbacks can silently select a retired scheme when master data is incomplete.

3. Test the currency-list changes with real document variants

The release removes ANG and BGN from the Peppol ISO 4217 subset and adds XCG. Search production and open-item data for the affected codes before changing a mapping. The objective is not merely to edit a value table. The team must determine whether an old currency appears in historical credit notes, reversals, intercompany billing or copied reference documents that can still be transmitted after the cutover.

4. Re-run Danish invoices and credit notes

PEPPOL-COMMON-R052 and PEPPOL-COMMON-R053 changed from warnings to errors. DK-R-017 and DK-R-003 became fatal. Danish test coverage should include customer legal identifiers, scheme 0184 where applicable, Danish P and SE numbers, UNSPSC classification and the relevant invoice and credit-note combinations.

Use negative tests deliberately. Remove the expected scheme, alter an identifier length and submit an unsupported classification value. The test is complete only when the team can show the exact rule ID, the rejection point and the operational owner who receives the exception.

5. Treat Dutch warnings as a dated remediation backlog

The release introduces warning rules for Dutch identifiers using schemes 0106, 0190, 0217 and 9944, plus Dutch VAT numbers. OpenPeppol explicitly states that these warnings will become fatal in a future release. They should therefore be collected from test and production validation logs now, assigned to master-data or mapping owners, and closed before the next severity escalation.

• Scheme 0106: eight digits
• Scheme 0190: twenty digits
• Scheme 9944: format NL123456789B12
• Dutch VAT identifiers: format NL123456789B12
• Scheme 0217: twelve digits

6. Verify French profile handling

Validation rule PEPPOL-EN16931-R007 now recognizes two temporary French profiles for UBL invoices and credit notes:

urn:peppol:france:billing:regulated
urn:peppol:france:billing:non-regulated

Do not activate these values globally. Confirm the applicable French process, the party capability, the expected transport route and the implementation guidance used by the Access Point. A technically valid ProfileID does not by itself establish that the business process is ready.

7. Test the new billing-with-response profile as a process

The new Billing with Response BIS combines billing and Invoice Response. The buyer must send at least one structured Invoice Response for each invoice or credit note received. The profile identifier is:

<cbc:ProfileID>urn:peppol:bis:billing_with_response</cbc:ProfileID>

This profile requires a separate SMP registration. Changing only the ProfileID in an outbound mapping is therefore incomplete. SAP teams must also verify receiver discovery, document-type capabilities, inbound Invoice Response processing, correlation to the original invoice, status interpretation and exception ownership.

8. Test SBDH separately from invoice syntax

OpenPeppol added optional validation rules for SBDH compliance for Billing and Self-Billing. Teams using a Peppol Business Message Envelope should validate the envelope independently from the invoice payload. Sender and receiver identifiers, document identifiers and process identifiers must agree across the envelope, the invoice and the SMP capability.

9. Run both positive and negative lifecycle tests

A successful XML generation test covers only the first step. The regression pack should include technical rejection, business rejection, correction, credit note, duplicate submission, retry after an uncertain response and receiver-side Invoice Response. Each result should be traceable back to the SAP billing or accounting document.

A practical regression matrix

Scenario	Evidence to retain
Standard invoice and credit note	SAP document keys, final XML, validator version, rule output and Access Point acknowledgement
Each endpoint and legal-ID scheme in use	Master-data source, mapped scheme, current code-list result and receiving-party capability
Affected currencies	Source currency, mapping decision, validation result and handling of historical corrections
Danish domestic flow	Identifier formats, classification data, fatal-rule result and exception route
Dutch identifiers	Warning inventory, affected business partners, remediation owner and target date
French regulated or non-regulated profile	Profile selection rule, Access Point confirmation and end-to-end acceptance
Billing with response	SMP registration, outbound invoice, inbound response, correlation and final status
SBDH envelope	Envelope validation output and consistency with payload and SMP identifiers
Rejected and replayed document	Original request, rejection, correction, retry identifier and duplicate-prevention evidence

Do not accept a generic provider statement as test evidence

An Access Point or middleware provider may state that the May 2026 release is supported. That statement is useful, but it does not prove that a specific SAP mapping, partner identifier, country rule or process profile passes. Request the provider’s cutover date and validator version, then validate representative customer payloads through the same route used in production.

The most useful evidence is reproducible: the exact source document, the generated payload, the validator artefact version, the rule output, the transport acknowledgement and the final business status. Screenshots without payload and version information are not enough for a controlled regression sign-off.

What this means for SAP DRC and external Access Points

The impact depends on the deployed architecture. SAP Document and Reporting Compliance may control document extraction and parts of mapping or communication, while an external Access Point controls Peppol validation, discovery and transport. In other landscapes, Integration Suite or another middleware layer performs transformations and pre-validation.

The release should therefore be recorded as an end-to-end compliance dependency, not assigned automatically to one product team. The requirement owner must identify which component supplies the Schematron package, which component selects ProfileID and CustomizationID, who maintains SMP registration, where rejections return and how the SAP document is updated.

Translate the release into controlled SAP work

DRC Sprint can turn the Peppol release into versioned requirements, evidence requests, test cases and owned remediation work. The assessment should capture the current validator baseline, actual identifier schemes, affected countries, Access Point dependencies and unresolved profile decisions before the release is marked complete.

Primary sources

• OpenPeppol: Peppol BIS Billing 3.0 version 3.0.21 release notes
• OpenPeppol: Peppol BIS Self-Billing 3.0.2 release notes
• OpenPeppol: Post-Award documentation and mandatory dates
• OpenPeppol: BIS Billing with Response 3.0
• SAP: Document and Reporting Compliance Cloud Edition updates

Release effective date: 17 August 2026. SAP DRC validator support confirmed: 18 August 2026. Article review date: 24 August 2026.