8 minute read

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 four corner model.

The “four corners” of this network model refer to

  1. the message sender,
  2. the message sender’s Peppol access point,
  3. the Peppol access point of the message recipient, and
  4. 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.

Peppol Message Responses - A Helpful Guide
Two corner model

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.

Peppol Message Responses - A Helpful Guide
Three corner model

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.
Peppol Message Responses - A Helpful Guide
The Peppol four corner model

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
Peppol Message Responses - A Helpful Guide

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.

White Paper - Peppol

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.

Peppol Message Responses - A Helpful Guide
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.

most read

Keep on reading

8 minute read

How External Invoicing is Changing the Game

With invoicing requirements changing fast, more and more companies are outsourcing invoicing tasks to an external provider. Find out why!

8 minute read

ViDA: What Is It and How Will It Affect You?

What is ViDA, what changes will it bring and who will it impact? In this article we explore all of these questions and more.

9 minute read

Selecting an E-invoicing Software

Choosing an e-invoicing software can be tricky. In this article we explore how options differ and the benefits a good solution can deliver.

8 minute read

E-invoicing in Romania

In this article we dive into Romanian e-invoicing regulations and how you and your team can prepare for the upcoming changes.

7 minute read

Explore the Latest in German E-Invoicing: Mandatory Implementation in B2B Sector starting from 2025

E-invoicing in Germany will soon become mandatory for B2B transactions. Make sure your business is ready for the upcoming changes.

21 minute read

What is an E-invoice and How Does E-invoicing Work?

Learn how e-invoices work and the many ways that e-invoicing can benefit your business in our comprehensive guide.

4 minute read

Belgium E-invoicing Developments on the Horizon

Belgium has begun rolling out B2B e-invoicing and e-reporting via a phased approach. Is your business prepared?

4 minute read

E-invoicing in Serbia

E-invoicing in Serbia is now mandatory for all B2B transactions. Read our article to learn what compliance involves.

2 minute read

New FatturaPA Specifications Introduced

New FatturaPA specifications (version 1.7.1) will be available from 1 October 2022. See what the changes are and what this means for you.

5 minute read

E-invoicing and Peppol in Japan

E-invoicing in Japan via Peppol will soon become the norm. In this article we explore the recent developments and what they mean for you.

6 minute read

B2G and B2B E-invoicing in Poland at a Glance

The VAT gap has been a topic of particular interest for Polish authorities in recent years. In this article we explore the B2G and B2B invoicing regulations they are using...

5 minute read

B2B E-invoicing in Poland - Key Facts and Deadlines

Updated on an ongoing basis, this article covers all the relevant details and dates concerning B2B electronic invoicing in Poland.

We use cookies to provide an optimal website experience. You decide which one you want to allow. Depending on the setting, however, not all functionalities may be available to you. Data protection & imprint.

WHITE PAPER

E-invoicing in Europe: State of Play

*Mandatory fields