QERDS and the European Business Wallet: the layer that makes digital communication legally valid — and what it means for Peppol

In the Dutch policy debate about the European Business Wallet (EBW), most attention goes to the EU Digital Identity Wallet and digital identity. At least as much weight is shifting toward the layer that makes digital communication between businesses and public authorities legally valid: QERDS, the Qualified Electronic Registered Delivery Service.

For the Peppol network, this raises a question that has barely been asked so far. Peppol has been carrying legally valid messages between businesses and public authorities for years. QERDS introduces a formal alternative for that same function, anchored in the eIDAS Regulation. What is the difference, where do they overlap, and what should OpenPeppol do about it?

What QERDS actually is

QERDS is not a new concept: it has been part of the eIDAS Regulation (Regulation (EU) No 910/2014) since 2014, and was tightened by the eIDAS 2.0 amendment (Regulation (EU) 2024/1183) in 2024. Article 43 of the Regulation grants a legal presumption to data sent and received through a qualified electronic registered delivery service: a presumption of the integrity of the data, and of its sending and receipt by the identified sender and addressee. Article 44 sets out the additional requirements a service must meet to earn that qualification, including mandatory identification of both parties and delivery by a qualified trust service provider (QTSP) listed on the national Trusted List.

An important detail: a non-qualified delivery service (ERDS) is therefore not automatically worthless as evidence. Article 43(1) explicitly states that a registered delivery service shall not be denied legal effect or admissibility as evidence solely on the grounds that it does not meet the requirements of the qualified service. The difference lies in the burden of proof: for QERDS the legal presumption applies automatically, while for an ordinary ERDS the evidentiary value must be demonstrated case by case. eIDAS 2.0 adds an interoperability obligation on top of this: QERDS providers must use standardised protocols and evidence formats between each other under the ETSI standards EN 319 522 and EN 319 523, so that a QERDS message from one provider is recognised as such by another provider.

QERDS as a core function of the European Business Wallet

On 19 November 2025, the European Commission published the formal legislative proposal COM(2025) 838 for a regulation establishing European Business Wallets. The proposal names three core functions: secure identification, electronic signing and sealing, and the sending and receiving of data through a qualified electronic registered delivery service. QERDS is therefore not a side note in the proposal, but one of the three pillars the entire Wallet rests on.

The Commission deliberately chooses to have QERDS services delivered by market parties rather than a centralised government solution. That makes interoperability, governance and oversight of those market parties a theme member states still need to take a position on. The legislative process has advanced considerably: on 9 June 2026 the Council of the European Union adopted a general approach, the ITRE rapporteur in the European Parliament (Eero Heinäluoma) published his draft report on 20 March 2026, and a political agreement is expected before the end of 2026, with formal adoption in the first half of 2027. Once the regulation enters into force, public authorities will have 24 months to be able to accept the core functions. For businesses, use of the EBW remains voluntary; the acceptance obligation in the proposal applies exclusively to public authorities.

The question that has not been asked yet: how does Peppol transport relate to QERDS?

The Peppol network already solves a similar problem with its AS4 profile: messages are signed, encrypted and provided with receipts that guarantee non-repudiation between Access Points. That trust, however, is built up predominantly through institutional and contractual means, through the Peppol Interoperability Framework, mandatory agreements between Access Points and Peppol Authorities, and conformance testing via the OpenPeppol Testbed, possibly supplemented with periodic audits or certification such as ISO 27001 depending on the requirements of the relevant Peppol Authority, rather than through a formally “qualified” eIDAS trust service. A Peppol message has a strong evidentiary position in practice, but it does not automatically enjoy the legal presumption that Article 43 grants to QERDS. For an invoice sent within a mandatory framework such as ViDA, that difference is usually of limited practical significance. For the document types the Commission explicitly links to QERDS in the EBW proposal, mandates and powers of attorney, permits and certificates, compliance documents, contractual declarations, the picture is different: precisely the documents most likely to end up in a dispute are the documents for which the legislator is now building a separate, heavier evidentiary regime.

This creates a real risk of two parallel European trust infrastructures: Peppol for invoices and procurement-related document flows, and QERDS/EBW for mandates, permits and compliance traffic. Both networks will in practice be used by the same organisations, often for document flows that are substantively linked, think of a power of attorney needed to authorise an invoice on behalf of a company, or a permit exchanged as an attachment to a tender over Peppol. Without coordination, this results in duplicate infrastructure, duplicate governance and duplicate integration costs for exactly the same end users.

This is a different question from the identity and addressing problem covered in an earlier Peppol.now article on the architectural relationship between the EBW and e-invoicing. That analysis looks at who the recipient is and where a message needs to be routed. QERDS is about something else: which legal evidentiary regime applies once the message is underway. It is the layer after addressing, before archiving, and that layer remains largely undiscussed from a Peppol perspective.

The Netherlands is already moving: the RDI opens a dialogue with Peppol Service Providers

This question is no longer purely theoretical. On 3 June 2026, the Rijksinspectie Digitale Infrastructuur (RDI), the Dutch supervisory authority for eIDAS and the Cyberbeveiligingswet, the Netherlands’ transposition of the NIS2 Directive, announced that following its own research it classifies providers of eDelivery services as trust service providers. That means these providers fall under eIDAS and under the Cyberbeveiligingswet, with obligations around risk management, duty of care and mandatory reporting of serious incidents.

Telling is where the RDI starts: the supervisor is opening a dialogue with Peppol Service Providers first in 2026, to explore what this legislation means for them in practice. The RDI itself describes eDelivery aptly as “digital registered mail”: messages sent securely with proof of arrival, exactly the qualification this article compares QERDS to.

An important distinction: “trust service provider” under eIDAS is a broader category than the QTSP status needed to provide QERDS, and it is not necessarily qualified, with lighter requirements than Article 44 sets out. But it is the step through which oversight enters the network. For Peppol Service Providers in the Netherlands, this means the question “what is the legal status of a Peppol message?” is no longer something that can be pushed down the road: the supervisor is asking that question in practice, to individual parties, already this year, and doing so without a shared answer from the network being available.

Recommendations for OpenPeppol

1. Determine and publish a formal position on the evidentiary standing of Peppol AS4 transport relative to QERDS, in the short term. With the announced RDI conversations, this is no longer a question for the long term: without a shared position, every Dutch Peppol Service Provider will have this conversation with the supervisor separately this autumn, with the risk of diverging interpretations of the same question within the same network. A clear, authoritative interpretation, ideally aligned with the national Peppol Authorities, prevents every organisation from having to answer this question on its own.
2. Join the RDI conversations through the Netherlands Peppol Authority, and treat the outcome as a template for other member states. The Netherlands, through the RDI, is the first country where a national supervisor concretely classifies eDelivery providers as trust service providers and opens a dialogue with Peppol Service Providers about it, but eIDAS and the underlying NIS2 Directive apply across the EU. Other national supervisors, on eIDAS and on their own NIS2 transposition, are almost certain to reach the same conclusion. By supporting the Netherlands Peppol Authority (NPA) now in its conversation with the RDI and documenting the outcome in a structured way, OpenPeppol prevents every Peppol Authority from having to go through this process separately and without coordination once their own supervisor asks the same question.
3. Explore an optional QERDS bridge for document types that warrant it. Not every message on the Peppol network needs QERDS-level assurance, a regular invoice under EN 16931 probably does not, a power of attorney or permit possibly does. A cooperation model in which Access Points, working with QTSPs, can optionally attach QERDS-compliant proof of delivery to specific message types prevents users from having to approach an entirely separate network for those documents.
4. Actively follow the ETSI interoperability standards EN 319 522 and EN 319 523, and assess where the Peppol eDelivery/AS4 profile can technically connect. If both worlds evolve independently, connecting them later becomes considerably more expensive than identifying shared technical touchpoints now.
5. Use the chairing role in the WE BUILD working group constructively and neutrally, not solely to defend the existing network. OpenPeppol already chairs the eInvoicing use case (SC5) within the WE BUILD Consortium, the European Commission’s Large Scale Pilot initiative for the EUDI Wallet and the EBW. That means OpenPeppol is already at the table; the question is not whether, but how that position is used. The angle should not primarily be what the EBW means for Peppol, but how e-invoicing as a phenomenon can function well within a way of working built around the EBW, and how an interoperable network like Peppol can learn from that and contribute to it. That neutral approach pays off more in the long run than a position that only defends the interests of the existing network.
6. Use the ongoing SML insourcing to factor in the governance implications of QERDS for mandates and powers of attorney now. This is not a hypothetical future exercise: in 2026 OpenPeppol itself is taking over the Service Metadata Locator, the DNS-based dynamic discovery infrastructure of Peppol, from the European Commission, with migration deadlines for SMP registrations and Access Point lookup in May and August 2026 respectively. Digitally provable authorisation through the EBW directly touches how those same SMP registrations and Access Point access are managed. Since this infrastructure is being rebuilt anyway, this is the moment to factor in design choices that can facilitate future EBW attributes, rather than having to do so later as a separate migration.
7. Take into account the establishment requirement for QERDS providers from rapporteur Heinäluoma’s draft report. His proposal that providers of QERDS, wallets and cloud services be established in the EU and free from third-country control is relevant when assessing non-EU Access Point providers that might want to offer QERDS-like services within the Peppol ecosystem in the future.

As long as the regulation has not been adopted, no immediate action is required. But the legislative window is open: the technical and legal choices being made right now in the Council and Parliament will determine whether Peppol and QERDS end up functioning side by side as disconnected pieces, or as coordinated layers of the same European trust infrastructure.

Compare certified Peppol Service Providers on Peppol.now

Sources

1. European Commission, Proposal for a Regulation establishing European Business Wallets, COM(2025) 838 final, 19 November 2025
2. European Commission, press release “Simpler EU digital rules and new digital wallets to save billions for businesses and boost innovation”, IP/25/2718
3. European Commission, “European Business Wallets”, Shaping Europe’s digital future
4. Consolidated text of Regulation (EU) No 910/2014 (eIDAS), as amended by Regulation (EU) 2024/1183, EUR-Lex, Articles 43 and 44
5. ENISA, “Security guidelines on the appropriate use of qualified electronic registered delivery services”
6. Council of the European Union, press release “European business wallets: Council adopts negotiating position”, 9 June 2026
7. European Parliament, Legislative Observatory, procedure 2025/0358(COD)
8. OpenPeppol, Peppol AS4 Profile
9. OpenPeppol, Peppol Interoperability Framework
10. Peppol.now, “European Business Wallet e-invoicing: the architectural solution” (background on identity and addressing; this article covers a different part of the stack: the evidentiary and transport layer)
11. Peppol.now, “European Business Wallet timeline: from proposal to regulation”
12. WE BUILD Consortium, use case SC5 “eInvoicing”
13. OpenPeppol, “SML Insourcing”
14. Rijksinspectie Digitale Infrastructuur (RDI), “Aanbieders van veilige digitale post (eDelivery) vallen onder eIDAS en de Cyberbeveiligingswet”, 3 June 2026