Key PEPPOL concepts
An overview of the key components within the PEPPOL network, explaining their roles and interactions in the context of e-document exchange.
PEPPOL includes a variety of elements:
- OpenPeppol
- A non-profit international association that governs the PEPPOL network. It was established in 2012 to maintain and develop the PEPPOL framework after the initial project, funded by the European Commission, was completed. OpenPeppol is responsible for setting the rules, standards, and governance model that ensure the interoperability and security of the PEPPOL network on a global scale, providing overall governance and global coordination. In addition, it acts as a PEPPOL Authority if a country doesn't have one.
- PEPPOL Authority (PA)
- A designated entity within a specific country that manages the local implementation and oversight of the PEPPOL network. Each PA is responsible for ensuring the PEPPOL framework is adapted to meet national or regional requirements, particularly in areas such as e-invoicing and public procurement. Certification and Supervision of Service Providers in their region is another main role played by PAs. They ensure that Service Providers adhere to local and PEPPOL-wide technical and security standards, guaranteeing a trustworthy network for document exchange.
- Service provider
- An entity that serves as an intermediary for companies around the world to send and receive e-documents through the PEPPOL network. Each service provider must be certified by OpenPeppol to be able to participate in the network. In addition, they need to be accredited by a PA to operate in certain countries, which is typically related to the PINT format. As a service provider, Sovos offers both an Access Point (AP) and a Service Metadata Publisher (SMP) solution, except for countries where a local SMP is required.
- Access Point (AP)
- A solution, offered by a service provider, which each participant chooses to deliver and receive electronic documents.
- Service Metadata Locator (SML)
A single central database owned by OpenPeppol, used to register and search for SMPs. Implementation-wise, the SML is a DNS service, so all recipients on the PEPPOL network are added as a DNS entry (by a hash of their PEPPOL identifiers, such as their Chamber of Commerce number) to this service, and this DNS entry points to the correct SMP.
- Service Metadata Publisher (SMP)
- A decentralized registry service that registers participants in SML and stores and publishes detailed information about PEPPOL network participants, including:
-
Globally unique identifiers known as participant IDs
-
Supported document types and business processes
-
Endpoint URL and Public key certificate from the receiver's service provider
-
- SMP profile
- An open specification for publishing service metadata within a four-corner network. This metadata contains information as to the types of documents the recipient's service provider is capable of handling and the supported methods of transport. The recipient makes this metadata available to other entities in the network through an SMP service.
- PEPPOL Participant ID
-
Also known as the PEPPOL identifier or PEPPOL participant identifier, this ID is a unique identification assigned to organizations or individuals participating in the PEPPOL network.
Typically a combination of numbers and letters, it forms a unique code that distinguishes each participant in the PEPPOL network. This ID, used in conjunction with other information, such as the participant's SMP details, facilitates the secure and accurate exchange of electronic documents.
PEPPOL provides a directory where it is possible to search for a specific participant ID or name of a company. In case a participant chooses not to be listed, they'll still be visible in the lookup process (SML or SMP). This portal uses the available PEPPOL API to find the list of results.
The PEPPOL Participant ID format consists of three parts:
- Participant identifier meta scheme
- As defined by policy five from the Policy for use of identifiers document, this is the PEPPOL participant identifier meta scheme:
iso6523-actorid-upis. This value is always case-sensitive. - Numeric code for identifier scheme
- The numeric ISO 6523 code set, used within PEPPOL, includes additional values not part of the official ISO 6523 set. Codes beginning with "99" extend this code set and are called "extended values." Although the term "ISO 6523" is used for all codes, it indicates the origin of many code values used in PEPPOL. See the participant identifier schemes code list).
- Identifier according to the scheme
- This is the participant identifier value, structured according to the indicated scheme.
- Public Key Infrastructure (PKI)
- An infrastructure used by PEPPOL to establish and maintain a trusted network that ensures the security and integrity of all messages exchanged over the PEPPOL network.
- PEPPOL Interoperability Framework
- For buyers and suppliers to successfully exchange electronic business documents across the PEPPOL network, a set of rules and specifications must be consistently applied by PEPPOL Authorities and PEPPOL-certified Service Providers.
These rules and specifications are provided through the PEPPOL Interoperability Framework, which provides both governance and architecture frameworks that incorporate legal agreements, policies, requirements, and specifications. Together, they support business process interoperability for the exchange of business documents between buyers and suppliers across sectors and borders.
Formal legal agreements ensure that organizations involved in the PEPPOL network act together in a trusted environment:- PEPPOL Authority Agreement
- An agreement between OpenPeppol — acting as the PEPPOL Coordinating Authority — and a PEPPOL Authority.
- PEPPOL Service Provider Agreement
- An agreement between a PEPPOL Authority and a Service Provider.
Note: The roles and responsibilities of each actor operating in the PEPPOL network are fully described in these agreements, providing an open and transparent community. These arrangements ensure that the technical specifications and business-level rules are consistently applied throughout the network. - Four-corner model
- In a typical usage of the PEPPOL network, messages are securely distributed between buyers and suppliers using their four-corner model:
- Sender Corner (C1)
- This corner represents the sender or the supplier providing goods or services. The seller issues an electronic invoice in the format agreed with the C2.
- Sender's Service Provider (C2)
- This corner represents the technology or system used by the sender to handle electronic documents. It is responsible for creating, validating, and sending electronic invoices in a supported PEPPOL format, declared by the C4 in the SMP registration. After connecting to the SML to look up the address of the SMP used by C3, it connects to the SMP used by C3 to look up the capabilities of the receiver.
- Receiver's Service Provider (C3)
- This corner represents the technology or system used by the receiver to handle electronic documents. It receives the electronic invoice, validates it, and integrates it into the receiver's financial or Enterprise Resource Planning (ERP) system.
- Receiver Corner (C4)
- This corner represents the receivers of the goods or services. In the context of e-invoicing, the receiver's corner is responsible for receiving and processing electronic invoices.
- Five-corner model
-
Also known as PEPPOL Continuous Transaction Controls (CTC), this is a hybrid model that adds a governmental platform as the fifth corner, placed between the supplier's and the buyer's Service Providers. This model consists of:
-
Real-time or near real-time information transmission to tax authorities.
-
A decentralized CTC model with regulated document exchange.
-
A document exchange flow that doesn't end with the service provider, as they must also send the documents to the central fiscal platform.
-
The governmental platform can validate the documents using two methods:
-
Assigning a unique identifier to each invoice before sending the invoice to the recipient.
-
Delegating the validation of documents to certified Service Providers and only acting as a repository for invoices.
-
-