Peppol Message Responses - A Helpful Guide

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 five-corner model (also pictured below).

The “five corners” of this network model refer to

1. The supplier
2. The supplier’s access point
3. The buyer’s access point
4. The buyer
5. The tax authority

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.

For more information on Peppol’s five corner model and the benefits it offers, please see our dedicated article on this subject.

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.

Where message responses fit in

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/Receipt
• SignalMessage/Error
• 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:

1. The sender assigns the outgoing message a unique ID (this happens automatically by the sender’s access point)
2. 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:

1. The message contained errors and failed validation.
2. The message did not contain errors and passed validation.
3. 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:

1. AB – basic message acknowledgement
2. AP – accepted
3. RE – rejected
4. IP – in progress
5. UQ – under query
6. CA – conditionally accepted
7. 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.


Business level response example (click for larger version)

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.