Link to main site of documentation

Introduction to openPEPPOL and BIS

This PEPPOL BIS provides a set of specifications for implementing a PEPPOL business process.

This specification, is a Country Specification of the Peppol International model (PINT). Any instance documents compliant to this specification will be compliant with the PINT.

The purpose of this document is to facilitate an efficient implementation and increased use of electronic collaboration regarding the billing process.

Statement of copyright

This Peppol Business Interoperability Specification (Peppol BIS) document is a Country Specification based on the PINT. The restrictions on PINT implemented in this Peppol BIS are identified in the conformance statement provided in appendix A.

The copyright of PINT is owned by OpenPEPPOL and its members.cOpenPEPPOL AISBL holds the copyright of this Peppol BIS.

This PEPPOL BIS document may not be modified, re-distribute, sold or repackaged in any other way without the prior consent of OpenPEPPOL AISBL.

Document Structure

This document is structured as follows:

Chapters 1 - 5 gives general information on the business processes, requirements and functionalities
Chapter 6 describes the semantical data types
Chapters 7 - 9 describes tax, calculations and rounding.
Chapter 10 provides examples of selected parts of the invoice
Chapter 11 gives extenal links to the relevant UBL schemas.

Scope

This document is concerned with clarifying requirements for ensuring interoperability and provides guidelines for the support and implementation of these requirements. This document will also provide a detailed implementation guideline for the invoice and credit note transactions.

Audience

The audience for this document is organisations wishing to be Peppol enabled for exchanging electronic invoices, and/or their ICT-suppliers. These organisations may be:

Service providers
Contracting Authorities (CA)
Economic Operators (EO)
Software Developers

More specifically, roles addressed are the following:

ICT Architects
ICT Developers
Business Experts

For further information on Peppol/OpenPEPPOL, please see PEPPOL BIS common text and introduction

1. Benefits

The invoice and credit note provides simple support for complex invoicing, where there is a need for credit note in addition to an invoice. Other potential benefits are, among others:

Can be mandated as a basis for national or regional eInvoicing initiatives.
Procurement agencies can use them as basis for moving all invoices into electronic form. The flexibility of the specifications allows the buyers to automate processing of invoices gradually, based on different sets of identifiers or references, based on a cost/benefit approach.
SME can offer their trading partners the option of exchanging standardised documents in a uniform way and thereby move all invoices/credit notes into electronic form.
Large companies can implement these transactions as standardised documents for general operations and implement custom designed bi-lateral connections for large trading partners.
Supports customers with need for more complex interactions.
Can be used as basis for restructuring of in-house processes of invoices.
Significant saving can be realised by the procuring agency by automating and streamlining in-house processing. The accounting can be automated significantly, approval processes simplified and streamlined, payment scheduled timely and auditing automated.

2. Parties and roles

The diagram below shows the roles involved in the invoice and credit note transactions. The customer and invoice receiver is the same entity, as is the supplier and the invoice sender.

2.1. Parties

Customer: The customer is the legal person or organisation who is in demand of a product or service. Examples of customer roles: buyer, consignee, debtor, contracting authority.
Supplier: The supplier is the legal person or organisation who provides a product or service.

2.2. Roles

Creditor: One to whom a debt is owe. The party that claims the payment and is responsible for resolving billing issues and arranging settlement. The party that sends the invoice or credit note. Also known as invoice issuer, accounts receivable or seller.
Debtor: 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 process

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 order and a specification of delivered goods and services.

An invoice may also refer to a contract or a frame agreement. The invoice may specify articles (goods and services) with article number or article description.

The customer receives the invoice and processes it in the invoice control system 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 completely rejects the invoice, 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 with the use of this PEPPOL BIS profile. This process assumes that both the invoice and the credit note are exchanged electronically.

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

4. Invoice functionality

An invoice may support functions related to a number of related (internal) business processes. This Peppol BIS shall support the following functions:

Accounting
Invoice verification against the contract, the purchase order and the goods and service delivered
Tax reporting
Auditing
Payment

In the following chapters an assessment is made of what information is needed for each of the functions listed above and whether it is in scope or out of scope for this Peppol BIS.

Explicit support for the following functions (but not limited to) is out of scope:

Inventory management
Delivery processes
Customs clearance
Marketing
Reporting

4.1. Accounting

Recording a business transaction into the financial accounts of an organization is one of the main objectives of the invoice. According to financial accounting best practice and CT rules every Taxable person shall keep accounts in sufficient detail for CT to be applied and its application checked by the tax authorities. For that reason, an invoice shall provide for the information at document and line level that enables booking on both the debit and the credit side.

4.2. Invoice verification

This process forms part of the Buyer’s internal business controls. The invoice shall refer to an authentic commercial transaction. 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, for example, and as applicable:

the relevant purchase order
the contract
the call for tenders, that was the basis for the contract
the Buyer’s reference
the confirmed receipt of the goods or services
delivery information

An invoice should also contain sufficient information that allows the received invoice to be transferred to a responsible authority, person or department, for verification and approval.

4.3. Auditing

Companies audit themselves as means of internal control or they may be audited by external parties as part of a legal obligation. Accounting is a regular, ongoing process whereas an audit is a separate review process to ensure that the accounting has been carried out correctly. The auditing process places certain information requirements on an invoice. These requirements are mainly related to enable verification of authenticity and integrity of the accounting transaction.

Invoices, conformant to this Peppol BIS support the auditing process by providing sufficient information for:

identification of the relevant Buyer and Seller
identification of the products and services traded, including description, value and quantity
information for connecting the invoice to its payment
information for connecting the invoice to relevant documents such as a contract and a purchase order

4.4. Tax Reporting

The invoice is used to carry Tax related information from the Seller to the Buyer to enable the Buyer and Seller to correctly handle Tax booking and reporting. An invoice should contain sufficient information to enable the Buyer and any auditor to determine whether the invoice is correct from a Tax point of view.

The invoice shall allow the determination of the Tax regime, the calculation and description of the tax, in accordance with the {Tax-dir} and subsequent amendments.

4.5. Payment

An invoice represents a claim for payment. The issuance of an invoice may take place either before or after the payment is carried out. When an invoice is issued before payment it represents a request to the Buyer to pay, in which case the invoice commonly contains information that enables the Buyer, in the role of a debtor, to correctly initiate the transfer of the payment, unless that information is already agreed in prior contracts or by means of payment instructions separately lodged with the Buyer.

If an invoice is issued after payment, such as when the order process included payment instructions or when paying with a credit card, online or telephonic purchases, the invoice may contain information about the payment made in order to facilitate invoice to payment reconciliation on the Buyer side. An invoice may be partially paid before issuing such as when a pre-payment is made to confirm an order.

Invoices, conformant with this specification should identify the means of payment for settlement of the invoice and clearly state what payment amount is requested. They should provide necessary details to support bank transfers. Payments by means of Credit Transfer, Direct debit, and Payment Card are in scope.

4.6. Negative invoices and credit notes

This BIS supports negative grand totals.

The argument for negative invoices is to open up for a wider spectrum of invoicing processes.

Examples of such processes are

Preliminary (estimated) consumption invoice that is balanced out in a later meter-based invoice;
Pre-payment (with or without CT) is settled through a final invoice; and
Some user communities prefer to use negative invoice rather than credit note when correcting transactions.

Buyers who value automatic matching of e-invoices to orders or invoicing objects may wish to limit the areas and situations where complex transactions can be accepted and voice their requirements at time of procurement.

The decision has the following implications on the transaction format:

The invoice (now with “negative invoice capacity”) can function as an alternative to the credit note. Invoice-generating systems may implement either option, while invoice-receiving systems have to support both of them.
The transaction format for credit note has to be designed to accommodate for negative grand total, as well; this is because an entire negative invoice may have to be balanced out by means of a credit note.

Attention is drawn to the intrinsic differences between credit note and negative invoice when it comes to convey crediting information.

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="JPY">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="JPY">1300</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="JPY">1325</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="JPY">1656</cbc:TaxInclusiveAmount>
        <cbc:ChargeTotalAmount currencyID="JPY">25</cbc:ChargeTotalAmount>
        <cbc:PayableAmount currencyID="JPY">1656</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

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

<cac:InvoiceLine>
    <cbc:ID>2</cbc:ID>(3)
    <cbc:InvoicedQuantity unitCode="DAY">-3</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="JPY">-1500</cbc:LineExtensionAmount>
    <!-- Code omitted for clarity -->
    <cac:Price>
        <cbc:PriceAmount currencyID="JPY">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

4.6.1. When crediting by means of credit note

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

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="JPY">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="JPY">1300</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="JPY">1325</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="JPY">1656</cbc:TaxInclusiveAmount>
        <cbc:ChargeTotalAmount currencyID="JPY">25</cbc:ChargeTotalAmount>
        <cbc:PayableAmount currencyID="JPY">1656</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

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

<cac:CreditNoteLine>
    <cbc:ID>2</cbc:ID>(4)
    <cbc:CreditedQuantity unitCode="DAY">-3</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="JPY">-1500</cbc:LineExtensionAmount>
    <!-- Code omitted for clarity -->
    <cac:Price>
        <cbc:PriceAmount currencyID="JPY">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

4.6.2. When crediting by means of negative invoice

The function of crediting or debiting is controlled merely by the sign (i.e. plus sign or minus sign) of the amount concerned, while the business document type (e.g. 380) has no relevance on the operation (“to credit”) itself.

UBL example of negative invoice correcting the example invoice above

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> (1)
<!-- Code omitted for clarity -->
<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Insurance</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="JPY">-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>
<!-- Code omitted for clarity -->
<cac:LegalMonetaryTotal> (3)
    <cbc:LineExtensionAmount currencyID="JPY">-1300</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="JPY">-1325</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="JPY">-1656</cbc:TaxInclusiveAmount>
    <cbc:ChargeTotalAmount currencyID="JPY">-25</cbc:ChargeTotalAmount>
    <cbc:PayableAmount currencyID="JPY">-1656</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

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

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

1	Code 380 indicating an invoice
2	Charge amount is negative to correct the original invoice
3	All document level amounts are negative
4	Invoice line 1 with originally positive quantity and line amount, now both negative
5	Price amount must always be positive, and is not changed
6	Invoice line 2 with originally negative quantity and line amount, now positive

5. Peppol Identifiers

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

5.1. Profiles and messages

All messages contains Business process type (IBT-23) and Specification identifier (IBT-24). Business process type (IBT-23) identifies what business process a given message is part of, and Specification identifier (IBT-24) identifies the kind of message and the rules applied.

Profiles are connected to one business process, and may contain multiple document types. Valid document instances shall contain corresponding Business process type (IBT-23) and Specification identifier (IBT-24).

Specification identifier (IBT-24) is a string without spaces. The list below contains spaces in Specification identifier (IBT-24) to make them easier to read. Make sure to remove any spaces before use.

5.2. Japanese Standard Invoice BIS

In the table below you will find the values to be used as the specification identifier (IBT-24) and the business process type (IBT-23) for this profile

Type Element cbc:CustomizationID Element cbc:ProfileID

Type	Element `cbc:CustomizationID`	Element `cbc:ProfileID`
Invoice and credit note	urn:peppol:pint:billing-3.0@jp:peppol-1	urn:peppol:bis:billing

Invoice and credit note

urn:peppol:pint:billing-3.0@jp:peppol-1

urn:peppol:bis:billing

UBL example of profile identifier

<cbc:CustomizationID>urn:peppol:pint:billing-3.0@jp:peppol-1</cbc:CustomizationID>
<cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>

6. Semantic datatypes

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

The details of the technical implementation can be found in [Detailed UBL message guideline]

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

6.2. Semantic data types

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

When used in an instance 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.

6.2.1. Amount

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

IMPORTANT:Amounts in JPY have no fraction digits.

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	10000

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000

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

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

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

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

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

GLN

Scheme version identifier

Conditional

String

1.0

6.2.7. Date

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

Dates shall not include timezone information.

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

6.2.8. 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 2. Document Reference. Type
Component	Use	Primitive Type	Example
Content	Mandatory	String	abc:123-DEF

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

Component

Use

Primitive Type

Example

Content

Mandatory

String

5% allowance when paid within 30 days

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

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 code list [media-type]

7. Consumption tax (CT)

The chapters below describe the different CT informations that can be provided in a Japanese PEPPOL invoice or credit note.

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

7.1. Line CT Information

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

7.2. Document level allowance or charge

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

7.3. CT Breakdown

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

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

Example 1. Example

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

7.4. Invoice total CT amount

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

8. Rounding

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

If Invoice currency code(ibt-005) is "JPY", all document level amounts shall have no decimals for accounting.
If Invoice currency code(ibt-005) is "JPY", invoice line net amount shall be rounded.
Results from calculations involving already rounded amounts are not subject to rounding, like payable amounts and total amounts included CT.

Please also see Calculation for details on how to calculate the different amounts.

9. Calculation

9.1. Calculation of totals

Formulas for the calculations of totals are as follows:

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

Business term id

Term name

Calculation

IBT-106

Sum of invoice line net amounts

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

IBT-107

Sum of allowances on document level

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

IBT-108

Sum of charges on document level

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

IBT-109

Invoice total amount without CT

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

IBT-110

Invoice total CT amount

\$sum("IBT-117: CT category tax amount")\$

IBT-112

Invoice total amount with CT

\$\ \ \ \ "IBT-109: Invoice total amount without CT"\$
\$+ \ "IBT-110: Invoice total CT amount"\$

IBT-115

Amount due for payment

\$\ \ \ \ "IBT-112: Invoice total amount with CT"\$
\$- \ "IBT-113: Paid amount"\$
\$+ \ "IBT-114: Rounding amount"\$

In case of amount in JPY, BT-114 Rounding amount is not used, therefore, BT-115 = BT-112: Invoice total amount with CT − BT-113: Paid amount.

9.1.1. 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"\$

9.2. Calculation on line level

9.2.1. Item net price (IBT-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 (IBT-148)" - "Item price discount (IBT-147)"\$

UBL example of item net price

<cac:Price>
    <cbc:PriceAmount currencyID="JPY">410</cbc:PriceAmount>(3)
    <cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
    <cac:AllowanceCharge>
        <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
        <cbc:Amount currencyID="JPY">40</cbc:Amount>(2)
        <cbc:BaseAmount currencyID="JPY">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"\$

9.2.2. Invoice line net amount (IBT-131)

The invoice line net amount (IBT-131) is as the name implies the net amount without CT, 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 (IBT-146)" div "Item price base quantity (IBT-149)")\$
\$times ("Invoiced Quantity (IBT-129)")\$
\$+ "Invoice line charge amount (IBT-141)" - "Invoice line allowance amount (IBT-136)"\$

As the line net amount must be rounded to no 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 (IBT-146)" div "Item price base quantity (IBT-149)") times ("Invoiced Quantity (IBT-129)")\$ must be rounded to no 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="C62">10</cbc:InvoicedQuantity>(3)
<cbc:LineExtensionAmount currencyID="JPY">1000</cbc:LineExtensionAmount>(4)

<!-- Code omitted for clarity-->

<cac:Price>
    <cbc:PriceAmount currencyID="JPY">200</cbc:PriceAmount>(1)
    <cbc:BaseQuantity unitCode="C62">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="C62">10</cbc:InvoicedQuantity>(4)
<cbc:LineExtensionAmount currencyID="JPY">900</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="JPY">1</cbc:Amount>(2)
    <cbc:BaseAmount currencyID="JPY">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="JPY">101</cbc:Amount>(3)
</cac:AllowanceCharge>

<!-- Code omitted for clarity-->

<cac:Price>
    <cbc:PriceAmount currencyID="JPY">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"\$

9.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="JPY">200</cbc:Amount> (3)
    <cbc:BaseAmount currencyID="JPY">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="JPY">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

9.4. Calculation of CT

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

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

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

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

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

Consumption Tax category tax amount (BT-117) = Consumption Tax category taxable amount (IBT-116) x (Consumption Tax category rate (IBT-119) / 100), rounded to integer. The rounded result amount SHALL be between the amount rounded down to integer value as floor and the amount rounded up to integer value as ceiling. (jp-br-co-01).

UBL example of calculations of CT Breakdown

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Cleaning</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="JPY">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="JPY">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="JPY">1250</cbc:TaxAmount>

    <cac:TaxSubtotal>(3)
        <cbc:TaxableAmount currencyID="JPY">5000</cbc:TaxableAmount>(4)
        <cbc:TaxAmount currencyID="JPY">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="JPY">2000</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="JPY">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="JPY">4000</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="JPY">2000</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="JPY">900</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	CT 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 ("CT rate" div 100)\$
6	CT Breakdown for category E, and rate = 0%

10. Examples of selected parts of the transaction

In the subchapters below you find examples of selected parts of the transaction. Please also look into the [Detailed UBL message guideline] for details on all elements and attributes, and their rules and use of code lists.

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

10.1.1. 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 1</cbc:StreetName>
            <cbc:AdditionalStreetName>Postbox 123</cbc:AdditionalStreetName>
            <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>GB76576657</cbc:CompanyID>
            (3)
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyTaxScheme>
            <cbc:CompanyID>TaxRegistrationID</cbc:CompanyID>
            <cac:TaxScheme>
                <cbc:ID>TAX</cbc:ID>
            </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyLegalEntity>
            <cbc:RegistrationName>SupplierOfficialName Ltd</cbc:RegistrationName>
            <cbc:CompanyID>GB983294</cbc:CompanyID>
            <cbc:CompanyLegalForm>Private Limited Company</cbc:CompanyLegalForm>
        </cac:PartyLegalEntity>
        <cac:Contact>
            <cbc:Name>John Doe</cbc:Name>
            <cbc:Telephone>9384203984</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 recommended for all party identifiers
3	VAT identifiers shall be prefixed with the country code

10.1.2. Buyer (AccountingCustomerParty)

Buyer is mandatory information and provided in element cac:AccountingCustomerParty

UBL example ofbuyer 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 32</cbc:StreetName>
            <cbc:AdditionalStreetName>Po box 878</cbc:AdditionalStreetName>
            <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>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>23434234</cbc:Telephone>
            <cbc:ElectronicMail>lj@buyer.se</cbc:ElectronicMail>
        </cac:Contact>
    </cac:Party>
</cac:AccountingCustomerParty>

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

10.1.3. Payment receiver (PayeeParty)

Payment receiver is optional information. If this information is not supplied, the seller is the payment receiver. When payee information is sent this is indicating that a factoring situation is being documented.

To reflect the assignment of an Invoice to a factor there is a need to:

have a disclaimer (notification notice) on the Invoice that the Invoice has been assigned to a factor. The disclaimer should be given using the Invoice note (IBT-22) on document level.
identify the Factor as the Payee
to have the bank account changed to favour of a Factor.

UBL example of payee information

<cac:PayeeParty>
    <cac:PartyIdentification>
        <cbc:ID schemeID="0192">987654325</cbc:ID>
        (1)
    </cac:PartyIdentification>
    <cac:PartyName>
        <cbc:Name>Payee party</cbc:Name>
    </cac:PartyName>
    <cac:PartyLegalEntity>
        <cbc:CompanyID schemeID="0192">987654325</cbc:CompanyID>
        (2)
    </cac:PartyLegalEntity>
</cac:PayeeParty>

1	schemeID attribute is recommended for all party identifiers
2	schemeID attribute is recommended for party legal entity identifiers

10.1.4. Sellers Tax Representative (TaxRepresentativePary)

Tax representative party for the seller is relevant for sellers delivering goods and services in a country without having a permanent establishment in that country. In such cases information on the tax representative shall be included in the invoice.

UBL example of tax representative information

<cac:TaxRepresentativeParty>
    <cac:PartyName>
        <cbc:Name>TaxRepresentative Name</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
        <cbc:StreetName>Regent street 32</cbc:StreetName>
        <cbc:AdditionalStreetName>Building 23</cbc:AdditionalStreetName>
        <cbc:CityName>London</cbc:CityName>
        <cbc:PostalZone>23W 45H</cbc:PostalZone>
        <cbc:CountrySubentity>Subentity</cbc:CountrySubentity>
        <cac:AddressLine>
            <cbc:Line>Back door</cbc:Line>
        </cac:AddressLine>
        <cac:Country>
            <cbc:IdentificationCode>GB</cbc:IdentificationCode>
        </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
        <cbc:CompanyID>GB122324324535</cbc:CompanyID>
        (1)
        <cac:TaxScheme>
            <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
    </cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>

1	VAT identifiers shall be prefixed with the country code

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

UBL example of delivery information

<cac:Delivery>
    <cbc:ActualDeliveryDate>2017-11-01</cbc:ActualDeliveryDate>
    <cac:DeliveryLocation>
        <cbc:ID schemeID="0088">7300010000001</cbc:ID>
        <cac:Address>
            <cbc:StreetName>Delivery street 2</cbc:StreetName>
            <cbc:AdditionalStreetName>Building 56</cbc:AdditionalStreetName>
            <cbc:CityName>Stockholm</cbc:CityName>
            <cbc:PostalZone>21234</cbc:PostalZone>
            <cac:AddressLine>
                <cbc:Line>Gate 15</cbc:Line>
            </cac:AddressLine>
            <cac:Country>
                <cbc:IdentificationCode>SE</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>

10.3. 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:

10.3.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 be aware that an invoice instance cannot have a sales order reference, without the corresponding purchase order reference.

UBL example or order and sales order reference

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

1	Purchase order reference
2	Sales order reference

10.3.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 recipient, and hence it is important to fill this element with the correct values according to the need of the recipient.

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.

When reference is provided by the customer, the correct element shall contain the provided reference.

UBL example of buyer reference

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

10.3.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 [inv-object-code].

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="ABT">DR35141</cbc:ID>(1)
    <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode>(2)
</cac:AdditionalDocumentReference>

1	Scheme identifier from UN/CEFACT 1153 code list
2	Document type code shall be ´130´ to indicate Invoiced object

10.3.4. Contract reference

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

UBL example of contract reference

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

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

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

10.3.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 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 proejct 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

10.4. Preceding invoice references

A credit note or negative invoice can refer to one or more initial invoice(s). This is done in the business group BG-3 Preceding invoice reference, providing the invoice number and issue date. The issue date shall be provided in case the preceding invoice reference is not unique.

In case correction applies to a large number of invoices, the invoicing period (BG-14), as necessary combined with a clarifying invoice note (IBT-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 shall be filled if the invoice reference is not unique
3	Repeat the `cac:BillingReference` to add several preceding invoice references

10.5. Allowances and Charges

The Invoice and credit note transactions has 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.

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 itself shall always be the net price, i.e. the base amount reduced with a discount (allowance).

Only one occurence of allowance (discount) is allowed.
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 amount and the base amount.

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="JPY">20</cbc:Amount> (5)
    <cbc:BaseAmount currencyID="JPY">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="JPY">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>
    <cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Cleaning</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
    <cbc:Amount currencyID="JPY">1</cbc:Amount>
    <cbc:BaseAmount currencyID="JPY">10</cbc:BaseAmount>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
    <cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="JPY">101</cbc:Amount>
</cac:AllowanceCharge>

10.6. CT accounting currency

If the invoice currency is different from the national currency, this is expressed in the invoice by stating the national currency in the element Tax accounting currency (IBT-6), and the amount of CT payable in national currency is stated in the element Invoice total CT amount in accounting currency (IBT-111).

UBL example of VAT currency

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

<cac:TaxTotal>
    <cbc:TaxAmount currencyID="JPY">1000</cbc:TaxAmount>
    (3)
    <cac:TaxSubtotal>
        <cbc:TaxableAmount currencyID="JPY">4000</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="JPY">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">100017.50</cbc:TaxAmount>
    (4)
</cac:TaxTotal>

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

10.7. Payment means information

10.7.1. Credit transfer

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

See [payment-means] for all allowed codes. Examples of codes for payment by credit transfer are:

30 - Credit transfer
58 - SEPA credit transfer

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

<cac:PaymentMeans>
    <cbc:PaymentMeansCode name="Credit transfer">30</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>93274234</cbc:PaymentID>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>32423940</cbc:ID>(3)
        <cbc:Name>AccountName</cbc:Name>
        <cac:FinancialInstitutionBranch>
            <cbc:ID>BIC32409</cbc:ID>(4)
        </cac:FinancialInstitutionBranch>
    </cac:PayeeFinancialAccount>
</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

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

See [payment-means] for all allowed codes. Examples of codes for payment by card are:

48 - Bank card
54 - Credit card
55 - Debet card

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

<cac:PaymentMeans>
    <cbc:PaymentMeansCode name="Credit card">54</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>9387439</cbc:PaymentID>
    <cac:CardAccount>
        <cbc:PrimaryAccountNumberID>123236</cbc:PrimaryAccountNumberID>(2)
        <cbc:NetworkID>VISA</cbc:NetworkID>(3)
        <cbc:HolderName>Card holders name</cbc:HolderName>(4)
    </cac:CardAccount>
</cac:PaymentMeans>

1	Payment means code for credit card
2	Mandatory, shall be the last 4 to 6 digits of the payment card number
3	Mandatory, used to identify the financial service network provider of the card. Examples are VISA, MasterCard, American Express.
4	Card holder name

10.7.3. Direct debit

See [payment-means] for all allowed codes. Examples of codes for payment by direct debit are:

49 - Direct debit
59 - SEPA direct debit

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

10.7.4. Payment by post- or bank giro

See [payment-means] for all allowed codes. Examples of codes for payment by giro are:

50 - Payment by postgiro
56 - Bankgiro

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

<cac:PaymentMeans>
    <cbc:PaymentMeansCode name="Postgiro">50</cbc:PaymentMeansCode>(1)
    <cbc:PaymentID>PgPaymRef-345</cbc:PaymentID>(2)
    <cac:PayeeFinancialAccount>
        <cbc:ID>98765432</cbc:ID>(3)
    </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

1	Payment means code
2	Remittance information
3	Local postgiro account number

10.8. Item information

10.8.1. Item identifiers

In an invoice line the seller item identifier, the buyer item identifier and the standard item identifier can be provided. For sellers and buyers item identifiers, no scheme attribute is used, whilst the schemeID is mandatory for the standard item identification, and must be from the ISO 6523 ICD list.

UBL example of item identifiers

<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

10.8.2. Item classification

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

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.

UBL example of UNSPSC

<cac:CommodityClassification>
    <cbc:ItemClassificationCode listID="TST" listVersionID="19.05.01">86776</cbc:ItemClassificationCode>(1)
</cac:CommodityClassification>

listID must be from UNCL7143 code list, and code TST indicates this is a UNSPSC classification, listVersionID is optional, but can be used to specify the version of UNSPSC. NOTE, in previous versions code MP was used as temporary workaround to identify UNSPSC. In fall release 2019 it is replaced with the new 7143 code TST that is specific for UNSPSC.

10.9. Price information

An invoice must contain information about the item net price and 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 (IBT-146).

UBL example of price with price discount

<cac:Price>
    <cbc:PriceAmount currencyID="JPY">410</cbc:PriceAmount>(4)
    <cbc:BaseQuantity unitCode="XBX">1</cbc:BaseQuantity>(3)
    <cac:AllowanceCharge>
        <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
        <cbc:Amount currencyID="JPY">40</cbc:Amount>(2)
        <cbc:BaseAmount currencyID="JPY">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="JPY">200</cbc:PriceAmount>
    <cbc:BaseQuantity unitCode="C62">2</cbc:BaseQuantity>
</cac:Price>

10.10. Unit of measure

Unit of measure in an invoice allows the use of codes from UNECE Recommendation No. 20 (version 11e), as well as codes from UNECE Recommendation No. 21 prefixed with an X. Please also see [uom] for further information on the code lists.

Table 3. Examples of unit of measure from Recommendation No. 20
Code	Name
H87	Piece
KGM	Kilogram
MTR	Meter
LTR	Litre
MTK	Square metre
MTQ	Cubic metre
KTM	Kilometre
TNE	Tonne (metric ton)
KWH	Kilowatt hour
DAY	Day
HUR	Hour
MIN	Minute

Table 4. Examples of unit of measure from Recommendation No. 21, prefixed with an X
Code	Name
XBG	Bag
XBX	Box
XCT	Carton
XCY	Cylinder
XBA	Barrel
XPK	Package
XPX	Pallet
XRL	Reel
XSA	Sack
XST	Sheet

UBL example of unit of measure

<cbc:InvoicedQuantity unitCode="H87">10</cbc:InvoicedQuantity>(1)
<cbc:InvoicedQuantity unitCode="XPX">10</cbc:InvoicedQuantity>(2)

1	Code H87 from Recommendation no. 20
2	Code PX, prefixed with an X from Recommendation no. 21

11. UBL schemas and namespaces

The XML schemas used are

UBL Invoice 2.1 with the target namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2
UBL CreditNote 2.1 with the target namespace urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2

Peppol BIS Japan Billing

Link to main site of documentation

Introduction to openPEPPOL and BIS

Document Structure

Scope

Audience

1. Benefits

2. Parties and roles

2.1. Parties

2.2. Roles

3. Business processes

3.1. General invoicing process

4. Invoice functionality

4.1. Accounting

4.2. Invoice verification

4.3. Auditing

4.4. Tax Reporting

4.5. Payment

4.6. Negative invoices and credit notes

4.6.1. When crediting by means of credit note

4.6.2. When crediting by means of negative invoice

5. Peppol Identifiers

5.1. Profiles and messages

5.2. Japanese Standard Invoice BIS

6. Semantic datatypes

6.1. Primitive types

6.2. Semantic data types

6.2.1. Amount

6.2.2. Unit Price Amount

6.2.3. Percentage

6.2.4. Quantity

6.2.5. Code

6.2.6. Identifier

6.2.7. Date

6.2.8. Document Reference

6.2.9. Text

6.2.10. Binary objects

7. Consumption tax (CT)

7.1. Line CT Information

7.2. Document level allowance or charge

7.3. CT Breakdown

7.4. Invoice total CT amount

8. Rounding

9. Calculation

9.1. Calculation of totals

9.1.1. UBL syntax calculation formulas

9.2. Calculation on line level

9.2.1. Item net price (IBT-146)

9.2.2. Invoice line net amount (IBT-131)

9.3. Calculation of allowance/charge amount

9.4. Calculation of CT

10. Examples of selected parts of the transaction

10.1. Parties

10.1.1. Seller (AccountingSupplierParty)

10.1.2. Buyer (AccountingCustomerParty)

10.1.3. Payment receiver (PayeeParty)

10.1.4. Sellers Tax Representative (TaxRepresentativePary)

10.2. Delivery Details (Date and Location)

10.3. References

10.3.1. Purchase order and sales order reference

10.3.2. Buyer reference

10.3.3. Invoiced object identifier

10.3.4. Contract reference

10.3.5. Despatch and receipt advice references

10.3.6. Tender reference

10.3.7. Project reference

10.4. Preceding invoice references

10.5. Allowances and Charges

10.6. CT accounting currency

10.7. Payment means information

10.7.1. Credit transfer

10.7.2. Card Payment

10.7.3. Direct debit

10.7.4. Payment by post- or bank giro

10.8. Item information

10.8.1. Item identifiers

10.8.2. Item classification

10.9. Price information

10.10. Unit of measure

11. UBL schemas and namespaces