Peppol MLS Specification
Peppol Message Level Status
peppol

OpenPeppol AISBL, eDEC v1.0.0

1. Introduction

The Peppol Message Level Status (MLS) specification supports Peppol Service Providers that receive a business document to respond a processing status of that business document back to the sending Peppol Service Provider. This document will explain and outline the procedures for the Message Level Status.

The MLS usage and the relationship to Peppol Reporting is described in the Service Provider Operational Guideline on MLS document.

1.1. Document Structure

This document is structured as follows:

  • Chapter 1 (Introduction) - provides general information about MLS.

  • Chapter 2 (Principles and Prerequisites) - provides the reader with general MLS information, defines the scope and assigns the roles to relevant parties.

  • Chapter 3 (Process) - provides the reader with a generic process how to apply an MLS.

  • Chapter 4 (SBDH Extension) - provides the details about the additional optional settings in the Peppol Business Message Envelope.

  • Chapter 5 (Rules) - provides the reader with information on the business rules to be respected for the MLS process.

  • Chapter 6 (Data Types) - provides the details on the used data types in an MLS.

  • Chapter 7 (Code Lists) - provides the details on the used code lists in an MLS.

  • Chapter 8 (Description of selected parts of the MLS message) - provides details on the syntax binding of selected parts of the MLS message.

  • Chapter 9 (Specification Identifiers) - provides the details on the customization and process identifiers for MLS.

1.2. Scope

This document provides a detailed implementation guideline for the MLS transaction; to do that, the document sets out the processes and procedure for MLS including:

  1. Parties and Roles,

  2. Document Structure,

  3. Transmission rules.

1.3. Audience

  • Service Provider (SP)

    • How SPs create and transmit MLS messages

1.4. References

1.5. Namespaces

The following table lists XML namespaces that are used in this document. The choice of any namespace prefix is arbitrary and not semantically significant.

Prefix Namespace URI

cac

urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2

cbc

urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2

ubl

urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2

1.6. Changelog

Version 1.0.0 (2025-05-22)

  • Including changes from the member review

Version 1.0.0-RC1 (2025-02-13)

  • Initial version

2. Principles and Prerequisites

This chapter describes the principles and assumptions that underlie the use of the Peppol Message Level Status (MLS) message.

An MLS message can be used in the choreography of the exchange of a business document between service providers (C2/C3) to improve reliability by allowing C3 to inform C2 about the results of the document exchange.

This document always uses the corner numbering (C1, C2, C3 and C4) based on the business document exchange.

In a CTC (Continuous Transaction Controls) setup every C5 that leverages the Peppol Network Specifications can act as a C3 in the context of this document. Every C3 mentioned in this document implicitly includes C5 when applicable in the business process.

The MLS process supports the use-cases where participants use multiple Service Providers, and where Service Providers use multiple Access Points due to the combination of OpenPeppol Service Provider Identification Scheme (SPIS) and the SBDH Extension.

The MLS message is an evolution based on Message Level Response (MLR) message as the foundation.

2.1. Peppol Status Messages in general

Through the start to end flow of a message exchange, from the creation of an electronic message, down the transport line that goes through one or more transport networks to the designated receiver and all the way through the eventual processing of the message content, there may be need to give responses to the relevant parties up-line about the status or results of the actions that the message goes through.
 
These responses are of different nature but for the purpose of this document they can be divided into the following main groups.

Protocol Status / Transport Level Acknowledgements

These are messages that are exchanged within the Peppol Network to inform about the process of carrying a message down the transport line. These responses may inform someone up-line that the delivery to a given point was successful or not and may contain details about issues that are relevant such as why a delivery was not successful.  
The key nature of these responses is that they do not in any way act on result of validation or processing of the content of the payload that is being transported. These response messages are commonly called "acks" (short for "acknowledgements").

Messaging Status / Message Level Responses

When a message has reached a given point in the transport line its content may be put through several types of checks according to agreed Peppol Specifications such as validation, attachment size, and/or virus scan before delivering it towards C4.  
The outcome of these activities may be reported to a relevant party up-line, informing it whether the message exchange was successfully handled or not as well as giving some details about the checks performed. An example could be that an order message that is received is rejected because it is missing a mandatory field, or because stated amounts don’t add up according to what is specified in the relevant syntax specification, or because handling at C3 or delivery towards C4 simply failed.  
The key nature of the existing MLR is that it reports on the message content only on the basis of the technical specifications that apply, whereas the MLS can also include delivery issue towards C4.  
Its content can be evaluated against conformance criteria.  
The extended capability aims to provide C2 with more useful information to enhance the recovery process on problems that may occur.

Business Status / Business Level Responses

A message that has been received and accepted for processing may call for an action on the receiver’s behalf. That receiver’s action may need to be reported back up-line to a relevant party. An example is that a technically correct order may be received but the receiver decides to reject the order for any business reason such as out-of-stock situation, expired contract etc.  
The key nature of these responses is that they report a business decision that is made on the message instance received.

This specification is only concerned with the Message Level Status.

peppol status messages
Figure 1. Flow of different response messages

2.2. Scope

MLS messages are sent by C3 to C2, and contain information about the processing and delivery of a message towards C4.

The MLS message is intended to inform the sending Service Provider of the original business document (C2) of the following situations:

  1. Message Rejected because not meeting conformance criteria

  2. Message Delivery towards C4 failed

  3. Message Delivery towards C4 succeeded (with confirmation)

  4. Message Delivery towards C4 performed (without confirmation)

These statuses are further explained in the following sections.

MLS messages MUST NOT be used as responses to other MLS (or MLR) messages.

2.2.1. Message Rejected because not meeting conformance criteria / Message Delivery towards C4 failed

The received message was not delivered towards the final recipient (C4) for business processing.

MLS Response code: RE

  1. C3 MUST NOT send another status via the Peppol Network for the same business document to C2.

  2. The responsibility of the message is transferred back to C1/C2.

  3. The MLS contains the reason that the message was not delivered towards C4:

    1. Errors according to the listed conformance rules. Examples are:

      1. XML schema validation error (MLS Status Reason Code is SV)

      2. Standard Compliance violations (e.g. empty elements not being allowed by UBL 2.1) (MLS Status Reason Code is BV)

      3. Schematron Validation error of type fatal error (MLS Status Reason Code is BV)

      4. Schematron Validation error of type warning. Warnings alone must NOT cause rejection of the business document, but they may be reported in addition to fatal errors. (MLS Status Reason Code is BW)

      5. Wrong version of the business document (e.g. wrong UBL version) (MLS Status Reason Code is BV)

    2. Other non-compliance with artefacts in the Peppol Interoperability Framework not otherwise covered by 3(a). Examples are:

      1. Discrepancies between values in the Business Message Envelope (currently SBDH) and required values in the Business Document (MLS Status Reason Code is BV)

      2. File size exceeds specifications (MLS Status Reason Code is BV)

      3. Value length exceeds specifications (MLS Status Reason Code is BV)

      4. Virus or malware detected (MLS Status Reason Code is BV)

      5. MIME Type mismatch (e.g. PDF specified, but image supplied) (MLS Status Reason Code is BV)

      6. Malformed content (e.g. corrupt or incomplete PDF as an attachment) (MLS Status Reason Code is BV)

    3. Failure of delivery:

      1. C3 is permanently unable to pass on the message towards C4 (for whatever reason) (MLS Status Reason Code is FD)

2.2.2. Message Delivery towards C4 succeeded (with confirmation)

The received message has been successfully delivered towards the final recipient (C4). C3 has received a verifiable confirmation that the message has been carried forward towards C4.

The communication between C4 and C3 is out of scope for this specification, and so is the form of this acknowledgement, but this status should only be sent if there is some form of acknowledgement between C4 and C3.

MLS Response code: AP

  1. C3 MUST NOT send another status via the Peppol Network for the same business document to C2.

  2. The responsibility of the message remains with C3/C4.

  3. The reason for this status may be optionally provided. Examples are:

    1. Delivery by API with acceptance acknowledgement

    2. Delivery by file transfer with acceptance acknowledgement

Note: For example email is a technology that does not guarantee the acceptance of a receiver, and therefore it cannot be used with this status code.

2.2.3. Message Delivery towards C4 performed (without confirmation)

The received message has been forwarded to C4, but C3 has no method to verify that it arrived. This status is used when communication between C3 and C4 is of such a nature that C3 is unable to confirm that delivery succeeded.

MLS Response code: AB

  1. C3 MUST NOT send another status via the Peppol Network for the same business document to C2.

  2. The responsibility of the message remains with C3/C4.

  3. The reason for this status may be optionally provided. Examples are:

    1. Delivery by postal service

    2. Delivery by email

    3. Delivery by file transfer without acceptance acknowledgement

    4. Delivery to a local storage for later polling from C3

2.3. Parties and roles

The table below gives the definitions of the parties and roles of the MLS process. The sender (C3) and receiver (C2) of the MLS message should be extracted from the AS4 message in the same way C2 and C3 are extracted for Peppol Reporting purposes.

Business partners

Description

C1

The party creating the business document

C2

The party sending the business document and receiving the MLS

C3

The party receiving the business document and creating and sending the MLS

C4

The party processing the business document

3. Process

MLS messages are sent from C3 to C2 (from Peppol Service Provider receiving the business document to Peppol Service Provider sending the business document). It can only be initiated as a response to a preceding business document exchange. Its source and destination MUST use the identifier of the interacting Peppol Service Providers. Peppol Service Providers are uniquely identified using the OpenPeppol Service Provider Identification Scheme (SPIS).

MLS offers C2 the possibility to control whether they expect only negative responses or all types of responses. These instructions are communicated through the SBDH, as specified in section SBDH Extension. The default behaviour for MLS is defined in the MLS Policy.

This makes the full process as follows:

  1. C3 receives a Peppol message from C2 (this includes at least the SBDH and the business document)

  2. C3 determines from the SBDH under what conditions an MLS message must be sent

    • If there is no entry in the SBDH, the respective default behaviour must be used (see section SBDH Extension)

  3. C3 determines from the SBDH to what Participant Identifier an MLS message must be sent

    • If the SBDH does not contain a specific receiver, the default is to use the SPIS Main ID from the PartyInfo/From/PartyId value of the AS4 User Message

  4. C3 performs validation steps as needed and forwards (at least) the business document to C4

  5. If the outcome of step 4 is successful

    • If the condition to send an MLS (see step 2) is only in case of error

      • Don’t send an MLS

    • If the condition to send an MLS (see step 2) is to always send

      • Send a positive MLS, without any errors

  6. If the outcome of step 4 is negative

    • Send a negative MLS, including details on the failure

seq diag process
Figure 2. MLS Exchange process overview

Sending an MLS always includes the following steps:

  1. Create an MLS document

  2. Technically validate the MLS document

  3. Perform an SMP lookup for the chosen C2 Participant ID (see step 3 above)

  4. Wrap MLS document in SBDH

  5. C3 sends the MLS message to C2

The details on the expected retry and error handling are defined in the Service Provider Operational Guideline.

4. SBDH Extension

In order to support MLS, the Peppol Business Message Envelope Specification is extended with two optional BusinessScope fields: MLS_TO, which signals an alternative address for sending the MLS response, and MLS_TYPE, which signals the type of MLS responses C2 wants to receive.

4.1. Specific MLS Receiver (MLS_TO)

The MLS_TO business scope field is an optional element that specifies an alternative address for sending MLS responses to. If this element is not present or invalid, MLS responses MUST be sent to the general Peppol Service Provider ID (SPID) of C2.

This element MAY be used when a Peppol Service Provider has multiple Access Points, or multiple Access Point instances that are not aware of transactions at other instances.

The Scope/InstanceIdentifier element MUST contain the Peppol Participant Identifier where MLS messages for the specific source business document should be sent, in the form <scheme ID>::<identifier value> (see Peppol Policy for use of Identifiers). The Participant Identifier Scheme for the Peppol SPIS MUST be used. The Participant Identifier Value MUST start with (or be equal to) the Main ID of C2, meaning that a redirect to a different Peppol Service Provider is not allowed.

C3 SHOULD check that the value of the Scope/InstanceIdentifier field correlates to C2’s SPID from the Peppol AP Certificate.

If this field is present, and the Participant Identifier is valid, and the Participant Identifier is existing, and the Participant Identifier has correctly registered for the MLS Document Type, MLS messages MUST be sent to the Participant Identifier specified.

If this field is present, and it does not contain a valid Participant Identifier, then this field MUST be ignored.

If this field is present, and the Participant Identifier is valid, but the Participant Identifier is either non-existing or lacking the necessary SMP registration, then this field MUST be ignored.

The Scope/Identifier element MUST contains the Peppol Participant Identifier Meta Scheme (see Peppol Policy for use of Identifiers).

Example of an MLS_TO business Scope element (02XX is the placeholder for the SPIS ICD code):

<Scope>
  <Type>MLS_TO</Type>
  <InstanceIdentifier>02XX:123456</InstanceIdentifier>
  <Identifier>iso6523-actorid-upis</Identifier>
</Scope>

4.2. Specific MLS Usage (MLS_TYPE)

The MLS_TYPE business scope element is an optional element that instructs C3 on when to send MLS messages.

With this element C2 can control whether they expect only negative responses (RE) or all types of responses (AP, AB and RE).

C3 MUST adhere to the request from C2.

The Scope/InstanceIdentifier element MUST have one of the following values (case sensitive):

FAILURE_ONLY

Only send MLS messages with status RE

ALWAYS_SEND

Always send an MLS message. Send MLS messages with status RE, AB and AP.

The default value of this field is defined in the Service Provider Operational Guideline on MLS. Any other value is considered as invalid and MUST be interpreted as the default value.

Example of an MLS_TYPE business scope element:

<Scope>
  <Type>MLS_TYPE</Type>
  <InstanceIdentifier>ALWAYS_SEND</InstanceIdentifier>
</Scope>

5. Rules

The Message Level Status process governs how and when the transactions are issued and how they are handled between the sending Service Provider and the receiving Service Provider.

Rule ID Rule Description Validation Level

OP-MLS-01

The MLS message is a one-directional message only. It MUST be directed from the Service Provider receiving the business document to the Service Provider sending the business document.

Access Point

OP-MLS-02

Each received business document MUST be responded by zero or one MLS message.

Access Point

OP-MLS-03

An MLS message MUST NOT be sent in response to another MLS or MLR message.

Access Point

OP-MLS-04

If an MLS message is sent, it MUST be sent as soon as the status is known.

Governance

OP-MLS-05

If the business message envelope of the original business document contains a specific MLS Receiver (MLS_TO), it MUST be verified for correctness.

Access Point

OP-MLS-06

If the business message envelope of the original business document contains a specific MLS Receiver (MLS_TO) that is valid (according to OP-MLS-05), it MUST be honoured by the MLS sender.

Access Point

OP-MLS-07

If the business message envelope of the original business document contains a specific MLS Receiver (MLS_TO) that is invalid (according to OP-MLS-05), the provided MLS Receiver MUST be ignored.

Access Point

OP-MLS-08

If the business message envelope of the original business document contains a specific MLS Usage (MLS_TYPE), it MUST be verified for correctness.

Access Point

OP-MLS-09

If the business message envelope of the original business document contains a specific MLS Usage (MLS_TYPE), with the value of ALWAYS_SEND then an MLS message MUST be sent for all Response Codes.

Access Point

OP-MLS-10

If the business message envelope of the original business document either does not contain a specific MLS Usage (MLS_TYPE) or contains an invalid MLS Usage, then an MLS message MUST be sent for all Response Codes.

Access Point

OP-MLS-11

If the business message envelope of the original business document contains a specific MLS Usage (MLS_TYPE), with the value of FAILURE_ONLY then an MLS message MUST only be sent for Response Code RE.

Access Point

OP-MLS-12

An MLS message for a valid business document MUST NOT be sent prior to trying to forward the original business document to the End User.

Access Point

OP-MLS-13

An MLS message with Response Code RE MUST contain sufficient information for the business document sender to identify the source of the problem and to determine who needs to take action.

Access Point

OP-MLS-14

An MLS message MUST contain an identification of the specification it conforms to.

XSD

OP-MLS-15

An MLS message MUST contain an identification of the business process context it appears in.

XSD

OP-MLS-16

An MLS message MUST contain the business message envelope identifier used by the original business document transmission.

XSD

OP-MLS-17

An MLS message MUST have an issue date without time zone information.

Schematron

OP-MLS-18

An MLS message MUST have an issue time including time zone information.

Schematron

OP-MLS-19

An MLS message MUST contain Sender Party and Receiver Party.

XSD

OP-MLS-20

The Sender Party Identifier of an MLS message MUST be the Receiver Party Identifier of the original business document.

Access Point

OP-MLS-21

The Sender Party Identifier of an MLS message MUST be the SPID of C3.

Access Point
Schematron

OP-MLS-22

The Receiver Party Identifier of an MLS message MUST start with the SPID of C2.

Access Point
Schematron

OP-MLS-23

The Receiver Party Identifier of an MLS message MUST be either the SPID of C2 or the specific MLS receiver as provided in the original business message envelope (MLS_TO).

Access Point

OP-MLS-24

An MLS message MUST have one overall Response Code in the specified code list.

XSD
Schematron

OP-MLS-25

An MLS message with a rejection code MUST contain an overall description for the rejection.

Schematron

OP-MLS-26

An MLS message MUST reference the original business document transmission via the unique identifier of the business message envelope of the original business document.

Access Point
Schematron

OP-MLS-27

An MLS message with a rejection code MUST contain a list of issues with details.

Schematron

OP-MLS-28

Each issue within an MLS message with a rejection code MUST contain an issue location.

Schematron

OP-MLS-29

Each issue within an MLS message with a rejection code MUST contain an issue description.

Schematron

OP-MLS-30

Each issue within an MLS message with a rejection code MUST contain an issue status reason code.

Schematron

6. Data Types

Semantic data types are used to bridge the gap between the semantic concepts expressed by the information elements and the technical implementation. The semantic data types define the allowed value domain for the content, and any additional information components (attributes) needed in order to ensure its precise interpretation.

6.1. Primitive Data Types

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000-5:2014, Annex A.

Primitive type Definition

Date

Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601:2004.

Time

Time point representing a specific moment during the day, defined within a 24-hour period, without reference to a specific date. It is based on a time scale with hours, minutes, and seconds, adhering to the ISO 8601:2004 standard, but not tied to a calendar date. This type focuses solely on the time of day, independent of any date-specific context.

Decimal

A subset of the real numbers, which can be represented by decimal numerals.

String

A finite sequence of characters.

6.2. Semantic Data Types

The different semantic data types are described in the tables below, where various features such as attributes, format, and decimals as well as the basic type are defined for each semantic data type. They are based on ISO 15000-5:2014.

When used in an instance document, each data element will contain data. In the below tables this is identified as the “content”. Whenever a business term is used this term shall always have content and therefore the content is always mandatory.

6.2.1. Code

Codes are used to specify allowed values in elements as well as for lists of options. Code is different from Identifier in that allowed values have standardized meanings that can be known by the recipient.

Codes shall be entered exactly as shown in the selected code list.

Component Use Primitive Type Example

Content

Mandatory

String

Abc123

6.2.2. Identifier

Identifiers (IDs) are keys that are issued by the sender or recipient of a document or by a third party.

The use of the attributes is specified for each information element.

Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

Scheme identifier

Conditional

String

0088

Scheme version identifier

Conditional

String

1.0

6.2.3. Date

Dates MUST be in accordance to the "Calendar date complete representation" as specified by ISO 8601:2004, format YYYY-MM-DD.

Table 1. Date Type
Component Use Primitive Type Example

Content

Mandatory

Date

2024-12-01

6.2.4. Time

Time MUST be in accordance to the "Extended time format" as specified by ISO 8601:2004, format [hh]:[mm]:[ss].[SSS]. The usage of fraction digits is optional.

Time MUST NOT use more than three decimal fraction digits on seconds. This means that the finest granularity are milliseconds.

Table 2. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Time

09:30:12.08

6.2.5. Reference

Reference Types are identifiers that were assigned to a document or document line.

Table 3. Reference Type
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

6.2.6. Text

Text is the actual wording of anything written or printed. Line breaks in the text MAY be present, and any line breaks SHOULD be preserved and respected by the receiver’s system

Component Use Primitive Type Example

Content

Mandatory

String

Validation gives error [CL-T77-R002] - Tax categories MUST be coded using UN/ECE 5305 code list

7. Code Lists

Any element with the semantic data type of Code, SHOULD mandate the use of a specific code list. In this section, you can find the valid codes, their names and description, and also links to where the same code list is used elsewhere in the transaction.

7.1. Electronic address identifier scheme identifier

All electronic address identifiers (cbc:EndpointID/@schemeID) use the Electronic Address Scheme code list (EAS), maintained by CEF (CEF Code lists) and subset by OpenPeppol.

Document location

ubl:ApplicationResponse/cac:SenderParty/cbc:EndpointID
ubl:ApplicationResponse/cac:ReceiverParty/cbc:EndpointID

Source code list

EAS Code List
Examples of usage in cbc:EndpointID
<cbc:EndpointID schemeID="02XX">12345</cbc:EndpointID> (1)
1 schemeID attribute is mandatory (see Peppol Policy for use of Identifiers, POLICY 9)

7.2. MLS Response Codes

The MLS Response Code List is a subset of the UN/CEFACT 4343 code list.

To create a "positive MLS", use one the codes AP or AB. To create a "negative MLS", use the code RE.

Document location

ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cbc:ResponseCode

Source code list

MLS Response Code List
Examples of usage in cbc:ResponseCode using "Message delivered towards C4 without confirmation"
<?xml version="1.0" encoding="UTF-8"?>
<ubl:ApplicationResponse
  xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2"
  xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
  xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
...
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ResponseCode>AB</cbc:ResponseCode>
...
    </cac:Response>
...
  </cac:DocumentResponse>
</ubl:ApplicationResponse>

7.3. Line Response Status Reason Codes

The Line Response Status Reason Codes are used to indicate specific failures in a rejected document.

Document location

ubl:ApplicationResponse/cac:DocumentResponse/cac:LineResponse/cac:Response/cac:Status/cbc:StatusReasonCode

Source code list

MLS Status Reason Code List
Examples of usage in cac:LineResponse having a "Business rule violation, fatal"
<cac:LineResponse>
  <cac:LineReference>
    <cbc:LineID>NA</cbc:LineID>
  </cac:LineReference>
  <cac:Response>
    <cbc:Description>Invoice tax exclusive amount MUST equal the sum of lines plus allowances and charges on header level</cbc:Description>
    <cac:Status>
      <cbc:StatusReasonCode>BV</cbc:StatusReasonCode>
    </cac:Status>
  </cac:Response>
</cac:LineResponse>

8. Description of selected parts of the MLS message

8.1. MLS header

8.1.1. Customization ID

The element cbc:CustomizationID MUST contain the customization identifier of the MLS as defined in Profiles and Messages.

Example:
<cbc:CustomizationID>urn:peppol:edec:mls:1.0</cbc:CustomizationID>

8.1.2. Profile ID

The element cbc:ProfileID MUST contain the profile identifier of the MLS as defined in Profiles and Messages.

Example:
<cbc:ProfileID>urn:peppol:edec:mls</cbc:ProfileID>

8.1.3. MLS ID

The element cbc:ID MUST contain a unique identifier for this message. It is recommended to use a UUID for this value.

Example:
<cbc:ID>3f64739a-72eb-4d27-b835-5fd1ba504a7b</cbc:ID>

8.1.4. MLS Issue Date and Time

The element cbc:IssueDate MUST contain the date of issue of the MLS. It MUST NOT contain time zone information.

The element cbc:IssueTime MUST contain the time of issue of the MLS. It MUST contain time zone information.

The date and time of issue of the MLS is different from the date and time of issue of the business document it refers to.

Example:
<cbc:IssueDate>2025-02-05</cbc:IssueDate>
<cbc:IssueTime>23:07:22Z</cbc:IssueTime>

8.2. Party identification

8.2.1. Sender Party

The element cac:SenderParty/cbc:EndpointID MUST contain the party identification of C3. This MUST be a Peppol SPID. The element MUST be filled according to Peppol Policy for use of Identifiers, POLICY 9.

Example:
<cac:SenderParty>
  <cbc:EndpointID schemeID="02XX">POP00001</cbc:EndpointID>
</cac:SenderParty>

8.2.2. Receiver Party

The element cac:ReceiverParty/cbc:EndpointID MUST contain the party identification of C2. The value MUST either be a Peppol SPID or a value provided by C2 in the SBDH (MLS_TO). The element MUST be filled according to Peppol Policy for use of Identifiers, POLICY 9.

Example:
<cac:ReceiverParty>
  <cbc:EndpointID schemeID="02XX">POP00002</cbc:EndpointID>
</cac:ReceiverParty>

8.3. Document Response

The document response is used to indicate the overall result of business document processing.

Exactly one cac:DocumentResponse element MUST be present.

The element cac:DocumentResponse/cac:Response/cbc:ResponseCode MUST contain the overall result code. See chapter MLS Response Codes for the code list.

Only the response code RE is considered to be a rejection. In case the document is rejected, the cac:DocumentResponse/cac:Response/cbc:Description element MUST be provided.

If the cac:DocumentResponse/cac:Response/cbc:Description element is provided it SHOULD be filled with text in English language only.

Example for Message Rejected because not meeting conformance criteria / Message Delivery towards C4 failed:
<cac:Response>
  <cbc:ResponseCode>RE</cbc:ResponseCode>
  <cbc:Description>The document was rejected because it failed validation</cbc:Description>
</cac:Response>
Example for Message Delivery towards C4 succeeded (with confirmation):
<cac:Response>
  <cbc:ResponseCode>AP</cbc:ResponseCode>
</cac:Response>
Example for Message Delivery towards C4 performed (without confirmation):
<cac:Response>
  <cbc:ResponseCode>AB</cbc:ResponseCode>
  <cbc:Description>The document was forwarded for delivery by email.</cbc:Description>
</cac:Response>

8.4. Document Reference

The document reference is used to provide a reference to the envelope of the business document message on which the MLS is based.

The MLS message MUST cover exactly one business document therefore exactly one cac:DocumentResponse/cac:DocumentReference element MUST exist.

The element cac:DocumentResponse/cac:DocumentReference/cbc:ID MUST contain the instance identifier of the envelope of the original business document (i.e. SBDH element StandardBusinessDocumentHeader/DocumentIdentification/InstanceIdentifier) which is typically a UUID.

Example:
<cac:DocumentReference>
  <!-- The SBDH envelope InstanceIdentifier of the source message -->
  <cbc:ID>90f14eff-3705-4869-ad3c-caae270a234e</cbc:ID>
</cac:DocumentReference>

8.5. Line Response

In case of a negative response (rejection), the cac:LineResponse element is used to specify the response reasons.

The cac:LineReference/cbc:LineID element is mandatory in UBL 2.1, and can be used to provide an XPath expression that points to the location of the issue in the original document. If the location is unknown or not relevant, the value NA (case-sensitive; stands for "Not Applicable") MUST be used.

Each response reason referencing the same cbc:LineID MUST be placed in a separate cac:Response element within the same cac:LineResponse element. One cac:LineResponse element MUST have one or more cac:Response elements.

Each cac:Response element MUST have one cbc:Description element and one cac:Status element.

Each cac:Response/cbc:Description element MUST be provided and SHOULD be filled with text in English language only.

Each cac:Response/cac:Status element MUST have one cbc:StatusReasonCode element. See chapter Line Response Status Reason Codes for the code list.

Take care when using namespace prefixes in XPath expressions. These can be the prefixes of the validation files, not of the document itself, and since they occur in attributes, they might be removed during XML canonicalization. If you are providing line responses with XPath values, make sure that namespace prefixes are defined in the XML file and preserved during canonicalization.
Example using an unspecific reference:
<cac:LineResponse>
  <cac:LineReference>
    <cbc:LineID>NA</cbc:LineID>
  </cac:LineReference>
  <cac:Response>
    <cbc:Description>Invoice tax exclusive amount MUST equal the sum of lines plus allowances and charges on header level</cbc:Description>
    <cac:Status>
      <cbc:StatusReasonCode>BV</cbc:StatusReasonCode>
    </cac:Status>
  </cac:Response>
</cac:LineResponse>
Example using an XPath expression as reference:
<cac:LineResponse>
  <cac:LineReference>
    <cbc:LineID>inv:Invoice/cac:TaxTotal/cac:TaxSubtotal/</cbc:LineID>
  </cac:LineReference>
  <cac:Response>
    <cbc:Description>Document level amounts cannot have more than 2 decimals</cbc:Description>
    <cac:Status>
      <cbc:StatusReasonCode>BV</cbc:StatusReasonCode>
    </cac:Status>
  </cac:Response>
</cac:LineResponse>

9. Specification Identifiers

Peppol has defined a Peppol Policy for use of Identifiers, POLICY 8 that specifies how to use identifiers in both the Peppol Network and within the documents exchanged across that infrastructure. It also introduces principles for any identifiers used in the Peppol environment.

9.1. Profiles and Messages

All messages must contain the elements ProfileID and CustomizationID. ProfileID identifies what business process a given message is part of, and CustomizationID identifies the kind of message and the rules applied.

Profiles are connected to one business process, and may contain multiple document types. Valid document instances shall contain corresponding ProfileID and CustomizationID.

In the table below you will find the values to be used as the specification identifier and the business process type for this profile

Type Element cbc:CustomizationID Element cbc:ProfileID

Message Level Status

urn:peppol:edec:mls:1.0

urn:peppol:edec:mls

This document type MUST use the Document Type Identifier Scheme busdox-docid-qns.

Full Peppol Document Type identifier
urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:peppol:edec:mls:1.0::2.1

9.2. XML Namespaces

The MLS data model is bound to the UBL Application Response 2.1. The target namespace for the UBL-ApplicationResponse-2.1 is:

urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2