The Peppol Business Interoperability Specification, “BIS” from here on after, has been developed by the OpenPeppol AISBL Post Award Coordinating Community and is published as part of the Peppol specifications.

Statement of copyright

This Peppol Business Interoperability Specification (BIS) document is based on the CEN CWA prepared by the BII workshop specified in the introduction below. The original CEN CWA document contains the following copyright notice which still applies:

© 2012 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.

The CEN CWA documents and profiles prepared by the BII workshop are not specific to a business area. Subject to agreement with CEN, customizations have been made by Peppol to establish the Peppol BIS, detailing and adding further guidance on the use of BII profiles.

OpenPeppol AISBL holds the copyright in the customizations made to the original document. The customizations appear from the corresponding conformance statement which is attached to this document. For the purpose of national implementations, customizations covered by the conformance statement may be further refined and detailed by Peppol Authorities and/or other entities authorized by OpenPeppol AISBL, provided that interoperability with Peppol BIS is ensured. This Peppol BIS document may not be modified, re-distributed, sold or repackaged in any other way without the prior consent of CEN and/or OpenPeppol AISBL.

Link to main site of documentation

Main documentation site

1. Introduction to openPeppol and BIS

This BIS is a result of work within OpenPeppol and is published as part of the Peppol specifications.

This Peppol BIS provides a set of specifications for implementing a Peppol business process. The document is concerned with clarifying requirements for ensuring interoperability of pan-European Public eProcurement and provides guidelines for supporting these requirements and how to implement them. This Peppol BIS is developed by OpenPeppol as a new business process.

The purpose of this document is to describe a common format for the invoice response message in the European market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding invoice responses based on this format.

1.1. Audience

The audience for this document is organizations wishing to be Peppol enabled for exchanging electronic business documents, and/or their ICT-suppliers.

These organizations may be:

  • Service providers

  • Contracting Authorities

  • Economic Operators

  • Software Developers

More specifically it is addressed towards the following roles:

  • ICT Architects

  • ICT Developers

  • Business Experts

For further information, please see Peppol BIS common text and introduction.

2. Principles and prerequisites

This chapter describes the principles and assumptions that underlie the use of the Peppol Invoice Response. The term Invoice in this specification is used for both an invoice and a credit note unless otherwise stated in the text or clear from the context.

An Invoice Response can be used in the process of the exchange of invoices and credit notes until the parties have agreed on its settlement as paid or cancelled. It provides the Seller, as the issuer of the invoice or credit note, with information about the status of his invoice or credit note and provides the Buyer, as receiver of the invoice or credit note, with efficient means for keeping the Seller informed.

2.1. Invoice Response message in general

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 way through the eventual processing of the message content; there may be a 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 in the scope of this document they can be divided into the following main groups.

IMR
Figure 1. Scope of different response message

2.1.1. Transport acknowledgements

These are messages that are exchanged within the transport network(s) to inform about the process of carrying a message down the transport line. These responses may inform someone up-line whether 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 the 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) and in Peppol they are part of the transport protocol of the Peppol network (Peppol eDelivery Network Specifications) (e.g. as MDN – Message Disposition Notification – in AS2).

2.1.2. Business Level Responses

A message that has been received and assigned to 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 invoice may be received but the receiver decides to dispute the invoice for any business reason such as incorrect values, delivery issues etc. The key nature of these responses is that they report a business decision that is made on the message instance received by the Receiver. Business level responses may have a role in the processing of various document types other than invoices.

2.2. Scope of Invoice Response message

Invoice Response is an invoice and credit note specific response message that can be used to inform the Seller of the status of an invoice in the Buyer’s approval and payment processes, based on the Buyer’s business rules and/or a Seller/Buyer agreement.

Invoice Response will provide following benefits to its users:

  • Invoice Response helps the Seller to initiate an action early in the case when processing of an invoice is challenged on the Buyer side.

  • The response informs Seller whether his invoice is in due process or whether that process is disrupted and requires action from Seller.

  • Invoice Response informs the Seller when their invoice has been approved or payment has been initiated so that the Seller can manage their cash flows and monitor the reception of funds through the payment channels.

  • Invoice Response provides automated means to the Buyer to keep the Seller informed of the invoice status in his invoice verification process and thus reduces or eliminates the need for manual status queries.

  • Invoice Response is designed to support automatic processing on the Seller side although it still may require manual actions.

  • Invoice Response is an informative message from Buyer to Seller.

  • Invoice Response structures the feedback loop from Buyer to Seller regarding the invoice handling process on Buyer’s side.

  • Invoice Response is an option for the Buyer to inform Seller about Buyer’s decisions in invoice processing in a structured or unstructured form.

2.2.1. In scope

The following concepts are within the scope of the Invoice Response:

  • Buyer can inform Seller about Invoice and credit note processing steps and statuses on Buyer’s side.

  • Invoice Response is based on Buyer’s business rules.

  • Invoice Response is a one directional message only - from Buyer to Seller.

  • Several response messages can potentially be exchanged for one invoice or credit note.

  • Response content may require manual action on Seller’s side.

  • Invoice Response supports only push message of the invoice status.

  • Invoice Response can not be automatically requested by Seller.

  • Acknowledging that a transmitted invoice has been received and can be processed.

2.2.2. Out of scope

The following concepts are outside the scope of the Invoice Response:

  • Invoice responses on a line level.

  • Several statuses in one response message.

  • Full automation on Seller side – not all the errors have to be encoded.

  • Bi-directional communication – discussion on response.

  • Enquiry of the Invoice response message.

  • Transmission level status.

  • Support for attachments.

2.3. Parties and roles

The table below gives the definitions of the parties and roles in the process of Invoice Response message. Parties are persons or entities who are responsible for roles. They may carry them out themselves or outsource them.

Table 1. Parties and roles
Party / Role Type Definition

Supplier

Party

The supplier is the legal person or organization who provides a product and/or service.

Examples of supplier roles: Seller, consignor, creditor, economic operator.

Customer

Party

The customer is the legal person or organization who is in demand of a product, service or works.

Examples of customer roles: buyer, consignee, debtor, contracting body.

Seller

Role

One who issues an invoice for items or services sold to a Buyer and to whom a debt is owed. The Party that claims the payment and is responsible for resolving billing issues and arranging settlement.

Also, known as Invoice Issuer, Accounts Receivable, Creditor, Economic operator.

Buyer

Role

One who receives an invoice for items or services bought from a Seller and who owes debt. The Party responsible for making settlements relating to a purchase.

Also, known as Invoicee, Accounts Payable, Debtor

Service provider

Party

A party that is contracted by either or both Supplier and/or the Customer to send or receive an Invoice Response message.
roles
Figure 2. Parties and roles

2.3.1. Parties responsibilities

Following paragraphs list the responsibilities and activities carried out by each party in the Invoice Response process from a technical, practical and informative perspective. Any legal implications of the measures discussed here are outside the scope of this document.

Seller

  • Not obliged to support the Invoice Response.

  • In case the Seller has registered support for the Invoice Response, then he is responsible for receiving an Invoice Response message and to take actions in accordance to this specification.

Buyer

  • Not obliged to send an Invoice Response.

  • Responsible for creating the Invoice Response.

  • Responsible for complying with the business rules used in invoice validations.

  • Responsible for when and how to use the Invoice Response in the frame of the Invoice Response document.

  • Responsible for expressing what action is expected from the Seller.

  • It is recommended that the Buyer maintains visibility of all Invoice Response messages created by him or on his behalf in order to solve potential issues with the Seller.

  • May have a bilateral agreement with Seller for using Invoice Response.

3. Process and typical use cases

3.1. Business process Diagram

3.1.1. Legend for BPMN diagrams

The diagrams are expressed in the BPMN notation. The diagram below serves as an explanation for the diagrams used in the process descriptions.

bpmn legend
Figure 3. BPMN legend

3.2. Process in general

The process starts when a Seller party is preparing an electronic invoice and then sends it to the Buyer. After the invoice has been validated and transported the Buyer party receives the invoice.

Once the Buyer has received the invoice in the form that it can be processed he may notify the Seller about this with an Invoice Response.

After reception, the Buyer will usually enter into the invoice reviewal and approval process. The approval process may result in the invoice being approved as is without any comments. In that case the Buyer sends an Invoice Response to the Seller to notify him that the invoice has been approved and will be paid on due date. Approval process might be a bit different for the credit note (especially as status “Paid” is not applicable, but the other statuses serve their purpose).

During the approval process, various issues may be identified. Issues such as quantities or amounts not being in line with Buyer’s data, missing information to correctly handle the invoice, invoice terms not in line with agreements or contracts and so forth. Depending on the nature of the issues the Buyer may do one of the following.

  • The Buyer may put the approval process on hold and notify the Seller by sending Invoice Response with status "under query" and add an explanation of what the issue is.

    • Once the Seller has responded to the issue the acceptance process may continue or the Buyer may raise further issues.

  • The Buyer may conditionally approve the invoice in which case they will send an Invoice Response to the Seller with the respective status and what the conditions are.

    • The Seller may respond externally, e.g. with an objection, or they may not respond in which case the Buyer will proceed and pay the invoice according to the conditions.

    • Most common example is when an invoice has payment terms like due date or payment account that are not in line with a contract.

    • Then the Buyer may notify that the invoice will be paid in accordance to the contract and then proceed to do so unless the Seller objects.

  • The Buyer may reject the invoice in which case it will notify the Seller and state the reason for the rejection and possibly request a credit note.

    • This is a final status for the invoice so if the Seller does not agree with the rejection they must follow that up externally.

If an invoice has been approved or conditionally approved the Buyer will in due time proceed to initiate payment. The Buyer may then notify the Seller that the payment has been initiated.

IMR bpmn
Figure 4. Common simplified invoice approval process

3.3. Invoice Response process rules

The Invoice Response process governs how and when the transactions are issued and how they are handled between the sender and the receiver.

Table 2. Invoice response process rules
RuleID Rule

OP-BR111-R001

The Invoice Response is one directional message only - from Buyer to Seller.

Invoice Response is meant to be sent from Buyer to Seller informing about invoice status inside the Buyer’s business process.

OP-BR111-R002

Each Invoice Response message is intended to carry one status code (top level status) at a time, for an individual invoice. To inform about several statuses of an Invoice then several messages shall be used in sequence. An invoice can only have one status at each time.

OP-BR111-R003

Several Invoice Response’s can be sent for one invoice.

OP-BR111-R004

If an invoice has been given the status Rejected or Paid, then no further Invoice Response may be sent regarding that invoice. I.e. Seller may ignore them.[1]

OP-BR111-R005

If an invoice has been given status Approved, then that may only be followed with an Invoice Response giving status Paid. I.e. Seller may ignore them.[1]

OP-BR111-R006

A Buyer shall provide first Invoice Response within 3 working days.

OP-BR111-R007

An Invoice Response message doesn’t prescribe the invoice workflow process for the Buyer. Different Buyers may have different workflows processes for the invoices.

OP-BR111-R008

An Invoice Response does not have any legal power.

OP-BR111-R009

An Invoice Response does not change the invoice content.

OP-BR111-R010

An Invoice Response does not change the commercial responsibilities between Buyer and Seller.

OP-BR111-R011

An Invoice Response (even as rejection) does not free the Buyer from his payment obligations towards the Seller if such an obligation exists by agreement or real business transaction or the other way around in case of a credit note.

OP-BR111-R012

The status of invoices shall advance in the following order.

AB

Acknowledged
IP

In process
UQ

Under query
CA

Conditionally accepted
RE

Rejected (Final status)
AP

Accepted (approved)
PD

Paid (Final status, The status code “Paid” will probably not be used in relation to credit notes)

The process may start at any status and not all statuses must be reported.

OP-BR111-R013

Seller can dispute any status presented by Buyer in Invoice Response with an external process.

OP-BR111-R014

Document type code must conform to the document type code of the original message the response is sent to (usually 380 for the commercial invoice and 381 for credit note).

3.4. Code Policy

Key information in an Invoice Response is the reporting of the status of the invoice. The objective of the status code is to provide the Seller with a clear indication of the status of the referenced invoice inside the Buyers process in a way that allows the Seller to clearly identify if an action is required on his behalf. The status code can be supplemented with a clarification or an action code or textual note that explains the status and assists the Seller in deciding on correct reaction.

The codes in the Invoice Response are given in the following structure.

  • Invoice Status (1..1) 'cac:DocumentResponse/Response/cbc:ResponseCode'

    • Clarification (0..n)

      • Data (0..n)

Each Invoice Response must have one and only one status code.

For each Invoice Response (status) there is the option of providing one or more clarification.

For each clarification there is the option to provide data that the Buyer proposes as a correction.

Example 1. Example

An invoice may have been put under query (status UQ), as clarification the code XYZ is given to indicate that there is an issue with the references in the invoice. As data the Invoice Response may state that the expected value for the Purchase Order reference in the invoice was PO123.

3.4.1. Status codes

The following policies apply to the use of status codes:

  • List of Status codes is fixed and can not be changed bilaterally.

  • There are seven pre-agreed status codes (main statuses).

  • Status code is sent from Buyer to Seller to inform the Seller about further processing of the invoice on Buyer side.

  • Status code does not inform the business reason for the Status to the Seller (there is a clarification code for that).

  • Every status can be the first status sent to the Seller but from there further statuses must follow a defined order (see Invoice Response process rules, rule OP-BR111-R012).

  • Maximum time for first response 3 days – The Seller should receive the first Invoice Response within 3 working days.

    • By receiving the first Response message the Seller will know that an Invoice has been received by the Buyer and what its status is.

    • However, if the Seller does not receive any response he should wait 3 working days before contacting the Buyer to query whether the Invoice was received.

    • A Buyer who has received an invoice should therefore provide a first Response before that time to notify the Seller that it has been received and what its status is.

  • The minimum set of Statuses that must be supported by a Buyer is “Message acknowledged”, “Rejected” and “Approved”.

The columns in the below table shall be understood as follows:
Status code

The code that defines the status of the reference document, e.g. AP.
UNECE name

The name of the code, based on UNECE code list 4343.
UNECE definition

The definition of the code, based on UNECE code list 4343.
BIS usage

An explanation of how the UNECE definition of the code shall be interpreted and applied in transactions that follow this BIS.
Response expected

Indicates that the Buyer expects a response from the Seller in accordance to the information given in the Invoice Response. If no response is expected, then the Buyer will proceed with the processing of the invoice without interruption. If a response is expected, then the Buyer will not proceed with the processing until the Seller has provided the response (externally).
Clarification required

Indicates that when Invoice Response message contains this code then a clarification must be provided by the Buyer in the form of a Status Reason code (See Code list section) or text or both.
Mandatory

Indicates that a Buyer who supports this BIS shall at minimum be able to report these statuses in the processing of the invoice. In other words, the Seller can at minimum expect to receive this status information.
Final

Indicates that this is a final status in the processing of the referenced invoice. The Seller will not receive any further Invoice Response messages referencing this invoice.
Table 3. The Status codes used in an Invoice Response message are defined in the below table and are a subset UNECE code list 4343 with additional codes.
Status Code UNECE name UNECE definition BIS usage Response expected Clarification Required Mandatory Final

AB

Message acknowledgement

Indicates that an acknowledgement relating to receipt of message or transaction is required.

Status is used when Buyer has received a readable invoice message that can be understood and submitted for processing by the Buyer.

NO

NO

YES

NO

IP

In Process

Indicates that the referenced message or transaction is being processed.

Status is used when the processing of the Invoice has started in Buyers system.

NO

NO

NO

NO

UQ

Under query

Indicates that the processing of the referenced message has been halted pending response to a query.

Status is used when Buyer will not proceed to accept the Invoice without receiving additional information from the Seller.

YES

YES

NO

NO

CA

Conditionally accepted

Indication that the referenced offer or transaction (e.g., cargo booking or quotation request) has been accepted under conditions indicated in this message.

Status is used when Buyer is accepting the Invoice under conditions stated in ‘Status Reason’ and proceed to pay accordingly unless disputed by Seller.

NO[2]

YES

NO

NO

RE

Rejected

Indication that the referenced offer or transaction (e.g., cargo booking or quotation request) is not accepted.

Status is used only when the Buyer will not process the referenced Invoice any further.
Buyer is rejecting this invoice but not necessarily the commercial transaction. Although it can be used also for rejection for commercial reasons (invoice not corresponding to delivery).

YES

YES

YES

YES

AP

Accepted

Indication that the referenced offer or transaction (e.g., cargo booking or quotation request) has been accepted.

Status is used only when the Buyer has given a final approval of the invoice and the next step is payment

NO

NO

YES

NO

PD with PPD (1)

Partially Paid

Indicates that the referenced document or transaction has been partially paid.

Status is used together with Clarification Reason code PPD, only when the Buyer has initiated the payment of the invoice without having paid the accepted amount in full.

NO

NO

NO

NO

PD

Fully Paid

Indicates that the referenced document or transaction has been paid.

Status is used only when the Buyer has initiated the payment of the invoice.

NO

NO

NO

YES

(1) Status code PD (Paid) together with Clarification Reason code PPD (Partially Paid) is the case when an invoice is partially paid with the intention of later paying the full invoice amount as was accepted.

The sequence of the status codes is fixed to allow the Seller, as receiver of the Invoice Response message, to advance the status of the invoice in his systems in an orderly way. See Invoice Response process rules. This requires the Buyer to be conservative in reporting status and only advance an invoice when the status is reasonably certain.

The status of an invoice must advance in the following sequence, but any status may be the first one used or may be omitted.

  1. AB – Message acknowledgement

  2. IP – In process

  3. UQ – Under query (may be repeated before moving forward)

  4. CA – Conditionally accepted

  5. RE – Rejected

  6. AP – Accepted

  7. PD – Paid, can be in steps, partially paid and then paid.

Example 2. Examples of status advancement:

  1. If an invoice is paid right after being received, the Buyer can report with a single Invoice Response using the code PD.

  2. If an invoice has been put under query then following the response from the Seller, the Buyer may advance it to any of the following codes:

    CA

    conditionally accepted
    RE

    Rejected
    AP

    Accepted
    PD

    Paid

Deviations from this sequence must be handled manually between the trading parties. As example, if a Buyer has stated that an invoice has been accepted they can not later send an Invoice Response indicating that it is under query or rejected. This does however not prohibit the Buyer from changing his decision, but he must report that to the Seller by other means than by using an Invoice Response.

The fixed order simplifies the automation of the processing for the receiver of the Invoice Response.

3.4.2. Clarification

Depending on the status code, a clarification may be needed to state the Buyer’s reason for the status and/or any expected action from the Seller’s side. The clarification may be given either as text (in Status Reason) or as code (in StatusReasonCode). The purpose of the clarification is to provide the Seller with structured information which enables him to partially or fully automate his processing. The clarifications are of two types.

  • Reasons for the given status.

  • Actions that the Buyer requests from the Seller.

These two types of clarifications are contained in separate code lists that have different list identifiers. This allows the Seller to distinguish between the two types of clarifications. Clarification codes are defined in Code list section.

Similar business reason (for example missing order number) may trigger different statuses depending on the Buyer’s business process. (e.g. missing order number - some of the Buyers might ’Reject’ the invoice but some of the Buyers might put it ’Under query’).

Detail type codes and values

For each clarification code the Buyer can provide details to assist in the correction. For example, if an invoice contains the wrong Buyers TAX number then the Buyer can provide the correct number in the Invoice Response. When a textual clarification that includes information about the correct values is not sufficient, but the correct values need to be provided in a structured way that information can be given by providing a type code that identifies the information type and the correct value.

The detail type code for each data type shall be the business term identifier of the referenced document that shall be corrected, and the detail value shall be the value that the Buyer proposes as the correct one.

Example:

A Buyer receives a Peppol invoice where the following is true

  • The invoice complies to Peppol Billing specification

  • The Buyer‘s TAX number in the invoice is incorrect and should be EU12345

  • The Buyer requests the Seller to send a credit note to cancel the incorrect invoice and issue a new invoice with the correct TAX number.

In the Billing specification for an invoice (See Peppol BIS Billing 3.0) the business term identifier for the Buyers TAX number is BT-48.

To inform and assist in resolution of the issue the Buyer sends an Invoice Response to the Seller as follows:

Invoice status

RE (Rejected)
Clarification code

LEG (Legal information missing)
Detail type code

BT-48
Detail value

EU12345

3.5. Typical use cases

The following use cases demonstrate how the Invoice Response message can be used in the described situations. While the use cases are drawn up to illustrate the general functionality of this BIS 63A, implementers are cautioned that national accounting rules may pose additional requirements on the handling of invoices.

No Use Case Name

1

Invoice in process.

2a

Invoice is in process with additional reference data.

2b

Invoice is in process but postponed.

3

Invoice is accepted.

4a

Invoice is rejected.

4b

Invoice is rejected requesting re-issue.

4c

Invoice is rejected requesting replacement.

5

Invoice is conditionally accepted.

6a

Invoice is under query because of wrong or missing information.

6b

Invoice is under query because of missing PO reference.

6c

Invoice is in under query because of wrong details, partial credit note requested.

7

Invoice payment has been initiated.

8

Invoice is accepted by a third party acting on behalf of the Buyer.

Example files are provided for all use cases, they are all available here: Use case example files
Table 4. Use case 1 — Invoice in process
Use Case number 1

Use Case Name

Invoice in process.

Assumption and description

Invoice has been received but a clear or final response is not possible within the Maximum response time
Therefore the Buyer must provide an initial response to inform the Seller that the invoice is in process within ‘Maximum Response time.

The flow

Invoice Response with 'In Process' status prior to ‘Maximum Response time'
Invoice Response with OTHER status is not part of the use case but the final status has to be delivered later when the invoice has been fully processed.

Parties involved

Buyer
Seller

Result

Seller is notified within the “Maximum Response Time” that the invoice is being processed.
A further Invoice Response will follow.
Table 5. Use case 2a — Invoice is in process with additional reference data
Use Case number 2a

Use Case Name

Invoice is in process with additional reference data.

Assumption and description

The Buyer wants to inform the Seller of the date when the Buyer has received an invoice as well as his internal reference ID for that invoice.

The flow

Invoice Response with 'In Process' status, including information about formal reception date and the internal reference for the invoice.

Parties involved

Buyer
Seller

Result

The Seller knows that invoice is in process and that the Buyer received it at a certain date. He knows the internal reference used by the Buyer for this invoice.
Table 6. Use case 2b — Invoice is in process but postponed
Use Case number 2b

Use Case Name

Invoice is in process but postponed

Assumption and description

Buyer informs Seller that a reference could not be validated but also indicates that a further attempt will be made to process the Invoice and so no further action is required at this time.

Buyer validates the invoice, but a Reference Number could not be matched to those on their system.

Buyer can re-attempt validation of the invoice (e.g. to allow updating of their internal Reference Number database in case the Reference Number details have not yet been processed ready for matching – or where the invoice arrives ahead of the goods).

The flow

Invoice Response with 'In Process' status and clarification text when invoice processing will continue, as no valid Reference Number was found.

Parties involved

Buyer
Seller

Result

Seller knows that the invoice is in the queue and the process is stopped until appointed date and then a further attempt will be made to match the Invoice.
Table 7. Use case 3 — Invoice is accepted
Use Case number 3

Use Case Name

Invoice is accepted

Assumption and description

Buyer has accepted the Invoice.

The flow

Invoice Response with 'Accepted' status and mandatory Invoice Response data indicating that an invoice is accepted.

Parties involved

Buyer
Seller

Result

Seller is notified that an invoice has been accepted and will be paid on due date.
Table 8. Use case 4a — Invoice is rejected
Use Case number 4a

Use Case Name

Invoice is rejected

Assumption and description

Buyer has rejected the invoice. Buyer doesn’t provide any encoded reasoning but provides only textual reason.

The flow

Invoice Response with 'Rejected' status and reasoning text why Invoice is rejected.

Parties involved

Buyer
Seller

Result

Seller is notified that an invoice has been rejected. In case further clarifications are needed, Seller needs to contact the Buyer for further actions (externally).
Table 9. Use case 4b — Invoice is rejected requesting re-issue
Use Case number 4b

Use Case Name

Invoice is rejected requesting re-issue

Assumption and description

Invoice is rejected e.g. because of missing PO reference. The Buyer may not have booked the invoice into his accounts, so he considers that a Credit note is not needed but a correct Invoice is needed.

The flow

Invoice Response with 'Rejected' status, explanatory clarification code e.g, for missing PO reference and instructive clarification code for issuing a correct Invoice.

Parties involved

Buyer
Seller

Result

Seller is notified that an invoice has been rejected because of missing PO reference.
Seller needs to add PO number to the Invoice and reissue it. How he handles the initial invoice is up to him.
Table 10. Use case 4c — Invoice is rejected requesting replacement
Use Case number 4c

Use Case Name

Invoice is rejected requesting replacement.

Assumption and description

The Invoice is rejected, Credit Note requested, and a new Invoice is requested.

The Buyer doesn’t accept the invoice content and rejects it. Buyer needs a Credit Note to cancel the original invoice and a new correct Invoice to continue with processing. The Buyer provides contact data and textual reasoning.

The flow

Invoice Response with 'Rejected' status with reasoning text why Invoice is rejected. Clarification codes for requesting a Credit Note and reissuing of a new Invoice. Buyer provides contact information to the Seller.

Parties involved

Buyer
Seller

Result

The Seller has been informed that the Invoice has been rejected. The Seller will proceed to issue a Credit Note for the referenced Invoice and a new Invoice to replace it.
The Seller can contact the Buyer using contact details provided in the Invoice Response.
Table 11. Use case 5 — Invoice is conditionally accepted
Use Case number 5

Use Case Name

Invoice is conditionally accepted

Assumption and description

The Invoice is conditionally accepted and will be paid on a date different from the Invoice due date.

The Buyer has accepted the invoice and intends to pay it according to agreement which gives a due date different from what is stated in the invoice.

The flow

Invoice Response with 'Conditionally accepted' status and explanatory clarification code for changed payment terms. The clarification includes information on what date the Invoice will be paid.

Parties involved

Buyer
Seller

Result

Seller is notified that Invoice has been conditionally accepted but will be paid on a date that is different from what was stated in the invoice. If the Seller accepts the change, he doesn’t need to react, otherwise he must contact the Buyer (externally).
Table 12. Use case 6a — Invoice is under query because of wrong or missing information.
Use Case number 6a

Use Case Name

Invoice is under query because of wrong or missing information.

Assumption and description

The Buyer cannot process the invoice and needs additional data from the Seller in order to proceed.

Buyer informs of the date when invoice was put under query (to allow for a potenital delay of the due date).

The flow

An Invoice Response is sent with 'Under query' status and clarification text stating what information is missing from the Invoice. Buyer informs of the reference date for the status.
Buyer provides his assumption for the correct data, if appropriate.
Buyer provides contact information to the Seller.

Parties involved

Buyer
Seller

Result

Seller has been notified that data is missing from the Invoice. Seller has notified about the date when the Invoice was put under query. Seller needs to forward the correct data to the Buyer (externally) to enable the Buyer to process the Invoice further.
Table 13. Use case 6b — Invoice is under query because of missing PO reference.
Use Case number 6b

Use Case Name

Invoice is under query because for example of missing PO reference.

Assumption and description

The Buyer cannot process the invoice because he requires a PO reference.

The flow

An Invoice Response is sent with 'Under query status, explanatory clarification code for missing PO reference and instructive clarification code for providing it.

Parties involved

Buyer
Seller

Result

The Seller has been notified that a PO reference is missing from the Invoice and that he must provide it in order for Buyer to continue with processing
Table 14. Use case 6c — Invoice is in under query because of wrong details, partial Credit Note is requested.
Use Case number 6c

Use Case Name

Invoice is in under query because of wrong details. A partial Credit Note is requested.

Assumption and description

The Buyer complains about a single line on the Invoice that doesn’t correspond to delivery and wants Seller to issue a Credit Note for that line.
The Buyer will hold the processing until a partial Credit Note is received

The flow

An Invoice Response is sent with 'Under query’ status, clarification text for incorrect Invoice line and instructive clarification code for issuing a Credit Note.

Parties involved

Buyer
Seller

Result

Seller has been notified that the Invoice has an incorrect Invoice Line and that he needs to issue a partial Credit Note.
Table 15. Use case 7 — Invoice payment has been initiated
Use Case number 7

Use Case Name

Invoice payment has been initiated

Assumption and description

The Buyer indicates to the Seller that an invoice payment has been initiated.

The flow

An Invoice Response is sent with 'Paid' status.

Parties involved

Buyer
Seller

Result

Seller knows that the payment will be received soon.
Table 16. Use case 8 — Invoice is accepted by a third party acting on behalf of the Buyer.
Use Case number 8

Use Case Name

Invoice is accepted by third party who acts on behalf of Buyer.

Assumption and description

The Buyer has contracted a service provider to handle Invoice to Order matching on his behalf.

The flow

Invoice Response with 'Accepted' status and mandatory Invoice Response data indicating that an Invoice is accepted. Sending Party differs from Buyer party details.

Parties involved

Buyer
Service provider
Seller

Result

Seller is notified that an Invoice has been accepted and will be paid on due date.

4. Semantic datatypes

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.

4.1. Primitive 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

Binary

A set of finite-length sequences of binary digits.

Date

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

Decimal

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

String

A finite sequence of characters.

4.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.

4.2.1. Amount

An amount states a numerical monetary value. The currency of the amount is defined as a separate business term.

Amount is floating up to two fraction digits.
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.25

4.2.2. Price Amount

A price amount states a numerical monetary amount value for data elements that contain item prices that may be multiplied by item quantities. The currency of the amount is defined as a separate business term.

Unit price amount does not set restrictions on number of decimals, as contrast to the Amount type
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.1234

4.2.3. Percentage

Percentages are given as fractions of a hundred (per cent) e.g. the value 34,78 % in percentage terms is given as 34,78.

No restriction on number of decimals for percentages.
Component Use Primitive Type Example

Content

Mandatory

Decimal

34.7812

4.2.4. Quantity

Quantities are used to state a number of units such as for items. The code for the Unit of Measure is defined as a separate business term.

No restriction on number of decimals for quantities.
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.1234

4.2.5. 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

4.2.6. 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

4.2.7. Date

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

Dates shall not include timezone information.
Table 17. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

2017-12-01

4.2.8. Time

Time shall be in accordance to the “Extended time format” as specified by ISO 8601:2004, format [hh]:[mm]:[ss].

Time shall not include timezone information. Decimal fraction on seconds SHALL not be used.
Table 18. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

09:30:12

4.2.9. Document Reference

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

Table 19. Document Reference. Type
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

4.2.10. 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

5% allowance when paid within 30 days

4.2.11. Binary objects

Binary objects can be used to describe files which are transmitted together with the business document. Attachments shall be transmitted together with the business document. The binary object has two supplementary components: a Mime Code, which specifies the Mime type of the attachment and a Filename that is provided by (or on behalf of) the sender of the business document.

Component Use Primitive Type Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

4.2.12. Boolean

Boolean indicators are used to specify the two allowed values, true or false. All elements of datatype Boolean, must have either true or false as their value.

Component Use Primitive Type Example

Content

Mandatory

String

true

5. Code lists

5.1. Code lists for coded elements

Any element with the semantic data type = code, can mandate the use of a specific code list (or a fixed value). The applicable code lists can be found in the Code list section. 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, or in other Peppol BIS v3. documents.

5.2. Code list for identifiers

5.2.1. Party identifiers and party legal registration identifier scheme

All party identifiers (cac:PartyIdentification/cbc:ID) and party legal registration identifier (cac:PartyLegalEntity/cbc:CompanyID) has an optional scheme identifier attribute (@schemeID). If used, the value shall be chosen from the code list ICD codes

Examples of usage in cac:PartyIdentification
<cac:PartyIdentification>
        <cbc:ID schemeID="0088">5790000435968</cbc:ID> (1)
</cac:PartyIdentification>
1 schemeID attribute is optional, but when used, the codes must be from ICD codes

5.2.2. 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).

Valid values are found here: EAS codes.

Examples of usage in cbc:EndpointID
<cbc:EndpointID schemeID="0184">DK87654321</cbc:EndpointID> (1)
1 schemeID attribute is mandatory

6. Description of selected parts of the invoice message response

6.1. Message identification

The first section of the message is concerned with identifying the message and declaring what specifications the message is based on.

UBL example:
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:invoice_response:3</cbc:CustomizationID> (1)
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:invoice_response:3</cbc:ProfileID> (2)
<cbc:ID>imrid001</cbc:ID> (3)
<cbc:IssueDate>2016-10-26</cbc:IssueDate> (4)
<cbc:IssueTime>12:00:00</cbc:IssueTime> (4)
1 The message is based on the Peppol transaction specification for transaction 111 and should therefore comply with the rules defined in that specification.
2 The profile ID states that the transaction is part of business process number 63 which is the Invoice Response process.
3 The identifier for this message, i.e. the identifier for this Invoice Response message, not the identifier of the invoice that is being responded to.
4 The date and the time when the response was issues is then provided

6.2. Message note

The Invoice Response enables the sender to provide a textual note that may give comments or instructions that apply to the whole response.

UBL example:
<cbc:Note>Please refer to previous email exchange regarding this invoice. </cbc:Note>

6.3. Sending and receiving parties

The sending and receiving parties are those that exchange the Invoice Response. These may be the Buyer and the Seller or service providers acting on their behalf.

6.3.1. SenderParty

The party that sends the Invoice Response. This may be the Buyer who received the invoice, or it may be a service provider processing the invoice on behalf of the Buyer. If the Invoice Response is issued by a service provider the name of the actual Buyer may be given with the invoice reference.

The information given for the sender is his EndpointID which is his Peppol Participant Identifier (PPID). The party identifier may be given as well and the schema that the identifier is based on. The name of the sender is then provided.

Contact information for the sender (Buyer) is the person that the receiver (Seller) can contact when resolving an issue reported in the Invoice Response. This should not be general company email and phone unless the sender has in place a process that would direct the contact efficiently to a relevant person.

UBL example:
<cac:SenderParty>
  <cbc:EndpointID schemeID="0196">6963495890</cbc:EndpointID>
  <cac:PartyIdentification>
    <cbc:ID schemeID="0088">senderif12345</cbc:ID>
  </cac:PartyIdentification>
  <cac:PartyLegalEntity>
        <cbc:RegistrationName>Buyer organization</cbc:RegistrationName>
  </cac:PartyLegalEntity>
  <cac:Contact>
    <cbc:Name>Invoice processing department</cbc:Name>
    <cbc:Telephone>012312312345</cbc:Telephone>
    <cbc:ElectronicMail>invoiceprocessingdepartment@organization.org</cbc:ElectronicMail>
  </cac:Contact>
</cac:SenderParty>

6.3.2. ReceiverParty

The party that sent the Invoice that the IMR is responding to. This is also the receiver of the Invoice Response. This may be the Seller who issued the invoice or a service provider who handles the invocing process on behalf of the Seller. If this is a service provider, then the actual Seller may be identified as part of the invoice reference information.

UBL example:
<cac:ReceiverParty>
  <cbc:EndpointID schemeID="0196">6841569459</cbc:EndpointID>
  <cac:PartyIdentification>
    <cbc:ID schemeID="0088">receiver12345</cbc:ID>
  </cac:PartyIdentification>
  <cac:PartyLegalEntity>
        <cbc:RegistrationName>Seller company</cbc:RegistrationName>
  </cac:PartyLegalEntity>
</cac:ReceiverParty>

6.3.3. Issuer and Recipient parties

In the case when the Invoice processing is handled by a service provider on behalf or the Buyer or the Seller then the sending/receiving party is not the Buyer/Seller stated in the Invoice document. In those cases, it is required to identify the Buyer and the Seller as declared in the referenced Invoice. This shall be done by giving an identifier and a name.

UBL example:
<cac:IssuerParty>
  <cac:PartyIdentification>
    <cbc:ID schemeID="0088">6543219876546</cbc:ID>
  </cac:PartyIdentification>
  <cac:PartyName>
    <cbc:Name>Seller A</cbc:Name>
  </cac:PartyName>
</cac:IssuerParty>
UBL example:
<cac:RecipientParty>
  <cac:PartyIdentification>
    <cbc:ID schemeID="0088">9876549873211</cbc:ID>
  </cac:PartyIdentification>
  <cac:PartyName>
    <cbc:Name>Buyer A</cbc:Name>
  </cac:PartyName>
</cac:RecipientParty>

6.4. Response

Is used to indicate the status of the Invoice. The response also provides information about the reason for the status as well as instructions on how the receiver of the Invoice Response is expected to react to the Invoice Response message.

This information is given in the following hierarchy:

  • Invoice processing status (of the invoice receiver).

    • Status clarification (Status reason and/or Status action)

      • Clarification detail

Each Invoice Response may only reference one invoice and that invoice can only have one status at a time. If the status of that Invoice changes the respective change must be reported with another Invoice Response.

The status clarification for the given status can be of either or both of two types - reason of that status and/or action expected by Seller. The purpose of this is to help Seller to understand the status and to resolve it in the correct way.

As example if an invoice is rejected it will be represented as status code RE (Rejected) in the Invoice Response. For clarification, the Invoice Response would then state why it is rejected and there may be more than one reason. The clarification may further give the instructions regarding actions expected from the Seller, for example to cancel the Invoice with a Credit Note and issue a new corrective Invoice.

To assist with resolution the Buyer might want to provide instructions on what is the correct data.

UBL example where TAX is VAT:
<cac:DocumentResponse>
  <cac:Response>
    <cbc:ResponseCode>RE</cbc:ResponseCode> (1)
    <cbc:EffectiveDate>2016-10-25</cbc:EffectiveDate>

      <cac:Status>
        <cbc:StatusReasonCode listID="OPStatusReason">LEG</cbc:StatusReasonCode> (2)
        <cbc:StatusReason>VAT Reference not found</cbc:StatusReason> (3)
        <cac:Condition>
          <cbc:AttributeID>BT-48</cbc:AttributeID> (4)
          <cbc:Description>EU123456789</cbc:Description> (5)
        </cac:Condition>
      </cac:Status>

      <cac:Status>
        <cbc:StatusReasonCode listID="OPStatusAction">CNF</cbc:StatusReasonCode> (6)
        <cbc:StatusReason>Credit fully</cbc:StatusReason> (6)
        </cac:Status>

      <cac:Status>
        <cbc:StatusReasonCode listID="OPStatusAction">NIN</cbc:StatusReasonCode> (7)
        <cbc:StatusReason>Issue new invoice</cbc:StatusReason> (7)
      </cac:Status>
  </cac:Response>
</cac:DocumentResponse>
1 An invoice is rejected using the status code RE.
2 The reason code for this rejection is LEG indicating that the invoice does not fulfil legal requirements
3 In text it is stated that the TAX reference is not found
4 Further reference is given to the element BT-48 in the Invoice (Buyers TAX number)
5 Expected value in BT-48 is EU123456789
6 The Buyer expects the Seller to issue a Credit Note that fully cancels the rejected Invoice
7 The Buyer also expects the Seller to issue a new Invoice with corrected information.

6.5. Document reference

Used to provide a reference to the business document e.g. the invoice or credit note, to which the Invoice Response is is responding.

One Invoice Response may only reference one business document.

The type of the business document must also be included in the document reference element. Document Type Code is coded according to code list 1001 issued by UN/CEFACT.

See chapter Code list section for a complete list of all the document types.

UBL example:
<cac:DocumentReference>
  <cbc:ID>inv021</cbc:ID> (1)
  <cbc:IssueDate>2017-11-30</cbc:IssueDate> (2)
  <cbc:DocumentTypeCode>380</cbc:DocumentTypeCode> (3)
</cac:DocumentReference>
1 Value from the ID element in the invoice for which this response is valid, found in element cbc:ID in the received invoice
2 The issue date of the invoice for which this response is valid, found in element cbc:IssueDate in the received invoice
3 The invoice type in the invoice for which this response is valid, found in element cbc:DocumentTypeCode in the received invoice

7. Peppol Identifiers

Peppol has defined a Peppol Policy for identifiers, policy 8 that specifies how to use identifiers in both its transport infrastructure and within the documents exchanged across that infrastructure. It also introduces principles for any identifiers used in the Peppol environment. The policies that apply to this BIS are the following:

7.1. Profiles and messages

All messages contains 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.

CustomizationID is a string without spaces. The list below contains spaces in CustomizationID to make them easier to read. Make sure to remove any spaces before use.

7.2. Customization and Profile identifiers

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

Invoice message response (Trns111)

urn:fdc:peppol.eu:poacc:trns:invoice_response:3

urn:fdc:peppol.eu:poacc:bis:invoice_response:3

7.3. Namespaces

The message level response data model is in this Peppol BIS 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

1. Business situations that require exceptions to these rules are not prohibited by this BIS but are not supported by the Invoice Response described in it. Such business situations must be handled externally between the trading parties.
2. When an invoice is conditionally accepted (CA) the Buyer will proceed with the processing according to the conditions it has stated. The Seller may still respond externally if he has comments or objections to the conditions given.