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

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 a Summary invoice pattern 1 business process, which includes the use of Debit Note, 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 Summary invoice pattern 1 process support for complex invoicing, where there is a need for a debit note in addition to an invoice and a credit note. 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.

Functionality and roles

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. Summary invoicing process, pattern 1.

In the summary invoicing process, pattern 1, the supplier sends a debit note to the buyer with each delivery and the buyer uses the information in the debit note to verify the reception of the items. The debit 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 a single invoice that summarises the items that were send during that period. The invoice contains represents a claim for payment and contains the necessary tax information.

The invoicing process is shown in this work flow:

  • A supplier can send one or more debit note along with the deliveries of items. The debit note refers to the order and provides information about the items and their quantities. The customer can use the debit note to control the receiption of the items.

  • A the end of a period a supplier issues and sends an invoice to a customer. The invoice summarizes all the items delivered during the period and references the debit notes.

  • 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 Japan summary invoice BIS profile. This process assumes that both the invoice and the credit note are exchanged electronically.

The invoicing process

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

3.2. Documents used in process.

The Summarized Invoiced process requires the use of the following documents:

  • Standard Japanese Invoice

  • Debit Note

3.2.1. Standard Japanese Invoice

The invoice used in this process is the same datamodel as specified for the Standard Japanese Invoice process, but with additional rules.

Additional rules are the following:

  • A reference to a debit note is required for each invoice line.

3.2.2. Debit Note

The debit note used in this process is the same as specifed for the stand alone Debit note process.

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

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

4.2. Summarised invoice messages

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

JP standard Invoice and credit note

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

urn:peppol:bis:suminvpt1

Debit Note

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

urn:peppol:bis:suminvpt1

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>

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