With more and more countries implementing e-invoicing rules and regulations, Peppol’s usage is spreading rapidly. While some countries have mandated the use of independent national e-invoicing systems and processes, the majority of European countries now promote the use of Peppol at one level or another. This popularity, combined with Peppol’s ability to simplify B2B and B2G transactions, has meant that Peppol compatibility is quickly becoming a must-have for forward thinking supply chain organisations.
In this article we explore some of the technical aspects of Peppol – namely the three types of message response supported by Peppol, Peppol transport acknowledgements, message level responses and business level responses. Looking at each one by one, we’ll examine what they do, how they work and how they differ from one another. To skip to a particular section, please click the relevant section heading below:
- Peppol’s four corner model
- Transport Acknowledgements (Acks)
- Message level responses (MLRs)
- Business level responses (invoice responses)
If you would like a more general overview of what Peppol is and the benefits it can offer, please find our downloadable white paper “Peppol: What You Need To Know”.
The structure of the Peppol network
Before we jump into the three different types of Peppol message responses, it is first important to understand the underlying network structure behind Peppol. This is known as the four corner model.
The “four corners” of this network model refer to
- the message sender,
- the message sender’s Peppol access point,
- the Peppol access point of the message recipient, and
- the message recipient themselves
This arrangement is fundamental to Peppol message exchange as, along with strict rules regarding which standards and protocols can be used, it makes message exchange as simple as possible. The easiest way to understand the benefits is by comparing to the alternative models:
The two corner model
With direct automated message exchange (AKA a two corner model) each connection requires time-consuming set-up by inhouse IT teams or an external consultant. Connections are not reusable for multiple partners, meaning every new partner requires a completely new setup.
The three corner model
In a three corner model on the other hand, message routing is done via a central service provider hub. Though this may be preferable to a two corner model, it still lacks flexibility, as both sender and receiver must have the same service provider, making it badly suited to large supply chains. In addition this model typically results in one of the parties being forced into a contract with the service provider of their partner.
The four corner model
By contrast, Peppol’s four corner model doesn’t require unique point-to-point connections or for both parties to use the same provider.
Once a connection to an access point has been established, the Peppol Participant ID is sufficient to send an electronic message to any Peppol partner of choice (and be reached by other Peppol-connected companies). Message validation is handled by the sender’s access point and both sender and receiver’s access points can access a service metadata locator (SML) and service metadata publishers (SMP) as required.
How Peppol message responses fit in
To help provide a framework for understanding the more detailed descriptions of each Peppol message response type below, this diagram shows how they fit into the four corner model. All messages and acknowledgements are exchanged via the access points of the sender and the receiver. The dashed arrows indicate, to which component of the exchange infrastructure an acknowledgement or a response message belongs to.
A transport acknowledgement is the most basic type of confirmation and is an integral part of Peppol’s AS4 protocol. Message level responses are generated by the receiver’s messaging system and are intended for the sender’s messaging system. Finally, a business level response is intended to be processed by the sender’s ERP system.
Now let’s examine each, starting with transport acknowledgements…
1) Transport acknowledgements
What is a transport acknowledgement (Ack)?
A transport acknowledgement is an electronic receipt sent from the receiving access point (C3) to the sending access point (C2) following the transmission of a structured message such as an invoice. The acknowledgement notifies the sending party if technical delivery was successful and can include relevant information such as why delivery of a message was unsuccessful. Importantly, however, acknowledgements do not say anything about the validation of the message or whether the contents were correct, for example.
In Peppol, communication takes place via the protocol AS4 (previously AS2). Acknowledgements are a key feature in AS4 communication, where an acknowledgement is referred to as a SignalMessage.
There are three types of SignalMessage:
- SignalMessage/PullRequest (not used in the context of Peppol)
What does a Peppol acknowledgement achieve?
Transport acknowledgements help to enforce data integrity and non-repudiation. In simple terms they clarify that a message has definitely been received and ensure that the recipient can’t deny receipt of that message.
In turn, this helps to speed up partner communication and make transactions more transparent.
A breakdown of the process
Essentially it works like this:
- The sender assigns the outgoing message a unique ID (this happens automatically by the sender’s access point)
- Once the outgoing message is received by corner three access point, the SignalMessage (Peppol acknowledgement) is returned. This message has a unique ID as well and carries a reference to the message it acknowledges. Thereby, a SignalMessage can carry a positive or a negative acknowledgement. Positive acknowledgements are submitted using SignalMessage/Receipt and negative acknowledgements are submitted using SignalMessage/Error.
2) Message level response (MLR)
Arguably the most important part of automated message exchange is message validation – i.e. where a message is checked against the agreed specifications (syntactical and semantic).
In Peppol, message level responses, or MLRs, serve to inform the sender of the success (or otherwise) of validation. Helpfully, in the case of failure, these messages also detail what went wrong, such as a specific syntax error relating to a missing closing tag. It is important to note that MLRs will not identify if a certain value is correct in the context of a certain message, but merely that it is in accordance with the agreed specifications. For example, an MLR would not notify you if an article number was wrong, but would alert you if an article number is missing (for a full rundown of what errors a message level response is capable of alerting you to, please check the external article “BIS Message Level Response 3.0”).
MLRs can communicate three things to the sender of the original message:
- The message contained errors and failed validation.
- The message did not contain errors and passed validation.
- The message has been received, but is not yet validated.
Technically MLRs are returned using UBL Application Response 2.1 messages.
3) Business level response
What is a business level response (AKA invoice response)?
The final Peppol message response type is the business level response and is used to inform the sender of a message about the status or outcome of corner four processing the message. In the case of invoices the business level response is called the invoice response message and could for instance contain a rejection, because the referenced purchase order number in the invoice is invalid.
In general an invoice response message supports the following status codes:
- AB – basic message acknowledgement
- AP – accepted
- RE – rejected
- IP – in progress
- UQ – under query
- CA – conditionally accepted
- PD – paid
While Peppol BIS does not require corner four to support all these codes, the first three (AB, AP and RE) must be supported as a minimum. Peppol BIS also requires that the initial sender (AKA corner one) must receive this response within three working days.
How a business level response works and what it looks like
In the event that an invoice is rejected (RE), put under query (UQ) or conditionally accepted (CA), corner four must provide information to help corner one resolve the issue. Status Reason codes and Status Action codes provide a means of doing this. Detailed information can also be added via a free text field which is supported by Peppol.
Like a message level response, a business level response is also based on a UBL Application Response 2.1. The following snippet shows an exemplary invoice response.
Want more information?
At ecosio we are experts in Peppol and e-invoicing and were one of the very first Peppol Access points in Europe. To date we have helped hundreds of companies to integrate efficient e-invoicing processes into existing systems and experience the benefits of Peppol.
For more information on Peppol please feel free to get in touch with our experts via our chat or our contact form. We are always happy to help!
Have you tried our free XML/Peppol document validator?
To help those in need of a simple and easy way to validate formats and file types, from CII (Cross-Industry Invoice) to UBL, we’ve created a free online validator.