Peppol Network: A Catalyst for Digital Commerce

The digitization of financial processes is accelerating. While organizations have traditionally relied on email, portals, and individual system integrations for document exchange, they quickly run into limitations as they grow. Email offers broad reach but little standardization or control. Direct API and EDI integrations are reliable but can become costly when a separate connection must be set up and maintained for each trading partner.

Peppol offers an alternative: a single international infrastructure for the secure and standardized exchange of electronic business documents. An organization connects through a certified Peppol Service Provider and can communicate with other connected organizations via that connection. OpenPeppol summarizes this principle as: connect once and reach all accessible participants.

Peppol is being used in an increasing number of countries as the infrastructure for e-invoicing and digital commerce. Belgium uses the network as the standard for mandatory domestic B2B e-invoicing. Countries such as Singapore, Australia, New Zealand, Japan, and Malaysia have also incorporated Peppol into their national e-invoicing policies. However, the way Peppol is implemented and the legal requirements associated with it vary by country.

What is Peppol?

Peppol is not a software package, an invoicing portal, or a standalone file format. It is an international framework for electronic document exchange. It combines technical specifications, document standards, addressing, security, and governance.

Among other things, the network determines:

• how senders and recipients are identified;
• how it is determined which documents a recipient supports;
• how a message reaches the correct Access Point;
• how Access Points authenticate each other;
• what requirements apply to documents and processes;
• how Service Providers and national Peppol Authorities collaborate.

For organizations, this means they do not have to set up a completely new technical infrastructure for every customer or supplier. Their own Service Provider handles the connection to the network and the routing to the trading partner’s Service Provider.

Peppol can be integrated directly into an ERP, accounting, invoicing, or workflow solution. As a result, users usually do not need to work in a separate Peppol portal for the daily sending and receiving of documents.

The Power of Standardization

The value of Peppol lies in the combination of technology, processes, and governance.

Technically, the network offers a standardized transport mechanism, centralized addressing, dynamic routing, and secure transmission between Access Points.

In terms of processes, Peppol defines standards for documents such as invoices, credit memos, orders, order confirmations, and shipping notices.

Strategically, the network enables scalable document exchange across different countries, sectors, and software packages.

What began as a European initiative for electronic government procurement and B2G invoicing is now used worldwide for both public and private document exchange. Peppol supports not only invoices but also other documents within procurement, sales, and logistics processes.

Architecture and the Quadrilateral Model

At the heart of Peppol is the four-corner model. A document is not sent directly from the sender’s system to the recipient’s system, but rather via two certified Service Providers.

The four corners are:

1. the sender;
2. the sending Peppol Access Point;
3. the receiving Peppol Access Point;
4. the recipient.

The sender submits the document to its own Service Provider. The Service Provider uses the Peppol addressing structure to determine where the document should be delivered and then sends it to the recipient’s Access Point. The receiving Access Point delivers the document to the recipient’s system.

This architecture prevents a proliferation of bilateral connections. An organization does not have to renegotiate transport protocols, security agreements, and technical addresses for every new trading partner.

SML, SMP, and Dynamic Routing

Addressing within Peppol is supported by the Service Metadata Locator and Service Metadata Publishers.

The Service Metadata Locator, usually abbreviated as SML, forms the central location layer. The SML helps determine in which SMP a participant’s reception capabilities are published.

A Service Metadata Publisher, or SMP, contains information about a connected recipient. Among other things, it specifies:

• which Access Point the participant can be reached via;
• which document types are supported;
• which business processes can be handled;
• what technical delivery information must be used.

When an Access Point needs to send a document, this data is retrieved dynamically. As a result, the sender does not have to manage all the technical delivery addresses of customers and suppliers themselves. The combination of SML, SMP, and Peppol PKI supports dynamic and secure transmission between Access Points.

Accurate participant registrations remain essential in this process. An incorrect identification number, a missing document type, or an outdated registration can prevent a document from being delivered.

Document Standards and Validation

Peppol not only describes how a document is transmitted but also how its content is structured. Various standards and specifications play a role in this process.

UBL

Universal Business Language, or UBL, is an XML-based syntax for electronic business documents. Within Peppol, UBL is used for invoices, credit memos, orders, and shipping notices, among other things.

UBL defines the technical structure of the message: how data fields, elements, and their relationships are defined in the XML file.

EN 16931

EN 16931 is the European standard for the semantic data model of the core electronic invoice. The standard describes what data an invoice contains and what that data means.

The standard does not automatically make an invoice legally valid. National VAT legislation, mandatory invoice data, archiving requirements, and other tax regulations remain relevant for this purpose. EN 16931 does, however, ensure that different systems can assign the same meaning to data such as invoice numbers, tax amounts, payment terms, and party details.

Peppol BIS

Peppol Business Interoperability Specifications, abbreviated as BIS, translate business processes and standards into concrete agreements for the Peppol network.

Peppol BIS Billing 3.0, for example, is an implementation of EN 16931 for invoices and credit memos. In addition to the data structure, the specifications include business rules, code lists, and validation rules.

This allows a document to be checked for syntactic and semantic correctness before it is processed in a financial workflow. Validation reduces the risk of missing or incorrectly used data, but does not automatically guarantee that every invoice is also correct in terms of content, commercial accuracy, and tax compliance.

CIUS and National Rules

Countries and sectors may impose additional requirements via a Core Invoice Usage Specification (CIUS). A CIUS modifies or refines the European core standard to comply with local legislation and processes.

As a result, not every invoice that technically complies with EN 16931 is automatically suitable for every national application. For example, countries may require additional identification numbers, tax codes, or validations.

PINT

For international use, OpenPeppol developed the Peppol International Invoice, abbreviated as PINT. PINT has been available since July 2023 and serves as a common model on which countries can base their own invoice specifications.

PINT reduces the need to develop a completely separate invoice model for every market. It provides a shared core, with room for local tax and organizational requirements. There are now PINT implementations for various countries and regions, including Australia and New Zealand, Japan, Malaysia, Singapore, the United Arab Emirates, and the European Union.

So PINT does not mean that exactly the same invoice can be used everywhere. It ensures that national implementations are built on a common international model.

From Invoices to Complete Document Workflows

Peppol is often associated primarily with e-invoicing, but it supports more document types. The current Peppol specifications include, among other things:

• invoices and credit memos;
• orders;
• order confirmations;
• order changes and order cancellations;
• catalogs;
• punch-out messages;
• shipment notifications;
• Message-Level Responses;
• Invoice Responses;
• self-billing invoices and self-billing credit memos.

OpenPeppol is also working on further support for logistics processes. Available and developed logistics documents include, among others, transport plans, waybills, weight declarations, transport statuses, and more detailed shipping messages.

This enables Peppol to support a larger portion of the purchase-to-pay and order-to-cash chain. However, practical availability varies by country, service provider, software vendor, and trading partner. The existence of a Peppol specification does not automatically mean that every recipient supports the relevant document type.

Security and Reliability

The AS4 protocol is used for transmission between Peppol Access Points. AS4 handles the asynchronous transmission of messages between the sending and receiving Access Points.

Peppol uses its Public Key Infrastructure for authentication, digital signing, and encryption at the AS4 message level. Security therefore takes place between the two Access Points. It is therefore more accurate to speak of secure transmission within the Peppol network rather than direct end-to-end encryption between the sender and the final recipient.

Certified Service Providers use Peppol certificates for their network connections. The end user generally does not need to manage a Peppol PKI certificate themselves. The Service Provider registers the organization and handles the technical connection.

In addition to the technical specifications, Peppol has a governance framework that includes agreements, operational procedures, and service requirements for Service Providers and Peppol Authorities. National Authorities may impose additional requirements in line with local legislation, regulatory oversight, and security policies.

Technical and Business Feedback

In electronic document exchange, simply knowing that a file has been sent is not enough. Organizations also want to be able to determine whether the message was technically delivered, its content could be validated, and it was accepted from a business perspective.

Peppol distinguishes between different levels of feedback.

Transport confirmation

The AS4 layer confirms the technical transfer between the sending and receiving Access Points. This allows one to determine whether the message has arrived at the transport level.

A transport confirmation does not necessarily mean that the recipient has accepted the invoice’s content or has even processed it in the financial system yet.

Message-Level Response

A Message Level Response can be used to report the outcome of document validation. This allows the recipient to indicate that the document does not comply with the agreed-upon rules, either technically or in terms of content.

Invoice Response

An Invoice Response provides information about the business processing of an invoice. For example, a recipient can use it to report that an invoice has been received, accepted, rejected, or disputed.

Not every organization or software solution supports all of these responses. Therefore, during implementation, it must be explicitly determined which statuses are available and how they are processed in the ERP, workflow, or customer portal.

Peppol, Compliance, and ViDA

In several countries, Peppol is linked to mandatory e-invoicing and tax reporting. However, this does not mean that Peppol itself is a tax platform or that every Peppol invoice automatically complies with all local tax requirements.

Furthermore, the European program “VAT in the Digital Age,” or ViDA, does not mandate the use of Peppol. Starting July 1, 2030, ViDA will introduce mandatory e-invoicing and digital reporting for relevant cross-border B2B transactions within the European Union. Member states with existing domestic real-time reporting systems must bring them into line with the European model by January 1, 2035, at the latest.

Peppol can, however, play an important role in this development. The network already offers standardized invoice data, reliable addressing, secure transmission, and international governance. OpenPeppol is also developing architectures and specifications that can support Continuous Transaction Controls and e-reporting.

The exact implementation will depend on national decisions. Some countries use Peppol as their primary exchange network, while others rely on central tax platforms or approved commercial platforms, with Peppol serving as a supplementary channel.

Governance and International Context

The Peppol framework is managed by OpenPeppol AISBL, an international nonprofit organization. OpenPeppol maintains the governance, technical specifications, document standards, and agreements for participation in the network.

A national Peppol Authority operates in various countries. It represents national interests within the network and may impose additional requirements on service providers and implementations. Examples include the Dutch Peppol Authority, BOSA in Belgium, KoSIT in Germany, the Australian Taxation Office in Australia, and IMDA in Singapore.

In countries without a national Peppol Authority, OpenPeppol itself can fulfill a coordinating role. This ensures that participation in the international network remains possible, even when national governance has not yet been established separately.

The combination of international agreements and national additions makes Peppol scalable, but also requires careful management. Organizations must not only comply with the general Peppol specifications but also take into account the regulations of the country and the process in which they exchange documents.

Connecting to Peppol

For most organizations, connection is established through a Peppol-certified Service Provider. Among other things, this provider handles:

• the connection to the Peppol network;
• registration of participants;
• publication of reception options;
• routing and secure transmission;
• management of Peppol certificates;
• monitoring and technical error handling.

OpenPeppol publishes an up-to-date list of certified Service Providers.

Organizations can integrate Peppol into their processes in various ways:

1. through accounting or invoicing software that already supports Peppol;
2. through an integration between the ERP system and an Access Point Provider;
3. via Access Point as a Service for software vendors;
4. by becoming a certified Peppol Service Provider themselves.

For end users, connecting via existing software or a specialized provider is usually the most practical option. Operating your own Access Point provides greater technical control but requires certification, infrastructure, security, monitoring, and ongoing adaptation to new specifications.

Success Factors for Implementation

An effective Peppol implementation does not begin with choosing a protocol, but with mapping out the entire document process.

Key considerations include:

• determine which legal entities need to be registered;
• verify which identification numbers are used in each country;
• start with a clearly defined document type and process;
• define which formats and Peppol profiles are supported;
• validate documents before they are sent;
• test the entire chain with representative trading partners;
• Incorporate technical errors and business statuses into the existing workflow;
• Set up monitoring, retries, and incident handling;
• define audit trails and retention periods;
• Agree on migration procedures and participant registrations in the event of a provider change;
• verify country-specific requirements and future reporting obligations.

The recipient side also deserves attention. Receiving a correct XML file is only the beginning. The data must be verified, visualized, matched, approved, posted, and archived. Only when Peppol is integrated into the financial process does structural process automation take place.

Conclusion

Peppol is more than just a transport channel for electronic invoices. It is an international framework that brings together addressing, secure transmission, document standards, and governance.

The network reduces the need for separate integrations and makes it easier to exchange structured documents with customers, suppliers, and government organizations. At the same time, Peppol is not a universal guarantee of tax compliance. Formats, national regulations, document types, and reporting requirements continue to vary by country and process.

Organizations that carefully implement Peppol not only create a channel for compliant e-invoicing but also lay the foundation for automatic validation, faster processing, better status information, and further digitization of purchase-to-pay, order-to-cash, and logistics document flows.