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.

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:

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.

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:

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 relevant legislation.

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.

The Summarised invoicing process requires the use of the following documents:

Seller is mandatory information and provided in element cac:AccountingSupplierParty

Buyer is mandatory information and provided in element cac:AccountingCustomerParty

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:

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.

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.

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.

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 code list.

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

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

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.

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.

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 given at document level.

An invoice may contain a supportive document as informative. Examples of such documents may be work reports, certificates or other documents that relate to the purchase or the invoiced items. A supportive document can be attached to the invoice in two ways: by providing a direct hyperlink through which the document can be downloaded or by embedding the document into the invoice. A compliant receiver is required to be able to receive an attached supportive document and, in case of embedded files, to convert it into a file but he is not required to handle the content of that file since it is only provided as informative.

When attaching a document using an uri the hyperlink shall point directly to the file that is to be downloaded.

An embedded document is contained in the invoice as binary object using base64 encoding and shall be supplemented with information about the name of the document file and a mime code indicating the type of the file. This allows the receiver to convert the binary code into a file that has the same name as the original file and allows him to associate the received file to a suitable application for viewing its content. The set of allowed codes for the file type (mime code) is limited to types that can be opened with applications that are commonly used and available.

As is with other file types, when an attached file is an XML file the receiver is expected to be able to receive and convert the binary object into an XML file but the sender can not expect the receiver to view or process the content of that XML file. Any further handling of an embedded XML file attachment is optional for the receiver.

In Summarised invoicing process, the supplier sends a Delivery Note to the customer with each delivery and the buyer uses the information in the Delivery Note to verify the reception of the items. The Delivery Note is focused on providing information about the items that are being delivered. At the end of a period (usually a month) the supplier sends an invoice that summarises the items that were delivered during that period.

To reference or match an invoice to a despatch or receipt advice use the following elements:

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

Examples of codes for payment by credit transfer are:

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.

Examples of codes for payment by card are:

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.

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.

Consumption Tax in Japan is a broad-based tax levied on nearly all supplies of goods and services in Japan. In other countries, Consumption Tax is known as the Value Added Tax (VAT) or Goods and Services Tax (GST). Consumption Tax in Japan is almost same as VAT in EU countries and GST.

There are two rates. One is standard rate (10%) and the other is reduced rate (8%). The reduced rate has been implemented from October 2019. Its scope is limited. Only transactions of foods and beverages (excluding liquors) and subscribed newspapers issued twice or more per week are covered by the reduced rate.

A taxpayer of Consumption Tax is a business. A business with taxable sales of more than 10 million JPY (during the reference taxable period)* shall be categorized as a taxable business. On the other hands, there is a special measure for SMEs. A business with taxable sales of 10 million JPY or under shall be exempt from Consumption Tax (an exempt business).

*The “during the reference period” is the year or business year before the previous one.

Under the current system, in Japan, Invoice Based method has not adopted for input tax credit purpose. To claim of input tax, in principle, a taxable business is required to retain an accounting book and a Document issued by a supplier with specific description.

The Document can be issued by not only a taxable business but also an exempt business. So, under the current system, even a taxable transaction with an exempt business would be subject to input tax credit.

The Document must contain the following information.

This specification may support the Document.

On October 1st, 2023, the current input tax credit system will be changed. “Qualified Invoice Base method”, new input tax credit system, will be implemented. It is almost same as Invoice Based method in other countries.

Under the new method, a taxable business shall retain an accounting book with certain descriptions and a Qualified Invoice issued by a registered taxable business. A Qualified Invoice can be issued only by a registered taxable business. This means that a taxable business without the registration and an exempt business can’t issue a Qualified Invoice. So that, a taxable transaction with them is not subject to input tax credit.

From October 1st, 2023 to September 30th, 2029, the transitional rule will be applicable. Under the transitional rule, a taxable business can recover a certain percentage of input tax paid on a taxable transaction with a non-registered taxable business or an exempt business by retaining the Document (same as the document under the current system) and an accounting book.

Table 1 Difference of requirements to apply input tax credit

Table 2 Difference of Information required on a Non-tax Invoice (the Document) and a Qualified Invoice

An exempt business that wants to correct an error may issue a new Non-tax Invoice to rectify the preceding one.

Formulas for the calculations of totals are as follows:

The following elements show the legal monetary totals for an invoice or credit note

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:

A maximum of two digits are allowed for the following amounts in an invoice.

A Non-tax Invoice is not allowed to have any tax amount by Consumption Tax law. So that, Invoice total tax amount in tax accounting currency (ibt-111), Tax category tax amount (ibt-117) and Tax category tax amount in tax accounting currency (ibt-190) must be zero.

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

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

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO15000, Annex A.

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 {ISO15000}.

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.