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.


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.


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.

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

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.

Der Beitrag Peppol Message Responses – A Helpful Guide erschien zuerst auf ecosio.

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.


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.


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.

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

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.

Der Beitrag Peppol Message Responses – A Helpful Guide erschien zuerst auf ecosio.

In this article we’ll explore the importance of XML document validity and how simple it is to integrate an XML checker into your system to enable you to start experiencing more of the benefits of supply chain document exchange automation.

Why is validity of e-documents so important?

As XML is machine-readable rather than human readable (see the example UBL order below), it is difficult to tell without the aid of a validation tool whether an XML document has been structured and populated correctly.

Example of a UBL order

Those who want to delve deeper into the logic behind XML validation can find a useful tutorial series here.

Without a system for checking that XML documents are valid, the structured documents exchanged with partners may well contain errors.

In turn, these errors can prove both time-consuming and costly to fix. Even if the error is immediately spotted, simply getting hold of the relevant person at the other end can be a challenge, while pinpointing exactly what needs to be amended in order to resubmit the message successfully can also be tricky. Worse still, the error may not initially be spotted if validation systems are not in place, which can lead to more complex issues requiring even longer and labour-intensive resolutions. This can end up costing a business dearly, not only in terms of the resource cost, but also through damaging partner relations.

Further, over the last decade many countries (particularly those in Europe) have begun to introduce strict regulations concerning the exchange of structured business documents. As many of these new regulations concern B2G e-invoicing and the digitisation of tax reporting, the consequences for non-compliance can be significant. For example, in Ireland, companies can be fined over €1,500 for each incorrect invoice, plus an additional personal fine of €950. Meanwhile in Sweden, non-compliance with e-invoicing regulations (deliberate or not) can result in up to two years in prison! Even in countries with less severe penalties, however, simple errors such as the incorrect VAT number on an invoice/invoices can result in massive financial repercussions, as such a mistake will make the recipient ineligible for VAT for the relevant transactions.

So what is validation?

XML validation is a process whereby XML documents can be checked instantly by software to confirm that they have been constructed and populated correctly.

Validity of an XML document means:

• Logical formatting
  An XML document is well formed if it adheres to the XML syntax rules. E.g. it only contains valid Unicode characters, elements are property closed, etc.
• Schema-conformant
  An XML document is schema-conformant if all rules in the associated XML Schema (e.g, a UBL invoice Schema) are fulfilled.
• Schematron-conformant
  An XML document is schematron-conformant if all rules of the associated Schemtatron file are fulfilled.

This is particularly useful in two scenarios:

1. When connecting to new partners: Without a validation tool, a constant back and forth is required between the two businesses wishing to establish an EDI connection to ensure that messages are coming through correctly during testing. With an integrated XML checker, however, it is possible to remove the dependence on the other party for feedback during the testing phase. Instead, the sender sees instantly if their document is formatted correctly and can make the necessary adjustments straight away, saving both parties time, money and stress.
2. During ongoing EDI operation: In addition to proving useful during the testing stage of partner onboarding, validation should ideally be the final step in every XML document creation process. As changes are constantly being made to live IT environments – both systems and processes – it is important to ensure that this doesn’t disrupt the accuracy of the XML documents generated. The only reliable and efficient way to ensure this is by integrating an XML checker as a final internal step. This way you can be sure that you never send an incorrectly formatted document – which as we have explored can have significant consequences.

What does a comprehensive XML checker provide?

While the exact monetary value of integrating an XML validator is hard to quantify, as it is impossible to predict how many errors you would experience without one, and how costly they would be, the benefits an XML checker can provide are clear. ecosio’s XML validation tool, for example, offers the following key advantages:

• Simple error descriptions – Non-technical and easy-to-understand error messages allow issues to be resolved by non-experts, minimising the chance of bottlenecks.
• Shareable test report – For those who wish to share test reports with colleagues etc., ecosio’s validator generates a concise, downloadable report.
• Zero maintenance – As the tool is maintained by ecosio, there is no need to install any updates or adjust the tool in-house. All necessary changes will be made to the tool directly by ecosio, with zero disruption to your business.
• Simplification of message exchange testing – Both parties save valuable time and money during onboarding as the need for bilateral testing is reduced.
• All major XML document types covered – From Cross Industry Invoice (CII) to Universal Business Language (UBL) file formats, ecosio’s tool covers all common XML file types.
• One click for all formats – The validation tool is as easy to use for complex XML file types as for the most basic ones. All that is required is a single click!
• Clear and unambiguous versioning

The full list of the XML document types that ecosio’s validator tool can check is located on the online tool page.

Before and after implementation – a comparison

Let’s look at how the installation of a validation tool can optimise EDI processes in practice by considering the same example with and without an XML checker. Imagine you wish to send an invoice to one of your partners using the European e-Invoice standard EN 16931 (let’s assume that you sent a Universal Business Document file, though a Cross Industry Invoice would also be feasible).

Without an integrated XML checker:

• Invalid characters could “sneak” into the document. This is typically a master data issue, if for example the business copy and pastes something in a header text or an item description.
• A change in one of the generating routines in the ERP could alter the namespace string, leading to an invalid XML.
• A missing master data entry could lead to a VAT-ID being missing in the XML document, which leads to non-VAT-deduction – depending on the invoice amount.

With an integrated XML checker:

• It is still possible for the things above to occur, but at least you will notice them before your business partner does.

How do I implement a validation tool into my system?

As with many software adjustments, there are two main options for companies looking to integrate an XML checker into their system – A) handle integration in-house, or B) outsource to the experts. The second of these options offers the far simpler option, not least because the first is likely to require the construction of the tool itself as well as its integration into your system.

At ecosio (as with our wider EDI solution) we offer integration of our comprehensive tool via an API connection. This way the tool is embedded directly in your existing ERP system. There is no requirement to navigate to another platform etc. Further, with such a connection you do not need to install updates when the tool is adjusted. Instead, the tool is updated centrally, meaning your validator is always up-to-date and reflects the most recent XML rule sets.

For more information on how to integrate ecosio’s XML checker into your system, or to find out more about the benefits this tool could offer your business in particular, contact us today. We are more than happy to answer any questions you have!

Der Beitrag Integrating an XML Checker into Your ERP System erschien zuerst auf ecosio.

In this article we’ll explore the importance of XML document validity and how simple it is to integrate an XML checker into your system to enable you to start experiencing more of the benefits of supply chain document exchange automation.

Why is validity of e-documents so important?

As XML is machine-readable rather than human readable (see the example UBL order below), it is difficult to tell without the aid of a validation tool whether an XML document has been structured and populated correctly.

Example of a UBL order

Those who want to delve deeper into the logic behind XML validation can find a useful tutorial series here.

Without a system for checking that XML documents are valid, the structured documents exchanged with partners may well contain errors.

In turn, these errors can prove both time-consuming and costly to fix. Even if the error is immediately spotted, simply getting hold of the relevant person at the other end can be a challenge, while pinpointing exactly what needs to be amended in order to resubmit the message successfully can also be tricky. Worse still, the error may not initially be spotted if validation systems are not in place, which can lead to more complex issues requiring even longer and labour-intensive resolutions. This can end up costing a business dearly, not only in terms of the resource cost, but also through damaging partner relations.

Further, over the last decade many countries (particularly those in Europe) have begun to introduce strict regulations concerning the exchange of structured business documents. As many of these new regulations concern B2G e-invoicing and the digitisation of tax reporting, the consequences for non-compliance can be significant. For example, in Ireland, companies can be fined over €1,500 for each incorrect invoice, plus an additional personal fine of €950. Meanwhile in Sweden, non-compliance with e-invoicing regulations (deliberate or not) can result in up to two years in prison! Even in countries with less severe penalties, however, simple errors such as the incorrect VAT number on an invoice/invoices can result in massive financial repercussions, as such a mistake will make the recipient ineligible for VAT for the relevant transactions.

So what is validation?

XML validation is a process whereby XML documents can be checked instantly by software to confirm that they have been constructed and populated correctly.

Validity of an XML document means:

• Logical formatting
  An XML document is well formed if it adheres to the XML syntax rules. E.g. it only contains valid Unicode characters, elements are property closed, etc.
• Schema-conformant
  An XML document is schema-conformant if all rules in the associated XML Schema (e.g, a UBL invoice Schema) are fulfilled.
• Schematron-conformant
  An XML document is schematron-conformant if all rules of the associated Schemtatron file are fulfilled.

This is particularly useful in two scenarios:

1. When connecting to new partners: Without a validation tool, a constant back and forth is required between the two businesses wishing to establish an EDI connection to ensure that messages are coming through correctly during testing. With an integrated XML checker, however, it is possible to remove the dependence on the other party for feedback during the testing phase. Instead, the sender sees instantly if their document is formatted correctly and can make the necessary adjustments straight away, saving both parties time, money and stress.
2. During ongoing EDI operation: In addition to proving useful during the testing stage of partner onboarding, validation should ideally be the final step in every XML document creation process. As changes are constantly being made to live IT environments – both systems and processes – it is important to ensure that this doesn’t disrupt the accuracy of the XML documents generated. The only reliable and efficient way to ensure this is by integrating an XML checker as a final internal step. This way you can be sure that you never send an incorrectly formatted document – which as we have explored can have significant consequences.

What does a comprehensive XML checker provide?

While the exact monetary value of integrating an XML validator is hard to quantify, as it is impossible to predict how many errors you would experience without one, and how costly they would be, the benefits an XML checker can provide are clear. ecosio’s XML validation tool, for example, offers the following key advantages:

• Simple error descriptions – Non-technical and easy-to-understand error messages allow issues to be resolved by non-experts, minimising the chance of bottlenecks.
• Shareable test report – For those who wish to share test reports with colleagues etc., ecosio’s validator generates a concise, downloadable report.
• Zero maintenance – As the tool is maintained by ecosio, there is no need to install any updates or adjust the tool in-house. All necessary changes will be made to the tool directly by ecosio, with zero disruption to your business.
• Simplification of message exchange testing – Both parties save valuable time and money during onboarding as the need for bilateral testing is reduced.
• All major XML document types covered – From Cross Industry Invoice (CII) to Universal Business Language (UBL) file formats, ecosio’s tool covers all common XML file types.
• One click for all formats – The validation tool is as easy to use for complex XML file types as for the most basic ones. All that is required is a single click!
• Clear and unambiguous versioning

The full list of the XML document types that ecosio’s validator tool can check is located on the online tool page.

Before and after implementation – a comparison

Let’s look at how the installation of a validation tool can optimise EDI processes in practice by considering the same example with and without an XML checker. Imagine you wish to send an invoice to one of your partners using the European e-Invoice standard EN 16931 (let’s assume that you sent a Universal Business Document file, though a Cross Industry Invoice would also be feasible).

Without an integrated XML checker:

• Invalid characters could “sneak” into the document. This is typically a master data issue, if for example the business copy and pastes something in a header text or an item description.
• A change in one of the generating routines in the ERP could alter the namespace string, leading to an invalid XML.
• A missing master data entry could lead to a VAT-ID being missing in the XML document, which leads to non-VAT-deduction – depending on the invoice amount.

With an integrated XML checker:

• It is still possible for the things above to occur, but at least you will notice them before your business partner does.

How do I implement a validation tool into my system?

As with many software adjustments, there are two main options for companies looking to integrate an XML checker into their system – A) handle integration in-house, or B) outsource to the experts. The second of these options offers the far simpler option, not least because the first is likely to require the construction of the tool itself as well as its integration into your system.

At ecosio (as with our wider EDI solution) we offer integration of our comprehensive tool via an API connection. This way the tool is embedded directly in your existing ERP system. There is no requirement to navigate to another platform etc. Further, with such a connection you do not need to install updates when the tool is adjusted. Instead, the tool is updated centrally, meaning your validator is always up-to-date and reflects the most recent XML rule sets.

For more information on how to integrate ecosio’s XML checker into your system, or to find out more about the benefits this tool could offer your business in particular, contact us today. We are more than happy to answer any questions you have!

Der Beitrag Integrating an XML Checker into Your ERP System erschien zuerst auf ecosio.

• EDI file formats standardise how B2B documents are structured for automated exchange
• Popular formats include EDIFACT, TRADACOMS, X12, VDA, and UBL, each suited to specific industries
• Each format follows different rules, like delimiters or fixed-length fields
• When partners use different formats, conversion is essential and often handled by a managed EDI provider

Document standards are an essential part of electronic data interchange (EDI). In short, EDI standards (aka EDI file formats) are the specific guidelines that govern the content and format of B2B documents such as orders, invoices and order responses. These documents are then sent via EDI protocols to the service provider / business partner.  

For more information on ecosio EDI as a Service solution and to find out how we could help your business move to the next step, get in touch today or chat with our Sales team now!

How EDI file formats work

Sending documents according to an EDI standard ensures that the machine receiving the message is able to interpret the information correctly as each data element is in its expected place. Without such standards the receiver’s system will be unable to identify what part of the message is what, making automated data exchange impossible.

Although EDI documents may seem like a random mix of letters and symbols, all EDI messages conform to very strict rules. Typically EDI standards are based on the following four principles:

Syntax

Syntax rules determine what characters can be used and in what order.

Codes

Codes are used to identify common information such as currencies, country names or date formats.

Message designs

The message design defines how a particular message type (e.g. invoice or purchase order) is structured and what subset of rules from the prescribed syntax it uses.

Identification values

The means by which values in an EDI file are identified, e.g. by its position in the file or via the use of separators. These changes from standard to standard.

Most EDI standards also include the following three components: 

• Elements – The smallest part of a message, providing submitted values (e.g. “50” or “KGM” or “Potatoes”)
• Segments – A collection of elements or values logically combined to provide an information (e.g. Quantity 50 kilograms of potatoes)
• Transaction sets – A collection of segments, composing a message (e.g. an Invoice for the sale of 50 kilogram of potatoes)

Essentially different formats are like different languages, with the elements and segments of a certain standard mirroring the words and sentences of a regular language.

A brief history of EDI document standards

In the very early days of EDI it quickly became evident that document standards were required to avoid confusion and improve the efficiency of even paper-based supply chain communication. Following the advent of file transfer between computers (FTP) becoming possible, in 1975 the very first EDI standards were published by the Transportation Data Coordinating Committee (an organisation formed by US automotive transport organisations in 1968). In 1981 the American National Standards Institute then published the first multi-industry national standard, X12. In turn this was followed by the creation by the UN of a global standard, EDIFACT, in 1985. 

No one attempt to unify standards has ever been completely successful, however. As technology has evolved and industry specific needs have become increasingly disparate, new standards have steadily been introduced over the decades. Somewhat counterintuitively, therefore, today there is no such thing as a single all-encompassing EDI standard for every document type. Instead, businesses choose their preferred document standard from a number of options (usually opting for the one most widely used in their industry). When trading with partners using different standards, businesses then have to ensure that their messages are correctly converted to the recipient’s required format. This process is called mapping.

The 5 most used EDI file format standards:

1) UN/EDIFACT

The most popular EDI file format standard today outside North America is UN/EDIFACT, which stands for United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport. These international B2B message guidelines are extremely widely used across many industries. 

In fact, given the scope of EDIFACT’s adoption, several industries have developed subsets of the main standard which allow for automation of industry-specific information. One well-known subset is EANCOM, for example, which is used in the retail industry.

EDIFACT document file types are identified by a six letter reference. For example, three of the most common of these references are:

• ORDERS (for purchase orders)
• INVOIC (for invoices)
• DESADV (for despatch advice)

All of these EDIFACT messages have the same basic structure, consisting of a sequence of segments:

• UNA – separators, delimiters and special characters are defined for the interpreting software 
• UNB – file header (with the file end UNZ this makes up the envelope, containing basic information)
• UNG – group start
• UNH – message header
• UNT – message end
• UNE – group end
• UNZ – file end

Example EDIFACT order

[segment tags shown in bold]

As well as transmission format, the EDIFACT standard also defines delivery requirements. EDIFACT provides set guidelines, for example, concerning the exact structure of specific message exchanges, which might themselves contain several individual EDIFACT files.

For a more detailed look at the structure of an EDIFACT file, see our blog post “EDI Standards Overview – Structure of an EDIFACT File” on this topic.

2) TRADACOMS

Despite being less widely-used than EDIFACT, the TRADACOMS standard was released several years before the UN standard. Designed primarily for UK domestic trade (and particularly popular in the retail industry), TRADACOMS is made up of a hierarchy of 26 messages. Like EDIFACT, each message is also given a six letter reference.

TRADACOMS does not use a single message format. Instead, a transmission to a trading partner will consist of a number of messages. For example, one purchase order will often contain an Order Header (ORDHDR), several Orders (ORDERS) and an Order Trailer (ORDTLR). Multiple individual order messages can repeat between the ORDHDR and the ORDTLR.

As with EDIFACT standards, the TRADACOMS standard uses segments for ease of translation. Below are four of the most common segments:

• STX – Start of Interchange
• MHD – Message start
• MTR – Message end
• END – End of Interchange

Example TRADACOMS order

[segment tags shown in bold]

3) ANSI ASC X12

ANSI ASC X12 stands for American National Standards (ANSI) Accredited Standards Committee (ASC) X12, though (for obvious reasons) this is often abbreviated to just X12.

Though initially developed in 1979 to help achieve EDI document standardisation across North America, X12 has been adopted as the preferred standard by approaching half a million businesses worldwide.

Compared to other EDI standards organisations, X12 has a particularly comprehensive transaction set. There are over 300 X12 standards, all of which are identified by a three digit number (e.g. 810 for invoices) rather than the six letter code system used by EDIFACT and TRADACOMS. These EDI file format standards fall under X12’s different industry-based subsets:

• AIAG – Automotive Industry Action Group
• CIDX – Chemical Industry Data Exchange
• EIDX – Electronics Industry Data Exchange Group (CompTIA)
• HIPAA – Health Insurance Portability and Accountability Act
• PIDX – American Petroleum Institute
• UCS – Uniform Communication Standard
• VICS – Voluntary Interindustry Commerce Standards

With each containing slight variations, these subsets are used by different industries as appropriate (apparel retail businesses use VICS for example).

In addition, the hundreds of document types are divided into 16 helpful message series, from ‘order’ to ‘transportation’, with each containing the relevant individual message types.

As with Documents conforming to X12 standards are made up of several segments, some of which are optional and some mandatory. Below is a list of the mandatory segments:

• ISA – Start of interchange
• GS – Start of functional group
• ST – Start of transaction set
• SE – End of transaction set
• GE – End of functional group
• IEA – End of Interchange

As with all EDI documents, these segments in turn are comprised of elements, as can be seen in the example X12 document below:

Example X12 order

[segment tags shown in bold]

For more information on the X12 format, please see our more recent article “EDI Standards Overview – Structure of an EDIFACT File”.

4) VDA

The Association of the Automotive Industry (Verband der Deutschen Auto­mobil­industrie in German, or VDA for short) was established in 1901 by German automobile businesses.

The VDA was one of the first associations to develop EDI file formats in 1977, making VDA standards even older than EDIFACT. 

Like X12 standards, every VDA message standard has a unique identification number (four digits long in this case). For example, VDA EDI file format 4905 is a delivery forecast.

As worldwide use was not expected when the standards were developed, all VDA standards were published in German – something that continues to this day. This can make interpretation difficult, particularly concerning German business terms. Likewise, as VDA also does not use a naming convention for each element, knowledge of German is required to identify them. 

Unlike EDIFACT and X12 standards, VDA standards do not use segments or separators. Instead data elements with a constant length, known as fixed length format elements, are used. When the data to be transmitted is shorter than the required length, spaces are used to fill the gaps. Unfortunately, this fixed length format means that the amount of data that can be transmitted is limited, meaning conversion to/from other EDI standards can be difficult.

Because of these issues, VDA fixed length document standards are slowly being replaced by EDIFACT document types. Today, VDA standards are effectively a subset of the EDIFACT standards used extensively by the automotive industry (much like the EDIFACT subset CEFACT is used by retail businesses).

To aid those using their standards, the VDA have published suggestions regarding transition to EDIFACT. 

Example VDA delivery forecast

[segment tags shown in bold]

For more information on VDA standards, please see our dedicated VDA blog post for a more comprehensive explanation.

5) UBL

The Universal Business Language, or UBL, is a library of standard XML-based business document formats. UBL is owned by Organisation for the Advancement of Structured Information Standards (OASIS), who have made it available to all businesses for free.

As UBL uses an XML structure it differs from other more traditional EDI document formats. Perhaps the biggest difference is the fact that XML-based transmissions are easier to read than other EDI file formats. However, XML file sizes are considerably larger than those of other EDI file formats, though this is no longer a problem following the advent of broadband internet. 

When first established in 2003, UBL had seven EDI file format standards. By the time version 2.1 was released over a decade later this number had increased to 65, and the release of version 2.2 in 2018 further increased the number of document types to over 80.

Significantly CEN/TC434 recently named UBL as one of two EDI syntaxes which comply with new EU regulations regarding e-invoicing. As such, as the use of PEPPOL grows, so the use of UBL is also likely to increase.

Like X12, UBL message types are split into higher level categories. These categories include pre-award sourcing, post-award sourcing, procurement and transportation. UBL messages themselves, meanwhile, include validators, generators, parsers and authoring software.

Example XML order (ecosio ERPEL)

How to exchange different EDI file formats with your trading partners

Whilst each of the above document standards is widely used, particularly within certain industries, unfortunately no one set of document standards is universally used by all supply chain businesses. As a result, if you wish to grow your business and to automate B2B data exchange with your partner network to achieve the cost benefits of automation you will need the ability to translate data between numerous formats.

Given the amount of technical expertise EDI file format translation requires, the fastest and most efficient way to gain this capability is to enlist the help of a managed EDI solution provider such as ecosio. In addition to enabling you to transfer documents in any required format and over any EDI protocol via a single connection to the ecosio cloud-based EDI solution (our Integration Hub), ecosio’s managed services remove virtually all internal effort concerning EDI. For example, new onboardings are handled by a dedicated project manager who is experienced in liaising between both sides to achieve fast, hassle-free and successful connections. Similarly, ecosio’s unique API ensures users are able to send and receive data directly from their ERP’s existing user interface.

For more information on ecosio EDI as a Service solution and to find out how we could help your business move to the next step, get in touch today or chat with our Sales team now!

Der Beitrag EDI file formats explained: key standards and differences erschien zuerst auf ecosio.

As of November 27th 2019, all federal agencies in Germany must be able to receive and process XRechnung. XRechnung is the German CIUS (Core Invoice Usage Specification), which originated from the EU standard EN 16931 . EN 16931 provides two types of XML schemas: Universal Business Language (UBL) and UN / CEFACT Cross Industry Invoice (CII). As a result, the ability to process CII and UBL documents is becoming increasingly important.

Companies that are contractors of public institutions must be able to create and send XRechnung. Furthermore, the billing format is also used in the B2B sector, which is why it makes sense for companies to make their ERP system fit for the creation, transmission, and receiving of XRechnung.

SAP ERP is one of the most popular ERP systems in the world but cannot create, convert or read documents out of the box according to the UBL standard. This means that without add-on modules, SAP ERP cannot work with the standard XRechnung and companies must look for suitable solutions.

Create UBL documents in SAP using the EPO connector

The SAP ERP system cannot generate XML files from the SD and FI modules that conform to the UBL specification. However, a solution can be created by using middleware in conjunction with a service provider. The EPO Connector happens to be a middleware solution that is integrated directly into the SAP system and helps connect further external products and services to the SAP. This means additional functions can be added to SAP cost effectively without having to intervene in the system itself.

In the following, we’ll look at how to use the EPO Connector to create UBL files with attachments, and also send and receive them.

Create and send XRechnung with attachments

Using the EPO Connector, e-Invoices can be created in UBL format from SD and FI documents. Since the middleware is written in ABAP and thus runs directly in SAP, no external tool is necessary, and the invoice workflow can be completely mapped in SAP. In addition, the EPO Connector can be used to integrate attachments into UBL that are directly embedded as Base64-encoded character strings in the document. For this purpose, UBL has its own attachment elements (cac: AdditionalDocumentReference):

Extract of a Base64-encoded Attachment in UBL

The EPO Connector takes care of the correct coding and embedding of the desired attachments and creates the final UBL file according to the XRechnung specification. In order to be able to transmit the created e-Invoice to the recipient, a service provider such as ecosio can be connected to the middleware. ecosio reads out the sender and recipient ID as well as the document type and sends the invoice to the bill-to party via the required channel. This results in a consistent and seamless invoice delivery and invoice receipt process. Peppol (Pan-European Public Procurement Online), which was developed by the European Union to facilitate the exchange of data between companies and public authorities, must be used for the automatic sending of XRechnung. In this case, the service provider connects to the recipient’s Peppol access point, which receives the transmitted XRechnung and forwards them for processing.

Receive and process XRechnung with attachments

The invoice receipt process using the EPO Connector is like sending invoices. The EDI service provider receives invoices via the required protocols (e.g. Peppol) and transfers them to the EPO Connector, which controls the transfer of the documents to the SAP system of the company. Since SAP cannot work with the XML format UBL, the received documents must be converted to the required SAP format. The EPO Connector is responsible for the correct conversion and unpacks any attachments from the UBL.

Invoice Book for Incoming Invoices Provided by the EPO Connector.

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

These attachments are appended to the final SAP document and can be viewed in the system as usual. The approval workflow can now be started in SAP and invoices released accordingly for payment.

In the Document Viewer

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

Transmission of UBL invoices by ecosio

Thanks to ecosio’s connection to the SAP system, documents can be sent in various structured formats via all common EDI protocols. In addition to the usual document exchange protocols such as X.400, AS2, SFTP, SMTP, OFTP2, as well as EDI networks such as GXS, INOVIS, etc., files can also be accessed via special platforms such as Peppol, FACe (Spain) or the Sistema di Interscambio (Italy).

This makes it quick and easy to send and receive UBL documents via the Peppol network.

Conversion and Dispatch of UBL Documents with the EPO Connector and ecosio

Since ecosio allows the connection of any partner via different protocols, companies do not need to worry about expensive special programming in SAP. In conjunction with the EPO Connector, companies stay up to date with the technological requirements surrounding EDI and can focus on their core business.

Summary

The EPO Connector allows companies to convert invoices in SAP into XML format UBL and add attachments. Likewise, UBL documents can be received, converted into an SAP format and then edited. In conjunction with ecosio, the generated invoices can be sent via all standard exchange protocols. It is also possible to send and receive XRechnung via Peppol with ecosio.

Thus, companies are not dependent on expensive additional software for SAP but can pursue a long-term and cost-saving strategy to meet the ever-increasing requirements for e-Invoices.

Any questions?

Do you still have questions about UBL documents in SAP and how they can be created and sent? Feel free to contact us or check out our chat, we would love to help you!

SAP ERP and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in several other countries.

Der Beitrag Create and Process UBL Documents with Attachments in SAP erschien zuerst auf ecosio.

The European e-invoicing norm EN 16931-1 was developed by the EU member states in accordance with the EU directive 2014/55/EU. The norm EN 16931-1 represents a semantic data model of an invoice’s core elements. This means that the requirements for the most important elements of an invoice are defined in a syntax-independent form. In other words, the norm EN 16931-1 is essentially a PDF document, in which the invoice requirements are described in a readable language and independently from the syntax.

In addition you will find conversions in the technical syntaxes, based on UBL (Universal Business Language) and CII (Cross Industry Invoice).

Philip Helger, who co-wrote the European norm, offers a good overview of the components of the EN 16931 on his website. Unfortunately the norm itself is not available publicly, but needs to be purchased.

Core invoice usage specification

The semantic data model EN 16931-1 can include more data elements and definitions than required in certain situations or applications. Furthermore, there is often a requirement, where some elements of the norm are not optional but mandatory.

This is where Core Invoice Usage Specification (CIUS) is used to further define this invoicing norm base.

A CIUS example

The Republic of Austria has defined their own CIUS for e-invoices sent to the Austrian authorities. This CIUS is called CIUS-AT-NAT Austrian National Core Invoice Usage Specification and limits the extent of both EU invoice syntaxes UBL and CII.

Those looking for information on how to create and process UBL documents with attachments in SAP can find our article “Create and Process UBL Documents with Attachments in SAP” on this topic. 

Example of an Austrian CIUS

You can access the Austrian CIUS at the following link.

Do you have any questions?

Do you still have questions about e-invoices? Feel free to contact us, we would love to help you!

SAP ERP and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in several other countries. 

Der Beitrag What is a Core Invoice Usage Specification (CIUS) erschien zuerst auf ecosio.

XRechnung overview

Things are getting serious as of November 27th 2018 – all federal ministries and constitutional bodies In Germany must be able to accept electronic invoices according to the XRechnung standard. All the other federal organisations will follow up a year later, on November 27th 2019, and will also have to accept XRechnung. Suppliers, on the other hand, will still be able to send paper and PDF invoices.

Paper invoices will then completely disappear from November 27th 2020 in this sector – suppliers will henceforth have to generate all their invoices electronically in XRechnung format for the public bodies. Paper invoices will not be accepted anymore after that. Therefore, it is time for any supplier of a federal agency to deal with the topic of XRechnung.

But what exactly is an XRechnung?

The XRechnung was developed in Germany as part of the implementation of the EU directive 2014/55/EU. This EU directive dictates the creation of an individual European standard for the core elements of an electronic invoice. The public bodies of the EU-member states will have to accept electronic invoices which comply with this European standard. The EU directive has already become reality – the EU-member states already developed the standard: today it is known as the EU invoice standard EN 16931.

Since every EU member state will have specific requirements for electronic invoices, the need arose to develop so called Core Invoice Usage Specifications (CIUS). As a matter of fact, the XRechnung is a CIUS for Germany, even though it is not the only CIUS in Germany.

From a technical point of view, an XRechnung is an XML file, which complies with the XML schema according to the European standard EN 16931 and further restrictions dictated by the XRechnung. The European Standard EN 16931 provides two types of XML schemas: Universal Business Language (UBL) and UN/CEFACT Cross Industry Invoice (CII).

For SAP systems this represents the first challenge. SAP systems are unable to populate UBL or CII data on the SD side (Sales and Distribution) out of the box.

Learn how to unlock the potential of EDI with ERP integration

Why Peppol?

Further to define a uniform e-invoicing standard, the protocol to be used to send e-invoices to the authorities must also be determined. In theory one could use the whole spectrum of communication protocols, the same way they are being used for B2B transactions, such as SFTP, AS2, X400 etc. This would result in the authorities having to support all those protocols, including the disadvantages each one may represent.

In order to define a uniform standard, the legislator had to fall back on a rather popular standard in the B2G area within the EU: Peppol. Peppol is the acronym for Pan-European Public Procurement OnLine and was developed by the European Union. Its goal is to simplify the communication between suppliers and public bodies for e-procurement.

Technically, Peppol is the definition of a delivery infrastructure for electronic documents.

Peppol consists of:

• The Peppol e-delivery network
• The Peppol document specifications, which determine the structure of the electronic documents (Peppol Business Interoperability Specifications – BIS)
• A legal framework, which regulates the collaboration within this network (Peppol Transport Infrastructure Agreement)

In order to send and receive via Peppol, one must be equipped with a Peppol Access Point. Since it might prove quite costly from a technical and organisational point of view to create and register an Access Point, most companies will resort to a specialised service provider, through which one can reach the Peppol network.

Do you have any questions?

Do you have further questions about XRechnung or how to connect SAP to Peppol? Feel free to contact us, we would love to help you!

Are you aware of 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.

SAP ERP and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in several other countries. 

Der Beitrag How to connect SAP to Peppol to allow the exchange of XRechnung erschien zuerst auf ecosio.