A few months ago, I made a Peppol transaction from a Raspberry Pi 5.

• Not a cloud cluster.
• Not a bank-grade mainframe.
• Not some sacred enterprise appliance hidden behind five layers of consulting.

A Raspberry Pi.

And that small fact says something much bigger about where Peppol is heading.

Peppol has long been treated as infrastructure — important infrastructure, yes, but still infrastructure: regulated, certified, controlled, and often wrapped in vendor-heavy language. For many companies, Peppol has not felt like a network they participate in. It has felt like a service they buy access to.

But when small, cheap, edge-level hardware can initiate real Peppol traffic, the mental model starts to change. Peppol stops looking like a destination and starts looking like a protocol layer — and this is where things get interesting.

The Access Point Is Becoming Less Magical

The original Access Point model made perfect sense. Businesses needed secure, standardized document exchange. Governments needed compliance. Vendors needed predictable rules. Peppol provided the rails.

But every infrastructure layer eventually goes through the same transformation.

• First, it is specialized.
• Then, it is standardized.
• Then, it is automated.
• Then, it becomes boring.

And “boring” is not an insult — boring infrastructure is successful infrastructure.

Nobody is impressed that a web server can send an HTTPS request anymore. Nobody builds a business case around the fact that their system can send email. Nobody says, “We are strategically positioned because we can resolve DNS.”

Today, being able to send and receive Peppol documents is still treated as a product feature. Soon, it may simply be expected behavior.

More Nodes, Less Gatekeeping

As more open-source libraries, lightweight nodes, containerized deployments, cloud-native Access Points, and embedded integrations appear, Peppol becomes less dependent on a small number of large vendors controlling the experience.

This does not mean governance disappears. Peppol still needs trust, certificates, authorities, conformance, service metadata, and rules. Without that, it becomes just another fragmented document transport mess.

But the technical implementation layer is becoming more accessible and that changes the balance of power.

Software vendors can embed Peppol directly into their platforms. ERP systems can run closer to the network. National implementations can become more automated. Small service providers can build focused products instead of massive monoliths. Developers can test, simulate, and validate flows locally before touching production.

The Access Point becomes less of a fortress, it becomes a node.

What happens when Peppol itself becomes a means to an end?

For years, “Peppol support” has been sold as if it were the product, but most customers do not actually care about Peppol.

• They care that invoices arrive.
• They care that orders are processed.
• They care that compliance is handled.
• They care that their accounting system, tax reporting, procurement workflow, and business partners all stay synchronized without manual work.

Peppol is not the business outcome — it is the transport and governance layer that makes the outcome possible. This distinction matters. Once the network becomes normal, the real value moves upward.

The winning companies will not be the ones shouting “we support Peppol” the loudest, they will be the ones that make Peppol invisible.

• Invisible in onboarding.
• Invisible in routing.
• Invisible in validation.
• Invisible in error handling.
• Invisible in reconciliation.

The real product will be automation, intelligence, compliance, observability, and trust. Peppol will be underneath it all, doing what good infrastructure does: quietly working.

For example, forward-thinking providers like Qvalia are already adding AI-powered document processing and analysis on top of the Peppol network.

The Future Is Not One Giant Platform

If Peppol continues to mature as a common protocol and governance framework, then its future is not one massive platform. It is thousands of interoperable nodes, each doing a specific job, all connected through shared rules.

• Some will run in hyperscale clouds.
• Some will run in national infrastructure.
• Some will run inside ERP vendors.
• Some will run in containers on modest hardware.
• And yes, some can run on a Raspberry Pi.

To be clear, this does not mean a Raspberry Pi is the right production platform for a regulated Access Point, nor that all these nodes are equal in operational capability.

A production-grade Access Point still requires security, monitoring, certificate handling, uptime, legal agreements, and support.

But it proves the architectural point, Peppol is no longer technically exotic.

The Real Competition Starts After Connectivity

When everyone can connect, connectivity stops being the differentiator. That marks the next phase. The question will no longer be: “Can you send Peppol?” It will be…

• Can you onboard a customer automatically?
• Can you detect routing problems before documents fail?
• Can you handle country-specific rules without hardcoding chaos?
• Can you explain why a document was rejected?
• Can you reconcile business events across systems?
• Can you turn Peppol traffic into operational intelligence?

That is where the serious engineering begins. Not in wrapping Peppol in more mystery, but in removing the friction around it.

A Raspberry Pi Is a Warning Shot

The Raspberry Pi transaction is not a gimmick.

It is a signal.

It says that the future of Peppol is not locked inside expensive enterprise platforms. It says the network can become more programmable, more distributed, and more accessible. It says that the value is moving away from merely having access to the rails and toward what you build on top of them.

Peppol will still need governance. It will still need certification. It will still need trust, but the implementation layer is opening up.

And when infrastructure opens up, markets change…

Want to Go Deeper?

Use the links below to get more information:

• OpenPeppol Interoperability Framework
• Node42 eDelivery — GitHub Repo
• Qvalia Access Point Solutions

The Long-Standing Visibility Gap

For years, Peppol invoice delivery operated with limited end-to-end visibility. A sender’s Access Point (C2) would transmit a document to the receiver’s Access Point (C3). An AS4 transport acknowledgement confirmed receipt at the gateway — but what happened after that remained largely opaque.

• Did the document pass validation?
• Was it successfully delivered to the buyer’s system (C4)?
• Were there business-level issues?

These questions often went unanswered in a standardized way. The earlier Message Level Response (MLR) attempted to address this but saw low adoption because it depended on end-user (C4) participation and optional capability declarations.

Peppol Message Level Status (MLS) v1.0.0, finalized on May 22, 2025, introduces a standardized, provider-to-provider feedback mechanism that significantly improves this situation.

For the first time, Peppol gains a standardized provider-level feedback loop that can be monitored operationally across networks and jurisdictions.

What MLS Actually Is

MLS operates at the service provider layer (C3 → C2) and is independent of end-user involvement. It uses the new Service Provider Identification Scheme (SPIS) for addressing.

MLS makes the three operational feedback layers in Peppol more explicit:

• Layer 1 — Protocol Status: AS4 transport acknowledgements (gateway delivery only)
• Layer 2 — Messaging Status: MLR (C4-scoped feedback) and MLS (C3-initiated, validation outcome and delivery to C4) both provide message-level feedback. MLS fills the gap where C4 participation was absent; it does not replace MLR where it is contractually required.
• Layer 3 — Business Level Response: Buyer’s commercial decision on the document (e.g. order rejection for business reasons). Separate UBL document type. Unaffected by MLS adoption.

MLS is designed to be enforceable at the service provider level, making reliable feedback possible without requiring every end-user to implement additional processes.

Technical Foundations of MLS

SBDH Extensions

MLS uses two optional BusinessScope elements:

• MLS_TO: Specifies the recipient of the MLS (defaults to the sender’s SPID)
• MLS_TYPE: Controls response behavior (FAILURE_ONLY= rejections only, ALWAYS_SEND= all outcomes)

SPIS — The New Identification Layer

A critical prerequisite for MLS is the Service Provider Identification Scheme (SPIS). Service providers now need a formal SPID registered in the SMP with MLS capabilities.

MLS Response States

C3 must produce at most one terminal MLS per inbound business document with one of the following terminal states:

• RE — Rejected (validation failure or permanent delivery failure to C4)
• AP — Accepted with positive confirmation
• AB — Accepted without positive confirmation (best-effort delivery)

Rejection reasons are detailed (SV, BV, etc.), while Schematron warnings alone do not trigger rejection.

MLS must not be sent in response to another MLS or MLR — the protocol is intentionally non-recursive.

Implementation Challenges Across Jurisdictions

While MLS solves a real problem, its roll-out highlights several systemic difficulties that affect multiple countries, particularly those implementing Continuous Transaction Controls (CTC) or real-time reporting models.

1. SPIS and Identifier Maturity Many markets are still finalizing SPIS registration processes and SMP capability declarations. The placeholder ICD code required careful handling during early adoption phases.

2. Parallel Reporting Channels (C5 Integration) In countries with tax-authority-as-C5 models, MLS only covers the invoice delivery path (C3 → C4). It does not automatically report status for parallel submissions to the tax authority. This creates the need for national extensions and careful error-handling design.

3. Validation and Timeline Alignment Countries with country-specific CIUS extensions (e.g., additional rules on top of PINT or BIS) must ensure alignment between generic Peppol validation and national requirements. Tight legislative timelines can compress testing periods for MLS capability.

4. Operational Handling of Validation Failures
Validation failures remain a major operational challenge because troubleshooting and reporting are often handled manually between service providers, customers, and support teams. However, MLS introduces standardized, machine-readable feedback with detailed validation and rejection information, reducing ambiguity and improving operational visibility.

Examples of Markets Navigating These Challenges

• United Arab Emirates (DCTCE model): The UAE has adopted a 5-corner Peppol architecture with PINT AE and parallel FTA reporting. The mandatory phase for larger businesses brings ambitious timelines. Service providers must manage both Peppol MLS flows and separate FTA reporting channels, while handling non-Peppol buyers.
• Slovakia (ViDA implementation): Slovakia requires MLS support in its Peppol Testbed certification for “Digitálni poštári” (Digital Postmen). The model includes parallel Tax Data Document (TDD) submission to the Financial Administration. This creates complex but clearly defined separation between MLS (delivery status) and tax reporting obligations.

These two markets are among the early large-scale adopters of MLS in CTC environments, which is why their experiences are particularly instructive for the broader Peppol community.

What Service Providers Should Prioritize

To support MLS v1.0.0 effectively:

• SMP Registration: Register your SPID and MLS reception capability
• SBDH Handling: Correctly process MLS_TO and MLS_TYPE elements (with proper fallback to Operational Guideline defaults)
• MLS Generation: Use reliable libraries such as Philip Helger’s peppol-commons (peppol-mls module)
• Operational Discipline: Implement exactly one terminal MLS per document, respect non-recursive rules, and handle C5 reporting paths separately
• Testing: Validate against national testbeds (especially where MLS is part of certification)

The MLS specification and accompanying operational guidance contain important details on timing, retries, and default behaviors that should not be overlooked.

Looking Ahead

MLS closes a long-standing visibility gap in the Peppol network. Its success will depend on widespread SPIS adoption, full alignment with the Operational Guideline, and smooth integration with national CTC requirements.

Service providers who invest in robust MLS implementation now will be better positioned as more countries move toward mandatory structured e-invoicing and real-time reporting. The infrastructure is evolving quickly — those who treat MLS as core infrastructure rather than a checkbox will gain a clear competitive advantage.

References

The mechanisms described in this article are based on the official Peppol specifications. Use the links below to get more information:

• Peppol MLS Specification v1.0.0
• SPIS documentation
• UAE Ministerial Decisions 243/244
• Slovak Law 385/2025
• Peppol Commons

Acknowledgements

Many thanks to Anders at Qvalia for proofreading the article and contributing valuable practical suggestions during review.

Anders has successfully implemented Peppol MLS and passed both testbeds, including complex 5-corner CTC setups in markets such as the UAE and Slovakia, using a Node.js-based Peppol solution.

This is not a hypothetical. This happens in production Peppol networks today — and often operators have no idea why.

Participant identifiers are hashed into deterministic DNS queries. DNS resolves the responsible SMP. The SMP returns signed metadata describing the receiving Access Point. TLS secures the transport. AS4 delivers the document.

Every layer is formally defined. Every layer is verifiable.

And yet, when delivery fails, operators are left staring at:

• Raw DNS records
• SMP XML metadata
• TLS certificate chains
• HTTP status codes

All technically correct — yet often of limited use for real operational debugging.

Because Peppol provides transport — not interpretation. That distinction matters more than most people in the ecosystem realize.

The Real Questions Are Unanswered

Most of today’s error resolution entails local scripts and generic tools that are good at collecting facts, but they cannot tell you what those facts mean.

They can tell you:

• Which SMP was resolved
• Which endpoint was returned
• Which certificate was presented

They cannot answer:

• Is this configuration compliant?
• Is this a transient issue or a structural misconfiguration?
• Which exact layer is responsible for this delivery failure?

This is the missing layer in Peppol today. Not transport. Not security. Interpretation.

The real story is a two-layer value proposition:

Layer 1 — Node42 Discovery

The JSON and SVG outputs from Node42 already gives operators structured, actionable insight that raw Peppol tools don’t provide. This alone is a significant step forward — most operators are working with unstructured protocol artifacts.

Layer 2: Node42 Discovery AI

Node42 approached this problem differently. Instead of treating discovery as the final step, we treat it as the input to an AI diagnostic engine.

The Node42 Discovery returns a JSON structure which is essentially a deterministic, machine-readable representation of Peppol network state.

Each discovery produces a structured, timestamped record of the complete resolution chain:

• SML lookup
• SMP metadata validation
• Certificate chain verification
• Endpoint connectivity

The structured output can be provided to an AI model for interpretation — specifically a model with access to a vector store containing the full corpus of Peppol specifications, BIS documentation, and governance publications.

The Node42 AI Engine then applies a reasoning layer — that translates this data into natural-language diagnostics, risk assessments, and remediation guidance.

Why This Matters?

Peppol is a decentralized system. There is no central authority validating operational correctness in real time.

Every Access Point and SMP operator is responsible for maintaining correct configuration. Even small misconfigurations silently break interoperability — for every participant trying to reach them.

Without interpretation, these failures remain invisible. An AI intelligence layer makes them visible. And more importantly, understandable.

A Necessary Evolution

Knowing the protocol is correct — is not enough. You need to know when correctness breaks — and why.

Peppol solved the hardest problems:

• Decentralized participant discovery
• Cryptographic trust infrastructure
• Secure, interoperable transport

These were extraordinary achievements. The protocol works.

But as the network scales globally — driven by real-time invoicing mandates across EU, APAC, and LATAM — operational visibility becomes equally critical.

What We Are Building

The Node42 AI intelligence layer transforms Peppol discovery from observation into diagnosis.

It answers not what happened — but what it means, whether delivery will succeed, and exactly what needs to change if it won’t.

• It is not a monitoring dashboard.
• It is not an alerting tool.

It is an AI interpretation engine for Peppol infrastructure state.

Want to Go Deeper?

Use the links below to get more information:

• OpenPeppol Interoperability Framework
• Peppol eDelivery Network SMP Specification v1.4.0
• Peppol Service Metadata Locator (SML) v1.3.0
• Peppol AS4 Profile v2.0.3
• Peppol Practical
• Node42 Discovery API
• Node42 Web UI

Peppol’s architecture is built on a deceptively simple idea: participants never connect to each other directly. Instead, messages are routed indirectly through certified intermediary Access Points. This structure — known as the Four Corner Model — is not just a network topology. It is a deliberate trust architecture.

This separation is what makes Peppol scalable. It is also what makes it enforceable.

Trust is not established between businesses directly — it is enforced through infrastructure: certificate hierarchies, signed metadata, SML-anchored DNS resolution, and mandatory transport rules. Every document flows through a controlled chain of accountability.

At first glance, the Four Corner Model looks like a routing pattern.

In reality, it is a distributed trust mechanism designed to prevent fragmentation, eliminate proprietary lock-in, and ensure that identity, capability, and transport security are validated before a single invoice is exchanged.

Why Four Corners?

1. Separation of concerns: C1/C4 handle business logic while C2/C3 handle transmission
2. Outsourcing: Small companies can use hosted Access Points (C2/C3) without building infrastructure
3. Interoperability: Any C2 can send to any C3 using the same protocol
4. Legal compliance: C2/C3 provide audit trails, archiving, and proof of delivery

The business document is encrypted by C2 (sender’s AP) and decrypted by C3 (receiver’s AP). C1 sends the plaintext document to C2, which encrypts it before transmission. C3 decrypts it and delivers plaintext to C4. The encryption protects the document in transit between Access Points, not end-to-end from C1 to C4.

The Trust Model

Peppol uses certificates for three distinct purposes.

1. TLS Certificate → Transport Identity

• Purpose: Secure the HTTPS connection
• Issuer: Any trusted CA (Let’s Encrypt, DigiCert, etc.)
• Validation: Standard PKI chain of trust
• Location: Web server configuration
• Lifetime: Typically 90 days (Let’s Encrypt) to several years
• What it proves: The server you’re talking to owns this domain

2. Signing Certificate → Message Integrity & Non-Repudiation

• Purpose: Sign the AS4 message <eb:Messaging> + Payload
• Issuer: Peppol CA
• Validation: Must chain to Peppol trust anchor
• Location: Included in message as <wsse:BinarySecurityToken>
• Lifetime: 2 years
• What it proves: This message came from this specific Access Point and hasn’t been tampered with

3. Encryption Certificate → Payload Confidentiality

• Purpose: Encrypt the business document
• Issuer: Peppol CA
• Validation: Retrieved from SMP, must chain to Peppol trust anchor
• Location: Retrieved from SMP before sending; included in message for verification
• Lifetime: 2 years
• What it proves: Only the intended receiver can decrypt this payload

Same Certificate, Different Roles

Peppol Access Points use the same X.509 certificate for both signing and encryption, but these remain logically distinct operations with separate security purposes:

• Signing: Uses the private key to create a digital signature
• Encryption: Uses the recipient’s public key to encrypt the session key

The Peppol PKI Hierarchy

Root CA: DigiCert One Trust Lifecycle Root CA G3
└─ Intermediate CA: Peppol Access Point CA - G3 (Production)
   └─ AP Certificate: CN=POP000001, O=Your Company
   
Root CA: DigiCert One Trust Lifecycle Root CA G3
└─ Intermediate CA: Peppol Access Point TEST CA - G3 (Test/Sandbox)
   └─ Test AP Certificate: CN=POP000001, O=Your Company

Production and test networks have separate CA chains. Never mix them. Your truststore must contain the correct chain for the environment.

Why This Separation Matters

• Security boundary clarity: Transport security (TLS) is independent from message security (WS-Security). You can send AS4 messages through proxies/load balancers that terminate TLS — the message-level security is preserved.
• Different lifetimes: TLS certs can be short-lived (Let’s Encrypt 90 days), Peppol certs are normally annual. You can rotate TLS certs without touching Peppol certs.
• Different issuers: You control your TLS cert provider. Peppol controls the message cert CA.
• Non-repudiation: Message signatures provide legal proof of origin. TLS doesn’t.

The Delivery You Can’t Dispute

Peppol’s security model is designed to produce cryptographic evidence at every stage of transmission. This ensures that invoices, orders, and other business documents can be exchanged with verifiable proof of origin, integrity, and receipt across organizational and national boundaries.

[C1: Sender]
    ↓ (creates business document)
[C2: Sender's Access Point]
    ↓ (signs & encrypts, sends via AS4)
[C3: Receiver's Access Point]
    ↓ (decrypts & validates, delivers)
[C4: Receiver]

This legal reliability is built on several cryptographic guarantees:

• Digital signatures — Prove the sender’s identity and ensure the message cannot be forged
• Message timestamps — Embedded in the signed header, providing a verifiable record of when the message was sent and received
• Digest verification — Cryptographically binds the receipt to the exact message content
• Non-repudiation — Both sender and receiver possess signed proof of transmission and receipt
• Full audit trail — Each step of the exchange can be independently verified
• Tamper evidence — Any modification invalidates the cryptographic signatures immediately

Together, these guarantees create a verifiable chain of evidence, making Peppol suitable for legally binding document exchange in regulated and cross-border environments.

Peppol’s security model secures the transport layer between Access Points (C2–C3), not the full path from sender to receiver (C1–C4). Access Points must decrypt and inspect the content to perform the validation that makes Peppol legally reliable in the first place.

The trust model is therefore not purely cryptographic. It is institutional and legal, built on contractual obligations, audits, and GDPR compliance rather than end-to-end encryption. Access Points are not passive routers — they are accountable intermediaries.

Peppol trades full confidentiality for something more pragmatic: radical interoperability, lightweight onboarding, and a governance layer strong enough to enforce rules without requiring every participant to become a cryptographer or infrastructure architect.

The network’s genius lies in that compromise — it democratized e-invoicing by minimizing friction. Endpoints resolve publicly, messages route through relays trusted through governance rather than end-to-end cryptographic isolation, and confidentiality rests on transport-layer encryption and signed receipts rather than zero-knowledge end-to-end proofs.

This is not a bug — it’s the explicit design philosophy. But it is also why it is often misunderstood.

From the outside, the network appears simple — just send a document from A to B. In reality, every exchange involves multiple layers of resolution, validation, certificate handling, and transport rules that must align perfectly. When something breaks, it rarely fails loudly. It fails somewhere along that chain.

Understanding that chain is no longer optional. As adoption grows and use cases expand, the challenge is not redefining the model — but making its behavior visible, predictable, and testable in practice.

The systems that succeed in this ecosystem will not be the ones that abstract everything away, but the ones that make the underlying mechanics transparent enough to trust.

Want to Go Deeper?

Use the links below to get more information:

• Peppol
• OpenPeppol eDEC Specifications
• Peppol Testbed

Peppol has a reputation for being complicated. If you look at the transport stack alone, it’s easy to see why. The Peppol transport layer is built on technologies that look intimidating at first glance:

• SOAP
• WS-Security
• XML Digital Signatures
• Encryption
• MIME attachments

If you search the ecosystem today, you’ll mostly find implementations built on large Java frameworks. These systems power production Access Points across the network, and they are excellent at what they do.

But they also give the impression that Peppol messaging requires tens of thousands of lines of infrastructure code. Recently, I wanted to test something. What if we stripped the protocol down to its essentials?

What if we implemented only what is strictly required to discover a participant, construct an AS4 message, sign it, encrypt it, and send it?

• No large frameworks.
• No external crypto tools.
• No heavy dependencies.

Just pure modern Node.js.

The Current Landscape

But why reinvent the wheel if you don’t have to? I began by looking at what already exists in terms of lightweight, local Peppol senders.

As it turns out, such implementations are rare. The few that exist — none found in Node.js — rely on external tools or heavy native dependencies, introducing installation complexity and tight coupling to the host system.

The experiment

So I started a small project as part of the Node42 tooling ecosystem: a pure Node.js Peppol sender that performs the entire sending pipeline:

1. Resolve a participant via SML
2. Retrieve metadata from SMP
3. Extract the receiving AP endpoint and certificate
4. Build the AS4 SOAP envelope
5. Apply WS-Security signing
6. Encrypt the payload
7. Construct the multipart MIME message
8. Send the message to the receiving AP
9. Validate the receipt
10. Persist the entire transaction for analysis

All of that turned out to be… surprisingly small. The core transport logic is roughly a few hundred lines of code. Not thousands, not tens of thousands. Just a clear sequence of deterministic transformations.

Why it works today

Ten years ago this would have been much harder. But modern Node.js already provides most of what AS4 requires:

• strong cryptographic primitives through OpenSSL
• stable streaming APIs
• reliable HTTP clients
• mature XML tooling

Once those pieces are available, the rest is largely specification work, reading the standards carefully and implementing exactly what they specify. In practice, the sending pipeline becomes something conceptually simple:

UBL document

• canonicalize XML
• calculate digest
• sign envelope
• encrypt payload
• build MIME message
• POST to Access Point

Each step is deterministic.

The real challenge isn’t sending

Interestingly, implementing the sender itself was not the hardest part. The harder part of working with Peppol is something different: observability.

Anyone who has operated an Access Point knows the situation. A message fails somewhere in the network. Logs appear, SOAP envelopes are dumped. Digests and signatures are inspected manually.

And somewhere in the chain between discovery, metadata, certificates, canonicalization, encryption, and transport… something breaks. The problem is rarely obvious.

While building the Node42 diagnostic platform and the Node.js sender extension, I focused on something else: making the protocol visible. Each run can persist a complete set of artifacts, including:

• discovery results
• SMP metadata
• canonicalized XML
• calculated digests
• the final SOAP envelope
• the complete multipart MIME message
• the AS4 receipt
• execution context

In other words: a full forensic record of the transaction. Instead of a black box, each message becomes something you can inspect step-by-step.

Treating Peppol as a protocol, not a platform

Most large Peppol implementations are designed as full Access Point platforms. They manage:

• message queues
• retries
• routing
• persistence
• monitoring
• administration interfaces
• multi-tenant environments

Those features are essential for operating an Access Point, but they are not part of the core transport protocol. When you separate those layers, Peppol messaging becomes much easier to reason about. The sender becomes simply:

• discovery
• message construction
• security transforms
• transport

Each stage can be inspected and validated independently.

A small tool with an unexpected use

What started as an experiment is turning into something slightly different: a protocol probe. Because the sender is small and deterministic, it can be used to debug interoperability issues between Access Points.

Instead of relying on large stacks, a developer can send a controlled AS4 message and inspect every step of the process. In a way, the tool behaves more like familiar protocol utilities:

• curl for HTTP
• dig for DNS
• openssl s_client for TLS

Simple tools that expose the mechanics of a protocol.

Why open source matters here

The Peppol ecosystem has always benefited from open reference implementations. Projects like phoss SMP and Phase4 helped many organizations understand how the network works internally and today effectively serve as de-facto reference implementations for the network.

Publishing a minimal sender continues that tradition. Not because the code itself is revolutionary, but because it fills a gap — a working, readable Node.js implementation that demonstrates something useful.

Peppol messaging is not mysterious enterprise middleware. It’s a protocol. And protocols become easier to understand when their mechanics are visible.

The bigger picture

This sender is part of a broader effort around Node42, a set of tools focused on making Peppol infrastructure easier to analyze and understand. So far that work has included:

• discovery diagnostics
• infrastructure tracing
• protocol analysis

Adding a minimal local sender closes an important gap: the ability to generate and observe messages end-to-end.

One practical benefit of this approach is that sensitive credentials never leave your environment. The sender runs locally, using your own Access Point certificate and keys, meaning there is no need to hand over private material to third-party services or external platforms.

For organizations operating in regulated environments, this can significantly simplify security considerations and avoid introducing additional compliance scopes such as ISO 27001 for external providers.

A small observation

When working with complex systems, we often assume that the difficulty lies in the protocol itself. But sometimes the complexity comes from the layers built around it.

Peppol transport is a good example. Once you peel away the surrounding infrastructure, what remains is surprisingly elegant. Sometimes the best way to understand a protocol is simply to build one message and watch what happens.

Want to Go Deeper?

If you’d like to explore the project or experiment with the sender yourself, the repository is now available on GitHub. Short CLI demos are also available on the Node42 YouTube channel if you’d like to see the sender in action.

• GitHub Repo
• npm package
• YouTube Demo
• Node42 Website

This article tears down the abstraction layers — from TCP handshake to encrypted invoice — revealing the cryptographic machinery that makes Peppol legally enforceable across countries.

Some details are simplified to focus on the core transmission and security mechanisms. The objective is to explain how Peppol AS4 message exchange actually works in practice, without covering every minor specification detail.

What Is Peppol AS4, Really?

Well, it isn’t just “SOAP with security”. It’s a precisely layered stack where each layer has a specific job, and understanding these layers is critical for debugging transaction issues.

Peppol AS4 is built on progressively constrained specifications

where the hierarchy is as follows:

OASIS ebMS3 standard — base messaging framework:

• Requires WS-Security (unlike full ebMS3 where it’s optional)
• Mandates specific MEPs (Message Exchange Patterns)

eDelivery AS4 v1.14 — further constrains:

• Mandates TLS for transport
• Requires XML Signature and XML Encryption
• Specifies exact algorithms (RSA-SHA256, AES-128-GCM, etc.)
• Defines conformance profiles (ebHandler, Light Client)
• Defines Four Corner topology for intermediated exchanges
• Adds SBDH (Standard Business Document Header) support

Peppol AS4 Profile v2.0 — adds final constraints:

• One-Way Push MEP only
• Messages must be signed and encrypted
• Exactly one encrypted payload (the business document)
• Payload must be wrapped in SBDH
• Peppol PKI certificates only
• Binary Security Token (BST) for certificate exchange
• Dynamic discovery via SML/SMP
• Requires synchronous signed AS4 Receipts (Non-Repudiation of Receipt)

Why This Layering Matters?

Because each layer can fail independently…

• TLS failures happen before SOAP
• WS-Security signature failures happen after SOAP parsing
• ebMS3 validation happens after security processing
• Peppol-specific validation happens last

Understanding the order helps you identify where problems occur.

Message Security vs. Transport Security

Before any AS4 message is exchanged, a standard TLS 1.2+ handshake establishes a secure HTTPS connection between Access Points.

The Peppol AS4 profile does not mandate mutual TLS. An Access Point that enforces it as a connection requirement is non-compliant with the specification.

TLS authenticates the server endpoint, not the sending Access Point itself. The actual sender identity is established at the application layer using the Peppol certificate embedded in the WS-Security header. This separation allows TLS termination at load balancers or proxies without breaking message-level trust.

Two Certificates, Two Distinct Security Roles

Peppol uses separate certificates for transport security and message security. These serve fundamentally different purposes and are never interchangeable:

TLS Certificate

• Purpose: Secure the HTTPS connection itself
• Issuer: Any CA from Mozilla’s trusted root certificate list (Let’s Encrypt, DigiCert, GlobalSign, etc.)
• Cannot be: Self-signed
• Required: Must achieve SSL Labs grade “A”
• Location: Web server configuration (Apache, nginx, Tomcat, etc.)
• Lifetime: Typically 90 days (Let’s Encrypt) to several years
• Used for: Establishing encrypted TLS connection before any AS4 message exchange

Peppol Certificate

• Purpose: Sign and encrypt AS4 messages
• Issuer: Peppol CA
• Location: Included in AS4 message as <wsse:BinarySecurityToken>
• Lifetime: 2 years
• Used for: Creating digital signatures on messages, encrypting payloads
• Retrieved from: SMP as part of the signed <smp:ServiceMetadata> containing the receiver’s public certificate

The SSL Labs grading methodology is subject to change, meaning an “A” rating today may not represent the same criteria in the future.

Message Structure — The Layers Inside

A Peppol AS4 message is a structured container of nested transport, messaging, and cryptographic layers. Each layer serves a specific role in ensuring secure, verifiable, and interoperable delivery. The complete anatomy is broken down below, from outer transport to inner business payload:

HTTP Layer

• Method: POST
• Content-Type: multipart/related with boundaries
• Contains: <soap:Envelope> and <xenc:EncryptedData> (payload) as separate MIME parts

SOAP 1.2 Envelope

• Header: contains all metadata and security (ebMS3 messaging metadata and WS-Security elements)
• Body: empty — the encrypted payload travels as a separate MIME part referenced by <eb:PayloadInfo>

This design avoids XML canonicalization and size limitations by keeping the encrypted business document outside the SOAP envelope while still cryptographically binding it via signature references.

The <soap:Envelope> forms the control structure of the AS4 message, encapsulating all protocol metadata and cryptographic security information. The <soap:Header> contains two critical sections:

ebMS3 (ebXML Messaging Services 3.0)

• <eb:MessageInfo>: Unique message ID and timestamp
• <eb:PartyInfo>: Sender/receiver AP identities (from certificate CNs)
• <eb:CollaborationInfo>: Process ID (Service), Document Type ID (Action)
• <eb:MessageProperties>: Original sender and final recipient Peppol participant IDs
• <eb:PayloadInfo>: Reference to encrypted MIME attachment

OASIS WS-Security 1.1

• <wsse:BinarySecurityToken>: Sender’s X.509 certificate (public key)
• <ds:Signature>: Digital signature covering <eb:Messaging> and encrypted payload
• <xenc:EncryptedKey>: Session key encrypted with receiver’s public key

The actual business document, as mentioned before travels as a separate MIME part, not embedded in the SOAP body but inside <xenc:EncryptedData>

Encrypted Data

• Compressed SBDH + Business Document
• Encrypted using AES-128-GCM with random IV
• Session key is in <xenc:EncryptedKey> element

The AS4 specification itself does not define hard message size limits.
However, within the Peppol network, Service Level Requirements apply.
For post-award message exchange services (e.g., invoices), an Access Point must support messages up to 100 MB. For pre-award procurement, the required capability is up to 2 GB.

Individual service providers may choose to accept larger messages, but they cannot enforce limits below these required thresholds and remain compliant.

Cryptographic Processing Order

When sending a Peppol AS4 message:

• SMP Lookup: Query SMP for recipient’s (C3) endpoint URL and certificate
• Verify SMP Signature: Validate <smp:ServiceMetadata> signature to ensure the received data was published by an authorized SMP (normally cached)
• Parse Recipient’s certificate: extract from SMP <ds:X509Certificate>, decode (Base64) and parse the X.509 structure
• Check Expiry: Verify (C3) cert NotBefore <= now <= NotAfter
• Build Chain: Construct chain from (C3) cert to Peppol Root CA
• Verify Chain: Validate that (C3) cert chains to trusted Peppol CA
• Check Revocation: OCSP/CRL check (optional but recommended)
• Validate Business Document: Check against UBL/CII schemas and Schematron rules (implementation specific, could also be an earlier step)
• Build and Compress Payload: (gzip) SBDH + Business Document
• Generate Session Key: Create random 128-bit key (AES-128-GCM) key for payload encryption
• Encrypt Payload: Encrypt compressed payload with session key (AES-128-GCM)
• Encrypt Session Key: Encrypt session key with (C3) public key (RSA-OAEP-MGF1-SHA256) then embed in <xenc:EncryptedKey> within the <soap:Header>
• Calculate Digests: Compute (SHA-256) digests of <eb:Messaging> and the encrypted payload
• Sign Message: Sign digests with sender’s (C2) private key (RSA-SHA256)
• Include Sender’s Certificate: Embed sender’s (C2) cert in <wsse:BinarySecurityToken>
• Construct MIME message: Build <soap:Envelope> with all headers and encrypted payload in <xenc:EncryptedData>
• Send: via HTTPS POST to (C3) endpoint with boundaries that separates SOAP and payload parts

When receiving a Peppol AS4 message:

Any step that fails returns an AS4 Error signal instead of a receipt, with the appropriate EBMS error code.

• Parse: incoming Content-Type: multipart/related request and extract boundary parameter
• Parse: <soap:Envelope> and extract <soap:Header> and <soap:Body>
• Parse Sender’s (C2) certificate: extract from<wsse:BinarySecurityToken>, decode (Base64) and parse the X.509 structure
• Check Expiry: Verify (C2) cert NotBefore <= now <= NotAfter
• Build Chain: Construct chain from (C2) cert to Peppol Root CA
• Verify Chain: Validate that (C2) cert chains to trusted Peppol CA
• Check Revocation: OCSP/CRL check (optional but recommended)
• Verify Message Signature: Use public key from (C2) cert to verify the XML Digital Signature (<ds:Signature>) in the <soap:Header>
• Verify Digest: Recalculate (SHA-256) digests of signed elements and compare with <ds:DigestValue> in <ds:SignedInfo>
• Decrypt Session Key: Use receiver’s (C3) private key to decrypt session key from <xenc:EncryptedKey>
• Decrypt Payload: Use session key to decrypt payload (AES-128-GCM) from <xenc:EncryptedData>
• Check Duplicate: Compare<eb:MessageId>with message log (reject if duplicate)
• Validate Timestamp: Reject messages with <eb:Timestamp> older than (implementation-defined) minutes or in the future (clock skew tolerance)
• Decompress: (gunzip) the decrypted payload
• Extract SBDH: Parse the Standard Business Document Header
• Validate Business Document: Check against UBL/CII schemas and Schematron rules (optional)
• Generate Receipt: and sign with (C3) private key
• Return Receipt: as synchronous response to original HTTP POST

Receipt and Delivery Guarantees

The AS4 Receipt — What It Actually Means

After successfully receiving and processing a message, the receiving Access Point sends back an AS4 Receipt. This is a signed acknowledgment that serves multiple purposes.

What the Receipt Proves

Non-Repudiation of Receipt (NRR) contains cryptographic digest values of the original message, signed by the receiving Access Point. This provides verifiable proof that:

• The receiver got the message: They had to compute the digests
• The message was intact: Digest values match what sender calculated
• The receiver can’t deny it: Their signature is cryptographic proof
• Legal evidence: Can be used in dispute resolution

Synchronous Receipts

Peppol AS4 uses synchronous receipts only:

• Receipt is returned in the HTTP response to the original HTTP POST request
• HTTP 200 with receipt in body means SUCCESS (meaning protocol-level success only — it does not imply business acceptance or downstream processing).
• HTTP 4xx/5xxor absence of a receipt mean FAILURE (retry behavior is implementation-defined)

The receipt is not merely an acknowledgment. It is a cryptographic artifact signed by the receiving Access Point, containing digest values of the original message. This creates verifiable proof that a specific Access Point received and validated a specific message at a specific time.

Receipt Processing Flow

Sender side:

• Send AS4 message via HTTP POST
• Wait for HTTP response
• Parse response — is it a receipt or an error?
• If receipt: Verify signature, check <eb:RefToMessageId> matches
• Store receipt for non-repudiation
• Mark message as delivered

Receiver side:

• Receive AS4 message
• Decrypt, verify signature, validate structure
• If valid: Generate receipt with digests from original message
• Sign receipt with receiver’s private key
• Return receipt in HTTP response (synchronously)
• Process business document

Delivery Guarantees

What AS4 Receipt Guarantees:

• Message was received by the Access Point
• Message was well-formed and valid
• Message was decrypted and signature verified
• Cryptographic proof of receipt

What AS4 Receipt Does NOT Guarantee:

• Business document was delivered to end user
• Business document was processed successfully
• Business document was accepted (vs rejected for business reasons)
• Payment was made, order was fulfilled, etc.

These business-level acknowledgments are out of scope for AS4. They’re handled at the business document level (e.g., UBL Application Response).

Error Signals vs Receipts

If something goes wrong, the receiver sends an Error Signal instead of a receipt, common error codes:

• EBMS:0001: ValueNotRecognized
• EBMS:0002: FeatureNotSupported
• EBMS:0003: ValueInconsistent
• EBMS:0004: Other (with description)
• EBMS:1001: FailedAuthentication
• EBMS:1002: FailedDecryption
• EBMS:1003: SignatureValidationFailed

Understanding the full transmission and cryptographic chain clarifies why many AS4 failures are not random, but deterministic — occurring at a specific validation layer in a strictly ordered processing flow.

References

The mechanisms described in this article are based on the official Peppol specifications. Use the links below to get more information:

• OASIS ebMS3 Core Specification
• OASIS AS4 Profile Specification
• CEF eDelivery AS4 Profile v1.14
• Peppol AS4 Profile v2.0.3

A participant lookup that should take milliseconds can fail for various reasons, and you will rarely receive a conclusive diagnostic response. Even seemingly compliant setups can still encounter frustrating silent failures in the real world.

But my AP passed the Testbed!? — Why the errors?

Passing the Peppol Testbed is a self-assessment tool for initial compliance that verifies basic conformance but does not guarantee handling of all edge case scenarios.

The Peppol Testbed primarily covers standard good-case and basic bad-case scenarios (e.g., invalid certificates or large messages) without delving into production-like complexities such as sporadic DNS resolution failures, high-load caching behaviors, or interactions with country-specific extensions.

This guide catalogs 12 common (often hidden) failure modes

with explanations of why they happen.

1. Participant ID schemes — 80+ supported (ISO 6523 ICD list), each with validation rules. Wrong scheme? Discovery fails silently.

Peppol relies on the ISO 6523 International Code Designator (ICD) list for participant identifiers, which spans over 700 registered codes globally, with more than 80 active schemes in use within Peppol.

Each scheme has specific validation rules, such as regex patterns, check digits (e.g., Luhn or MOD11 algorithms), and structure requirements. For example, the French SIRENE scheme (ICD 0002) uses a 9- or 14-digit format with Luhn check digits.

If an incorrect scheme is used (e.g., mismatched ICD prefix), participant discovery via the Service Metadata Locator (SML) or Publisher (SMP) fails without explicit error feedback to the sender, as the hashed lookup in DNS/SML simply returns no match, leading to silent non-delivery.

This is a common complexity, as invalid IDs cause “silent failures” in dynamic discovery.

2. Multiple profiles per participant — A company might support 10+ document types, each with process identifiers, extension possibilities.

A single Peppol participant can register multiple profiles in their SMP entry, supporting various document types (e.g., invoices, orders, credit notes) under different business processes.

Official code lists show over 50 document types, and a company could realistically support 10+ (e.g., BIS Billing 3.0 for invoices plus PINT variants for international extensions). Each includes process identifiers (e.g., urn:fdc:peppol.eu:edec:bis:reporting:1.0) and allows extensions for country-specific customizations.

This flexibility adds complexity in managing capabilities, as senders must query SMP for supported types to avoid mismatches.

3. Redirects and migrations — Participants can switch SMPs; old metadata must be cleaned, or stale caches cause delivery failures.

Participants can migrate to a new SMP (e.g., during service provider changes), and redirects (via SMP entries) handle forwarding. However, old metadata must be explicitly deleted or updated in the SML/SMP; failure to do so leads to stale data persisting in Access Point (AP) caches, resulting in delivery to outdated endpoints.

Documentation stresses proper cleanup during migrations to prevent failures. This is a noteworthy hidden pitfall, because unrefreshed caches from migrations can cause “delivery failures” without clear indicators.

4. Signing and security — SMP responses are XMLDSig-signed (now SHA-256 required post-1.3 updates); invalid signatures block the whole chain.

SMP responses are signed using XML Digital Signature (XMLDSig) to ensure integrity and authenticity. As of SMP specification 1.3.0 (effective 2023–2024, with phase-in), SHA-256 is mandatory for digests and signatures (replacing SHA-1 for security).

Invalid signatures cause the receiving AP to reject the metadata, blocking the discovery and delivery chain entirely.

Signature validation failures “block the whole chain,” especially during updates, and are widely seen in issue trackers. Note that phoss SMP was already compliant with SHA-256 by v5.x — this pitfall primarily affects operators running legacy custom implementations or older third-party tools.

5. Caching pitfalls — Access Points cache results for performance, but expiration, revocation, or changes mean you must detect and refresh — or send to the wrong place.

Most AP implementations cache SMP metadata (e.g., endpoints, certificates) to optimize performance, but metadata includes expiration dates (xs:dateTime format; missing means “eternal”).

Changes, revocations (e.g., via PKI), or expirations require refresh mechanisms; failure to detect/refresh leads to sending documents to incorrect or revoked endpoints.

Stale caches are a frequent cause of “wrong place” deliveries. Official guides warn of these pitfalls, emphasizing revocation checks and cache invalidation.

6. Certificate management and updates — Specific processes required for certificate changes (e.g., expiration); standard updates don’t suffice, leading to registration or lookup blocks.

SMP certificates (used for SML interactions and signing) require a dedicated update process separate from general SMP metadata changes.

Expiring or invalid certificates prevent SMP registration in the SML or cause signature validation failures during lookups, blocking participant discovery.

Multiple sources — blogs, GitHub discussions, and practitioner experience — consistently highlight mismatches (e.g., using test certs in prod) as common causes of 401 Unauthorized errors or failed registrations. Incomplete certificate chains (e.g., missing intermediates) also lead to authentication failures.

7. DNS propagation delays — Changes to participant or SMP DNS records (NAPTR) can take minutes to hours to propagate, causing temporary discovery failures.

The SML uses distributed DNS for participant addressing, and updates (e.g., after registration, migration, or deletion) involve NAPTR records that may not replicate immediately across nodes, leading to inconsistent lookups and silent failures during that window.

Implementation guides note this as a standard DNS pitfall in Peppol, exacerbated during migrations.

8. Intermittent SML/DNS issues — Sporadic lookup failures due to network or DNS resolution problems, often resolving unpredictably.

SML lookups rely on DNS queries, and transient network issues can cause exceptions like “Identifier not registered in SML,” even for valid participants.

These are not SML-side but often client-side DNS resolution glitches, affecting production more than test environments.

GitHub issues describe these as “come and go” problems, recommending tools like nslookup for debugging. For a faster, Peppol-specific alternative without touching the command line, the Node42 Web UI handles this directly.

9. HTTPS mandatory migration — As of February 1, 2026, SMPs must use HTTPS on port 443 with approved TLS certs; non-compliance causes service interruptions.

SMPs must now exclusively use HTTPS for APIs, with TLS certs from approved CAs (not OpenPeppol PKI certs).

Failure to migrate leads to inaccessibility, disrupting metadata retrieval and document exchange.

Improper certificate setup or missed migration deadlines will cause service disruptions.

10. Outdated SMP software versions — Older versions incompatible with current specs (e.g., CNAME to NAPTR migration), leading to registration failures.

The SML historically used CNAME-based DNS records for participant addressing. OpenPeppol deprecated this in favor of NAPTR records as part of the post-2025 infrastructure modernization. NAPTR records carry richer routing information and align with how modern DNS-based service discovery is expected to work at scale.

SMP tools like phOSS SMP versions prior to v7.2.7 lack full support for the CNAME to NAPTR migration. While v7.2.7+ handles NAPTR, upgrading to v8+ is recommended to ensure full compatibility with all post-2025 infrastructure changes, including HTTPS enforcement and ongoing specification updates.

11. Unregistered SMP deletion risks — Unregistering an SMP without migrating participants deletes all linked DNS entries, disrupting addressing.

SMP unregistration from SML cascades to delete participant DNS records if not preceded by migration, causing widespread discovery failures for those participants.

Guides stress manual migration to avoid this pitfall.

12. PKI Certificate Migration (G2 → G3) — OpenPeppol G2 certificates stop being issued after February 11, 2026 and are fully revoked April 1, 2026; any SMP or AP still relying on G2 certs after that date fails SML authentication entirely.

The OpenPeppol PKI is transitioning from its G2 (Generation 2) root to G3. This affects both SMP certificates (used for SML registration and SMP response signing) and AP certificates (used for AS4 message signing and encryption).

Because the revocation happens at the PKI root level, no amount of reconfiguration fixes it — the cert itself must be replaced. APs that cache certificate validity can also be caught off guard if they don’t actively check revocation status (OCSP/CRL) on each transaction.

A particularly nasty edge case exists between T1 (February 11) and T2 (April 1, 2026): APs must simultaneously trust both G2 and G3 chains during this window. An AP that has migrated its truststore to G3-only will silently reject incoming AS4 messages from peers still on G2 — with no informative error. This makes the transition window itself a source of intermittent delivery failures even for providers who have done everything right on their own side.

Why Discovery Matters More Than Ever

If you’ve made it through all 12 pitfalls (and there are a great deal more not covered here), you’re probably thinking:

“That’s a lot that can go wrong…” — You’d be right.

As Peppol expands globally with real-time invoicing mandates, discovery failures become critical business issues. A misconfigured certificate or stale cache can silently break delivery for hours…

Want to Go Deeper?

• OpenPeppol eDEC Specifications
• Peppol Testbed
• Peppol Practical
• Node42 Discovery API
• Node42 Web UI
• Qvalia Access Point Solutions

But behind that seamless experience lies a cleverly engineered yet surprisingly intricate system of distributed components, DNS tricks, strict governance, and potential failure points that make it robust — and occasionally frustrating.

Peppol (now global beyond its Pan-European roots) relies on a four-corner model for document exchange — though a fifth corner for tax authorities is emerging in some jurisdictions.

The magic enabling any-to-any connectivity without prior agreements? Dynamic discovery via the Service Metadata Locator (SML) and Service Metadata Publishers (SMPs).

Before we dive in, this article assumes basic familiarity with Peppol concepts. At a high level, the model resembles email delivery — but with an important architectural difference: routing is derived deterministically from the participant identifier itself.

The discovery core components

can be understood as follows:

• Participant ID — globally unique identifier of the recipient (analogous to an email address, but used as a deterministic routing key)
• SML (Service Metadata Locator) — DNS-based routing layer that resolves the participant to its authoritative SMP
• SMP (Service Metadata Publisher) — capability directory that publishes signed metadata describing how to reach the participant
• AS4 — secure transport protocol used by Access Points to exchange documents

DNS as a Cryptographic Routing Fabric

the architectural breakthrough:

Peppol discovery is often described as a lookup process. In reality, this characterization understates the architectural innovation that makes the network scalable and decentralized.

Peppol does not use DNS merely as a directory. It uses DNS as the routing fabric itself.

A participant identifier is transformed using a cryptographic hash into a deterministic DNS name. This hash becomes a globally unique routing key that any Access Point can compute independently, without prior coordination, configuration, or centralized knowledge of the recipient.

This approach eliminates the need for a central routing database. Instead, it leverages DNS — one of the most resilient and globally distributed systems ever built — as the routing layer for business document delivery.

The use of cryptographic hashing also preserves privacy. The resulting DNS name reveals nothing about the original participant identifier, preventing passive enumeration while still allowing deterministic resolution.

The result is a decentralized, privacy-preserving, and globally scalable routing system built entirely on standard DNS infrastructure.

Peppol effectively transforms DNS into a cryptographic routing namespace, enabling any Access Point to route documents to any participant in the world without prior relationships or centralized coordination.

SML — The Centralized “Phone Book” Pointer

The SML is the network’s single root registry, but it is not involved in runtime discovery (operated under the governance of OpenPeppol and runs on infrastructure provided by the European Commission’s eDelivery BDMSL service). It doesn’t store full details; it just maps a participant’s unique ID (e.g., schemeID + value like iso6523:0191:123456789) to the URL of their chosen SMP.

How? It uses DNS in a non-obvious way. The participant ID is hashed (MD5 historically, now SHA-256 per current specifications), and turned into a special subdomain under e.g., acc.edelivery.tech.ec.europa.eu. A sender’s Access Point does a standard DNS lookup (no fancy API calls), gets the SMP hostname back. This leverages DNS’s global speed, redundancy, and caching while keeping the system decentralized in feel.

SMP — The Detailed Capability Directory

Once you have the SMP URL, query it (REST interface) for the participant. The SMP returns signed XML metadata: supported document types (e.g., Peppol BIS Billing 3.0), transport profile (usually AS4), endpoint address/URL of the recipient’s Access Point, and sometimes activation status or redirects.

This is where hidden complexity explodes

And these are just a few examples of the many gotchas that could derail an implementation:

• Participant ID schemes — dozens supported (ISO 6523 ICD list), each with validation rules. Wrong scheme? Discovery fails silently.
• Multiple profiles per participant — A company might support 10+ document types, each with process identifiers, extension possibilities.
• Redirects and migrations — Participants can switch SMPs; old metadata must be cleaned, or stale caches cause delivery failures.
• Signing and security — SMP responses are XMLDSig-signed (now SHA-256 required post-1.3 updates); invalid signatures block the whole chain.
• Caching pitfalls — Access Points cache results for performance, but expiration, revocation, or changes mean you must detect and refresh — or send to the wrong place.

Visualizing the Flow

The visualization below shows what happens from initial query to the point of sending:

• Sender obtains Recipient ID → generates Hash
• DNS query to SML → SMP URL returned
• SMP Lookup → Signed metadata with AP endpoint
• Verify SMP signature and validate AP certificate
• Ready to send (via AS4) to recipient’s Access Point

The actual document transmission (AS4 protocol, encryption, signatures, receipts) is a whole other layer of complexity — a topic for an upcoming post.

Any break — DNS propagation delay, SMP downtime, hash mismatch, expired cert — breaks delivery. No fallback routing exists by design (decentralized resilience).

Why the “Hidden” Complexity Matters

• For implementers — Building or integrating an Access Point? You must handle DNS quirks, XML parsing, signature validation, error codes from SML/SMP.
• For businesses — “Why isn’t my invoice arriving?” Often traces back to discovery misconfiguration, not the document itself.
• Scalability & global reach — As Peppol expands (Asia, Australia, etc.), more SMPs, more IDs, more edge cases.

In a world pushing real-time e-invoicing mandates, this elegant DNS+SMP dance keeps Peppol interoperable without a monolithic hub. But master it, and you unlock truly borderless B2B exchange. Or ignore it, and spend days debugging why invoices vanish into the void…

Want to Go Deeper?

The discovery mechanism described in this article is based on the official Peppol specifications. Use the links below to get more information:

• OpenPeppol Interoperability Framework
• Peppol eDelivery Network SMP Specification v1.4.0
• Peppol Service Metadata Locator (SML) v1.3.0
• Peppol AS4 Profile v2.0.3
• Node42 Discovery API
• Node42 Web UI