OIOUBL BIS Billing with Response

v3.0.0 RC

The Business Interoperability Specification,, called the “OIOUBL BIS” from here on, has been developed by the Danish Business Authority.

1. Document Structure

This document is structured as follows:

Chapters 1 - 3 Provides general information on the business processes, use cases and functionalities.
Chapter 4 Describes the primitive and semantic data types.
Chapter 5 Provides information about identifiers, e.g. customization and profile identifiers .
Chapter 6 Provides examples of selected parts of the invoice.
Chapter 7 Provides examples of selected parts of the invoice response.
Chapter 8 Statement of license and copyright.
Chapter 9 Link to the main site for additional documentation.

2. Parties and roles

OIOUBL BIS 3 Billing supports the following parties:

2.1. Supplier side parties

These parties are involved on the supplier’s side of the transaction, and will usually be the supplier or the supplier’s contractors.

AccountingSupplierParty: The original creditor to the claim that the invoice is presenting to the debtor. This party is the only mandatory party for the supplier side of the transaction. If the other supplier side roles are not included in the document, the creditor is deemed to fulfil these as well.

PayeeParty: The party to receive payment for the invoice, when this is not the creditor (e.g. in the case of factored invoices).

SellerSupplierParty: The party who made the sale, where this is different from the creditor. Used in cases where the seller is not the creditor, for instance because the seller is acting as an agent of the creditor.

TaxRepresentativeParty: The party responsible for creditor’s VAT compliance, provided this is not the creditor. Rarely used in Denmark.

2.2. Customer side parties

These parties are involved on the customer’s side of the transaction, and will usually be the customer or the customer’s contractors.

AccountingCustomerParty: The debtor, who has received a consideration from the seller, and is therefore liable to pay the invoiced amount. This party is the only mandatory party for the customer side of the transaction. If the other customer side roles are not included in the document, the debtor is deemed to fulfil these as well.

BuyerCustomerParty: The party who issued the purchase order, where this is different from the debtor. Used in cases where the buyer is not the debtor, for instance because the buyer is acting as an agent of the debtor.

DeliveryParty: The party to whom delivery is made, when distinct from the debtor. Note that this is distinct from the delivery location, which is a physical location where delivery takes place. The address associated with the DeliveryParty is the correspondance address for the party, not the physical location of delivery.

DeliveryParty may be specified at document or line level, depending on whether the invoice covers more than one delivery or not.

OriginatorParty: The party that requisitioned the purchase, where this is different from the buyer or debtor. Used in cases where it is important to be able to track where in the customer’s organization the purchase originated (e.g. because the originator is part of the control flow for the invoice).

OriginatorParty is specified at the invoice line level.

2.3. Logistics Parties

These parties are not involved in the transaction as such; only in the delivery of goods from supplier to customer. However, the invoice recipient may require this information, e.g. for compliance reasons or to match against a receipt they have issued for delivery of goods.

The logistics parties are associated with individual consignments, as different consignments may be shipped from different warehouses using different carriers and forwarders.

CarrierParty: The carrier employed in the delivery of goods. This is the party that actually physically moves the consignment.

FreightForwarderParty: The freight forwarder employed in the delivery. This is the party that arranges for paperwork, warehousing, etc. along the consignment’s journey, and coordinates between different carriers.

OriginalDespatchParty: The party responsible for the original despatch. Typically the operator of the warehouse from which the goods were sent.

2.4. Other parties

ManufacturerParty: The party that originally manufactured the item. May or may not be party to the actual transaction. Used when it is important to be able to identify which manufacturer a given item is sourced from (e.g. because the customer and supplier have a frame agreement with different discount schemes for different manufacturers).

Manufacturer party is specified at the item level.

IssuerParty: The party that issued a document referenced in the invoice. Usually not a party to the transaction itself, but the parties to the transaction may wish to be able to track the issuer of documents such as material safety data sheets or certificatoins of conformity.

SignatoryParty: The party issuing a digital signature included in the invoice.

One who owes debt. The party responsible for making settlement relating to a purchase. The party that receives the invoice or credit note. Also known as invoicee, accounts payable, or buyer.

3. Business Processes

3.1. General invoicing processes

The invoicing process includes issuing and sending the invoice and the credit note from the supplier to the customer and the reception and handling of the same at the customer’s site.

The invoicing process is shown in this work flow:

A supplier issues and sends an invoice to a customer. The invoice refers to one or more deliveries of goods and services.

An invoice may also refer to one or more preceding orders, contracts or frame agreements. The invoice shall describe the delivered goods and services, and may reference the article numbers or manufacturer or other IDs.

The customer receives the invoice and processes it in their invoice control system(s), leading to one of the following results:
1. The customer fully approves the invoice, posts it in the accounting system and passes it on to be paid.
2. The customer disputes the invoice in its entirety, contacts the supplier and requests a credit note.
3. The customer disputes parts of the invoice, contacts the supplier and requests a credit note and a new invoice.

The diagram below shows the basic invoicing process supported by this OIOUBL BIS profile.

This profile covers the following invoice processes:

P1	Invoicing of deliveries of goods and services against purchase orders, based on a contract
P2	Invoicing deliveries of goods and services based on a contract
P3	Invoicing the delivery of an incidental purchase order
P4	Pre-payment
P5	Spot payment
P6	Payment in advance of delivery
P7	Invoices with references to a despatch advice
P8	Invoices with references to a despatch advice and a receiving advice
P9	Credit notes or invoices with negative amounts, issued for a variety of reasons including the return of empty packaging
P10	Corrective invoicing (cancellation/correction of an invoice)
P11	Partial and final invoicing

3.2. Invoice Response principles and prerequisites

This chapter describes the principles and assumptions that underlie the use of the 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 before 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 the invoice or credit note and provides the Buyer, as receiver of the invoice or credit note, with efficient means for keeping the Seller informed and maintain a secure record of their response.

3.2.1. Invoice Response message in general

Once an electronic business document is created and passed to the recipient’s endpoint, there may be a need to inform relevant parties involved in the data exchange about the message’s status or validation results. These response types are different in nature and for the purpose of this document they can be divided into the following main groups:

Figure 1. Flow of different response messages

Once an electronic business message is delivered to the recipient, there may be a need to inform involved parties about the message’s status or validation results. These response types are different in nature, and for the purpose of this document they can be divided into the following main groups:

Transport acknowledgement

This message is exchanged within the transport network(s), to inform on the status of a message which is being exchanged between parties. These responses may inform a counterparty about the status of a delivery (success/failure/in process), and may contain details about relevant issues, such as why a delivery was not successful. The key feature of these responses is that they do not inform on results of validation or processing of the of the payload content that is being transported. These response messages are commonly called “acks”.

Message Level Response

When a message has reached a given point in a data exchange, its content may be validated according to agreed specifications. Such specifications may be syntactical and/or semantic. The outcome of these validations may be reported to a relevant up-stream party. These outcomes include the success or failure of the validation, along with additional explanatory details on errors. An example could be an order message that is rejected after receipt, because the subtotals do not add up to the order total (syntax error), or because a free text field is used to provide information for which the BIS prescribes a specific data structure (semantic error). Message level responses do not report on the business content of the communication, only on syntactic and semantic (in)validity.

Business Level Response

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-stream to a relevant party. An example is where a technically correct invoice may be received but the receiver decides to dispute the invoice for a business reason, such as incorrect values, delivery issues etc. The key feature of these responses is that they report a business decision that is made on the message instance which is received.

This specification is only concerned with the Business Level Responses, specifically in response to invoices.

3.2.2. Scope of the Invoice Response message

The Invoice Response is a response message specific to invoices and credit notes. The invoice response can be used to inform the Seller of the status of an invoice in the Buyer’s approval and payment processes.

Invoice Response provides the following benefits to its users:

Invoice Response helps the Seller to initiate an action early in the case when the processing of an invoice is challenged on the Buyer side.
Invoice Response informs the Seller whether his invoice is following the ordinary approval process, or 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 an automated means for 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 provides the structure for 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 the Buyer’s decisions when invoice processing in a structured form.
Invoice Reponse provides the parties with a clear record of their communication, should either party need to document this interaction at a later date.

In scope

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

Buyer can inform the Seller about Invoice and Credit Note processing steps and statuses on Buyer’s side.
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.
Invoice 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.
Invoice Response can acknowledge that a transmitted Invoice has been received and can be processed, or communicate an acceptance, partial acceptance or rejection.

Out of scope

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

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.
Inquiry of the Invoice response message.
Transmission level status.
Support for attachments.

3.3. Invoice Response process and typical use cases

3.3.1. Process in general

The process starts when a Seller party has sent an electronic invoice to the Buyer, and the invoice has been received without identified syntax or semantic errors.

After reception, the Buyer will usually send the invoice to the review and approval process. The approval process may result in the invoice being approved 'as is' without any comments. In this case the Buyer sends an Invoice Response to the Seller, to notify him that the invoice has been approved and will be paid on the due date. The approval process may be different for the Credit Note, which is generally not intended to result in a payment by the Buyer. However, there may still be a need or desire for the Buyer to communicate the status of the Credit Note to the Buyer (e.g. to confirm that it has been accepted, so a corrective invoice can be issued).

Alternatively, the approval process may result in various issues with the invoice being identified. Such issues could be:

Discrepancies between the information in the invoice and the Buyer’s records, on such matters as prices or volumes.
Discrepancies between the invoice terms and the terms of a binding prior agreement, e.g. wrong payment terms.
Invoice fails to meet invoicing requirements set by prior agreement between the parties, e.g. in the specificity of the description of goods and services delivered.
Invoice is for goods or services not ordered or delivered.
Invoice is for goods or services only partially delivered, but invoiced for the full amount.

Depending on the nature of the issues the Buyer has the following options:

The Buyer may put the approval process on hold and notify the Seller by sending an Invoice Response with the status 'under query' and add a further explanation of the issue(s).
- 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 outside of the electronic communication process with an objection, or they may not respond in which case the Buyer will proceed and pay the invoice according to the conditions.
- The most common examples are when an invoice has payment terms like due date or payment account that are not in line with a contract.
- The Buyer may notify the Seller 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 the Buyer 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 this up outside of the electronic communication process.

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.

Figure 2. Common simplified invoice approval process

3.3.2. Code Policy

A key feature in an Invoice Response is to report of the status of an Invoice. The objective of the status code is to provide the Seller with a clear indication of the status of the referenced Invoice in the Buyers process in a way that clearly identifies if an action is required by the Seller. 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 the correct response.

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 a status 'under query' (status UQ), as clarification the code XYZ is given to indicate that there is an issue with the references in the Invoice. For example, the information in the Invoice Response may state that the expected value for the Purchase Order reference in the Invoice was PO123.

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 (the clarification code performs this function).
Any status can be the first status sent to the Seller however further statuses must follow a defined order (see [invoice-response-process-rules], rule OP-BR111-R012).
On receipt of the first Invoice Response the Seller will know that an Invoice has been received by the Buyer and also be informed of the Invoice current status.
- If the Seller does not receive any response, the Seller may assume that the invoice is accepted without comment.
- Buyer and Seller may have made other bilateral arrangements regarding the coreography, for example:
  - A contractual requirement on the buyer to dispute invoices within a set number of business days
  - An obligation to positively affirm receipt or approval of an invoice, for the purpose of enabling factoring of the invoice.
- Such bilateral arrangements, and their impact on the obligations of the parties, are a matter of contract law and beyond the scope of this BIS.
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 a 'clarification required' code, then a clarification must be provided by the Buyer in the form of a Status Reason Code (See OIOUBL 3 Kodelister) or text or both.
Mandatory	Indicates that a Buyer who supports this BIS shall at minimum be able to report these statuses when processing the Invoice. In other words, the Seller can at a minimum expect to receive the status information.
Final	Indicates that this is a final status when processing the referenced invoice. The Seller will not receive any further Invoice Response messages referencing this invoice.

Table 1. 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 acknowledgement that the invoice or credit note has been received and will be processed.	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 invoice or credit note is being processed. Distinct from status code AB Message Acknowledgement in that code IP In Process may contain additional clarifications.	Status is used to inform Seller of states in Buyer’s approval flow that require no action from Seller (e.g. an internal tracking number that Seller can use in follow-up queries, the reason for a delay, or the approval step that the invoice is at).	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 invoice or credit note 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^[1]	YES	NO	NO
RE	Rejected	Indication that the referenced invoice or credit note 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 (e.g. rejecting an invoice for wrong payment due date). Although it can be used also for rejection for commercial reasons (the underlying claim is disputed, e.g. product not delivered). Unless otherwise agreed between the parties, the clarification should include the extent to which the underlying claim is disputed.	YES	YES	YES	YES
AP	Accepted	Indication that the referenced invoice or credit note 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.

AB – Message acknowledgement
IP – In process
UQ – Under query (may be repeated before moving forward)
CA – Conditionally accepted
RE – Rejected
AP – Accepted
PD – Paid, can be in steps, partially paid and then paid.

Example 2. Examples of status advancement:

If an invoice is paid right after being received, the Buyer can report with a single Invoice Response using the code PD.
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 an 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 not in itself prohibit the Buyer from changing the original decision (though prior agreement or general principles of contract law may), but the Buyer must report this 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.

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 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 the Seller to partially or fully automate 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 OIOUBL 3 Kodelister.

Similar business reasons, for example missing order number, may trigger different statuses depending on the Buyer’s business process e.g. missing order number - some Buyers might ’Reject’ the invoice but some 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 VAT ID for the Buyer, then the Buyer can provide the correct ID in the Invoice Response. When providing such data, it should when possible be provided in a structured format (type code), which identifies the information type and the correct value.

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

Example:

A Buyer receives an Invoice where the following is true:

The Invoice complies to OIOUBL BIS Billing specification.
The Buyer‘s VAT ID 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 VAT ID.

The EN 16931 business term identifier for the Buyers TAX number is BT-48. To inform and assist in resolving the issue the Buyer sends an Invoice Response to the Seller as follows:

Invoice status	RE (Rejected)
Clarification code	LEG (Legal information incorrect)
Detail type code	BT-48
Detail value	EU12345

3.3.3. Typical use cases

The following use cases demonstrate how the Invoice Response can be used in various scenarios. This list is not intended to be comprehensive; the use cases are drawn up to illustrate the general functionality.

No	Use Case Name
1a	Invoice in process.
1b	Invoice is in process with additional reference data.
1c	Invoice is in process but postponed.
2a	Invoice is accepted.
2b	Invoice is accepted by a third party acting on behalf of the Buyer.
3a	Invoice is rejected.
3b	Invoice is rejected requesting replacement.
4	Invoice is conditionally accepted.
5a	Invoice is under query because of wrong or missing information.
5b	Invoice is under query because of missing purchase order (PO) reference.
5c	Invoice is in under query because of wrong details, partial Credit Note requested.
6	Invoice payment has been initiated.

Use Case Name

Invoice in process.

Invoice is in process with additional reference data.

Invoice is in process but postponed.

Invoice is accepted.

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

Invoice is rejected.

Invoice is rejected requesting replacement.

Invoice is conditionally accepted.

Invoice is under query because of wrong or missing information.

Invoice is under query because of missing purchase order (PO) reference.

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

Invoice payment has been initiated.

Table 2. Use case 1a — Invoice In Process
Use Case number	1a
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 agreed between the Parties Therefore the Buyer must provide an initial response to inform the Seller that the invoice is 'In Process' within agreed upon maximum response time.
The flow	Invoice Response with 'In Process' status prior to the agreed deadline. The final status has to be delivered later when the invoice has been fully processed.
Parties involved	Buyer Seller
Result	Seller is notified that the invoice is being processed, and a further Invoice Response will follow.

Table 3. Use case 1b — Invoice is 'In process with additional reference data'
Use Case number	1b
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 together with the Buyer’s internal reference ID for that invoice.
The flow	Invoice Response with 'In Process' status, including information about formal date of receipt and Buyer’s reference ID for the invoice.
Parties involved	Buyer Seller
Result	The Seller knows that invoice is in process and that the Buyer received it on a certain date. The Seller is informed of the internal reference used by the Buyer for this invoice.

Table 4. Use case 1c — Invoice is 'In process but postponed'
Use Case number	1c
Use Case Name	Invoice is 'In process but postponed'
Assumption and description	Buyer informs Seller that a reference could not be validated, but a further attempt will be made to process the Invoice at a later date. No further action is required at this time. Buyer validates the invoice, but a reference number could not be matched to those on the Buyer’s system. E.g. Buyer’s invoice processing system does not show the goods received notice from Buyer’s inventory processing system. Buyer has reason to expect that the Invoice will pass validation at a later date without any action needed from Seller. E.g. Buyer knows that there is a synchronization delay between their inventory management and invoice processing systems, or believes that the invoice has arrived ahead of the goods.
The flow	Invoice Response with 'In Process' status and clarification text providing a date when invoice processing will continue/be retried.
Parties involved	Buyer Seller
Result	Seller knows that the Invoice is in the payment queue and the process is stopped until an appointed date when a further attempt will be made to match the Invoice.

Table 5. Use case 2a — Invoice is 'Accepted'
Use Case number	2a
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 by the due date.

Table 6. Use case 2b — Invoice is 'Accepted by a third party acting on behalf of the Buyer'.
Use Case number	2b
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 the Buyer’s 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 the due date.

Table 7. Use case 3a — Invoice is 'Rejected'
Use Case number	3a
Use Case Name	Invoice is 'Rejected'
Assumption and description	Buyer has rejected the invoice. Buyer does not provide any encoded reasoning for the rejection but does provide a free text description of the reason.
The flow	Invoice Response with 'Rejected' status and a free text rejection reason.
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 8. Use case 3b — Invoice is 'Rejected requesting replacement'
Use Case number	3b
Use Case Name	Invoice is 'Rejected requesting replacement'.
Assumption and description	Invoice is rejected. A Credit Note and a new Invoice are requested. The Buyer does not accept the invoice content and rejects it, e.g. because of missing purchase order (PO) reference. 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, explanatory clarification as text or code (e.g. missing PO reference) and instructive clarification code for issuing Credit Note and re-issuing of a new Invoice by Seller. 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 9. Use case 4 — Invoice is 'Conditionally accepted'
Use Case number	4
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' and will be paid on a date that is different from what was stated in the Invoice. If the Seller accepts the change, the Seller does not need to react, otherwise the Seller must contact the Buyer (externally).

Table 10. Use case 5a — Invoice is 'Under query because of wrong or missing information'.
Use Case number	5a
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 the Invoice was put under query (to allow for a potential 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 the incorrect/missing data, as 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 been 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 11. Use case 5b — Invoice is 'Under query' e.g. missing purchase order (PO) reference.
Use Case number	5b
Use Case Name	Invoice is 'Under query' because for example of missing purchase order (PO) reference.
Assumption and description	The Buyer cannot process the invoice because he requires a PO reference. Distinct from use case 5a "Under query because of wrong or missing information," because the missing information in this case is covered by a structured status code.
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 the Seller must provide it in order for Buyer to continue with processing. Seller’s system has the possibility to automatically identify the missing or invalid information, because an explicit code has been provided for it, rather than a free text description.

Table 12. Use case 5c — Invoice is 'Under query because of incorrect details, partial Credit Note is requested'.
Use Case number	5c
Use Case Name	Invoice is 'Under query because of incorrect details'. A partial Credit Note is requested.
Assumption and description	The Buyer objects to a single line on the Invoice that doesn’t correspond to the delivery and wants the Seller to issue a Credit Note for that line. The Buyer will hold the Invoice processing until a partial Credit Note is received
The flow	An Invoice Response is sent with an '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 13. Use case 6 — Invoice 'Payment has been initiated'
Use Case number	6
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 before long.

4. Invoice functionality

4.1. Calculation

4.1.1. Calculation of totals

Formulas for the calculations of totals are as follows:

Business term id	Term name	Calculation
BT-106	Sum of invoice line net amounts	\$sum("BT-131: Invoice line net amount")\$
BT-107	Sum of allowances on document level	\$sum("BT-92: Document level allowance amount")\$
BT-108	Sum of charges on document level	\$sum("BT-99: Document level charge amount")\$
BT-109	Invoice total amount without VAT	\$\ \ \ \ "BT-106: Sum of invoice line net amounts"\$ \$- \ "BT-107: Sum of allowances on document level"\$ \$+ \ "BT-108: Sum of charges on document level"\$
BT-110	Invoice total VAT amount	\$sum("BT-117: VAT category tax amount")\$
BT-112	Invoice total amount with VAT	\$\ \ \ \ "BT-109: Invoice total amount without VAT"\$ \$+ \ "BT-110: Invoice total VAT amount"\$
BT-115	Amount due for payment	\$\ \ \ \ "BT-112: Invoice total amount with VAT"\$ \$- \ "BT-113: Paid amount"\$ \$+ \ "BT-114: Rounding amount"\$

Business term id

Term name

Calculation

BT-106

Sum of invoice line net amounts

\$sum("BT-131: Invoice line net amount")\$

BT-107

Sum of allowances on document level

\$sum("BT-92: Document level allowance amount")\$

BT-108

Sum of charges on document level

\$sum("BT-99: Document level charge amount")\$

BT-109

Invoice total amount without VAT

\$\ \ \ \ "BT-106: Sum of invoice line net amounts"\$
\$- \ "BT-107: Sum of allowances on document level"\$
\$+ \ "BT-108: Sum of charges on document level"\$

BT-110

Invoice total VAT amount

\$sum("BT-117: VAT category tax amount")\$

BT-112

Invoice total amount with VAT

\$\ \ \ \ "BT-109: Invoice total amount without VAT"\$
\$+ \ "BT-110: Invoice total VAT amount"\$

BT-115

Amount due for payment

\$\ \ \ \ "BT-112: Invoice total amount with VAT"\$
\$- \ "BT-113: Paid amount"\$
\$+ \ "BT-114: Rounding amount"\$

UBL syntax calculation formulas

The following elements show the legal monetary totals for an Invoice or Credit Note

Element	Formula
<cbc:LineExtensionAmount>	\$sum("cac:InvoiceLine/cbc:LineExtensionAmount")\$
<cbc:AllowanceTotalAmount>	\$sum("cac:AllowanceCharge[ChargeIndicator='false']/cbc:Amount")\$
<cbc:ChargeTotalAmount>	\$sum("cac:AllowanceCharge[ChargeIndicator='true']/cbc:Amount")\$
<cbc:TaxExclusiveAmount>	\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:LineExtensionAmount"\$ \$– \ "cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount"\$ \$+ \ "cac:LegalMonetaryTotal/cbc:ChargeTotalAmount"\$
<cbc:TaxInclusiveAmount>	\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount"\$ \$+ \ "cac:TaxTotal/cbc:TaxAmount"\$
<cbc:PrepaidAmount>	Not applicable
<cbc:PayableRoundingAmount>	Not applicable
<cbc:PayableAmount>	\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount"\$ \$- \ "cac:LegalMonetaryTotal/cbc:PrepaidAmount"\$ \$+ \ "cac:LegalMonetaryTotal/cbc:PayableRoundingAmount"\$

Element

Formula

<cbc:LineExtensionAmount>

\$sum("cac:InvoiceLine/cbc:LineExtensionAmount")\$

<cbc:AllowanceTotalAmount>

\$sum("cac:AllowanceCharge[ChargeIndicator='false']/cbc:Amount")\$

<cbc:ChargeTotalAmount>

\$sum("cac:AllowanceCharge[ChargeIndicator='true']/cbc:Amount")\$

<cbc:TaxExclusiveAmount>

\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:LineExtensionAmount"\$
\$– \ "cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount"\$
\$+ \ "cac:LegalMonetaryTotal/cbc:ChargeTotalAmount"\$

<cbc:TaxInclusiveAmount>

\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount"\$
\$+ \ "cac:TaxTotal/cbc:TaxAmount"\$

<cbc:PrepaidAmount>

Not applicable

<cbc:PayableRoundingAmount>

Not applicable

<cbc:PayableAmount>

\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount"\$
\$- \ "cac:LegalMonetaryTotal/cbc:PrepaidAmount"\$
\$+ \ "cac:LegalMonetaryTotal/cbc:PayableRoundingAmount"\$

Element for rounding amount, the PayableRoundingAmount

It is possible to round the expected payable amount.

The element cac:LegalMonetaryTotal/cbc:PayableRoundingAmount is used for this purpose and is specified on the header level. This value shall be added to the value in: cac:LegalMonetaryTotal/cbc:PayableAmount.

Example: Amount 999.81 rounded to 1000. PayableRounding Amount = 0.19

4.1.2. Calculation on line level

Item net price (BT-146)

If gross price and discount exist, the Item net price has to equal with the item gross price less the item price discount.

Calculation formula:

\$"Item net price" = "Item gross price (BT-148)" - "Item price discount (BT-147)"\$

UBL example of item net price

<cac:Price>
    <cbc:PriceAmount currencyID="DKK">410</cbc:PriceAmount>(3)
    <cbc:BaseQuantity unitCode="XPK">1</cbc:BaseQuantity>
    <cac:AllowanceCharge>
        <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
        <cbc:Amount currencyID="DKK">40</cbc:Amount>(2)
        <cbc:BaseAmount currencyID="DKK">450</cbc:BaseAmount>(1)
    </cac:AllowanceCharge>
</cac:Price>

1	Item gross price
2	Item price discount
3	\$"Item price net amount" = "Item gross price" - "Item price discount"\$

Invoice line net amount (BT-131)

The invoice line net amount (BT-131) is as the name implies the net amount without VAT and inclusive of line level allowance and charges.

The formula for calculating the invoice line net amount is:

\$"Item line net amount" = (("Item net price (BT-146)" div "Item price base quantity (BT-149)")\$
\$times ("Invoiced Quantity (BT-129)")\$
\$+ "Invoice line charge amount (BT-141)" - "Invoice line allowance amount (BT-136)"\$

As the line net amount must be rounded to two decimals, please note that the different parts of the calculation must be rounded separately.
I.e the result of \$"Item line net amount" = (("Item net price (BT-146)" div "Item price base quantity (BT-149)") times ("Invoiced Quantity (BT-129)")\$ must be rounded to two decimals, and the allowance/charge amounts are also rounded separately.

UBL example of invoice line net amount where no line allowance/charge exist

<cbc:InvoicedQuantity unitCode="XPK">10</cbc:InvoicedQuantity>(3)
<cbc:LineExtensionAmount currencyID="DKK">1000.00</cbc:LineExtensionAmount>(4)

<!-- Code omitted for clarity-->

<cac:Price>
    <cbc:PriceAmount currencyID="DKK">200</cbc:PriceAmount>(1)
    <cbc:BaseQuantity unitCode="XPK">2</cbc:BaseQuantity>(2)
</cac:Price>

1	Item net price
2	Item price base quantity
3	Invoiced quantity
4	\$"Invoice line net amount" = (("Item net price" div "Item price base quantity") times ("Invoiced Quantity")\$

UBL example of invoice line net amount where line allowance and charge exist

<cbc:InvoicedQuantity unitCode="XPK">10</cbc:InvoicedQuantity>(4)
<cbc:LineExtensionAmount currencyID="DKK">900.00</cbc:LineExtensionAmount>(5)

<!-- Code omitted for clarity-->

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Charge</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>1</cbc:MultiplierFactorNumeric>
    <cbc:Amount currencyID="DKK">1</cbc:Amount>(2)
    <cbc:BaseAmount currencyID="DKK">100</cbc:BaseAmount>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="DKK">101</cbc:Amount>(3)
</cac:AllowanceCharge>

<!-- Code omitted for clarity-->

<cac:TaxTotal>
    <cbc:TaxAmount currencyID="DKK">225.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
        <cbc:TaxableAmount currencyID="DKK">900.00</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="DKK">225.00</cbc:TaxAmount>
        <cac:TaxCategory>
            <cbc:ID>S</cbc:ID>
            <cbc:Percent>25</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:TaxCategory>
    </cac:TaxSubtotal>
</cac:TaxTotal>

<cac:Price>
    <cbc:PriceAmount currencyID="DKK">100</cbc:PriceAmount>(1)
</cac:Price>

1	Item net price
2	Line charge amounts
3	Line allowance amount
4	Invoiced quantity
5	\$"Invoice line net amount" = ("Item net price" times "Invoiced Quantity") + "line charge amount" - "line allowance amount"\$

4.1.3. Calculation of allowance/charge amount

Allowance and charge on document and line level consists of elements carrying information on the allowance/charge base amount and the allowance/charge percentage. These are, if present in the invoice instance, used for calculating the allowance/charge amount.

If base amount is present, the percentage shall also be present, and if percentage is present, the base amount shall also be present, and the calculation of the amount shall be:

\$"Amount" = "Base amount" times ("Percentage" div 100)\$

UBL example of calculations of allowances and charges where base amount and percentage exist

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Cleaning</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>20</cbc:MultiplierFactorNumeric>(2)
    <cbc:Amount currencyID="DKK">200</cbc:Amount> (3)
    <cbc:BaseAmount currencyID="DKK">1000</cbc:BaseAmount>(1)
    <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>25</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>

1	Base amount, to be used with the percentage to calculate the amount
2	Charge percentage
3	\$"Base amount" times ("Percentage" div 100) = "Amount"\$

UBL example of calculations of allowances and charges where base amount and percentage does not exist

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="DKK">200</cbc:Amount>(1)
    <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>25</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>

1	Amount of allowance without calculations based on base amount and percentage

4.1.4. Calculation of VAT

One VAT Breakdown shall be provided for each distinct combination of VAT category code and VAT rate found in either the line VAT information or the Document level allowance or charges.

For each distinct combination of VAT category code and VAT rate the calculations are:

\$"VAT category taxable amount (BT-116)" = sum("Invoice line net amounts (BT-131)")\$
\$+ "Document level charge amount (BT-99)" - "Document level allowance amount (BT-92)"\$

\$"VAT category tax amount (BT-117)" = "VAT category taxable amount (BT-116)" times ("VAT rate (BT-119)" div 100)\$

For VAT Breakdown where the VAT Category is "Not subject to VAT" (O), the VAT category tax amount shall be zero.

UBL example of calculations of VAT Breakdown

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Cleaning</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="DKK">200</cbc:Amount>(1)
    <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>25</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="DKK">100</cbc:Amount>(2)
    <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>25</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>

<cac:TaxTotal>
    <cbc:TaxAmount currencyID="DKK">1250.00</cbc:TaxAmount>

    <cac:TaxSubtotal>(3)
        <cbc:TaxableAmount currencyID="DKK">5000.0</cbc:TaxableAmount>(4)
        <cbc:TaxAmount currencyID="DKK">1250</cbc:TaxAmount>(5)
        <cac:TaxCategory>
            <cbc:ID>S</cbc:ID>
            <cbc:Percent>25</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:TaxCategory>
    </cac:TaxSubtotal>

    <cac:TaxSubtotal>(6)
        <cbc:TaxableAmount currencyID="DKK">2000.0</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="DKK">0</cbc:TaxAmount>
        <cac:TaxCategory>
            <cbc:ID>E</cbc:ID>
            <cbc:Percent>0</cbc:Percent>
            <cbc:TaxExemptionReason>Reason for tax exempt</cbc:TaxExemptionReason>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:TaxCategory>
    </cac:TaxSubtotal>
</cac:TaxTotal>

<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
    <cbc:Note>Testing note on line level</cbc:Note>
    <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="DKK">4000.00</cbc:LineExtensionAmount>
        <!-- code omitted for clarity -->
        <cac:ClassifiedTaxCategory>
            <cbc:ID>S</cbc:ID>
            <cbc:Percent>25.0</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:ClassifiedTaxCategory>

<cac:InvoiceLine>
    <cbc:ID>2</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="DKK">2000.00</cbc:LineExtensionAmount>
        <!-- code omitted for clarity -->
        <cac:ClassifiedTaxCategory>
            <cbc:ID>E</cbc:ID>
            <cbc:Percent>0.0</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:ClassifiedTaxCategory>
<cac:InvoiceLine>
    <cbc:ID>3</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="DKK">900.00</cbc:LineExtensionAmount>
        <!-- code omitted for clarity -->
        <cac:ClassifiedTaxCategory>
            <cbc:ID>S</cbc:ID>
            <cbc:Percent>25.0</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:ClassifiedTaxCategory>

1	Document level charge amount for category S and rate 25%
2	Document level allowance amount for category S and rate 25%
3	VAT Breakdown for category S and rate = 25%
4	Taxable amount = sum of line amount (line 1 and 3), plus charge amount minus allowance amount where category = S and rate = 25%
5	\$"Tax Amount" = "Taxable amount" times ("VAT rate" div 100)\$
6	VAT Breakdown for category E, and rate = 0%

4.2. Value added tax (VAT)

The chapters below describe the different VAT informations that can be provided in an Invoice or Credit Note.

Please also see [VAT category codes] for details on the VAT category code list, and Calculation of VAT for detailed explanation and example on how to perform the calculations for VAT Breakdown.

4.2.1. Line VAT Information

Each invoice line shall have the invoiced item VAT category code (BT-151), and for all VAT categories except "Not subject to VAT" (O), the VAT rate shall be provided.

4.2.2. Document level allowance or charge

Each document level charge or allowance must have the Document level allowance or charge VAT category code (BT-95 and BT-102), and for all VAT categories except "Not subject to VAT" (O), the VAT rate shall be provided.

4.2.3. VAT Breakdown

One VAT Breakdown shall be provided for each distinct combination of VAT category code and VAT rate found in either the line VAT information or the Document level allowance or charges. For some VAT categories, the VAT rate shall be zero, and hence the rate is not needed in order to group the VAT Breakdown for these.

Please note that for the VAT rate, only significant decimals should be considered, i.e any difference in trailing zeros should not result in different VAT breakdowns.

Example 3. Example

Invoice line 1 has category code = S and VAT rate = 25
Invoice line 2 has category code = S and VAT rate = 25.00
This should result in only one VAT Breakdown.

4.2.4. Invoice total VAT amount

The invoice total VAT amount (BT-110) is the sum of all VAT Category VAT amounts (BT-117)

4.3. Rounding

To minimize the risk of differences due to rounding, the following rules apply:

All document level amounts shall be rounded to two decimals for accounting
Invoice line net amount shall be rounded to two decimals
Results from calculations involving already rounded amounts are not subject to rounding, like payable amounts and total amounts included VAT.

Please also see Calculation for details on how to calculate the different amounts. = Shared rules for invoice and credit note

Unless specifically noted, the same rules apply for both invoices and credit notes. In OIOUBL 3, the differences are mostly naming conventions for certain fields and subclasses (e.g. InvoiceLine vs. CreditNoteLine) and some code lists (e.g. document type codes where valid InvoiceTypeCode and CreditNoteTypeCode values are different subsets of the master document type code list).

4.4. Negative invoices and credit notes are not allowed in OIOUBL 3

The European standard EN 16931 is a common description of both Invoices and Credit Notes, and EN 16931 allows Invoice and Credit Note documents to end up having a negative total “Amount due for payment.” If, for instance, an Invoice has a negative line due to goods returned.

OIOUBL 3 imposes a restriction on this: In OIOUBL 3, both Invoice and Credit Note must have non-negative total “Amount due for payment.” If there is a business need for a negative invoice, the invoice should be re-cast as a credit note instead. The shared rules for invoice and credit note should make this a painless process.

The function of crediting or debiting is controlled by the business document type (e.g. InvoiceTypeCode=380 vs. CreditNoteTypeCode=381) while the representation of the amount, including its sign, is not affected.

4.4.1. Example of usage of invoice and credit note

In this example, the Buyer has rejected an invoice and the Seller has agreed that a credit note must be issued to cancel the invoice, and a corrective invoice issued. For brevity the corrected invoice is not shown, only the erroneous invoice and the credit note that cancels it.

UBL example of Invoice to be corrected

    <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
    <!-- Code omitted for clarity -->
        <cac:AllowanceCharge>
            <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
            <cbc:AllowanceChargeReason>Insurance</cbc:AllowanceChargeReason>
            <cbc:Amount currencyID="DKK">25</cbc:Amount>(1)
            <cac:TaxCategory>
                <cbc:ID>S</cbc:ID>
                <cbc:Percent>25.0</cbc:Percent>
                <cac:TaxScheme>
                    <cbc:ID>VAT</cbc:ID>
                </cac:TaxScheme>
            </cac:TaxCategory>
        </cac:AllowanceCharge>
    <!-- Code omitted for clarity -->
    <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="DKK">1300</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="DKK">1325</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="DKK">1656.25</cbc:TaxInclusiveAmount>
        <cbc:ChargeTotalAmount currencyID="DKK">25</cbc:ChargeTotalAmount>
        <cbc:PayableAmount currencyID="DKK">1656.25</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

<cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>(2)
    <cbc:InvoicedQuantity unitCode="DAY">7</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID= "DKK">2800</cbc:LineExtensionAmount>
    <!-- Code omitted for clarity -->
    <cac:Price>
        <cbc:PriceAmount currencyID="DKK">400</cbc:PriceAmount>
    </cac:Price>

<cac:InvoiceLine>
    <cbc:ID>2</cbc:ID>(3)
    <cbc:InvoicedQuantity unitCode="DAY">-3</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="DKK">-1500</cbc:LineExtensionAmount>
    <!-- Code omitted for clarity -->
    <cac:Price>
        <cbc:PriceAmount currencyID="DKK">500</cbc:PriceAmount>
    </cac:Price>

1	Charge amount
2	Invoice line 1 with positive quantity and line amount
3	Invoice line 2 with negative quantity and line amount

UBL example of Credit Note correcting the example invoice above

    <cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>(1)
    <!-- Code omitted for clarity -->
        <cac:AllowanceCharge>
            <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
            <cbc:AllowanceChargeReason>Insurance</cbc:AllowanceChargeReason>
            <cbc:Amount currencyID="DKK">25</cbc:Amount>(2)
            <cac:TaxCategory>
                <cbc:ID>S</cbc:ID>
                <cbc:Percent>25.0</cbc:Percent>
                <cac:TaxScheme>
                    <cbc:ID>VAT</cbc:ID>
                </cac:TaxScheme>
            </cac:TaxCategory>
        </cac:AllowanceCharge>
    <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="DKK">1300</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="DKK">1325</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="DKK">1656.25</cbc:TaxInclusiveAmount>
        <cbc:ChargeTotalAmount currencyID="DKK">25</cbc:ChargeTotalAmount>
        <cbc:PayableAmount currencyID="DKK">1656.25</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

<cac:CreditNoteLine>
    <cbc:ID>1</cbc:ID>(3)
    <cbc:CreditedQuantity unitCode="DAY">7</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID= "DKK">2800</cbc:LineExtensionAmount>
    <!-- Code omitted for clarity -->
    <cac:Price>
        <cbc:PriceAmount currencyID="DKK">400</cbc:PriceAmount>
    </cac:Price>

<cac:CreditNoteLine>
    <cbc:ID>2</cbc:ID>(4)
    <cbc:CreditedQuantity unitCode="DAY">-3</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="DKK">-1500</cbc:LineExtensionAmount>
    <!-- Code omitted for clarity -->
    <cac:Price>
        <cbc:PriceAmount currencyID="DKK">500</cbc:PriceAmount>
    </cac:Price>

1	Code 381 indicating a credit note
2	Charge amount
3	Invoice line 1 with positive quantity and line amount
4	Invoice line 2 with negative quantity and line amount

5. 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 a precise interpretation of the content.

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

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.

5.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 of an Invoice, 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.

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

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.25

5.2.2. Unit Price Amount

A unit 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

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.1234

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

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

34.7812

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

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.1234

5.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 of the applicable syntax.

Component	Use	Primitive Type	Example
Content	Mandatory	String	Abc123

Component

Use

Primitive Type

Example

Content

Mandatory

String

Abc123

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

5.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 time zone information.

Table 14. EN 16931_ Date. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	2024-12-01

5.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 time zone information. Decimal fraction on seconds SHALL not be used.

Table 15. EN 16931_ Time. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Time	09:30:12

5.2.9. Document Reference

Document Reference Types are identifiers that were assigned to a document or document line by the Buyer, the Seller or by a third party.

Table 16. Document Reference. Type
Component	Use	Primitive Type	Example
Content	Mandatory	String	abc:123-DEF

5.2.10. Short String

Text is the actual wording of anything written or printed. Line breaks in the text must not be present. Maximum length of short string is 64 characters.

Component	Use	Primitive Type	Example
Content	Mandatory	String	Product Name

Component

Use

Primitive Type

Example

Content

Mandatory

String

Product Name

5.2.11. Long String

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. Maximum length of short string is 1024 characters.

Component

Use

Primitive Type

Example

Content

Mandatory

String

5% allowance when paid within 30 days

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

5.2.13. Binary objects

Binary objects can be used to describe files which are transmitted together with the Invoice. The attachment functionality is not intended for of including a copy of the invoice in an image format (such as PDF). Attaching an invoice copy is not in compliance with this specification.

Attachments shall be transmitted together with the Invoice. 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 invoice or credit note.

Component

Use

Primitive Type

Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

A receiver of an invoice or credit note, shall accept and process attachments that are according to the MimeCode code list [oioubl3-link-codelist]

5.2.14. Boolean Indicators

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

6. OIOUBL 3 Identifiers

OIOUBL 3 requires the use of identifiers in both the Nemhandel eDelivery transport infrastructure and within the documents exchanged across that infrastructure. The policies that apply to this OIOUBL 3 BIS are:

6.1. Profiles and messages

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

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

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

urn:fdc:oioubl.dk:trns:billing:invoice:3.0

urn:fdc:oioubl.dk:bis:billing_with_response:3

Credit Note

urn:fdc:oioubl.dk:trns:billing:creditnote:3.0

Invoice Response

urn:fdc:peppol.eu:poacc:trns:invoice_response:3@urn:fdc:oioubl.dk:trns:billing:invoice_response:3.0

Personal Invoice

urn:fdc:oioubl.dk:trns:billing:invoice:3.0

urn:fdc:oioubl.dk:bis:billing_private_without_response:3

Personal Credit Note

urn:fdc:oioubl.dk:trns:billing:creditnote:3.0

6.3. Namespaces

All document types in OIOUBL BIS Billing with Response are bound to the UBL 2.1. The target namespaces are:

Type Namespace

Invoice and Personal Invoice

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

Credit Note and Personal Credit Note

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

Invoice Response

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

7. Descriptions and Examples of Selected Elements of the Invoice and the Credit Note

In the subchapters below you find examples of selected elements of the transaction.

This list is not intended to be exhaustive, but rather to showcase elements of particular importance or for which disambiguation is required. For the full list of supported elements, please refer to the syntax documentation.

7.1. Parties

The following roles may be specified. The same actor may play more than one role depending on the handling routine.

Further details on the roles/actors can be found in Parties and roles.

7.2. Seller (AccountingSupplierParty)

Seller is mandatory information and provided in element cac:AccountingSupplierParty

UBL example of Seller information

<cac:AccountingSupplierParty>
    <cac:Party>
        <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
        (1)
        <cac:PartyIdentification>
            <cbc:ID schemeID="0088">7300010000001</cbc:ID>
            (2)
        </cac:PartyIdentification>
        <cac:PartyName>
            <cbc:Name>SupplierTradingName Ltd.</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
            <cbc:StreetName>Main street</cbc:StreetName>
            <cbc:AdditionalStreetName>Postbox 123</cbc:AdditionalStreetName>
            <cbc:BuildingNumber>1</cbc:BuildingNumber>
            <cbc:CityName>London</cbc:CityName>
            <cbc:PostalZone>GB 123 EW</cbc:PostalZone>
            <cbc:CountrySubentity>West London district</cbc:CountrySubentity>
            <cac:AddressLine>
                <cbc:Line>Third address line</cbc:Line>
            </cac:AddressLine>
            <cac:Country>
                <cbc:IdentificationCode>GB</cbc:IdentificationCode>
            </cac:Country>
        </cac:PostalAddress>
        <cac:PartyTaxScheme>
            <cbc:CompanyID schemeID="ZZZ">GB76576657</cbc:CompanyID>
            (3)
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyTaxScheme>
            <cbc:CompanyID schemeID="ZZZ">TaxRegistrationID</cbc:CompanyID>
            <cac:TaxScheme>
                <cbc:ID>TAX</cbc:ID>
            </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyLegalEntity>
            <cbc:RegistrationName>SupplierOfficialName Ltd</cbc:RegistrationName>
            <cbc:CompanyID schemeID="0089">GB983294</cbc:CompanyID>
            <cbc:CompanyLegalForm>Private Limited Company</cbc:CompanyLegalForm>
        </cac:PartyLegalEntity>
        <cac:Contact>
            <cbc:Name>John Doe</cbc:Name>
            <cbc:Telephone>+449384203984</cbc:Telephone>
            <cbc:ElectronicMail>john.doe@foo.bar</cbc:ElectronicMail>
        </cac:Contact>
    </cac:Party>
</cac:AccountingSupplierParty>

1	schemeID attribute is mandatory for electronic addresses, ie. EndpointID
2	schemeID attribute is mandatory for all party identifiers
3	VAT identifiers shall be prefixed with the country code

7.3. Buyer (AccountingCustomerParty)

Buyer is mandatory information and provided in element cac:AccountingCustomerParty

UBL example of Buyer information

<cac:AccountingCustomerParty>
    <cac:Party>
        <cbc:EndpointID schemeID="0002">FR23342</cbc:EndpointID>
        (1)
        <cac:PartyIdentification>
            <cbc:ID schemeID="0002">FR23342</cbc:ID>
            (2)
        </cac:PartyIdentification>
        <cac:PartyName>
            <cbc:Name>BuyerTradingName AS</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
            <cbc:StreetName>Hovedgatan</cbc:StreetName>
            <cbc:AdditionalStreetName>Po box 878</cbc:AdditionalStreetName>
            <cbc:BuildingNumber>32</cbc:BuildingNumber>
            <cbc:CityName>Stockholm</cbc:CityName>
            <cbc:PostalZone>45634</cbc:PostalZone>
            <cac:AddressLine>
                <cbc:Line>Third line</cbc:Line>
            </cac:AddressLine>
            <cac:Country>
                <cbc:IdentificationCode>SE</cbc:IdentificationCode>
            </cac:Country>
        </cac:PostalAddress>
        <cac:PartyTaxScheme>
            <cbc:CompanyID schemeID="ZZZ">SE459837593701</cbc:CompanyID>
            (3)
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyLegalEntity>
            <cbc:RegistrationName>Buyer Official Name</cbc:RegistrationName>
            <cbc:CompanyID schemeID="0183">39937423947</cbc:CompanyID>
            (4)
        </cac:PartyLegalEntity>
        <cac:Contact>
            <cbc:Name>Lisa Johnson</cbc:Name>
            <cbc:Telephone>+4623434234</cbc:Telephone>
            <cbc:ElectronicMail>lj@buyer.se</cbc:ElectronicMail>
        </cac:Contact>
    </cac:Party>
</cac:AccountingCustomerParty>

7.4. Delivery Details (Date and Location)

Delivery details may be given at document level.

Place and date of delivery is recommended and should be sent unless this does not affect the ability to ensure the correctness of the invoice.

The delivery element contains information on name, address and delivery location identifier (cac:Delivery/cac:DeliveryLocation/cbc:ID) which may be used if the place of delivery is defined through an identifier. For example GLN (Global Location Number)issued by GS1.

Important distinction between DeliveryParty and DeliveryLocation: DeliveryParty is the party that took delivery of the goods, while DeliveryLocation is the physical location to which delivery was made. DeliveryParty, being a Party element, may have an address associated with it. However this is the correspondance address of the party taking delivery, not the location of the delivery itself.

UBL example of delivery information

<cac:Delivery>
    <cbc:ActualDeliveryDate>2024-11-01</cbc:ActualDeliveryDate>
    <cac:DeliveryLocation>
        <cbc:ID schemeID="0088">7300010000001</cbc:ID>
        <cac:Address>
            <cbc:StreetName>Delivery street</cbc:StreetName>
            <cbc:AdditionalStreetName>Building 56</cbc:AdditionalStreetName>
            <cbc:BuildingNumber>2</cbc:BuildingNumber>
            <cbc:CityName>Frederiksberg</cbc:CityName>
            <cbc:PostalZone>2000</cbc:PostalZone>
            <cac:Country>
                <cbc:IdentificationCode>DK</cbc:IdentificationCode>
            </cac:Country>
        </cac:Address>
    </cac:DeliveryLocation>
    <cac:DeliveryParty>
        <cac:PartyName>
            <cbc:Name>Delivery party Name</cbc:Name>
        </cac:PartyName>
    </cac:DeliveryParty>
</cac:Delivery>

7.5. References

Support for invoice verification is a key function of an invoice. The invoice should provide sufficient information to look up relevant existing documentation, electronic or paper.

Any reference element should contain valid information, if you do not have a reference, the element should not be present in the instance document.

The Invoice and Credit Note transactions supports the following references to existing documentation:

7.5.1. Purchase Order and Sales Order reference

The Purchase Order is conditional. If order reference exist, use that, else use Buyer reference (see Buyer reference).

The customer will issue an order with a unique order number. This unique Purchase Order number should be supplied as the order reference on the invoice.

If order reference is stated at header level, the order reference element on line level can be used to state the order line numbers.

A sales order is issued by the seller, confirming the sale of specified products.

In the Invoice, both a Purchase Order and a Sales Order reference can be given, but an Invoice instance cannot have a sales order reference without the corresponding purchase order reference. If (and only if) Buyer has not provided a purchase order ID but Seller has provided a sales order ID, it is permissible and recommended to use the sales order ID to dummy out the mandatory purchase order field. In this case it is strongly recommended to also include buyer reference, to ensure that Buyer is able to process the invoice.

UBL example or order and sales order reference

<cac:OrderReference>
    <cbc:ID>PO-998877</cbc:ID>(1)
    <cbc:SalesOrderID>SO-12343</cbc:SalesOrderID>(2)
</cac:OrderReference>

1	Purchase Order reference
2	Sales Order reference

7.5.2. Buyer reference

The Buyer reference, known as 'Your ref', is conditional. An Invoice shall have either the Buyer reference or the order reference (see Purchase Order and Sales Order reference)

The element is used for the reference of who ordered the products/services. Example being the name of the person ordering, employee number or a code identifying this person or department/group. 'Your ref' is often used for internal routing at the recipient and hence it is important to fill this element with the correct values according to the need of the recipient.

When a reference is provided by the customer, this reference should always be used.

If neither Buyer reference nor a reference to an order is supplied by the customer, the name of the person ordering or appointed for the customer can be supplied in buyer reference if known by the supplier.

If Buyer reference is to a person in Buyer’s organization, Seller may provide the name or e-mail address of the person in question, or their employee ID (if known). Buyer shall undertake reasonable effort to identify the person in question in their organization, and shall not reject an invoice solely because Buyer reference is in the form of an e-mail or name, rather than an employee ID or other Buyer-provided reference.

UBL example of buyer reference

<cbc:BuyerReference>0150abc</cbc:BuyerReference>

7.5.3. Invoiced object identifier

The invoiced object identifier is the identifier for an object on which the invoice is based, given by the Seller. Examples may be a subscription number, telephone number, meter point, vehicle, person etc., as applicable.

If it is not clear to the receiver what scheme is used for the identifier, a conditional scheme identifier should be used, that shall be chosen from the Invoiced object identifier scheme (UNCL 1153) code list.

The invoiced object reference is provided by using the element cac:AdditionalDocumentReference with the document type code = 130

UBL example of invoiced object identifier

<cac:AdditionalDocumentReference>
    <cbc:ID schemeID="AKZ">DR35141</cbc:ID>(1)
    <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode>(2)
</cac:AdditionalDocumentReference>

1	Scheme identifier from Invoiced object identifier scheme (UNCL 1153) code list
2	Document type code shall be ´130´ to indicate Invoiced object, based on Document name code, full list (UNCL1001) code list

Person reference (Ydelsesmodtager)

The European Norm specifies a “Invoiced object identifier” at document level and a corresponding “Invoice line object identifier” at line level.

This may be used to connect the invoice line to a census ID (CPR-number), in cases where it is important to connect a product or service to a particular physical person, who may or may not be covered by one of the available Party classes.

If the object of the invoice is not clear to the recipient, a reference to a code in the Invoiced object identifier scheme (UNCL 1153) code list must be provided.

To identify that they are the “mapped” from the European Norm object identifier, the DocumentTypeCode is set to “130” based on Document name code, full list (UNCL1001) code list.

Invoices which contain a census ID (CPR-number) must be processed as documents containing confidential personal data covered by GDPR. Nemhandel eDelivery provides an envelope-level identifier that the transmitted document contains such data. This identifier must be used where applicable.

UBL example of CPR-number in the invoiced object identifier

<cac:AdditionalDocumentReference>
    <cbc:ID schemeID="ARR">2211801232</cbc:ID>(1)
    <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode>(2)
</cac:AdditionalDocumentReference>

1	Scheme identifier from Invoiced object identifier scheme (UNCL 1153) code list and the indentifier value is a census ID (CPR-nummer) with 10 digits.
2	Document type code shall be ´130´ to indicate Invoiced object, based on Document name code, full list (UNCL1001) code list

7.5.4. Contract reference

To reference or match an Invoice to a purchase contract or frame agreement, the contract number could be specified like this:

UBL example of contract reference

<cac:ContractDocumentReference>
    <cbc:ID>framework no 1</cbc:ID>
</cac:ContractDocumentReference>

7.5.5. Despatch and Receipt Advice references

To reference or match an Invoice to a Despatch or Receipt Advice use the following elements:

UBL example of Despatch and Receipt Advice

<cac:DespatchDocumentReference>
    <cbc:ID>despadv-3</cbc:ID>(1)
</cac:DespatchDocumentReference>
<cac:ReceiptDocumentReference>
    <cbc:ID>resadv-1</cbc:ID>(2)
</cac:ReceiptDocumentReference>

1	Despatch Advice
2	Receipt Advice

7.5.6. Tender reference

To identify the call for tender or lot the invoice relates to, use the 'OriginatorDocumentReference'. The identifier is, in most cases, the Procurement Procedure Identifier.

UBL example of tender reference

<cac:OriginatorDocumentReference>
    <cbc:ID>ppid-123</cbc:ID>
</cac:OriginatorDocumentReference>

7.5.7. Project reference

The project reference is optional to use, and is sent in an Invoice in the element cac:ProjectReference/cbc:ID. In a Credit Note, this element does not exist, and the project reference is sent by using the element cac:AdditionalDocumentReference[cbc:DocumentTypeCode='50']/cbc:ID.

NOTE: When sending the project reference, only the cbc:ID and the cbc:DocumentTypeCode are allowed in the cac:AdditionalDocumentReference element.

UBL example of project reference in an Invoice

<cac:ProjectReference>
    <cbc:ID>project333</cbc:ID>
</cac:ProjectReference>

UBL example of project reference in a Credit Note

<cac:AdditionalDocumentReference>
    <cbc:ID>p-2347234</cbc:ID>(2)
    <cbc:DocumentTypeCode>50</cbc:DocumentTypeCode>(1)
</cac:AdditionalDocumentReference>

1	Code 50 indicating this is a project reference
2	The project reference identifier

7.5.8. Preceding Invoice references

A Credit Note or Invoice can refer to one or more preceding Invoice(s). This is done in the business group BG-3 Preceding invoice reference, providing the invoice number and issue date. The issue date should be provided, against the possibility that the preceding invoice reference is not unique (the invoice reference is only guaranteed to be unique to issuer and fiscal year, not universally unique).

In case correction applies to a large number of Invoices, the invoicing period (BG-14), as necessary combined with a clarifying invoice note (BT-22), may instead be be given at document level.

UBL example of preceding invoice information

<cac:BillingReference>
    <cac:InvoiceDocumentReference>
        <cbc:ID>123</cbc:ID>(1)
        <cbc:IssueDate>2017-10-20</cbc:IssueDate>(2)
    </cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:BillingReference>(3)
    <cac:InvoiceDocumentReference>
        <cbc:ID>124</cbc:ID>
    </cac:InvoiceDocumentReference>
</cac:BillingReference>

1	The identifier is mandatory if `cac:BillingReference` is provided
2	Issue date should be provided
3	Repeat the `cac:BillingReference` to add several preceding invoice references

7.6. Allowances and Charges

The Invoice and Credit Note transactions have elements for Allowance/charge on 3 levels.

The element cac:AllowanceCharge with sub element cbc:ChargeIndicator indicates whether the instance is a charge (true) or an allowance (false).

The header level

Applies to the whole invoice and is included in the calculation of the invoice total amount.

Several allowances and charges may be supplied.
Specification of VAT for allowances and charges, cac:TaxCategory with sub elements, shall be supplied.
The sum of all allowances and charges on the header level shall be specified in cbc:AllowanceTotalAmount and cbc:ChargeTotalAmount respectively. See UBL syntax calculation formulas.

The line level

Applies to the line level and is included in the calculation of the line amount.

Several allowances and charges may be supplied.
Specification of VAT for allowances and charges shall not be specified, as the VAT category stated for the invoice line itself, applies also to the allowances or charges of that line.
The sum of all allowances and charges on the line level shall be taken into account, subtracted or added, when calculating the line extension amount.

These line level allowances and charges shall not be calculated into the header level elements. This would be double counting, as they must be applied to the line totals.

The line level Price element

A way to inform the buyer how the price is set. Is also relevant if the seller or buyer want to post the allowance in their accounting systems. The price amount that enters into line level calculations shall always be the net price, after the price-level discount is applied. The gross price, pre-discount, shall be given as the base amount in the Allowance class.

Only one occurrence of allowance (discount) is allowed.
Price-level charge is not allowed, only allowance.
Specification of VAT for allowance shall not be specified
Allowance related to Price shall not be part of any other calculations.
Allowance related to Price may specify allowance amount and the base amount (gross price).

Further details of the calculation of allowance/charge amount, can be found in Calculation of allowance/charge amount

UBL example of Allowances and Charges on the document level

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>(1)
    <cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Freight service</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>2</cbc:MultiplierFactorNumeric>(4)
    <cbc:Amount currencyID="DKK">20</cbc:Amount> (5)
    <cbc:BaseAmount currencyID="DKK">1000</cbc:BaseAmount>(3)
    <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>25</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>(2)
    <cbc:AllowanceChargeReasonCode>65</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Production error discount</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="DKK">10</cbc:Amount>
    <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>25</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>

1	ChargeIndicator = true to indicate a charge.
2	ChargeIndicator = false to indicate an allowance.
3	Base amount, to be used with the percentage to calculate the amount.
4	Charge percentage.
5	Amount = Base amount times (Percentage div 100).

UBL example of Allowances and Charges on invoice line

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>(1)
    <cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Cleaning</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>(4)
    <cbc:Amount currencyID="DKK">1</cbc:Amount>(5)
    <cbc:BaseAmount currencyID="DKK">10</cbc:BaseAmount>(3)
</cac:AllowanceCharge>
<cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>(2)
    <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="DKK">101</cbc:Amount>
</cac:AllowanceCharge>

1	ChargeIndicator = true to indicate a charge.
2	ChargeIndicator = false to indicate an allowance.
3	Base amount, to be used with the percentage to calculate the amount.
4	Charge percentage.
5	Amount = Base amount times (Percentage div 100).

UBL example of Charges on invoice line for Danish Tax Categories / Duty Codes

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>(1)
    <cbc:AllowanceChargeReasonCode>ZZZ</cbc:AllowanceChargeReasonCode>(2)
    <cbc:AllowanceChargeReason>110a#3620</cbc:AllowanceChargeReason>(3)
    <cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>(4)
    <cbc:Amount currencyID="DKK">1</cbc:Amount>(6)
    <cbc:BaseAmount currencyID="DKK">10</cbc:BaseAmount>(5)
</cac:AllowanceCharge>

1	ChargeIndicator = true to indicate a charge.
2	AllowanceChargeReasonCode = ZZZ to indicate Danish Tax Categories.
3	AllowanceChargeReason = "100a#3620" as an example of "CO2-change on gas"/"CO2 on gas- & diesel oil".
4	Charge percentage.
5	Base amount, to be used with the percentage to calculate the amount.
6	Amount = Base amount times (Percentage div 100).

For detailed use excise duties https://info.skat.dk/. SKAT’s guide for excise duties for 2024 can be found here,

7.7. VAT accounting currency

Article 230 of Directive 2006/112/EC states:

The amounts which appear on the invoice may be expressed in any currency, provided that the amount of VAT payable is expressed in the national currency of the Member State in which the supply of goods or services takes place, using the conversion mechanism laid down in Article 91.

If the invoice currency is different from the national currency, this is expressed in the invoice by stating the national currency in the element VAT accounting currency (BT-6), and the amount of VAT payable in national currency is stated in the element Invoice total VAT amount in accounting currency (BT-111). The exchange rate to use for calculating is described in Article 91 of Directive 2006/112/EC.

UBL example of VAT currency

<cbc:DocumentCurrencyCode>DKK</cbc:DocumentCurrencyCode>
(1)
<cbc:TaxCurrencyCode>SEK</cbc:TaxCurrencyCode>
(2)

<cac:TaxTotal>
    <cbc:TaxAmount currencyID="DKK">1000.00</cbc:TaxAmount>
    (3)
    <cac:TaxSubtotal>
        <cbc:TaxableAmount currencyID="DKK">4000.0</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="DKK">1000</cbc:TaxAmount>
        <cac:TaxCategory>
            <cbc:ID>S</cbc:ID>
            <cbc:Percent>25</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:TaxCategory>
    </cac:TaxSubtotal>
</cac:TaxTotal>
<cac:TaxTotal>
    <cbc:TaxAmount currencyID="SEK">817.50</cbc:TaxAmount>
    (4)
</cac:TaxTotal>

1	Invoice currency
2	National currency
3	VAT amount in invoice currency
4	VAT amount in national currency

7.8. Payment means information

PaymentMeans identifies how payment may be made to the supplier. In OIOUBL, only a limited set of payment means is permitted; the below description covers only these payment means.

The PaymentMeans element consists of the following general fields:

ID: An identifier used to distinguish different payment means, where more than one is provided.
PaymentMeansCode: A code identifying the type of payment requested.
- @name: Optionally, the name of the payment means type may be given in text.
PaymentChannelCode: A code that disambiguates the payment means, where PaymentMeansCode is insufficient to provide unambiguous identification.

For the sake of compatibility with existing systems, PaymentChannelCode is permitted for a number of PaymentMeansCode values where there is no ambiguity. However, the reader is advised that this use is deprecated and may be desupported in a future release.

PaymentMeans additionally contains a number of fields and subclasses specific to various methods of payment:

7.8.1. Danish postal giro and related systems

PaymentID: Indicates the type of giro document.
InstructionID: The instruction string for the giro document. Syntax depends on PaymentID.
InstructionNote: Instruction text for the giro type which does not support encoded instructions.

These fields are found directly in the PaymentMeans class, but only used for giro payments.

7.8.2. Payment means with their own subclasses

CardAccount: Payment by credit or debit card.
PayeeFinancialAccount: Bank account details for the payee, for use in bank transfers.
CreditAccount: Identifies the credit account of the customer with the supplier, for purchases on account.
PaymentMandate: Information regarding the payment mandate used for self-debit.

Only one set of details may be given in a PaymentMeans instance, and it must correspond to the PaymentMeansCode. If multiple payment means are supported, each must have its own instance.

The table below lists the supported PaymentMeansCode values, and their relationships with the other general fields:

Payment Means Code

Payment Means Name

Payment Channel Code

Field Type

Instrument not defined

<blank>

Not allowed

In cash

<blank>

Not allowed

Debit transfer

IBAN or ZZZ

Mandatory

Payment to bank account

DK:BANK

Optional

Bank card

<blank>

Not allowed

Direct debit

DK:BANK or IBAN

Mandatory

Payment by postgiro

DK:GIRO

Optional

SEPA credit transfer

<blank>

Not allowed

SEPA direct debit

<blank>

Not allowed

Reference giro

DK:FIK

Optional

Clearing between partners

DK:NEMKONTO

Optional

The chosen PaymentMeansCode controls which other fields must be used, and which values each field can contain.

Different codes apply for the specification of an international versus a domestic bank transfer.

7.8.3. Detailed payment means descriptions

Bank Transfer

The PaymentMeansCode values for bank transfer are:

31: Debit transfer (international bank transfer/International bankoverførsel)
42: Payment to bank account (domestic bank transfer/Kontooverførsel)

UBL example of payment means info when payment is done by debit transfer (IBAN)

<cac:PaymentMeans>
    <cbc:PaymentMeansCode>31</cbc:PaymentMeansCode>(1)
    <cbc:PaymentChannelCode>IBAN</cbc:PaymentChannelCode>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>123456789012345</cbc:ID>(3)
        <cbc:PaymentNote>Information</cbc:PaymentNote>
        <cac:FinancialInstitutionBranch>
            <cbc:ID>1234</cbc:ID>
            <cbc:Name>Bank</cbc:Name>
            <cac:FinancialInstitution>
                <cbc:ID>DABADKKK</cbc:ID>(4)
                <cbc:Name>Andelsbanken</cbc:Name>
            </cac:FinancialInstitution>
            <cac:Address>
               <cbc:StreetName>Bank street</cbc:StreetName>
                <cbc:BuildingNumber>1234</cbc:BuildingNumber>
                <cbc:CityName>København</cbc:CityName>
                <cbc:PostalZone>1234</cbc:PostalZone>
                <cac:Country>
                    <cbc:IdentificationCode>DK</cbc:IdentificationCode>
                </cac:Country>
            </cac:Address>
        </cac:FinancialInstitutionBranch>
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

1	Payment means code
2	Payment channel code - IBAN or alternatively ZZZ other international debit transfers.
3	PayeeFinancialAccount.ID - IBAN number - no more than 34 characters
4	PayeeFinancialAccount.FinancialInstitutionBranch.FinancialInstitution.ID

UBL example of payment means info when payment is done to domestic bank account

<cac:PaymentMeans>
    <cbc:PaymentMeansCode>42</cbc:PaymentMeansCode>(1)
    <cac:PayeeFinancialAccount>
        <cbc:ID>1234567890</cbc:ID>(2)
        <cbc:PaymentNote>A00095678</cbc:PaymentNote>
        <cac:FinancialInstitutionBranch>
          <cbc:ID>1234</cbc:ID>(3)
       </cac:FinancialInstitutionBranch>
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

1	Payment means code
2	Bank account number - no more than 10 characters
3	Bank registration number - no more than 4 digits

Direct debit

The codes for payment by direct debit are:

49 - Direct debit (Direct Debit, herunder Betalings- eller leverandørservice)
59 - SEPA direct debit

UBL example of payment means info when payment is done by direct debit

<cac:PaymentMeans>
    <cbc:PaymentMeansCode>49</cbc:PaymentMeansCode>(1)
    <cbc:PaymentChannelCode>DK:BANK</cbc:PaymentChannelCode>(2)
    <cbc:InstructionID>123456789012345678901234567890123456789012345678901234567890</cbc:InstructionID>(3)
    <cac:PaymentMandate>
        <cbc:ID>1234567891234656</cbc:ID>
        <cac:PayerFinancialAccount>
            <cbc:ID>123456789</cbc:ID>
            <cac:FinancialInstitutionBranch>
                <cbc:ID>1234</cbc:ID>
            </cac:FinancialInstitutionBranch>
        </cac:PayerFinancialAccount>
    </cac:PaymentMandate>
</cac:PaymentMeans>

1	Payment means code
2	Payment channel code - DK:BANK or IBAN
3	Instruction id - example on Betalingsservice

UBL example of payment means info when payment is done by SEPA direct debit

 <cac:AccountingSupplierParty>
     <cac:Party>
         <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
         <cac:PartyIdentification>
             <cbc:ID schemeID="0089">99887766</cbc:ID>
         </cac:PartyIdentification>
         <cac:PartyIdentification>
             <cbc:ID schemeID="SEPA">23123687</cbc:ID>(1)
         </cac:PartyIdentification>
<!-- omitted code for clarity -->
 <cac:PaymentMeans>
     <cbc:PaymentMeansCode name="SEPA direct debit">59</cbc:PaymentMeansCode>(2)
     <cbc:PaymentID>payref2</cbc:PaymentID>(3)
     <cac:PaymentMandate>
         <cbc:ID>123456</cbc:ID>(4)
         <cac:PayerFinancialAccount>
             <cbc:ID>DK12328462834823</cbc:ID>
         </cac:PayerFinancialAccount>
     </cac:PaymentMandate>
 </cac:PaymentMeans>

1	Unique banking reference identifier of the Seller or Payee, schemeID shall have value "SEPA"
2	Payment means code
3	Remittance information
4	Mandate reference identifier

Payment by giro

The codes for payment by giro are:

50 - Payment by giro (Giroindbetalingskort)
93 - Reference giro (Fælles indbetalingskort - FIK kort)

PaymentID (KortArtsKode) exits in three variants 01, 04 and 15 for PaymentMeansCode 50, and PaymentID (KortArtsKode) exits in three variants 71, 73, 75 for PaymentMeansCode 93.

UBL example of payment means info when payment is done by giro 01

<cac:PaymentMeans>
    <cbc:PaymentMeansCode>50</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>01</cbc:PaymentID>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>1234567</cbc:ID>(3)
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

1	Payment means code
2	Remittance information
3	Giro account number

UBL example of payment means info when payment is done by giro 04

 <cac:PaymentMeans>
    <cbc:PaymentMeansCode>50</cbc:PaymentMeansCode>(1)
    <cbc:InstructionID>1234567890123456</cbc:InstructionID>(4)
    <cbc:PaymentID>04</cbc:PaymentID>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>1234567</cbc:ID>(3)
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

1	Payment means code
2	Remittance information
3	Giro account number
4	Instruction ID - for Payment ID 04, 15 and 75 shall Instruction ID contain 16 numeric characters.

UBL example of payment means info when payment is done by giro 73

<cac:PaymentMeans>
    <cbc:PaymentMeansCode>93</cbc:PaymentMeansCode>(1)
    <cbc:InstructionID>123456789012345</cbc:InstructionID>(4)
    <cbc:PaymentID>71</cbc:PaymentID>(2)
    <cac:CreditAccount>
        <cbc:AccountID>12345678</cbc:AccountID>(3)
    </cac:CreditAccount>
</cac:PaymentMeans>

1	Payment means code
2	Remittance information
3	Giro account number
4	Instruction ID - for Payment ID 71 shall Instruction ID contain 15 numeric characters.

Card Payment

If the Buyer had opted to pay by using a payment card such as a credit or debit card, information on the Primary Account Number (PAN) shall be present in the invoice.

The Primary Account Number must always be sufficiently obfuscated to prevent cloning of the card, but sufficiently legible to enable Buyer to identify the card used.

The code for payment by card is:

48 - Bank card (Kreditkort)

UBL example of payment means info when payment is done by credit transfer

<cac:PaymentMeans>
    <cbc:PaymentMeansCode>48</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>2015048300000000</cbc:PaymentID>(2)
    <cac:CardAccount>
        <cbc:PrimaryAccountNumberID>1234</cbc:PrimaryAccountNumberID>(3)
        <cbc:NetworkID>Visa</cbc:NetworkID>(4)
        <cbc:HolderName>Peter Petersen</cbc:HolderName>(5)
    </cac:CardAccount>
</cac:PaymentMeans>

1	Mandatory, payment means code for credit transfer
2	Remittance information
3	Primary account number ID
4	Network ID
5	Cardholder name

Credit transfer

If payment is made by credit transfer, the Payment account identifier (BT-84) is mandatory

The code for payment by credit transfer is:

58 - SEPA credit transfer

UBL example of payment means info when payment is done by credit transfer

<cac:PaymentMeans>
    <cbc:PaymentMeansCode>48</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>2015048300000000</cbc:PaymentID>(2)
    <cac:CardAccount>
        <cbc:PrimaryAccountNumberID>1234</cbc:PrimaryAccountNumberID>(3)
        <cbc:NetworkID>Visa</cbc:NetworkID>(4)
        <cbc:HolderName>Peter Petersen</cbc:HolderName>(5)
    </cac:CardAccount>
</cac:PaymentMeans>

1	Mandatory, payment means code for credit transfer
2	Remittance information
3	Mandatory, IBAN (in case of a SEPA payment) or a national account number (BBAN)
4	BIC or a national clearing code

Nemkonto

The code for use with Nemkonto is:

97 - Clearing between partners (NemKonto or Bilaterally defined)

UBL example of payment means info when payment is done by Nemkonto

<cac:AccountingSupplierParty>
        <cac:PartyLegalEntity>
            <cbc:RegistrationName>SupplierOfficialName DK</cbc:RegistrationName>
            <cbc:CompanyID schemeID="0184">12345678</cbc:CompanyID>(3)
        </cac:PartyLegalEntity>
<cac:PaymentMeans>
    <cbc:PaymentMeansCode>97</cbc:PaymentMeansCode>(1)
    <cbc:PaymentChannelCode>DK:NEMKONTO</cbc:PaymentChannelCode>(2)
</cac:PaymentMeans>

1	Mandatory payment means code for Nemkonto
2	Optional payment channel code for Nemkonto
3	PartyLegalEntity.CompanyID must be either CVR-number (0184) or CPR-number (0237) to support Nemkonto payment information. = Item Information

7.8.4. Item Identifiers

An invoice line may contain the seller, buyer and manufacturer item identifiers may be provided as well as a standard item identifier. For seller, buyer and manufacturer item identifiers, no scheme attribute is used. For standard item identifiers the schemeID is mandatory, and must be from the ISO 6523 ICD list.

UBL example of item identifiers

<cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">1000.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
        <cbc:TaxableAmount currencyID="EUR">4000.00</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="EUR">1000.00</cbc:TaxAmount>
        <cac:TaxCategory>
            <cbc:ID>S</cbc:ID>
            <cbc:Percent>25</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:TaxCategory>
    </cac:TaxSubtotal>
</cac:TaxTotal>

<cac:Item>

    <!-- Code omitted for clarity -->
    <cac:BuyersItemIdentification>
        <cbc:ID>b-13214</cbc:ID>
    </cac:BuyersItemIdentification>
    <cac:SellersItemIdentification>
        <cbc:ID>97iugug876</cbc:ID>
    </cac:SellersItemIdentification>
    <cac:StandardItemIdentification>
        <cbc:ID schemeID="0160">97iugug876</cbc:ID> (1)
    </cac:StandardItemIdentification>

    <!-- Code omitted for clarity -->

1	0160 is the ICD value for a GTIN identifier

7.8.5. Item Classification

Different item classification codes can be provided per invoice line and the codes must be from one of the classification schemes in code list UNCL7143. Examples of item classification codes are CPV, UNSPSC or HS, which are described further here.

Use of CPV Classification

UBL example of using CPV

<cac:CommodityClassification>
    <cbc:ItemClassificationCode listID="STI">09348023</cbc:ItemClassificationCode>(1)
</cac:CommodityClassification>

1	listID must be from UNCL7143 code list, and code STI indicates this is a CPV classification.

Use of UNSPSC Code for Item Classification

UNSPSC codes can used to classify products and services according to the United Nations Standard Products and Services Code.

Background information on UNSPSC can be found on: https://www.unspsc.org/

UNSPSC codes are provided in the CommodityClassification and the ItemClassificationCode elements of the Item classification, under the general Item data element.

OIOUBL 3 permits two different UNSPSC versions. The UNSPSC version is required, and must be inserted in the attribute listVersionID:

The latest version which exists in a version translated to Danish (at time of publication version 19.05.01).
The latest international UNSPSC version (at time of publication version 26.08.01).

UBL example of UNSPSC - CommodityClassification as a part of Item

<cac:Item>
    <cbc:Description>Hejsetavle</cbc:Description>
    <cbc:Name>Hejsetavle</cbc:Name>
    <cac:SellersItemIdentification>
        <cbc:ID>5712345780121</cbc:ID>
    </cac:SellersItemIdentification>
    <cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="TST"
                                    listVersionID="19.05.01">12345678</cbc:ItemClassificationCode>
        (1)
        (2)
    </cac:CommodityClassification>
    <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>25</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
    </cac:ClassifiedTaxCategory>
</cac:Item>

1	listID must be from "Item type identification code (UNCL7143)" code list, and code TST indicates this is a UNSPSC classification.
2	listVersionID specify the version of UNSPSC, and is mandatory, when the code TST is used in listID. Use either 19.05.01 (the latest version which exists in a version translated to Danish) or 26.08.01 (the latest international UNSPSC version).

Intrastat

When EU member states buy from other EU members, traders commonly require some statistical information in the invoice (normally a classification code from the Combined Nomenclature).

It is recommended to use the Item classification identifier (BT-158) for this purpose, with the code "HS" as list identifier.

UBL example of Combined nomenclature information

<cac:CommodityClassification>
    <cbc:ItemClassificationCode listID="HS">080110</cbc:ItemClassificationCode>
</cac:CommodityClassification>

7.9. Price information

An invoice must contain information about the item net price. Additional information such as gross price, item price base quantity and price discount may be added.

For details on calculating price see Item net price (BT-146).

UBL example of price with price discount

<cac:Price>
    <cbc:PriceAmount currencyID="DKK">410</cbc:PriceAmount>(4)
    <cbc:BaseQuantity unitCode="XBX">1</cbc:BaseQuantity>(3)
    <cac:AllowanceCharge>
        <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
        <cbc:Amount currencyID="DKK">40</cbc:Amount>(2)
        <cbc:BaseAmount currencyID="DKK">450</cbc:BaseAmount>(1)
    </cac:AllowanceCharge>
</cac:Price>

1	Item gross price
2	Item price discount
3	Item price base quantity
4	Item net price, must be equal to Item Gross price - item price discount (if these elements are used)

UBL example of price without price discount

<cac:Price>
    <cbc:PriceAmount currencyID="DKK">200</cbc:PriceAmount>
    <cbc:BaseQuantity unitCode="C62">2</cbc:BaseQuantity>
</cac:Price>

7.10. Standard Invoice Line

An invoice line includes as a minimum the invoiced quantity, the line total amount, basic item information (name and description) and some basic price information related to the unit price.

Invoice lines may contain further item information and references, as described elsewhere.

UBL example of standard invoice line

<cac:InvoiceLine>
        <cbc:ID>1</cbc:ID>
        <cbc:InvoicedQuantity unitCode="KGM">2.00</cbc:InvoicedQuantity>
        <cbc:LineExtensionAmount currencyID="DKK">200.00</cbc:LineExtensionAmount>

        <cac:TaxTotal>
                <cbc:TaxAmount currencyID="DKK">50.00</cbc:TaxAmount>
                <cac:TaxSubtotal>
                        <cbc:TaxableAmount currencyID="DKK">200.00</cbc:TaxableAmount>
                        <cbc:TaxAmount currencyID="DKK">50.00</cbc:TaxAmount>
                        <cac:TaxCategory>
                                <cbc:ID>S</cbc:ID>
                                <cbc:Percent>25</cbc:Percent>
                                <cac:TaxScheme>
                                        <cbc:ID>VAT</cbc:ID>
                                </cac:TaxScheme>
                        </cac:TaxCategory>
                </cac:TaxSubtotal>
        </cac:TaxTotal>
        <cac:Item>
                <cbc:Description>Portobello mushroom</cbc:Description>
                <cbc:Name>Portobello mushroom</cbc:Name>

        </cac:Item>

        <cac:Price>
                <cbc:PriceAmount currencyID="DKK">100.00</cbc:PriceAmount>
                <cbc:BaseQuantity unitCode="KGM">1</cbc:BaseQuantity>
        </cac:Price>
</cac:InvoiceLine>

7.11. Use of BaseQuantity in Item.Price

BaseQuantity is defined as the number of item units to which the price (item net price) applies.

If BaseQuantity is used, it enters into the calculation of Invoice line net amount as follows:

Invoice line net amount = Item net price * Invoiced quantity / Base quantity

InvoiceLine.LineExtensionAmount = InvoiceLine.Price.PriceAmount * InvoiceLine.InvoicedQuantity / InvoiceLine.Price.BaseQuantity

UBL example of use of BaseQuantity

<cbc:InvoicedQuantity unitCode="EA">7.00</cbc:InvoicedQuantity>
(4)
<cbc:LineExtensionAmount currencyID="DKK">24.50</cbc:LineExtensionAmount>
(5)

<cac:Price>
        <cbc:PriceAmount currencyID="DKK">3.50</cbc:PriceAmount>(1)
        <cbc:BaseQuantity unitCode="EA">1</cbc:BaseQuantity>(2)
        <cbc:OrderableUnitFactorRate>0.33</cbc:OrderableUnitFactorRate>(3)
</cac:Price>

1	Item net price
2	Base quantity
3	Invoiced quantity
4	Invoice line net amount

7.12. Environmental data in the Invoice

7.12.1. CO2 Emission data

CO2 emissions data may be included in the invoice. This information is optional, but when provided must be in the structured syntax outlined below.

Emissions data uses the following data elements: AdditionalItemProperty, ItemSpecificationDocumentReference and Certificate.

CO2 emission data fields added in AdditionalItemProperty are:

Property

Description

EmissionFactor

Emissions per invoiced unit.

Unit of measure is always kilogram CO2-eq (CO2e) per unit of InvoicedQuantity.

NetEmissionQuantity

NetEmissionQuantity is the total CO2e amount for the invoice line item (always in CO2e)
Calculated as InvoicedQuantity * EmissionFactor

Unit of measure is always kg CO2e.

EmissionFactorSource

The source for the CO2e calculation. Can be either an internal source (Internal) or external database(Database). This indicates whether the sender has done their own CO2e calculation or relies on third parties

(see also the subsection below, regarding use of external references)

EmissionFactorCalculationRate

The multiplication factor for converting the emission factor listed in EmissionFactorSource into emissions per invoiced unit listed in EmissionFactor.

The EmissionFactorCalculationRate is required if the emission factor in the EmissionFactorSource is calculated on a different basis than InvoicedQuantity. For example:
* The source specifies emission factor per kilogram (KGM), but InvoicedQuantity is each (EA). In this case EmissionFactorCalculationRate is the (average) number of kilogram per piece. If each piece is 10 kilogram (on average), the EmissionFactorCalculationRate is 10.
* The source specifies the emission factor per 100 litre, but the InvoicedQuantity is in litre. In this case the EmissionFactorCalculationRate is equal to 0.01.

This allows EmissionFactor to be calculated from first principles as
(the emission factor from EmissionFactorSource) * EmissionFactorCalculationRate

EmissionFactorCalculationUnit

The EmissionFactorCalculationUnit is required if the emission factor unit code is different from the InvoicedQuantity unit code (e.g. source specifies emissions factor per kilogram (KGM) but InvoicedQuantity is each (EA)). EmissionFactorCalculationUnit is used to specify the base unit used by the source (e.g. KGM).

Unit of measure shall contain a valid unit code (e.g. KGM (kilogram) or LTR (litre)), which must be different from the unit code of InvoicedQuantity.

BaseQuantity does not impact the EmissionFactor and the EmissionFactorQuantity (which are defined per invoiced unit, not per price unit).

UBL example of AdditionalItemProperty for CO2 emission data

<cac:InvoiceLine>
        <cbc:ID>1</cbc:ID>
        <cbc:InvoicedQuantity unitCode="EA">7.00</cbc:InvoicedQuantity>(2)
        <cbc:LineExtensionAmount currencyID="DKK">24.50</cbc:LineExtensionAmount>
        <cac:TaxTotal>
                <cbc:TaxAmount currencyID="DKK">6.63</cbc:TaxAmount>
                <cac:TaxSubtotal>
                        <cbc:TaxableAmount currencyID="DKK">24.50</cbc:TaxableAmount>
                        <cbc:TaxAmount currencyID="DKK">6.63</cbc:TaxAmount>
                        <cac:TaxCategory>
                                <cbc:ID>S</cbc:ID>
                                <cbc:Percent>25</cbc:Percent>
                                <cac:TaxScheme>
                                        <cbc:ID>VAT</cbc:ID>
                                </cac:TaxScheme>
                        </cac:TaxCategory>
                </cac:TaxSubtotal>
        </cac:TaxTotal>
        <cac:Item>
                <cbc:Description>Din favorit dåse sodavand (0,33l)</cbc:Description>
                <cbc:Name>Din favorit sodavand</cbc:Name>
                <cac:AdditionalItemProperty>
                        <cbc:Name>EmissionFactor</cbc:Name>(1)
                        <cbc:Value>0.20</cbc:Value>
                </cac:AdditionalItemProperty>
                <cac:AdditionalItemProperty>
                        <cbc:Name>NetEmissionQuantity</cbc:Name>(3)
                        <cbc:Value>1.4</cbc:Value>
                </cac:AdditionalItemProperty>
                <cac:AdditionalItemProperty>
                        <cbc:Name>EmissionFactorSource</cbc:Name>(4)
                        <cbc:Value>Database</cbc:Value>
                </cac:AdditionalItemProperty>
                <cac:AdditionalItemProperty>
                        <cbc:Name>EmissionFactorCalculationRate</cbc:Name>(5)
                        <cbc:Value>0.33</cbc:Value>
                </cac:AdditionalItemProperty>
                <cac:AdditionalItemProperty>
                        <cbc:Name>EmissionFactorCalculationUnit</cbc:Name>(6)
                        <cbc:Value>KGM</cbc:Value>
                </cac:AdditionalItemProperty>
        </cac:Item>
        <cac:Price>
                <cbc:PriceAmount currencyID="DKK">3.50</cbc:PriceAmount>
                <cbc:BaseQuantity unitCode="EA">1</cbc:BaseQuantity>
        </cac:Price>
</cac:InvoiceLine>

1	EmissionFactor
2	InvoicedQuantity (including UnitCode)
3	NetEmissionQuantity
4	EmissionFactorSource
5	EmissionFactorCalculationRate
6	EmissionFactorCalculationUnit

7.12.2. Use of Links to External References in Item.ItemSpecificationDocumentReference

ItemSpecificationDocumentReference is used to reference additional item specifications that exist in an external reference.

External Database Link

The seller can link to reference documents from the invoice line item, such as reference documents specifying the CO2e calculation.

If AdditionalItemProperty(EmissionFactorSource) refers to an external database link, the data element ItemSpecificationDocumentReference must have an ExternalReference to the database in question.

UBL example of reference to external CO2 emission database

<cac:ItemSpecificationDocumentReference>
        <cbc:ID>CO2EmissionFactorSource-1</cbc:ID> (1)
                <cac:Attachment>
                        <cac:ExternalReference>
                                <cbc:URI>https://denstoreklimadatabase.dk/en</cbc:URI> (2)
                                <cbc:ExpiryDate>2024-12-31</cbc:ExpiryDate>
                        </cac:ExternalReference>
                </cac:Attachment>
</cac:ItemSpecificationDocumentReference>

1	Unique ID to the linked external document.
2	URI contains the external reference link. It’s recommended always to use https.

7.13. Product Certifications in the Invoice

The invoice may contain additional information regarding various product certifications. This information shall be provided in the Certificate subclass to the Item class.

The Certificate class contains the following mandatory fields and sub-classes:

ID: Certificate identifier. If the certificate authority has issued a unique identifier for the product certification, this identifier shall be provided as ID. In the absence of such an identifier, the certificate ID is a tracking number assigned by Supplier.
CertificateTypeCode: The certification scheme (e.g. "FSC/COC" or "ENERGY STAR").
CertificateType: The code list from which the CertificateTypeCode is chosen (e.g. "PackagingMarkedLabelCodeList"). At time of writing, only "PackagingMarkedLabelCodeList" and "Other" are supported.

The Certificate class additionally supports the following optional fields and subclasses:

Remarks: Free text field for additional information not covered in the structured data fields.
IssuerParty: The certification authority which issued the certificate, approved the product’s use of the certificate or (for certificates with no specific approval process) governs the use of the certificate.
DocumentReference: Supplementary documentation regarding the certificate, e.g. a specific proof-of-issue for the certificate, or online lookup service.
Signature: The issuing body may provide a digital signature to allow verification of the authenticity and integrity of a proof-of-issue document.

UBL example of Certificate for Environmental Code documentation

<cac:Certificate>
        <cbc:ID>ENERGY_STAR-1234</cbc:ID>
        <cbc:CertificateTypeCode>ENERGY_STAR</cbc:CertificateTypeCode>
        <cbc:CertificateType>PackagingMarkedLabelCodeList</cbc:CertificateType>
        <cac:IssuerParty>
                <cac:PartyName>
                        <cbc:Name>NA</cbc:Name>
                </cac:PartyName>
        </cac:IssuerParty>
</cac:Certificate>

8. Description and Examples of Selected Elements of the Invoice Response

8.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@urn:fdc:oioubl.dk:trns:billing:invoice_response:3.0</cbc:CustomizationID>
        <cbc:ProfileID>urn:fdc:oioubl.dk:bis:billing_with_response:3</cbc:ProfileID>
        <cbc:ID>imrid001</cbc:ID>(3)
        <cbc:IssueDate>2024-12-01</cbc:IssueDate>(4)
        <cbc:IssueTime>12:00:00</cbc:IssueTime>(4)

1	The message is based on the OIOUBL specialized transaction, which is in turn based on Peppol transaction specification for Invoice Response (T111)
2	The profile ID states that the OIOUBL profile, like the Invoice Response (T111) on which it is based, is integrated in the Billing with 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

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

8.3. Response

The Response class 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 change must be reported with another Invoice Response.

The status clarification can be an explanation of the reason for the reported status and/or an action expected from Seller (typically a clarification request or a request for a credit note and corrected invoice). The purpose of this is to help Seller understand the status and resolve it correctly.

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

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

UBL example where TAX is VAT:

<cac:DocumentResponse>
  <cac:Response>
    <cbc:ResponseCode>RE</cbc:ResponseCode> (1)
    <cbc:EffectiveDate>2024-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 (Buyer’s 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.

8.4. Document reference

Used to provide a reference to the business document e.g. the Invoice or Credit Note, to which the Invoice Response 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 OIOUBL 3 Kodelister for a complete list of all the document types.

UBL example:

                <cac:DocumentReference>
                        <cbc:ID>inv021</cbc:ID>(1)
                        <cbc:IssueDate>2014-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

9. OIOUBL License and Statement of Copyright

OIOUBL 3 Licens og ophavsret[OIOUBL 3 License and Statement of Copyright]

10. Link to main site of documentation

Main documentation site

1. When an invoice is conditionally accepted (CA) the Buyer will proceed with the processing according to the conditions stated in the Invoice Response. The Seller may still respond with any comments or objections to the conditions given.