This is an very short technical overview of PEPPOL, and how parties to connect to the PEPPOL network and exchange business documents. To fully discuss all the ins and outs of everything PEPPOL goes beyond the scope of this article, but it should give you a very general view of the main components that are involved.

From a very high viewpoint, PEPPOL defines two core concepts: how to format documents so that they can be processed automatically, and how to exchange those documents between senders and receivers.

Let’s start with the second one.

Transport

The four corner model

A party (Corner 1) wants to send a document, such as an invoice, to a different party (Corner 4). The sending party gives this document to its service provider (Corner 2) for sending. The service provider sends the document over the PEPPOL network to the service provider of the receiving party (Corner 3).

PEPPOL defines the protocol(s) that are used in this exchange between corners 2 and 3. Currently, this is done through AS4 (or rather a subset of AS4: PEPPOL Specification). Before AS4 became mandatory, the protocol that was used was AS2 (RFC4130) which you may still see in use. Before that, it was START, but use of START should be completely phased out now.

Access points

The systems that execute this protocol for sending and receiving documents are called Access Points; there are several implementations of these access points available, both as propietary software and as open source software. One of the wider-used open source implementations is Oxalis.

The messages that are exchanged with this protocol are signed (and/or encrypted) with a certificate that can be obtained from PEPPOL. This way, it is guaranteed that the service providers are PEPPOL members, and have signed the relevant agreements (to name a few, that they will conform to the specifications, and that they will not send falsified documents over the network).

How communication between corners 1 and 2, and 3 and 4 is done is considered of of scope of the PEPPOL agreements, except for a few non-technical requirements, such as that this communication is done securely, and that it is verified that corners 1 and 4 are the parties they claim to be. It is up to the service providers how to do this, and how to implement this communication.

For example, a possible method a service provider could use is that their customers provide them with fully formed documents in the correct format over SFTP, which can then be sent directly from the service provider’s access point to the access point of the receiving srevice provider. On the other end of the spectrum, the service provider could also have a tight intergration with the ERP system of the sending party, retrieve the necessary information to create the document itself, and then send it to the receiving party in a format that they support.

Similar ways of working could be used on the receiving end, but of course, direct processing into the ERP system of the receiving party provides the most advantages that electronic invoicing brings.

Service Metadata Providers

One significant part that is then still missing is how to find out whether the receiving party is connected to the network, who their service provider is, where their access point is located, and what documents they support. This is done via Service Metadata Providers (SMPs), which can be run by the service providers themselves, but they can also use one of the central SMPs for this. For more information on how the role of SMPs, see the documentation on ion-SMP.

 

That should be about it for the high-over view of the transport, which leaves us to the document format(s).

Document formats

The transport itself is format-agnostic; in theory you could exchange any document in any form, but of course both parties should know the format of the documents, and how to interpret what the documents contain. That is why PEPPOL defines a number of specific document formats that parties can be used, and a way to extend this list for specific sectors or countries.

PEPPOL BIS v3

The default format is PEPPOL BIS version 3. PEPPOL BIS v3 contains, amongst others, format for invoices, credit notes, and orders. There are specifications for UBL 2.1 and UN/CEFACT, but UBL is the default. PEPPOL BIS v3 is a CIUS of European Norm 16931

These are somewhat mandatory; you do not need to support every type of document (for instance, you could only support invoices), and you are allowed to support other documents that those in PEPPOL BIS v3, but if any document you support is of a type that is also defined in PEPPOL BIS, you MUST also support the PEPPOL BIS equivalent. This can mean that you might need to support multiple formats of the same type. For example, in the Netherlands, the most widely used format is SI-UBL 2.0 Invoice, as this format was specifically defined for the Dutch market by the Dutch e-invoicing community (STPE). Since there is an equivalent in PEPPOL BIS v3, it means that in practice all Dutch service providers should support both SI-UBL 2.0 and PEPPOL BIS v3 invoice.

Recipients on the network publish which documents they can process through their entries in their SMP. There, potential senders can find whether the document they wish to send is supported by the recipient.

Creating and processing documents

Just as with transport, there are no strict requirements whether is is corner 1 or 2 that puts the document in the correct format, as long as what is sent between corners 2 and 3 is in the correct format and does not contain false information. So a service provider could agree with their customers that the customers provide them with documents that are fully formed, so that they can send it directly. They could also agree that the customers only provide them with the relevant contents (in any reliable way), and that the service provider generates the correct format (UBL/PEPPOL BIS/etc.). The same goes for receiving service providers; where and how the integration between the receiving access points and the ERP systems of the receiving parties is done is up to the receiving service providers and their customers. Provided, again, that certain requirements are fullfilled, such as that documents should not get lost between corners 3 and 4.

Conclusion

This was a quick run-through of PEPPOL, in which I have intentionally skipped over a number of things, and probably unintentionally left out quite a few more. However, I do hope that this article has given you a better view of what PEPPOL entails, as a starting point when starting to implement e-invoicing.