Peppol Specifications for PINT Self Billing
OpenPeppol AISBL, Post-Award Coordinating Community v1.1.3
Link to main site of documentation
Introduction
Alignment point for local introduction.
The purpose of this document is to describe the use of self-billing self-billed invoice and self-billed credit note messages in Peppol, and to facilitate efficient implementation and increased use of electronic collaboration in the billing process based on these formats.
Document Structure
This document is structured as follows:
-
Chapter 1 provides general information on the business processes, requirements, and functionalities.
-
Chapter 2 provides information on business-related requirements supported by the self-billed invoice.
-
Chapter 3 provides information on legal and tax-related requirements supported by the self-billed invoice.
-
Chapter 4 provides information about rules and calculations that apply to the self-billed invoice content.
-
Chapter 5.1 describes the BIS identifiers.
-
Chapter 5.2 describes the semantic data types.
-
Chapter 5.3 provides external links to the relevant UBL schemas.
Scope
This document clarifies requirements for ensuring interoperability and provides guidelines for the support and implementation of these requirements. It provides detailed implementation guidelines for the self-billing self-billed invoice and self-billed credit note transactions.
Audience
The audience for this document comprises organisations wishing to become Peppol-enabled for exchanging electronic self-billed invoices and self-billed credit notes, and/or their ICT suppliers. These organisations may include:
-
Service providers
-
Contracting Authorities (CA)
-
Economic Operators (EO)
-
Software developers
More specifically, the following roles are addressed:
-
ICT architects
-
ICT developers
-
Business experts
For further information on Peppol/OpenPEPPOL, see http://peppol.org
Benefits
The self-billed invoice and self-billed credit note provide straightforward support for invoicing scenarios where a self-billed credit note is required in addition to a self-billed invoice. Other potential benefits include, but are not limited to:
-
Can be mandated as a basis for national or regional eInvoicing initiatives.
-
Procurement agencies can use these as a basis for moving all self-billed invoices and self-billed credit notes into electronic form. The flexibility of the specifications allows buyers to gradually automate self-billed invoice processing based on different sets of identifiers or references, following a cost–benefit approach.
-
SMEs can offer their trading partners the option of exchanging standardised documents in a uniform manner, thereby moving all self-billed invoices and self-billed credit notes into electronic form.
-
Large companies can implement these transactions as standardised documents for general operations and implement custom-designed bilateral connections for large trading partners.
-
Supports customers with a need for more complex interactions.
-
Can be used as a basis for restructuring in-house self-billed invoice processes.
-
Significant savings can be realised by procuring agencies through the automation and streamlining of in-house processing. Accounting can be significantly automated, approval processes simplified and streamlined, payment scheduling improved, and auditing automated.
1. Business Processes
1.1. Parties and Roles
The diagram below illustrates the roles involved in the self-billed invoice and self-billed credit note transactions. The supplier and the self-billed invoice receiver are the same entity, as are the customer and the self-billed invoice sender.
1.1.1. Parties
- Customer
-
The customer is the legal person or organisation that demands a product or service. Examples of customer roles include buyer, consignee, debtor, and contracting authority.
- Supplier
-
The supplier is the legal person or organisation that provides a product or service.
1.1.2. Roles
- Creditor
-
The party to whom a debt is owed. This is the party that claims payment and is responsible for resolving billing issues and arranging settlement. It is the party that receives the self-billed invoice or self-billed credit note. Also known as the self-billed invoice receiver, accounts receivable, or seller.
- Debtor
-
The party that owes a debt. This is the party responsible for making settlement relating to a purchase and that sends the self-billed invoice or self-billed credit note. Also known as the self-billed invoice sender, accounts payable, or buyer.
1.2. PINT Self-billing Process
The self-billed invoicing process includes issuing and sending the self-billed invoice and the self-billed credit note from the customer to the supplier, as well as the reception and handling of these documents at the supplier’s site.
The self-billing process is illustrated in the following workflow:
-
A customer issues and sends a self-billed invoice in the supplier’s name and sends it to the supplier. The self-billed invoice refers to the supplier’s goods or services that have been consumed by the customer, based on the customer’s own records.
A self-billed invoice may also refer to a contract or a framework agreement. The self-billed invoice may specify articles (goods and services) using an article number or an article description.
-
The customer raises the self-billed invoice in the supplier’s name and processes it as a purchase self-billed invoice, as if it had been received from the supplier.
-
The customer records the self-billed invoice as a purchase.
-
The customer records the self-billed invoice as accounts payable.
-
-
The supplier receives the self-billed invoice and processes it as revenue in the sales control system, leading to one of the following outcomes:
-
The supplier fully approves the self-billed invoice, posts it in the accounting system as revenue and accounts receivable.
-
The supplier completely rejects the self-billed invoice, contacts the buyer, and requests a self-billed credit note.
-
The supplier disputes parts of the self-billed invoice, contacts the buyer, and requests a self-billed credit note and/or a new self-billed invoice.
-
The diagram below shows the basic self-billing process using this Peppol BIS profile. This process assumes that both the self-billed invoice and the self-billed credit note are exchanged electronically.
This profile covers the following self-billed invoice processes:
| P1 |
Invoicing 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 |
Self-billed invoices with references to a despatch advice |
| P8 |
Self-billed invoices with references to a despatch advice and a receipt advice |
| P9 |
Self-billed credit notes or self-billed invoices with negative amounts, issued for a variety of reasons, including the return of empty packaging |
1.3. Self-billed Invoice Functionality
A self-billed invoice may support functions related to several (internal) business processes. This Peppol BIS supports the following functions:
-
Accounting
-
Self-billed invoice verification against the contract, the purchase order, and the goods and services delivered
-
Tax reporting
-
Auditing
-
Payment
In the following chapters, an assessment is made of which information is required 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 (not limited to these) is out of scope:
-
Inventory management
-
Delivery processes
-
Customs clearance
-
Marketing
-
Reporting
1.3.1. Accounting
Recording a business transaction in the financial accounts of an organisation is one of the main objectives of the self-billed invoice. According to financial accounting best practices and tax rules, every taxable person shall keep accounts in sufficient detail to enable tax to be applied and its application to be checked by the tax authorities. For this reason, a self-billed invoice shall provide information at both document and line level that enables booking on both the debit and the credit side.
1.3.2. Self-billed Invoice Verification
This process forms part of the seller’s internal business controls. The self-billed invoice shall refer to an authentic commercial transaction. Support for self-billed invoice verification is a key function of a self-billed invoice. The self-billed invoice should provide sufficient information to enable lookup of relevant existing documentation, whether electronic or paper-based, for example, as applicable:
-
the relevant purchase order
-
the contract
-
the call for tenders that formed the basis for the contract
-
the buyer’s reference
-
the confirmed receipt of the goods or services
-
delivery information
A self-billed invoice should also contain sufficient information to allow the received self-billed invoice to be routed to a responsible authority, person, or department for verification and approval.
1.3.3. Auditing
Companies may audit themselves as a means of internal control or 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 accounting has been carried out correctly. The auditing process places certain information requirements on a self-billed invoice. These requirements are mainly related to enabling verification of the authenticity and integrity of the accounting transaction.
Self-billed invoices conformant with 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 self-billed invoice to its payment
-
information for connecting the self-billed invoice to relevant documents, such as a contract and a purchase order
1.3.4. Tax Reporting
The self-billed invoice is used to convey tax-related information from the seller to the buyer, enabling both parties to correctly handle tax booking and reporting. A self-billed invoice should contain sufficient information to allow the supplier and any auditor to determine whether the self-billed invoice is correct from a tax perspective.
The self-billed invoice shall enable determination of the tax regime, the calculation, and the description of the tax, in accordance with the relevant legislation.
1.3.5. Payment
A self-billed invoice represents a claim for payment. Issuance of a self-billed invoice may occur either before or after payment is carried out. When a self-billed invoice is issued before payment, it represents a request to the buyer to pay. In such cases, the self-billed invoice commonly contains information that enables the buyer, in the role of debtor, to correctly initiate the payment transfer, unless that information has already been agreed in prior contracts or provided through separate payment instructions.
If a self-billed invoice is issued after payment, such as in cases where the order process included payment instructions or where payment was made by credit card for online or telephone purchases, the self-billed invoice may contain information about the payment made to facilitate reconciliation between the self-billed invoice and the payment on the supplier’s side. A self-billed invoice may also be partially paid before issuance, for example, when a pre-payment is made to confirm an order.
Self-billed invoices conformant with this specification should identify the means of payment for settlement of the self-billed invoice and clearly state the payment amount requested. They should provide the necessary details to support bank transfers. Payments by means of credit transfer, direct debit, and payment card are in scope.
1.4. Self-billded Invoices with negative amounts and Self-billed Credit Notes
Reversing a self-billed invoice that has been issued and received can be done in two basic ways: by issuing a self-billed credit note or by issuing a negative self-billed invoice.
-
When crediting by means of a self-billed credit note, the document type code is '261', and the self-billed credit note quantities and extension or total amounts have the same sign (positive or negative) as the self-billed invoice being cancelled or credited. The document type code acts as an indicator that the amounts are booked in reverse and cancel out the self-billed invoice amounts.
-
When crediting by means of a negative self-billed invoice, the document type code is '389', and the quantities and extension or total amounts have the opposite sign (negative versus positive) to those of the self-billed invoice being cancelled or credited. It is the mathematical sign that indicates that, when booked, the amounts cancel out the original amounts. The Price Amount shall always be positive.
A self-billed credit note may include negative amounts when cancelling a self-billed invoice that itself contains negative line items or amounts.
2. Business information
In the subchapters below you find description of selected parts of the transaction.
2.1. Parties
The following roles may be specified. The same actor may assume more than one role, depending on the handling scenario.
Further details on the roles and actors can be found in Roles.
2.1.1. Seller (AccountingSupplierParty)
Seller information is mandatory and is provided in the element cac:AccountingSupplierParty.
<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> (3)
</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> (4)
</cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>GB76576657</cbc:CompanyID>
(5)
<cac:TaxScheme>
<cbc:ID>TAX</cbc:ID> (6)
</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> (7)
<cbc:CompanyID>GB983294</cbc:CompanyID> (8)
<cbc:CompanyLegalForm>Private Limited Company</cbc:CompanyLegalForm>
</cac:PartyLegalEntity>
<cac:Contact> (9)
<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 | Seller electronic address (ibt-034), mandatory. The identification scheme identifier shall be selected from the Electronic Address Scheme (EAS) list. |
| 2 | Seller identifier (ibt-029). If used, the identification scheme identifier shall be selected from the entries published by the ISO/IEC 6523 maintenance agency. |
| 3 | Seller’s trading name (ibt-028). |
| 4 | Seller’s country code (ibt-040). |
| 5 | Seller tax registration ID (ibt-031). |
| 6 | Tax scheme for the seller’s tax registration. Use the appropriate code for the seller’s jurisdiction, such as VAT or GST. |
| 7 | Seller legal registered name (ibt-027). |
| 8 | Seller legal registration identifier (ibt-030). If used, the identification scheme identifier shall be selected from the entries published by the ISO/IEC 6523 maintenance agency. |
| 9 | Seller contact (ibg-06). |
2.1.2. Buyer (AccountingCustomerParty)
Buyer information is mandatory and is provided in the element cac:AccountingCustomerParty.
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0007">5561234567</cbc:EndpointID>
(1)
<cac:PartyIdentification>
<cbc:ID schemeID="0007">5561234567</cbc:ID>
(2)
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>BuyerTradingName AS</cbc:Name> (3)
</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> (4)
</cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>SE459837593701</cbc:CompanyID>
(5)
<cac:TaxScheme>
<cbc:ID>TAX</cbc:ID> (6)
</cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Buyer Official Name</cbc:RegistrationName> (7)
<cbc:CompanyID>5561234567</cbc:CompanyID> (8)
</cac:PartyLegalEntity>
<cac:Contact> (9)
<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 | Buyer electronic address (ibt-049), mandatory. The identification scheme identifier shall be selected from the Electronic Address Scheme (EAS) list. |
| 2 | Buyer identifier (ibt-046). If used, the identification scheme identifier shall be selected from the entries published by the ISO/IEC 6523 maintenance agency. |
| 3 | Buyer trading name (ibt-045). |
| 4 | Buyer country code (ibt-055), mandatory. |
| 5 | Buyer tax registration ID (ibt-048). |
| 6 | Tax scheme for the buyer tax registration. Use the appropriate code for the buyer’s jurisdiction, such as VAT or GST. |
| 7 | Buyer legal registered name (ibt-044). |
| 8 | Buyer legal registration identifier (ibt-047). If used, the identification scheme identifier shall be selected from the entries published by the ISO/IEC 6523 maintenance agency. |
| 9 | Buyer contact (ibg-09). |
2.1.3. Payment Receiver (PayeeParty)
Payment receiver information is optional. If this information is not provided, the seller is assumed to be the payment receiver. When payee information is provided, it indicates that a factoring arrangement is being documented.
To reflect the assignment of a self-billed invoice to a factor, the following is required:
-
A disclaimer (notification notice) on the self-billed invoice stating that the self-billed invoice has been assigned to a factor. The disclaimer should be provided using the self-billed invoice note (IBT-22) at document level.
-
Identification of the factor as the payee.
-
Updating the bank account to be in favour of the factor.
<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 | The schemeID attribute is recommended for all party identifiers. |
| 2 | The schemeID attribute is recommended for party legal entity identifiers. |
2.1.4. Seller’s Tax Representative (TaxRepresentativeParty)
The seller’s tax representative is relevant when the seller delivers goods or services in a country where the seller does not have a permanent establishment. In such cases, information about the tax representative shall be included in the self-billed invoice.
<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>TAX</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>| 1 | Tax identifier of the seller’s tax representative (ibt-063) |
2.2. Delivery Details (Date and Location)
Delivery details may be provided at the document level.
The place and date of delivery are recommended and should be provided unless their absence does not affect the ability to ensure the correctness of the self-billed invoice.
The delivery element contains information on the name, address, and delivery location identifier (cac:Delivery/cac:DeliveryLocation/cbc:ID), which may be used when the place of delivery is defined through an identifier, for example, a GLN (Global Location Number) issued by GS1.
<cac:Delivery>
<cbc:ActualDeliveryDate>2017-11-01</cbc:ActualDeliveryDate>
<cac:DeliveryLocation>
<cbc:ID schemeID="0088">7300010000001</cbc:ID>
<cac:Address> (1)
<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> (2)
</cac:Country>
</cac:Address>
</cac:DeliveryLocation>
<cac:DeliveryParty> (3)
<cac:PartyName>
<cbc:Name>Delivery party Name</cbc:Name>
</cac:PartyName>
</cac:DeliveryParty>
</cac:Delivery>| 1 | Deliver-to address (ibg-15), the address to which the invoiced goods and services were or are delivered. |
| 2 | Deliver-to country code (ibt-080), mandatory. |
| 3 | Deliver-to party name (ibt-070), the name of the party to which the goods and services are delivered. |
2.3. References and Attachments
Support for self-billed invoice verification is a key function of a self-billed invoice. The self-billed invoice should provide sufficient information to enable lookup of relevant existing documentation, whether electronic or paper-based.
| Any reference element shall contain valid information. If no reference is available, the element shall not be present in the instance document. |
The self-billed invoice and self-billed credit note transactions support the following references to existing documentation:
2.3.1. Purchase Order and Sales Order Reference
The purchase order reference is a conditional business term. If the customer has issued a purchase order, it should be referenced by providing its identifier in the resulting self-billed invoice; otherwise, the buyer reference should be used (see Buyer Reference).
If the purchase order is referenced at the self-billed invoice header level, the order reference element at line level can be used to state the relevant line numbers in the order.
A sales order is issued by the seller to confirm the sale of specified products and may be provided in the self-billed invoice.
| In a self-billed invoice, both a purchase order and a sales order reference may be provided. However, a self-billed invoice instance shall not reference a sales order without also providing the corresponding purchase 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 |
2.3.2. Buyer Reference
The buyer reference, known as "Your ref", is conditional. A self-billed invoice shall contain either a buyer reference or an order reference (see Purchase Order and Sales Order Reference).
This element is used to identify who ordered the products or services. Examples include the name of the person placing the order, an employee number, or a code identifying the relevant person, department, or group. "Your ref" is often used for internal routing at the recipient, and it is therefore important to populate this element with correct values according to the recipient’s needs.
If neither a buyer reference nor a reference to an order is supplied by the customer, the name of the person ordering or appointed by the customer may be supplied in the buyer reference, if known to the supplier.
| When a reference is provided by the customer, the corresponding element shall contain that reference. |
<cbc:BuyerReference>0150abc</cbc:BuyerReference>2.3.3. Invoiced Object Identifier
The invoiced object identifier identifies the object on which the self-billed invoice is based and is provided by the seller. Examples include a subscription number, telephone number, meter point, vehicle, or person, as applicable.
If it is not clear to the receiver which scheme is used for the identifier, an optional scheme identifier attribute should be used and shall be selected from the invoiced object identifier scheme code list.
The invoiced object reference is provided using the element cac:AdditionalDocumentReference with the document type code set to 130.
<cac:AdditionalDocumentReference>
<cbc:ID schemeID="ABT">DR35141</cbc:ID> (1) (2)
<cbc:DocumentTypeCode>130</cbc:DocumentTypeCode> (3)
</cac:AdditionalDocumentReference>| 1 | The self-billed invoice object identifier scheme is given as an attribute on the identifier. It states the type of the identifier according to the UN/CEFACT 1153 code list. |
| 2 | An identifier of the object to which the self-billed invoice relates. |
| 3 | A code that qualifies the identifier as an invoiced object identifier. Document type code "130" provides this qualification. |
2.3.4. Contract Reference
To reference or match a self-billed invoice to a purchase contract, the contract number may be specified as follows:
<cac:ContractDocumentReference>
<cbc:ID>framework no 1</cbc:ID>
</cac:ContractDocumentReference>2.3.5. Despatch and Receipt Advice References
Document Level
To reference or match a self-billed invoice to a despatch or receipt advice, use the following elements:
<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 |
Line Level
When a self-billed invoice charges items that have been delivered in separate despatches, the references shall be provided at line level as follows. If the invoiced quantity of an item has been delivered by more than one despatch, the self-billed invoice shall contain separate lines for each despatch. When despatches are referenced at line level, no reference shall be provided at document level.
<cac:InvoiceLine>
<cac:DespatchLineReference>
<cac:DocumentReference>
<cbc:ID>despadv-3</cbc:ID> (1)
</cac:DocumentReference>
</cac:DespatchLineReference>
</cac:InvoiceLine>| 1 | Despatch advice |
Alignment point for dispatch references
2.3.6. Tender Reference
To identify the call for tender or lot to which the self-billed invoice relates, use the OriginatorDocumentReference. In most cases, the identifier is the Procurement Procedure Identifier.
<cac:OriginatorDocumentReference>
<cbc:ID>ppid-123</cbc:ID>
</cac:OriginatorDocumentReference>2.3.7. Project Reference
The project reference is optional and is sent in a self-billed invoice using the element cac:ProjectReference/cbc:ID. In a self-billed credit note, this element does not exist; instead, the project reference is sent using the element cac:AdditionalDocumentReference[cbc:DocumentTypeCode='50']/cbc:ID.
- NOTE
-
When sending the project reference, only
cbc:IDandcbc:DocumentTypeCodeare allowed within thecac:AdditionalDocumentReferenceelement.
<cac:ProjectReference>
<cbc:ID>project333</cbc:ID>
</cac:ProjectReference>2.3.8. Preceding Self-billed Invoice References
A self-billed credit note or a negative self-billed invoice may refer to one or more preceding self-billed invoices. This is done using business group BG-3 Preceding self-billed invoice reference, providing the self-billed invoice number and issue date. The issue date shall be provided if the preceding self-billed invoice reference is not unique.
If a correction applies to a large number of invoices, the invoicing period (BG-14), optionally combined with a clarifying self-billed invoice note (IBT-22), may be provided at document level instead.
2.3.9. Attachments
A self-billed invoice may include a supporting document for informational purposes. Examples of such documents include work reports, certificates, or other documents related to the purchase or the invoiced items. A supporting document may be attached to the self-billed invoice in two ways: by providing a direct hyperlink from which the document can be downloaded, or by embedding the document within the self-billed invoice. A compliant receiver is required to be able to receive an attached supporting document and, in the case of embedded files, to convert it into a file. However, the receiver is not required to process or interpret the content of that file, as it is provided for informational purposes only.
When attaching a document using a URI, the hyperlink shall point directly to the file to be downloaded.
An embedded document is included in the self-billed invoice as a binary object using Base64 encoding and shall be supplemented with information about the document file name and a MIME code indicating the file type. This enables the receiver to convert the binary content into a file with the same name as the original and to associate it with an appropriate application for viewing. The set of allowed file type codes (MIME codes) is limited to types that can be opened using commonly available applications.
As 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. However, the sender shall 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.
<cac:AdditionalDocumentReference>
<cbc:ID>ts12345</cbc:ID> (1)
<cbc:DocumentDescription>Technical specification</cbc:DocumentDescription> (2)
<cac:Attachment>
<cac:ExternalReference>
<cbc:URI>www.techspec.no</cbc:URI> (3)
</cac:ExternalReference>
</cac:Attachment>
</cac:AdditionalDocumentReference><cac:AdditionalDocumentReference>
<cbc:ID>mr4343</cbc:ID> (1)
<cbc:DocumentDescription>milage report</cbc:DocumentDescription> (2)
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject mimeCode="text/csv" filename="milage.csv"
>
bWlsYWdlIHJlcG9ydA==</cbc:EmbeddedDocumentBinaryObject> (4)
</cac:Attachment>
</cac:AdditionalDocumentReference>-
An identifier of the supporting document (ibt-122)
-
A description of the supporting document (ibt-123)
-
The URL (Uniform Resource Locator) identifying where the external document is located (ibt-124)
-
An attached document embedded as a binary object or sent together with the self-billed invoice (ibt-125). The file type is specified using the
mimeCodeattribute (ibt-125-1), and the original file name is specified using thefilenameattribute (ibt-125-2).
Alignment point for local reference information
2.4. Allowances and Charges
The self-billed invoice and self-billed credit note transactions include elements for allowances and charges at three levels.
The element cac:AllowanceCharge, with the sub-element cbc:ChargeIndicator, indicates whether the instance is a charge (true) or an allowance (false).
- The header level
-
Applies to the entire self-billed invoice and is included in the calculation of the total self-billed invoice amount.
-
Several allowances and charges may be supplied.
-
The specification of TAX for allowances and charges, using
cac:TaxCategorywith its sub-elements, shall be supplied. -
The sum of all allowances and charges at the header level shall be specified in
cbc:AllowanceTotalAmountandcbc:ChargeTotalAmount, respectively.
-
- 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.
-
The specification of TAX for allowances and charges shall not be provided, as the TAX category stated for the self-billed invoice line itself also applies to the allowances or charges on that line.
-
The sum of all allowances and charges at 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 included in the header-level elements.
-
- The line-level Price element
-
Provides information to the buyer on how the price is determined. It is also relevant if the seller or buyer wants to post the allowance in their accounting systems. The price itself shall always be the net price, i.e. the base amount reduced by a discount (allowance).
-
Only one occurrence of an allowance (discount) is allowed.
-
The specification of TAX for the allowance shall not be provided.
-
Allowances related to Price shall not be included in any other calculations.
-
Allowances related to Price may specify both the amount and the base amount.
-
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator> (1)
<cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Freight service</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>20</cbc:MultiplierFactorNumeric> (4)
<cbc:Amount currencyID="EUR">200</cbc:Amount> (5)
<cbc:BaseAmount currencyID="EUR">1000</cbc:BaseAmount> (3)
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>25</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>TAX</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="EUR">300</cbc:Amount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>25</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>TAX</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)\$ |
<!-- Code omitted for clarity -->
<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="EUR">1</cbc:Amount>
<cbc:BaseAmount currencyID="EUR">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="EUR">101</cbc:Amount>
</cac:AllowanceCharge>2.5. Payment Means Information
2.5.1. Credit Transfer
| Payment means code 30, as defined below, shall be supported by all receivers of a PINT-compliant self-billed invoice. This payment method acts as the common denominator for global trade. |
If payment is made by credit transfer, the payment account identifier (IBT-84) is mandatory.
Examples of codes for payment by credit transfer are:
-
30 - 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 the case of a SEPA payment) or a national account number (BBAN) |
| 4 | BIC or a national clearing code |
2.5.2. Card Payment
If the buyer has opted to pay using a payment card, such as a credit or debit card, information on the Primary Account Number (PAN) shall be present in the self-billed invoice.
Examples of codes for payment by card are:
-
48 - Bank card
-
54 - Credit card
-
55 - Debit 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 include VISA, MasterCard, and American Express. |
| 4 | Cardholder name |
Alignment point for local payment means
2.6. Item Information
2.6.1. Item Identifiers
In a self-billed invoice line, the seller item identifier, the buyer item identifier, and the standard item identifier may be provided. For the seller’s and buyer’s item identifiers, no scheme attribute is used, whereas the schemeID is mandatory for the standard item identifier and must be selected from the ISO 6523 ICD list.
<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>| 1 | 0160 is the ICD value for a GTIN identifier |
2.6.2. Item Classification
Several different item classification codes may be provided per self-billed invoice line. The codes shall be taken from one of the classification schemes listed in the UNCL7143 code list.
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="STI">09348023</cbc:ItemClassificationCode>(1)
</cac:CommodityClassification>| 1 | listID must be from the UNCL7143 code list, and the code STI indicates that this is a CPV classification. |
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="TST" listVersionID="19.05.01">86776</cbc:ItemClassificationCode>(1)
</cac:CommodityClassification>| 1 | listID must be from the UNCL7143 code list, and the code TST indicates that this is a UNSPSC classification. The listVersionID is optional but may be used to specify the version of UNSPSC. NOTE: In previous versions, the code MP was used as a temporary workaround to identify UNSPSC. In the Fall 2019 release, this was replaced with the new 7143 code TST, which is specific to UNSPSC. |
2.7. Price Information
A self-billed invoice shall contain information about the item net price. Additional information, such as the gross price, item price base quantity, and price discount, may also be provided.
For details on price calculation, see Item Net Price (IBT-146).
<cac:Price>
<cbc:PriceAmount currencyID="EUR">410</cbc:PriceAmount> (4)
<cbc:BaseQuantity unitCode="H87">1</cbc:BaseQuantity> (3)
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:Amount currencyID="EUR">40</cbc:Amount> (2)
<cbc:BaseAmount currencyID="EUR">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; shall be equal to the item gross price minus the item price discount (if these elements are used) |
<cac:Price>
<cbc:PriceAmount currencyID="EUR">200</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="H87">2</cbc:BaseQuantity>
</cac:Price>2.8. Unit of Measure
The unit of measure in a self-billed 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".
| Code | Name |
|---|---|
H87 |
Piece |
KGM |
Kilogram |
MTR |
Metre |
LTR |
Litre |
MTK |
Square metre |
MTQ |
Cubic metre |
KTM |
Kilometre |
TNE |
Tonne (metric ton) |
KWH |
Kilowatt hour |
DAY |
Day |
HUR |
Hour |
MIN |
Minute |
| Code | Name |
|---|---|
XBG |
Bag |
XBX |
Box |
XCT |
Carton |
XCY |
Cylinder |
XBA |
Barrel |
XPK |
Package |
XPX |
Pallet |
XRL |
Reel |
XSA |
Sack |
XST |
Sheet |
<cbc:InvoicedQuantity unitCode="H87">1</cbc:InvoicedQuantity> (1)
<cbc:InvoicedQuantity unitCode="XPX">1</cbc:InvoicedQuantity> (2)| 1 | Code H87 from Recommendation No. 20 |
| 2 | Code PX, prefixed with an "X", from Recommendation No. 21 |
3. Tax information
The following sections provide information on tax related issue.
Alignment point for tax information
4. Rules
The information provided in a PINT self-billed invoice shall comply with a set of rules governing both the content of the business terms and the relationships between them.
4.1. Calculations
4.1.1. Calculation of Totals
The formulas for calculating totals are as follows:
| Business Term ID | Term Name | Calculation |
|---|---|---|
IBT-106 |
Sum of self-billed invoice line net amounts |
\$sum("IBT-131: self-billed invoice line net amount")\$ |
IBT-107 |
Sum of allowances at document level |
\$sum("IBT-92: Document level allowance amount")\$ |
IBT-108 |
Sum of charges at document level |
\$sum("IBT-99: Document level charge amount")\$ |
IBT-109 |
Self-billed invoice total amount without TAX |
\$\ \ \ \ "IBT-106: Sum of self-billed invoice line net amounts"\$ |
IBT-110 |
Self-billed invoice total TAX amount |
\$sum("IBT-117: TAX category tax amount")\$ |
IBT-112 |
Self-billed invoice total amount with TAX |
\$\ \ \ \ "IBT-109: Self-billed invoice total amount without TAX"\$ |
IBT-115 |
Amount due for payment |
\$\ \ \ \ "IBT-112: Self-billed invoice total amount with TAX"\$ |
4.1.2. UBL Syntax Calculation Formulas
The following elements represent the legal monetary totals for a self-billed invoice or self-billed 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"\$ |
<cbc:TaxInclusiveAmount> |
\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount"\$ |
<cbc:PrepaidAmount> |
Not applicable |
<cbc:PayableRoundingAmount> |
Not applicable |
<cbc:PayableAmount> |
\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount"\$ |
Element for Rounding Amount: PayableRoundingAmount
It is possible to round the expected payable amount.
The element cac:LegalMonetaryTotal/cbc:PayableRoundingAmount is used for this purpose and is specified at the header level. This value shall be added to the value in cac:LegalMonetaryTotal/cbc:PayableAmount.
4.1.3. Calculation at Line Level
Item Net Price (IBT-146)
If a gross price and a discount exist, the item net price shall be equal to the item gross price minus the item price discount.
Calculation formula:
\$"Item net price" = "Item gross price (IBT-148)" - "Item price discount (IBT-147)"\$
<cac:Price>
<cbc:PriceAmount currencyID="EUR">410</cbc:PriceAmount>(3)
<cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:Amount currencyID="EUR">40</cbc:Amount>(2)
<cbc:BaseAmount currencyID="EUR">450</cbc:BaseAmount>(1)
</cac:AllowanceCharge>
</cac:Price>| 1 | Item gross price |
| 2 | Item price discount |
| 3 | \$"Item net price amount" = "Item gross price" - "Item price discount"\$ |
Self-billed Invoice Line Net Amount (IBT-131)
The self-billed invoice line net amount (IBT-131) is, as the name implies, the net amount without TAX and includes line-level allowances and charges.
The formula for calculating the self-billed 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)")\$
\$+ "Self-billed invoice line charge amount (IBT-141)" - "Self-billed invoice line allowance amount (IBT-136)"\$
|
If the line net amount must be rounded to a maximum number of decimals, each part of the calculation shall be rounded separately. That is, the result of: \$"Item line net amount" = (("Item net price (IBT-146)" div "Item price base quantity (IBT-149)") times ("Invoiced quantity (IBT-129)")\$ shall be rounded to the maximum number of decimals, and the allowance and charge amounts shall also be rounded separately. |
<cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity>(3)
<cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>(4)
<!-- Code omitted for clarity-->
<cac:Price>
<cbc:PriceAmount currencyID="EUR">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 | \$"Self-billed invoice line net amount" = (("Item net price" div "Item price base quantity") times ("Invoiced quantity")\$ |
<cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity>(4)
<cbc:LineExtensionAmount currencyID="EUR">900.00</cbc:LineExtensionAmount>(5)
<!-- Code omitted for clarity-->
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Charge</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>1</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="EUR">1</cbc:Amount>(2)
<cbc:BaseAmount currencyID="EUR">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="EUR">101</cbc:Amount>(3)
</cac:AllowanceCharge>
<!-- Code omitted for clarity-->
<cac:Price>
<cbc:PriceAmount currencyID="EUR">100</cbc:PriceAmount>(1)
</cac:Price>| 1 | Item net price |
| 2 | Line charge amount |
| 3 | Line allowance amount |
| 4 | Invoiced quantity |
| 5 | \$"Self-billed invoice line net amount" = ("Item net price" times "Invoiced quantity") + "Line charge amount" - "Line allowance amount"\$ |
4.1.4. Calculation of Allowance and Charge Amounts
Allowances and charges at document and line level consist of elements that provide information on the base amount and the percentage. When present in a self-billed invoice instance, these elements are used to calculate the allowance or charge amount.
If a base amount is present, the percentage shall also be present. Likewise, if a percentage is present, the base amount shall also be present. The calculation of the amount shall be as follows:
\$"Amount" = "Base amount" times ("Percentage" div 100)\$
<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="EUR">200</cbc:Amount> (3)
<cbc:BaseAmount currencyID="EUR">1000</cbc:BaseAmount>(1)
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>25</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>TAX</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>| 1 | Base amount, used with the percentage to calculate the amount |
| 2 | Charge percentage |
| 3 | \$"Base amount" times ("Percentage" div 100) = "Amount"\$ |
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="EUR">200</cbc:Amount>(1)
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>25</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>TAX</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>| 1 | Allowance amount without calculation based on base amount and percentage |
4.2. Rounding
4.2.1. Shared Rounding Rules
A maximum of two decimal digits is allowed for the following amounts in a self-billed invoice:
-
Document-level allowance amount (ibt-092)
-
Document-level charge amount (ibt-099)
-
Sum of allowances at document level (ibt-107)
-
Sum of charges at document level (ibt-108)
-
Self-billed invoice total amount without TAX (ibt-109)
-
Self-billed invoice total TAX amount (ibt-110)
-
Self-billed invoice total amount with TAX (ibt-112)
-
Amount due for payment (ibt-115)
Alignment point for rounding
5. Technical details
Following section provide technical details.
5.1. BIS Identifiers
Peppol has a defined policy that specifies how identifiers are to be used both in 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 applicable to this BIS are described below.
5.1.1. Profiles and Messages
All messages shall contain a Business process type (IBT-23) and a Specification identifier (IBT-24). The Business process type (IBT-23) identifies the business process to which a given message belongs, and the Specification identifier (IBT-24) identifies the type of message and the rules that apply.
Profiles are associated with a single business process and may contain multiple document types. Valid document instances shall contain the corresponding Business process type (IBT-23) and Specification identifier (IBT-24).
| The Specification identifier (IBT-24) is a string without spaces. The list below includes spaces in the Specification identifier (IBT-24) values to improve readability. Ensure that all spaces are removed before use. |
The table below provides the values to be used for the Specification identifier (IBT-24) and the Business process type (IBT-23) for this profile.
| Type | Element cbc:CustomizationID |
Element cbc:ProfileID |
|---|---|---|
Self-billed Invoice and self-billed credit note |
urn:peppol:pint:selfbilling-1 |
urn:peppol:bis:selfbilling |
In the customization element the specialization is a short id that identifies the specialization. As example, jp-1 is for the Japan standard self-billed invoice, where -1 is a versioning number for the specialization.
<cbc:CustomizationID>urn:peppol:pint:selfbilling-1</cbc:CustomizationID>
<cbc:ProfileID>urn:peppol:bis:selfbilling</cbc:ProfileID>5.2. 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. Semantic data types define the allowed value domain for the content, as well as any additional information components (attributes) required to ensure precise interpretation.
5.2.1. Primitive Types
Semantic data type content may use the following primitive types. These primitive types are derived from ISO 15000, Annex A.
| Primitive Type | Definition |
|---|---|
Binary |
A finite-length sequence of binary digits. |
Date |
A time point representing a calendar day on a time scale consisting of an origin and a succession of calendar days, in accordance with ISO 8601. |
Decimal |
A subset of the real numbers that can be represented using decimal numerals. |
String |
A finite sequence of characters. |
5.2.2. Semantic Data Types
The different semantic data types are described in the tables below. For each semantic data type, various characteristics are defined, such as attributes, format, number of decimals, and the underlying primitive type. These semantic data types are based on {ISO15000}.
When used in an instance of a self-billed invoice, each data element shall contain data. In the tables below, this is identified as the “content”. Whenever a business term is used, it shall always have content; therefore, the content is always mandatory.
Amount
An amount represents a numerical monetary value. The currency of the amount is defined as a separate business term.
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Decimal |
10000.25 |
Unit Price Amount
A unit price amount represents a numerical monetary value for data elements that contain item prices, which may be multiplied by item quantities. The currency of the amount is defined as a separate business term.
| The unit price amount does not impose restrictions on the number of decimal places, in contrast to the Amount type. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Decimal |
10000.1234 |
Percentage
Percentages are expressed as fractions of a hundred (per cent). For example, the value 34.78% is represented as 34.78.
| There is no restriction on the number of decimal places for percentages. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Decimal |
34.7812 |
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.
| There is no restriction on the number of decimal places for quantities. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Decimal |
10000.1234 |
Code
Codes are used to specify allowed values in elements, as well as lists of options. A code differs from an identifier in that allowed values have standardised meanings that are known by the recipient.
| Codes shall be entered exactly as specified in the selected code list of the applicable syntax. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
String |
Abc123 |
Indicator
Indicators are used to provide boolean values that state whether something is true or false.
| Indicators shall be expressed in lower case. |
| The default value is "false" and applies if the relevant business term is not used. |
| Component | Use | Primitive Type | Allowed values |
|---|---|---|---|
Content |
Mandatory |
String |
false |
true |
Identifier
Identifiers (IDs) are keys issued by the sender or recipient of a document, or by a third party.
| The use of attributes is specified for each information element. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
String |
abc:123-DEF |
Scheme Identifier |
Optional |
String |
GLN |
Scheme Version Identifier |
Optional |
String |
1.0 |
Date
Dates shall be in accordance with the “Calendar date complete representation” as specified by {ISO8601}, using the format YYYY-MM-DD.
| Dates shall not include time zone information. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Date |
2017-12-01 |
Time
Time shall be expressed in accordance with the UBL-allowed format.
| Time may include time zone information. |
| Component | Use | Primitive Type | Allowed forms |
|---|---|---|---|
Content |
Mandatory |
Date |
13:20:00 (1:30 PM) |
13:20:30.55 (30.55 sec) |
|||
13:20:00Z (UTC) |
|||
13:20:00-05:00 (UTC-5) |
|||
00:00:00 (midnight) |
|||
24:00:00 (midnight) |
Time formats without time zone information (i.e. other than hh:mm:ssZ and hh:mm:ss-hh:mm) shall be interpreted as being in the time zone of the seller’s address and according to the daylight saving status on the issue date of the self-billed invoice. = Document Reference
Document reference types are identifiers assigned to a document or a document line by the buyer, the seller, or a third party.
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
String |
abc:123-DEF |
Text
Text represents the actual wording of any written or printed content. Line breaks may be present in the text, and any such line breaks shall be preserved and respected by the receiver’s system.
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
String |
5% allowance when paid within 30 days |
Binary Object
A binary object may be used to describe files that are transmitted together with the self-billed invoice. The attachment functionality is not intended for attaching a copy of the self-billed invoice in an image format (such as PDF). Attaching a copy of the self-billed invoice is not compliant with this specification.
Attachments shall be transmitted together with the self-billed invoice. The binary object has two supplementary components: a MIME code, which specifies the MIME type of the attachment, and a filename, which is provided by (or on behalf of) the sender of the self-billed invoice or self-billed credit note.
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Binary |
QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ== |
Mime Code |
Mandatory |
String |
image/jpeg |
Filename |
Mandatory |
String |
drawing5.jpg |
A receiver of a self-billed invoice or self-billed credit note shall accept and process attachments that comply with the Media Type Code List.
5.3. UBL schemas and namespaces
The XML schemas used are
-
UBL self-billed Invoice 2.1, with the target namespace
urn:oasis:names:specification:ubl:schema:xsd:self-billed Invoice-2 -
UBL CreditNote 2.1 with the target namespace
urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2
5.4. Glossary
Business Term - Label assigned to a given information element that is used as a primary reference.
Compliant - Some or all features of the self-billed invoice model are used, and all rules of the self-billed invoice model are respected. Note 1 to entry: Based on the TOGAF definition of a compliant specification.
Conditional - Whether the option is used, and in what way, depends on other data in the message.
Conformant - All rules of the self-billed invoice model are respected, and some additional features not defined in the self-billed invoice model are also used.
Electronic Self-billed Invoice - A self-billed invoice that has been issued, transmitted, and received in a structured electronic format that allows for automatic electronic processing.
Identification Scheme - A collection of identifiers applicable to a given type of object, governed under a common set of rules.
Identifier - A character string used to establish the identity of, and uniquely distinguish, one instance of an object within an identification scheme from all other objects within the same scheme. Note 1 to entry: An identifier may be a word, number, letter, symbol, or any combination thereof, depending on the identification scheme used.
Information Element - A semantic concept that can be defined independently of any particular syntactic representation.
Mandatory - The option must be used in all messages.
May - Indicates that an option is truly optional.
Optional - Whether the option is used or not is the choice of the users, independent of other data in the message.
Semantic Data Model - A structured set of logically interrelated information elements.
Shall - Indicates that the definition is an absolute requirement of the specification.
Shall Not - Indicates that the definition is an absolute prohibition of the specification.
Should - Indicates that there may be valid reasons, in particular circumstances, to ignore a specific item, but the full implications must be understood and carefully weighed before choosing a different course.
Should Not - Indicates that there may be valid reasons, in particular circumstances, where the specified behaviour is acceptable or even useful, but the full implications should be understood and carefully weighed before implementing any behaviour described with this label.
Structured Information Element - An information element that can be processed automatically.
Syntax - A machine-readable language or dialect used to represent the information elements contained in an electronic document (for example, an electronic self-billed invoice).