Link to main site of documentation

Introduction to openPeppol and BIS

This specification is an extension of the Peppol BIS Billing 3.0 specification, following the guidance given in TR 16931-5 “Guidelines on the use of sector or country extensions in conjunction with EN16931-1” Any instance documents compliant to this specification will be conformant to the Peppol BIS Billing 3.0 and to the European Standard EN 16931.

The main requirement for the extensions comes from the fact that Singapore uses Goods and Service Tax (GST) instead of Value Added Tax (VAT). This has consequences on code lists and the naming of some business terms. In addition to GST this specification also supports typical Singapore payment methods (PayNow and Giro).

On a syntactical level, this specification uses the OASIS UBL 2.1 XML format.

A PEPPOL BIS provides a set of specifications for implementing a PEPPOL business process. A BIS document is concerned with clarifying requirements for ensuring interoperability between business partners and provides guidelines for the support and implementation of these requirements.

The purpose of this document is to describe the use of the invoice and credit note messages as used by Singapore in the Peppol network, and to facilitate an efficient implementation and increased use of electronic collaboration.

Statement of copyright

This Peppol Business Interoperability Specification (Peppol BIS) document is an extension of Peppol BIS Billing 3 (and consequently CEN/EN 16931:2017).

The copyright of CEN/EN 16931:2107 is owned by CEN and its members - the European National Standards Bodies. A copy of CEN/EN 16931-1:2017 may be obtained free of charge from any CEN member.

OpenPeppol AISBL holds the copyright of this Peppol BIS, developed and published subject to the conditions of the agreement between the European Commission and CEN allowing derivate works to be developed and distributed with no additional licensing requirements. CEN and the National Standards Bodies bears no liability from the content and implementation 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 - 4 gives general information on the business processes, requirements and functionalities
Chapters 5 - 7 describes GST, calculations and rounding.
Chapter 8 provides examples of selected parts of the invoice
Chapter 9 gives details and links to all code lists used
Chapter 10 describes the semantical data types
Chapter 11 gives information on Peppol identifiers
Chapter 12 describes in detail on namespaces
Chapters 13 and 14 provides information on validation and validation rules

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 {common}

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 SG 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
GST 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 GST rules every Taxable person shall keep accounts in sufficient detail for GST 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. GST Reporting

The invoice is used to carry GST related information from the Seller to the Buyer to enable the Buyer and Seller to correctly handle GST 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 GST point of view.

The invoice shall allow the determination of the GST regime, the calculation and description of the tax, in accordance with Singapore GST regulations.

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 can identify the means of payment for settlement of the invoice and clearly state what payment amount is requested.

Specifically three types of payment means are used for invoices in Singapore:

Direct debit using GIRO (PaymentMeans Code Z01
Credit Transfer using PayNow Corporate using the UEN as identification of the payee account. (PaymentMeans Code Z02)
Credit Card (PaymentMeans Code 54)

PaymentMeans Codes Z01 and Z02 are not recoginized codes in UNCL4461. They have been added in the Singapore extension of Peppol BIS Billing 3.

4.6. Negative invoices and credit notes

In line with requirements of EN 16931 this BIS supports negative grand totals in order 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 VAT) is settled through a final invoice; and
Some user communities prefer to use negative invoice rather than credit note when correcting transactions.

This 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="SGD">25</cbc:Amount>(1)
            <cac:TaxCategory>
                <cbc:ID>SR</cbc:ID>
                <cbc:Percent>7.0</cbc:Percent>
                <cac:TaxScheme>
                    <cbc:ID>GST</cbc:ID>
                </cac:TaxScheme>
            </cac:TaxCategory>
        </cac:AllowanceCharge>
    <!-- Code omitted for clarity -->
    <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="SGD">2800</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="SGD">2825</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="SGD">3022.75</cbc:TaxInclusiveAmount>
        <cbc:ChargeTotalAmount currencyID="SGD">25</cbc:ChargeTotalAmount>
        <cbc:PayableAmount currencyID="SGD">3022.75</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

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

1	Charge amount
2	Invoice line 1 with positive 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="SGD">25</cbc:Amount>(2)
            <cac:TaxCategory>
                <cbc:ID>SR</cbc:ID>
                <cbc:Percent>7.0</cbc:Percent>
                <cac:TaxScheme>
                    <cbc:ID>GST</cbc:ID>
                </cac:TaxScheme>
            </cac:TaxCategory>
        </cac:AllowanceCharge>
    <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="SGD">2800</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="SGD">2825</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="SGD">3022.75</cbc:TaxInclusiveAmount>
        <cbc:ChargeTotalAmount currencyID="SGD">25</cbc:ChargeTotalAmount>
        <cbc:PayableAmount currencyID="SGD">3022.75</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

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


</CreditNote>

1	Code 381 indicating a credit note
2	Charge amount
3	Invoice line 1 with positive 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. If the original invoice had contained a line with negative quantity and line amount then in a negative invoice the signs would be reversed in the same way resulting in a line with positive quantity and positive line amount.

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="SGD">-25</cbc:Amount>(2)
        <cac:TaxCategory>
            <cbc:ID>SR</cbc:ID>
            <cbc:Percent>7.0</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>GST</cbc:ID>
            </cac:TaxScheme>
        </cac:TaxCategory>
    </cac:AllowanceCharge>
    <!-- Code omitted for clarity -->
    <cac:LegalMonetaryTotal> (3)
        <cbc:LineExtensionAmount currencyID="SGD">-2800</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="SGD">-2825</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="SGD">-3022.75</cbc:TaxInclusiveAmount>
        <cbc:ChargeTotalAmount currencyID="SGD">-25</cbc:ChargeTotalAmount>
        <cbc:PayableAmount currencyID="SGD">-3022.75</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>

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


</Invoice>

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

If the original invoice had contained a line with negative quantity and line amount then in a negative invoice the signs would be reversed in the same way to a line with positive quantity and positive line amount.

5. Goods and Services Tax (GST)

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

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

5.1. Line GST Information

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

5.2. Document level allowance or charge

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

5.3. GST Breakdown

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

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

Example 1. Example

Invoice line 1 has category code = SR and GST rate = 7
Invoice line 2 has category code = SR and GST rate = 7.00
This should result in only one GST Breakdown.

5.4. Invoice total GST amount

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

5.5. GST accounting currency

When the Invoice currency (BT-5-GST) is not Singapore dollar (SGD) the seller may be required to state GST related amounts in SGD. This can be provided in the following way.

The tax currency code (BT-6-GST) shall be given as SGD. The required amounts are given as shown in the following XML.

UBL example showing GST in SGD when invoice currency is EUR

   <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> (1)
<cbc:TaxCurrencyCode>SGD</cbc:TaxCurrencyCode> (2)
<cac:AdditionalDocumentReference>
        <cbc:ID>SGD</cbc:ID>
        <cbc:DocumentTypeCode>sgdtotal-excl-gst</cbc:DocumentTypeCode>
        <cbc:DocumentDescription>2065.72</cbc:DocumentDescription> (3)
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
        <cbc:ID>SGD</cbc:ID>
        <cbc:DocumentTypeCode>sgdtotal-incl-gst</cbc:DocumentTypeCode>
        <cbc:DocumentDescription>2210.21</cbc:DocumentDescription> (4)
</cac:AdditionalDocumentReference>
<!-- Code omitted for clarity -->
   <cac:TaxTotal>
       <cbc:TaxAmount currencyID="EUR">92.75</cbc:TaxAmount> (5)
       <cac:TaxSubtotal>
           <cbc:TaxableAmount currencyID="EUR">1325</cbc:TaxableAmount>
           <cbc:TaxAmount currencyID="EUR">92.75</cbc:TaxAmount>
           <cac:TaxCategory>
               <cbc:ID>SR</cbc:ID>
               <cbc:Percent>7.0</cbc:Percent>
               <cac:TaxScheme>
                   <cbc:ID>GST</cbc:ID>
               </cac:TaxScheme>
           </cac:TaxCategory>
       </cac:TaxSubtotal>
   </cac:TaxTotal>
<cac:TaxTotal>
       <cbc:TaxAmount currencyID="SGD">144.49</cbc:TaxAmount> (6)
   </cac:TaxTotal>

1	Invoice currency as EUR (BT-5-GST)
2	Tax currency as SGD (BT-6-GST)
3	Invoice total without GST in tax currency being GST (BT-SG-001)
4	Invoice total with GST in tax currency being GST (BT-SG-002)
5	GST total amount in invoice currency (BT-110-GST)
6	GST total amount in tax currency being GST (BT-111-GST)

6. Rounding

The following amounts shall be rounded to 2 decimals in both the Invoice and the Credit Note:

AllowanceCharge / Amount
AllowanceCharge / BaseAmount
TaxTotal / TaxAmount
TaxTotal / TaxSubtotal / TaxableAmount
TaxTotal / TaxSubtotal / TaxAmount
LegalMonetaryTotal / LineExtensionAmount
LegalMonetaryTotal / TaxExclusiveAmount
LegalMonetaryTotal / TaxInclusiveAmount
LegalMonetaryTotal / AllowanceTotalAmount
LegalMonetaryTotal / ChargeTotalAmount
LegalMonetaryTotal / PrepaidAmount
LegalMonetaryTotal / PayableRoundingAmount
LegalMonetaryTotal / PayableAmount

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

7. Calculation

7.1. Calculation of totals

Formulas for the calculations of totals are as follows:

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

Business term id

Term name

Calculation

BT-106

Sum of invoice line net amounts

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

BT-107

Sum of allowances on document level

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

BT-108

Sum of charges on document level

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

BT-109-GST

Invoice total amount without GST

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

BT-110-GST

Invoice total GST amount

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

BT-112-GST

Invoice total amount with GST

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

BT-115

Amount due for payment

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

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

7.1.2. Element for rounding amount, the PayableRoundingAmount

It is possible to round the expected payable amount.

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

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

7.2. Calculation on line level

7.2.1. Item net price (BT-146)

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

Calculation formula:

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

UBL example of item net price

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

7.2.2. Invoice line net amount (BT-131-GST)

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

The formula for calculating the invoice line net amount is:

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

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

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

<!-- Code omitted for clarity-->

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

<!-- Code omitted for clarity-->

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

7.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="SGD">200</cbc:Amount> (3)
    <cbc:BaseAmount currencyID="SGD">1000</cbc:BaseAmount>(1)
    <cac:TaxCategory>
        <cbc:ID>SR</cbc:ID>
        <cbc:Percent>7</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>GST</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="SGD">200</cbc:Amount>(1)
    <cac:TaxCategory>
        <cbc:ID>SR</cbc:ID>
        <cbc:Percent>7</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>GST</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>

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

7.4. Calculation of GST

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

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

\$"GST category taxable amount (BT-116-GST)" = sum("Invoice line net amounts (BT-113)")\$ \$+ "Document level charge amount (BT-99)" - "Document level allowance amount (BT-93)"\$

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

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

UBL example of calculations of GST Breakdown

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Cleaning</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="SGD">200</cbc:Amount>(1)
    <cac:TaxCategory>
        <cbc:ID>SR</cbc:ID>
        <cbc:Percent>7</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>GST</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>

<cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
    <cbc:Amount currencyID="SGD">100</cbc:Amount>(2)
    <cac:TaxCategory>
        <cbc:ID>SR</cbc:ID>
        <cbc:Percent>7</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>GST</cbc:ID>
        </cac:TaxScheme>
    </cac:TaxCategory>
</cac:AllowanceCharge>

<cac:TaxTotal>
    <cbc:TaxAmount currencyID="SGD">350</cbc:TaxAmount>

    <cac:TaxSubtotal>(3)
        <cbc:TaxableAmount currencyID="SGD">5000.0</cbc:TaxableAmount>(4)
        <cbc:TaxAmount currencyID="SGD">350</cbc:TaxAmount>(5)
        <cac:TaxCategory>
            <cbc:ID>SR</cbc:ID>
            <cbc:Percent>7</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>GST</cbc:ID>
            </cac:TaxScheme>
        </cac:TaxCategory>
    </cac:TaxSubtotal>

    <cac:TaxSubtotal>(6)
        <cbc:TaxableAmount currencyID="SGD">2000.0</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="SGD">0</cbc:TaxAmount>
        <cac:TaxCategory>
            <cbc:ID>ES33</cbc:ID>
            <cbc:Percent>0</cbc:Percent>
            <cbc:TaxExemptionReason>Reason for tax exempt</cbc:TaxExemptionReason>
            <cac:TaxScheme>
                <cbc:ID>GST</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="H87">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="SGD">4000.00</cbc:LineExtensionAmount>
        <!-- code omitted for clarity -->
        <cac:ClassifiedTaxCategory>
            <cbc:ID>SR</cbc:ID>
            <cbc:Percent>7.0</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>GST</cbc:ID>
            </cac:TaxScheme>
        </cac:ClassifiedTaxCategory>

<cac:InvoiceLine>
    <cbc:ID>2</cbc:ID>
    <cbc:InvoicedQuantity unitCode="H87">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="SGD">2000.00</cbc:LineExtensionAmount>
        <!-- code omitted for clarity -->
        <cac:ClassifiedTaxCategory>
            <cbc:ID>ES33</cbc:ID>
            <cbc:Percent>0.0</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>GST</cbc:ID>
            </cac:TaxScheme>
        </cac:ClassifiedTaxCategory>
<cac:InvoiceLine>
    <cbc:ID>3</cbc:ID>
    <cbc:InvoicedQuantity unitCode="H87">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="SGD">900.00</cbc:LineExtensionAmount>
        <!-- code omitted for clarity -->
        <cac:ClassifiedTaxCategory>
            <cbc:ID>SR</cbc:ID>
            <cbc:Percent>7.0</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>GST</cbc:ID>
            </cac:TaxScheme>
        </cac:ClassifiedTaxCategory>

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

8. 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 syntax description for UBL Invoice and CreditNote on the main specification page for details on all elements and attributes, and their rules and use of code lists.

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

8.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>Singapore</cbc:CityName>
            <cbc:PostalZone>1000</cbc:PostalZone>
            <cbc:CountrySubentity>Singapore</cbc:CountrySubentity>
            <cac:AddressLine>
                <cbc:Line>Third address line</cbc:Line>
            </cac:AddressLine>
            <cac:Country>
                <cbc:IdentificationCode>SG</cbc:IdentificationCode>
            </cac:Country>
        </cac:PostalAddress>
        <cac:PartyTaxScheme>
            <cbc:CompanyID>M2-1234567-K</cbc:CompanyID>
            <cac:TaxScheme>
                <cbc:ID>GST</cbc:ID>
            </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyLegalEntity>
            <cbc:RegistrationName>SupplierOfficialName Ltd</cbc:RegistrationName>
            <cbc:CompanyID>B5963654</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

8.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="0195">SGUENT16GB0004K</cbc:EndpointID> (1)
        <cac:PartyIdentification>
            <cbc:ID schemeID="0002">345KS5324</cbc:ID> (2)
        </cac:PartyIdentification>
        <cac:PartyName>
            <cbc:Name>BuyerTradingName Ltd</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
            <cbc:StreetName>Central road 56</cbc:StreetName>
            <cbc:AdditionalStreetName>Second floor</cbc:AdditionalStreetName>
            <cbc:CityName>Singapore</cbc:CityName>
            <cbc:PostalZone>101</cbc:PostalZone>
            <cac:AddressLine>
                <cbc:Line>Third line</cbc:Line>
            </cac:AddressLine>
            <cac:Country>
                <cbc:IdentificationCode>SG</cbc:IdentificationCode>
            </cac:Country>
        </cac:PostalAddress>
        <cac:PartyTaxScheme>
            <cbc:CompanyID>M2-1234567-8</cbc:CompanyID>
            <cac:TaxScheme>
                <cbc:ID>GST</cbc:ID>
            </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyLegalEntity>
            <cbc:RegistrationName>Buyer Official Name</cbc:RegistrationName>
            <cbc:CompanyID>T16GB0004K</cbc:CompanyID> (3)
        </cac:PartyLegalEntity>
        <cac:Contact>
            <cbc:Name>Lisa Johnson</cbc:Name>
            <cbc:Telephone>23434234</cbc:Telephone>
            <cbc:ElectronicMail>lj@buyer.sg</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	schemeID attribute is recommended for party legal entity identifiers

8.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 (BT-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="0195">T16GB0004K</cbc:ID> (1)
    </cac:PartyIdentification>
    <cac:PartyName>
        <cbc:Name>Payee party</cbc:Name>
    </cac:PartyName>
    <cac:PartyLegalEntity>
        <cbc:CompanyID>T16GB0004K</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

8.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>Coleman street 32</cbc:StreetName>
        <cbc:AdditionalStreetName>Building 23</cbc:AdditionalStreetName>
        <cbc:CityName>Singapore</cbc:CityName>
        <cbc:PostalZone>56236</cbc:PostalZone>
        <cbc:CountrySubentity>Subentity</cbc:CountrySubentity>
        <cac:AddressLine>
            <cbc:Line>Back door</cbc:Line>
        </cac:AddressLine>
        <cac:Country>
            <cbc:IdentificationCode>SG</cbc:IdentificationCode>
        </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
        <cbc:CompanyID>M2-1234567-8</cbc:CompanyID>
        <cac:TaxScheme>
            <cbc:ID>GST</cbc:ID>
        </cac:TaxScheme>
    </cac:PartyTaxScheme>
</cac:TaxRepresentativeParty>

8.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. Examples are GLN (Global Location Number) or GSRN (Global Service Relationship Number) both 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>Singapore</cbc:CityName>
            <cbc:PostalZone>21234</cbc:PostalZone>
            <cac:AddressLine>
                <cbc:Line>Gate 15</cbc:Line>
            </cac:AddressLine>
            <cac:Country>
                <cbc:IdentificationCode>SG</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>

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

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

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

8.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 Invoiced object identifier scheme.

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

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

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

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

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

8.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 (BT-22), may instead be be given at document level.

UBL example of preceding invoice information

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

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

8.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 GST 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 GST for allowances and charges shall not be specified, as the GST 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 GST 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="SGD">20</cbc:Amount> (5)
    <cbc:BaseAmount currencyID="SGD">1000</cbc:BaseAmount>(3)
    <cac:TaxCategory>
        <cbc:ID>SR</cbc:ID>
        <cbc:Percent>7</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>GST</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="SGD">10</cbc:Amount>
    <cac:TaxCategory>
        <cbc:ID>SR</cbc:ID>
        <cbc:Percent>7</cbc:Percent>
        <cac:TaxScheme>
            <cbc:ID>GST</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="SGD">1</cbc:Amount>
    <cbc:BaseAmount currencyID="SGD">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="SGD">101</cbc:Amount>
</cac:AllowanceCharge>

8.6. Payment means information

In addition to the payment means allowed according to Peppol BIS Billing 3, the following three alternatives are used in the context of Singapore Peppol BIS Billing 3.

8.6.1. GIRO

If payment is made by the GIRO-system (direct debit)

Z01 - GIRO

PaymentTerms/Note can be used to indicated additional information about payment date.

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

<cac:PaymentMeans>
  <cbc:PaymentMeansCode name="GIRO">Z01</cbc:PaymentMeansCode> (1)
  <cbc:PaymentID>93274234</cbc:PaymentID> (2)
</cac:PaymentMeans>

1	Mandatory, payment means code
2	Remittance information

8.6.2. Card Payment

If the Buyer had opted to pay by using a payment card, this can be indicated in the invoice. The card number or type of card should not be stated in the invoice.

54 - Credit card

UBL example of payment means info when payment is done by Credit Card

<cac:PaymentMeans>
  <cbc:PaymentMeansCode name="Credit Card">54</cbc:PaymentMeansCode> (1)
  <cbc:PaymentID>93274234</cbc:PaymentID> (2)
</cac:PaymentMeans>

1	Mandatory, payment means code
2	Remittance information

8.6.3. Payment by PayNow Corporate

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

<cac:PaymentMeans>
  <cbc:PaymentMeansCode name="PayNow">Z02</cbc:PaymentMeansCode> (1)
  <cbc:PaymentID>93274234</cbc:PaymentID> (2)
  <cac:PayeeFinancialAccount>
    <cbc:ID>UEN123456879</cbc:ID> (3)
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

1	Mandatory, payment means code
2	Remittance information
3	UEN used to identify the payee account

8.7. Item information

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

8.7.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 a temporary workaround to identify UNSPSC. In release 3.0.5 in fall 2020 it is replaced with the new 7143 code TST that is specific for UNSPSC.

8.8. 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 (BT-146).

UBL example of price with price discount

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

8.9. 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 Unit of measure for further information on the code lists.

Table 1. 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 2. 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

9. Code lists

The following chapters give an overview of the restricted set of codes that is used in this PEPPOL BIS. For most codes the restriction is only to add a dated reference of the code list, but for the Invoice Type Code a subset of valid values have been established.

9.1. Code lists for coded elements

9.1.1. Code list for invoice type code (BT-3)

The following sub-chapters give an overview of the restricted set of invoice type codes (BT-3) that is used in this PEPPOL BIS Billing.

The table indicates the name and description of each code, as well as a column "Synonym with" to indicate how this invoice type can be processed if the recipient does not have a separate process/work flow for this code, and as you will see, all invoice types valid in this profile can be processed as a commercial invoice (380) and all credit note types as Commercial credit note (381). Some recipients might have separate processes or work flows for some of these types, and can then use these processes.

The table also gives information on what message type is to be used in the UBL syntax for the different codes.

Specific code lists for the invoice

Invoice Type Code

Document location	`cbc:InvoiceTypeCode`
Source codelist	Subset of UN/CEFACT code list 1001, D.16B

Document location

cbc:InvoiceTypeCode

Source codelist

Subset of UN/CEFACT code list 1001, D.16B

Table 3. Code list
Code	Name	Description	Synonym with	UBL Message type
380	Commercial invoice	Document/message claiming payment for goods or services supplied under conditions agreed between seller and buyer.		`Invoice`
393	Factored invoice	Invoice assigned to a third party for collection.	380	`Invoice`
82	Metered services invoice	Document/message claiming payment for the supply of metered services (e.g., gas, electricity, etc.) supplied to a fixed meter whose consumption is measured over a period of time.	380	`Invoice`
80	Debit note related to goods or services	Debit information related to a transaction for goods or services to the relevant party.	380	`Invoice`
84	Debit note related to financial adjustments	Document/message for providing debit information related to financial adjustments to the relevant party.	380	`Invoice`
395	Consignment invoice	Commercial invoice that covers a transaction other than one involving a sale.	380	`Invoice`
575	Insurer’s invoice	Document/message issued by an insurer specifying the cost of an insurance which has been effected and claiming payment therefore	380	`Invoice`
623	Forwarder’s invoice	Invoice issued by a freight forwarder specifying services rendered and costs incurred and claiming payment therefore.	380	`Invoice`
780	Freight invoice	Document/message issued by a transport operation specifying freight costs and charges incurred for a transport operation and stating conditions of payment.	380	`Invoice`
383	Debit note	Document/message for providing debit information to the relevant party.	380	`Invoice`
386	Prepayment invoice	An invoice to pay amounts for goods and services in advance; these amounts will be subtracted from the final invoice.	380	`Invoice`

Specific code lists for the credit note

Credit note Type Code

Document location	`cbc:CreditNoteTypeCode`
Source codelist	Subset of UN/CEFACT code list 1001, D.16B

Document location

cbc:CreditNoteTypeCode

Source codelist

Subset of UN/CEFACT code list 1001, D.16B

Table 4. Code list
Code	Name	Description	Synonym with	UBL Message type
381	Credit note	Document/message for providing credit information to the relevant party.		`CreditNote`
396	Factored credit note	Credit note related to assigned invoice(s).	381	`CreditNote`
81	Credit note related to goods or services	Document message used to provide credit information related to a transaction for goods or services to the relevant party.	381	`CreditNote`
83	Credit note related to financial adjustments	Document message for providing credit information related to financial adjustments to the relevant party, e.g., bonuses.	381	`CreditNote`
532	Forwarder’s credit note	Document/message for providing credit information to the relevant party.	381	`CreditNote`

9.1.2. Country code

All country codes in an invoice or credit note shall be the alpha-2 code from ISO 3166-1

Document location	`cac:CountryCode/cbc:IdentificationCode` `cac:OriginCountry/cbc:IdentificationCode`
Source codelist	ISO 3166-1

Document location

cac:CountryCode/cbc:IdentificationCode
cac:OriginCountry/cbc:IdentificationCode

Source codelist

ISO 3166-1

9.1.3. Currency code

All currencies in an invoice or credit note shall be the alphabetic code from ISO 4217:2015

Table 5. Document and GST currency codes
Document location	`cbc:DocumentCurrencyCode` `cbc:TaxCurrencyCode`
Source codelist	ISO 4217:2015

Table 6. Currency identifiers
Document location	`cbc:*/@currencyID`
Source codelist	ISO 4217:2015

9.1.4. GST category codes

The following codes shall be used to specify GST categories.

Document location	`cac:ClassifiedTaxCategory/cbc:ID` `cac:TaxCategory/cbc:ID`
Source codelist	IMDA

Document location

cac:ClassifiedTaxCategory/cbc:ID
cac:TaxCategory/cbc:ID

Source codelist

IMDA

Valid values are listed in the table below:

Table 7. Code list
Type of supply	Code	Description	Rate (From 1 Jan 2023)	Rate (From 1 Jan 2024)
Standard rated	SR	Local supply of goods and services	8%	9%
	SRCA-S	Customer accounting supply made by the supplier	N/A	N/A
	SRCA-C	Customer accounting supply made by the customer on supplier’s behalf	8%	9%
	SRRC	Reverse charge regime for Business-to-Business (“B2B”) supplies of imported services	8%	9%
	SROVR-RS	Supply of remote services accountable by the electronic marketplace under the Overseas Vendor Registration Regime	8%	9%
	SROVR-LVG	Supply of low-value goods accountable by the redeliverer or electronic marketplace on behalf of third-party suppliers	8%	9%
	SRLVG	Own supply of low-value goods	8%	9%
Zero rated	ZR	Supplies involving goods for export/ provision of international services	0%	0%
Exempt	ES33	Specific categories of exempt supplies listed under regulation 33 of the GST (General) Regulations	N/A	N/A
Exempt	ESN33	Exempt supplies other than those listed under regulation 33 of the GST (General) Regulations	N/A	N/A
Deemed supplies	DS	Supplies required to be reported pursuant to the GST legislation	8%	9%
Out-of-Scope supplies	OS	Supplies outside the scope of the GST Act	N/A	N/A
Supplies from Non GST registered company	NG	Supplies from a company which is not registered for GST	N/A	N/A

9.1.5. Unit of measure

Valid unit codes shall be from UN/ECE Recommendation 20, Revision 11 (2015). Unless codes for unit of measure are not in common daily use, implementers should as necessary provide a function for clarification of codes when invoices are visualised.

Codes for unit of packaging from UNECE Recommendation No. 21 can be used in accordance with the descriptions in the "Intro" section of UN/ECE Recommendation 20, Revision 11 (2015):
The 2 character alphanumeric code values in UNECE Recommendation 21 shall be used. To avoid duplication with existing code values in UNECE Recommendation No. 20, each code value from UNECE Recommendation 21 shall be prefixed with an “X”, resulting in a 3 alphanumeric code when used as a unit of measure.

Document location	`cbc:*/@unitCode`
Source codelist	UN/ECE Recommendation 20, Revision 11 (2015)

Document location

cbc:*/@unitCode

Source codelist

UN/ECE Recommendation 20, Revision 11 (2015)

9.1.6. Allowance reason codes

Any allowance reason codes shall be from UN/CEFACT code list 5189, D.16B

Document location	`cbc:AllowanceChargeReasonCode[cbc:ChargeIndicator=false]`
Source codelist	Subset of UN/CEFACT code list 5189, D.16B

Document location

cbc:AllowanceChargeReasonCode[cbc:ChargeIndicator=false]

Source codelist

Subset of UN/CEFACT code list 5189, D.16B

Valid values are listed in the table below:

Table 8. Code list
Code	Description
41	Bonus for works ahead of schedule
42	Other bonus
60	Manufacturer’s consumer discount
62	Due to military status
63	Due to work accident
64	Special agreement
65	Production error discount
66	New outlet discount
67	Sample discount
68	End-of-range discount
70	Incoterm discount
71	Point of sales threshold allowance
88	Material surcharge/deduction
95	Discount
100	Special rebate
102	Fixed long term
103	Temporary
104	Standard
105	Yearly turnover

9.1.7. Charge reason codes

Any charge reason code shall be from UN/CEFACT code list 7161, D.16B

Document location

cbc:AllowanceChargeReasonCode[cbc:ChargeIndicator=true]

Source codelist

UN/CEFACT code list 7161, D.16B

9.1.8. Media type code of attached document

Subset of IANA Media Types.

Document location

cbc:EmbeddedDocumentBinaryObject/@mimeCode

Source codelist

Subset of IANA

Valid values are listed in the table below.

Table 9. Code list
Documents	application/pdf
Images	image/png
Images	image/jpeg
Text	text/csv
Spreadsheet	application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Spreadsheet	application/vnd.oasis.opendocument.spreadsheet

9.1.9. Payment means type code

Payment means type code shall be from UN/CEFACT code list 4461, D.16B

Document location

cac:PaymentMeans/cbc:PaymentMeansCode

Source codelist

UN/CEFACT code list 4461, D.16B

9.2. Code lists for identifier schemes

9.2.1. Identifiers used for Singapore businesses

There are three particularly important identifiers used in messages addressed to or from Singapore businesses.

Type of identifier

Format

Location in message

Example

Company legal registration identifier (UEN)

The value of the UEN

Element cac:Party/cac:PartyLegalEntity/cbc:CompanyID with no schemeID

T16GB0004K

Peppol ID/Electronic address identifier (0195)

Fixed prefix SGUEN + the value of the UEN

Element cac:Party/cbc:EndpointID with schemeID 0195

SGUENT16GB0004K

GST Identifier

Use the format of the GST identifier as it has been issued by the Inland Revenue Authority of Singapore (IRAS)

Element: cac:Party/cac:PartyTaxScheme/cbc:CompanyID and with cac:TaxScheme/cbc:ID = 'GST'

M2-1234567-8

9.2.2. Electronic address identifier scheme

For BT-49 and BT-34 Sellers and Buyers Electronic address identifiers (Endpoint identification) the EN 16931 mandates use of a code list to be maintained by Connecting Europe Facility (CEF).

Business Term

Applicable XPath

Code list (link or subset values)

Electronic address identifiers (Endpoint)

cbc:EndpointID/@schemeID

Code list for electronic address

9.2.3. Party identifiers and party legal registration identifier scheme

All party identifiers and party legal registration identifier has an optional scheme attribute. If used, the value shall be chosen from the ICD list from ISO/IEC 6523

Business Term

Applicable XPath

Code list (link or subset values)

Party identifiers (Buyer, Seller, Payee)

cac:PartyIdentification/cbc:ID/@schemeID

ICD list from ISO/IEC 6523

Legal registration identifiers (Buyer, Seller, Payee)

cac:PartyLegalEntity/cbc:CompanyID/@schemeID

Deliver to location identifier

cac:Delivery/cac:DeliveryLocation/cbc:ID/@schemeID

9.2.4. Invoiced object identifier scheme

The invoiced object identifier scheme shall be from UN/CEFACT code list 1153, D.16B

Business Term

Applicable XPath

Code list (link or subset values)

Invoiced object identifier

cac:AdditionalDocumentReference[cbc:DocumentTypeCode = '130']/cbc:ID/@schemeID

UN/CEFACT code list 1153, D.16B

9.2.5. Item standard identifier scheme

An item standard identifier has a mandatory scheme attribute. The value shall be chosen from the ICD list from ISO/IEC 6523

Business Term

Applicable XPath

Code list (link or subset values)

Item Standard identifier

cac:InvoiceLine/cac:Item/cac:StandardItemIdentification/cbc:ID/@schemeID

ICD list from ISO/IEC 6523

9.2.6. Item classification identifier

An item classification identifier has a mandatory scheme attribute. The value shall be chosen from UN/CEFACT code list 7143, D.16B.

Business Term

Applicable XPath

Code list (link or subset values)

Item Classification identifier

cac:InvoiceLine/cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode/@listID

UN/CEFACT code list 7143, D.16B

10. 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 from EN 16931 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]

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

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

10.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 10. EN 16931_ Date. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	2017-12-01

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

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

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

A receiver of an invoice or credit note, shall accept and process attachments that are according to the code list Media type code of attached document

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

11.1. Profiles and messages

All messages contains ProfileID and CustomizationID. ProfileID identifies what business process a given message is part of, and CustomizationID 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 ProfileID and CustomizationID.

CustomizationID is a string without spaces. The list below contains spaces in CustomizationID to make them easier to read. Make sure to remove any spaces before use.

11.2. Profile 01 - Billing

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

Type Element cbc:CustomizationID Element cbc:ProfileID

Invoice and credit note

urn:cen.eu:en16931:2017#conformant#
urn:fdc:peppol.eu:2017:poacc:billing:international:sg:3.0

urn:fdc:peppol.eu:2017:poacc:billing:01:1.0

UBL example of profile identifier

<cbc:CustomizationID>urn:cen.eu:en16931:2017#conformant#urn:fdc:peppol.eu:2017:poacc:billing:international:sg:3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>

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

Download a Zip-archive with the Invoice and CreditNote XML Schemas.

The full documentation package for UBL is available on the OASIS Universal Business Language website.

13. Validation

To optimize the flexibility in the validation process, each PEPPOL document is validated in different stages with shifting focus in every stage.

13.1. Validation Principles

Stages in the validation process:

Validation of syntax

For example:

Check well-formedness
Tag names and attributes shall be correctly written and follow the UBL 2.1 sequence
All UBL 2.1 mandatory elements shall be present.
The element’s contents shall be according to the element’s type definition.

Validation against a subset of EN 16931

To verify that the instance message is compliant to the european standard, like:

Valid codes for currencies, countries, tax etc.
Mandatory elements according to EN 16931.
Logical correlations between information element, i.e. that start date is lower than or equal to end date, calculations give the correct result etc.
The subset excludes EN16931 rules that are specific to Europe.

Peppol BIS Billing 3.0 - General rules

General rule that applies to all invoices in Peppol and are triggered by the existence of one or more specific business term(s).

Example rule text
An invoice shall have a buyers reference or an order reference
Context that triggers the rule
Existence of either Buyer reference (BT-10) OR Purchased order reference (BT-13)

Singapore - Country qualified validation rules

Specific rule relevant for Singapore such for calculation of GST.

Example rule text
[BR-NG-11-GST-SG]-An Invoice that contains a GST breakdown group (BG-23) with a GST category code (BT-118-GST) "NG" shall not contain other GST breakdown groups (BG-23)
Context that triggers the rule
The SG BIS Customization identifier

14. Transaction validation rules

14.1. International transaction business rules

The following EN 16931 and PEPPOL rules apply to invoice and credit note transaction as it is used in this Singapore BIS. This PEPPOL BIS uses a forked version of the validation rules from EN 16931. Further details can be found at https://github.com/OpenPEPPOL/tc434-validation.

Table 12. EN 16931 business rules
Rule	Message
BR-01 (fatal)	An Invoice shall have a Specification identifier (BT-24).
BR-02 (fatal)	An Invoice shall have an Invoice number (BT-1).
BR-03 (fatal)	An Invoice shall have an Invoice issue date (BT-2).
BR-04 (fatal)	An Invoice shall have an Invoice type code (BT-3).
BR-05 (fatal)	An Invoice shall have an Invoice currency code (BT-5).
BR-06 (fatal)	An Invoice shall contain the Seller name (BT-27).
BR-07 (fatal)	An Invoice shall contain the Buyer name (BT-44).
BR-08 (fatal)	An Invoice shall contain the Seller postal address.
BR-09 (fatal)	The Seller postal address (BG-5) shall contain a Seller country code (BT-40).
BR-10 (fatal)	An Invoice shall contain the Buyer postal address (BG-8).
BR-11 (fatal)	The Buyer postal address shall contain a Buyer country code (BT-55).
BR-12 (fatal)	An Invoice shall have the Sum of Invoice line net amount (BT-106).
BR-15 (fatal)	An Invoice shall have the Amount due for payment (BT-115).
BR-16 (fatal)	An Invoice shall have at least one Invoice line (BG-25)
BR-17 (fatal)	The Payee name (BT-59) shall be provided in the Invoice, if the Payee (BG-10) is different from the Seller (BG-4)
BR-18 (fatal)	The Seller tax representative name (BT-62) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11)
BR-19 (fatal)	The Seller tax representative postal address (BG-12) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11).
BR-20 (fatal)	The Seller tax representative postal address (BG-12) shall contain a Tax representative country code (BT-69), if the Seller (BG-4) has a Seller tax representative party (BG-11).
BR-21 (fatal)	Each Invoice line (BG-25) shall have an Invoice line identifier (BT-126).
BR-22 (fatal)	Each Invoice line (BG-25) shall have an Invoiced quantity (BT-129).
BR-23 (fatal)	An Invoice line (BG-25) shall have an Invoiced quantity unit of measure code (BT-130).
BR-24 (fatal)	Each Invoice line (BG-25) shall have an Invoice line net amount (BT-131).
BR-25 (fatal)	Each Invoice line (BG-25) shall contain the Item name (BT-153).
BR-26 (fatal)	Each Invoice line (BG-25) shall contain the Item net price (BT-146).
BR-27 (fatal)	The Item net price (BT-146) shall NOT be negative.
BR-28 (fatal)	The Item gross price (BT-148) shall NOT be negative.
BR-29 (fatal)	If both Invoicing period start date (BT-73) and Invoicing period end date (BT-74) are given then the Invoicing period end date (BT-74) shall be later or equal to the Invoicing period start date (BT-73).
BR-30 (fatal)	If both Invoice line period start date (BT-134) and Invoice line period end date (BT-135) are given then the Invoice line period end date (BT-135) shall be later or equal to the Invoice line period start date (BT-134).
BR-31 (fatal)	Each Document level allowance (BG-20) shall have a Document level allowance amount (BT-92).
BR-33 (fatal)	Each Document level allowance (BG-20) shall have a Document level allowance reason (BT-97) or a Document level allowance reason code (BT-98).
BR-36 (fatal)	Each Document level charge (BG-21) shall have a Document level charge amount (BT-99).
BR-38 (fatal)	Each Document level charge (BG-21) shall have a Document level charge reason (BT-104) or a Document level charge reason code (BT-105).
BR-41 (fatal)	Each Invoice line allowance (BG-27) shall have an Invoice line allowance amount (BT-136).
BR-42 (fatal)	Each Invoice line allowance (BG-27) shall have an Invoice line allowance reason (BT-139) or an Invoice line allowance reason code (BT-140).
BR-43 (fatal)	Each Invoice line charge (BG-28) shall have an Invoice line charge amount (BT-141).
BR-44 (fatal)	Each Invoice line charge shall have an Invoice line charge reason or an invoice line allowance reason code.
BR-49 (fatal)	A Payment instruction (BG-16) shall specify the Payment means type code (BT-81).
BR-50 (fatal)	A Payment account identifier (BT-84) shall be present if Credit transfer (BG-17) information is provided in the Invoice.
BR-51 (warning)	In accordance with card payments security standards an invoice should never include a full card primary account number (BT-87). At the moment PCI Security Standards Council has defined that the first 6 digits and last 4 digits are the maximum number of digits to be shown.
BR-52 (fatal)	Each Additional supporting document (BG-24) shall contain a Supporting document reference (BT-122).
BR-54 (fatal)	Each Item attribute (BG-32) shall contain an Item attribute name (BT-160) and an Item attribute value (BT-161).
BR-55 (fatal)	Each Preceding Invoice reference (BG-3) shall contain a Preceding Invoice reference (BT-25).
BR-57 (fatal)	Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80).
BR-61 (fatal)	If the Payment means type code (BT-81) means SEPA credit transfer, Local credit transfer or Non-SEPA international credit transfer, the Payment account identifier (BT-84) shall be present.
BR-62 (fatal)	The Seller electronic address (BT-34) shall have a Scheme identifier.
BR-63 (fatal)	The Buyer electronic address (BT-49) shall have a Scheme identifier.
BR-64 (fatal)	The Item standard identifier (BT-157) shall have a Scheme identifier.
BR-65 (fatal)	The Item classification identifier (BT-158) shall have a Scheme identifier.
BR-66 (fatal)	An Invoice shall contain maximum one Payment Card account (BG-18).
BR-67 (fatal)	An Invoice shall contain maximum one Payment Mandate (BG-19).
BR-CL-01 (fatal)	The document type code MUST be coded by the invoice and credit note related code lists of UNTDID 1001.
BR-CL-03 (fatal)	currencyID MUST be coded using ISO code list 4217 alpha-3
BR-CL-04 (fatal)	Invoice currency code MUST be coded using ISO code list 4217 alpha-3
BR-CL-05 (fatal)	Tax currency code MUST be coded using ISO code list 4217 alpha-3
BR-CL-06 (fatal)	Value added tax point date code MUST be coded using a restriction of UNTDID 2005.
BR-CL-07 (fatal)	Object identifier identification scheme identifier MUST be coded using a restriction of UNTDID 1153.
BR-CL-08 (fatal)	Invoiced note subject code shall be coded using UNCL4451
BR-CL-10 (fatal)	Any identifier identification scheme identifier MUST be coded using one of the ISO 6523 ICD list.
BR-CL-11 (fatal)	Any registration identifier identification scheme identifier MUST be coded using one of the ISO 6523 ICD list.
BR-CL-13 (fatal)	Item classification identifier identification scheme identifier MUST be coded using one of the UNTDID 7143 list.
BR-CL-14 (fatal)	Country codes in an invoice MUST be coded using ISO code list 3166-1
BR-CL-15 (fatal)	Country codes in an invoice MUST be coded using ISO code list 3166-1
BR-CL-19 (fatal)	Coded allowance reasons MUST belong to the UNCL 5189 code list
BR-CL-20 (fatal)	Coded charge reasons MUST belong to the UNCL 7161 code list
BR-CL-21 (fatal)	Item standard identifier scheme identifier MUST belong to the ISO 6523 ICD code list
BR-CL-23 (fatal)	Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension
BR-CL-24 (fatal)	For Mime code in attribute use MIMEMediaType.
BR-CL-25 (fatal)	Endpoint identifier scheme identifier MUST belong to the CEF EAS code list
BR-CL-26 (fatal)	Delivery location identifier scheme identifier MUST belong to the ISO 6523 ICD code list
BR-CO-03 (fatal)	Value added tax point date (BT-7) and Value added tax point date code (BT-8) are mutually exclusive.
BR-CO-05 (fatal)	Document level allowance reason code (BT-98) and Document level allowance reason (BT-97) shall indicate the same type of allowance.
BR-CO-06 (fatal)	Document level charge reason code (BT-105) and Document level charge reason (BT-104) shall indicate the same type of charge.
BR-CO-07 (fatal)	Invoice line allowance reason code (BT-140) and Invoice line allowance reason (BT-139) shall indicate the same type of allowance reason.
BR-CO-08 (fatal)	Invoice line charge reason code (BT-145) and Invoice line charge reason (BT-144) shall indicate the same type of charge reason.
BR-CO-19 (fatal)	If Invoicing period (BG-14) is used, the Invoicing period start date (BT-73) or the Invoicing period end date (BT-74) shall be filled, or both.
BR-CO-20 (fatal)	If Invoice line period (BG-26) is used, the Invoice line period start date (BT-134) or the Invoice line period end date (BT-135) shall be filled, or both.
BR-CO-21 (fatal)	Each Document level allowance (BG-20) shall contain a Document level allowance reason (BT-97) or a Document level allowance reason code (BT-98), or both.
BR-CO-22 (fatal)	Each Document level charge (BG-21) shall contain a Document level charge reason (BT-104) or a Document level charge reason code (BT-105), or both.
BR-CO-23 (fatal)	Each Invoice line allowance (BG-27) shall contain an Invoice line allowance reason (BT-139) or an Invoice line allowance reason code (BT-140), or both.
BR-CO-24 (fatal)	Each Invoice line charge (BG-28) shall contain an Invoice line charge reason (BT-144) or an Invoice line charge reason code (BT-145), or both.
BR-CO-25 (fatal)	In case the Amount due for payment (BT-115) is positive, either the Payment due date (BT-9) or the Payment terms (BT-20) shall be present.
BR-DEC-01 (fatal)	The allowed maximum number of decimals for the Document level allowance amount (BT-92) is 2.
BR-DEC-02 (fatal)	The allowed maximum number of decimals for the Document level allowance base amount (BT-93) is 2.
BR-DEC-05 (fatal)	The allowed maximum number of decimals for the Document level charge amount (BT-99) is 2.
BR-DEC-06 (fatal)	The allowed maximum number of decimals for the Document level charge base amount (BT-100) is 2.
BR-DEC-09 (fatal)	The allowed maximum number of decimals for the Sum of Invoice line net amount (BT-106) is 2.
BR-DEC-10 (fatal)	The allowed maximum number of decimals for the Sum of allowanced on document level (BT-107) is 2.
BR-DEC-11 (fatal)	The allowed maximum number of decimals for the Sum of charges on document level (BT-108) is 2.
BR-DEC-16 (fatal)	The allowed maximum number of decimals for the Paid amount (BT-113) is 2.
BR-DEC-17 (fatal)	The allowed maximum number of decimals for the Rounding amount (BT-114) is 2.
BR-DEC-18 (fatal)	The allowed maximum number of decimals for the Amount due for payment (BT-115) is 2.

14.2. PEPPOL specific transaction business rules

The following PEPPOL rules apply to invoice and credit note transaction as it is used in this Singapore BIS. The PEPPOL BIS uses a forked version of the validation rules from EN 16931.

Table 13. PEPPOL transaction business rules
Rule	Message
PEPPOL-COMMON-R040 (fatal)	GLN must have a valid format according to GS1 rules.
PEPPOL-COMMON-R041 (fatal)	Norwegian organization number MUST be stated in the correct format.
PEPPOL-COMMON-R042 (fatal)	Danish organization number (CVR) MUST be stated in the correct format.
PEPPOL-COMMON-R043 (fatal)	Belgian enterprise number MUST be stated in the correct format.
PEPPOL-COMMON-R044 (warning)	IPA Code (Codice Univoco Unità Organizzativa) must be stated in the correct format
PEPPOL-COMMON-R045 (warning)	Tax Code (Codice Fiscale) must be stated in the correct format
PEPPOL-COMMON-R046 (warning)	Tax Code (Codice Fiscale) must be stated in the correct format
PEPPOL-COMMON-R047 (warning)	Italian VAT Code (Partita Iva) must be stated in the correct format
PEPPOL-COMMON-R049 (fatal)	Swedish organization number MUST be stated in the correct format.
PEPPOL-COMMON-R050 (fatal)	Australian Business Number (ABN) MUST be stated in the correct format.
PEPPOL-EN16931-CL001 (fatal)	Mime code must be according to subset of IANA code list.
PEPPOL-EN16931-CL002 (fatal)	Reason code MUST be according to subset of UNCL 5189 D.16B.
PEPPOL-EN16931-CL003 (fatal)	Reason code MUST be according to UNCL 7161 D.16B.
PEPPOL-EN16931-CL006 (fatal)	Invoice period description code must be according to UNCL 2005 D.16B.
PEPPOL-EN16931-CL007 (fatal)	Currency code must be according to ISO 4217:2005
PEPPOL-EN16931-CL008 (fatal)	Electronic address identifier scheme must be from the codelist "Electronic Address Identifier Scheme"
PEPPOL-EN16931-F001 (fatal)	A date MUST be formatted YYYY-MM-DD.
PEPPOL-EN16931-P0100 (fatal)	Invoice type code MUST be set according to the profile.
PEPPOL-EN16931-P0101 (fatal)	Credit note type code MUST be set according to the profile.
PEPPOL-EN16931-R001 (fatal)	Business process MUST be provided.
PEPPOL-EN16931-R002 (fatal)	No more than one note is allowed on document level.
PEPPOL-EN16931-R003 (fatal)	A buyer reference or purchase order reference MUST be provided.
PEPPOL-EN16931-R005 (fatal)	GST accounting currency code MUST be different from invoice currency code when provided.
PEPPOL-EN16931-R007 (fatal)	Business process MUST be in the format 'urn:fdc:peppol.eu:2017:poacc:billing:NN:1.0' where NN indicates the process number.
PEPPOL-EN16931-R008 (fatal)	Document MUST not contain empty elements.
PEPPOL-EN16931-R010 (fatal)	Buyer electronic address MUST be provided
PEPPOL-EN16931-R020 (fatal)	Seller electronic address MUST be provided
PEPPOL-EN16931-R040 (fatal)	Allowance/charge amount must equal base amount * percentage/100 if base amount and percentage exists
PEPPOL-EN16931-R041 (fatal)	Allowance/charge base amount MUST be provided when allowance/charge percentage is provided.
PEPPOL-EN16931-R042 (fatal)	Allowance/charge percentage MUST be provided when allowance/charge base amount is provided.
PEPPOL-EN16931-R043 (warning)	Allowance/charge ChargeIndicator value MUST equal 'true' or 'false'
PEPPOL-EN16931-R044 (fatal)	Charge on price level is NOT allowed. Only value 'false' allowed.
PEPPOL-EN16931-R046 (fatal)	Item net price MUST equal (Gross price - Allowance amount) when gross price is provided.
PEPPOL-EN16931-R051 (fatal)	All currencyID attributes must have the same value as the invoice currency code (BT-5), except for the invoice total GST amount in accounting currency (BT-111)
PEPPOL-EN16931-R053 (fatal)	Only one tax total with tax subtotals MUST be provided.
PEPPOL-EN16931-R054 (fatal)	Only one tax total without tax subtotals MUST be provided when tax currency code is provided.
PEPPOL-EN16931-R061 (fatal)	Mandate reference MUST be provided for direct debit.
PEPPOL-EN16931-R080 (fatal)	Only one project reference is allowed on document level
PEPPOL-EN16931-R100 (fatal)	Only one invoiced object is allowed pr line
PEPPOL-EN16931-R101 (fatal)	Element Document reference can only be used for Invoice line object
PEPPOL-EN16931-R110 (fatal)	Start date of line period MUST be within invoice period.
PEPPOL-EN16931-R111 (fatal)	End date of line period MUST be within invoice period.
PEPPOL-EN16931-R120 (fatal)	Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount
PEPPOL-EN16931-R121 (fatal)	Base quantity MUST be a positive number above zero.
PEPPOL-EN16931-R130 (fatal)	Unit code of price base quantity MUST be same as invoiced quantity.

14.3. SG specific transaction business rules

The following rules have been defined by Singapore in addition to the rules adopted from PEPPOL. These rules apply in all profiles that use this transaction specification.

Table 14. PEPPOL transaction business rules
Rule	Message
BR-100-GST-SG (fatal)	Total Amount including GST in SGD must be numeric and have maximum of 2 decimals
BR-101-GST-SG (fatal)	Total Amount excluding GST in SGD must be numeric and have maximum of 2 decimals
BR-102-GST-SG (fatal)	Attachment must not be used when providing reference to Total Amount incl or excl GST in SGD, Invoiced Object Reference or Project Reference
BR-103-GST-SG (fatal)	When providing Total Amount including GST in SGD, element ID must be set to the code value SGD
BR-104-GST-SG (fatal)	When providing Total Amount excluding GST in SGD, element ID must be set to the code value SGD
BR-105-GST-SG (fatal)	An Invoice that contains an GST Category code of value SR, SRCA-S, SRCA-C, ZR, SRRC, SROVR-RS, SROVR-LVG or SRLVG shall contain the Seller GST identifier (BT-31-GST) or the Seller tax representative GST identifier (BT-63-GST)
BR-13-GST-SG (fatal)	An Invoice shall have the Invoice total amount without GST (BT-109-GST).
BR-14-GST-SG (fatal)	An Invoice shall have the Invoice total amount with GST (BT-112-GST).
BR-45-GST-SG (fatal)	Each GST Breakdown (BG-23-GST) shall have a GST category taxable amount (BT-116-GST).
BR-46-GST-SG (fatal)	Each GST Breakdown (BG-23-GST) shall have a GST category tax amount (BT-117-GST).
BR-47-GST-SG (fatal)	Each GST Breakdown (BG-23-GST) shall be defined through a GST category code (BT-118-GST).
BR-48-GST-SG (fatal)	Each GST breakdown (BG-23-GST) shall have a GST category rate (BT-119-GST), except if the Invoice is not subject to GST.
BR-53-GST-SG (fatal)	If the GST accounting currency code (BT-6-GST) is present, then the Invoice total GST amount (BT-111-GST), Invoice total including GST amount and Invoice Total excluding GST amount in accounting currency shall be provided.
BR-56-GST-SG (fatal)	Each Seller tax representative party (BG-11) shall have a Seller tax representative GST identifier (BT-63-GST).
BR-CL-16-SG (fatal)	Payment means in an invoice MUST be coded using UNCL4461 code list, or code Z01 or Z02
BR-CL-17-GST-SG (fatal)	Invoice tax categories MUST be coded using valid Singapore code values
BR-CL-18-GST-SG (fatal)	Invoice tax categories MUST be coded using valid Singapore code values
BR-CO-04-GST-SG (fatal)	Each Invoice line (BG-25) shall be categorized with an Invoiced item GST category code (BT-151-GST).
BR-CO-10-SG (fatal)	Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
BR-CO-11-SG (fatal)	Sum of allowances on document level (BT-107) = Σ Document level allowance amount (BT-92).
BR-CO-12-SG (fatal)	Sum of charges on document level (BT-108) = Σ Document level charge amount (BT-99).
BR-CO-13-GST-SG (fatal)	Invoice total amount without GST (BT-109-GST) = Σ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108).
BR-CO-14-GST-SG (fatal)	Invoice total GST amount (BT-110-GST) = Σ GST category tax amount (BT-117-GST).
BR-CO-15-GST-SG (fatal)	Invoice total amount with GST (BT-112-GST) = Invoice total amount without GST (BT-109-GST) + Invoice total GST amount (BT-110-GST).
BR-CO-16-GST-SG (fatal)	Amount due for payment (BT-115) = Invoice total amount with GST (BT-112-GST-SG) -Paid amount (BT-113) +Rounding amount (BT-114).
BR-CO-17-GST-SG (fatal)	GST category tax amount (BT-117-GST) = GST category taxable amount (BT-116-GST) x (GST category rate (BT-119-GST) / 100).
BR-CO-18-GST-SG (fatal)	An Invoice shall at least have one GST Breakdown group (BG-23-GST).
BR-CO-26-GST-SG (fatal)	In order for the buyer to automatically identify a supplier, the Seller identifier (BT-29), the Seller legal registration identifier (BT-30) and/or the Seller GST identifier (BT-31-GST) shall be present.
BR-DEC-12-GST-SG (fatal)	The allowed maximum number of decimals for the Invoice total amount without GST (BT-109-GST) is 2.
BR-DEC-13-GST-SG (fatal)	The allowed maximum number of decimals for the Invoice total GST amount (BT-110-GST) is 2.
BR-DEC-14-GST-SG (fatal)	The allowed maximum number of decimals for the Invoice total amount with GST (BT-112-GST) is 2.
BR-DEC-15-GST-SG (fatal)	The allowed maximum number of decimals for the Invoice total GST amount in accounting currency (BT-111-GST) is 2.
BR-DEC-19-GST-SG (fatal)	The allowed maximum number of decimals for the GST category taxable amount (BT-116-GST) is 2.
BR-DEC-20-GST-SG (fatal)	The allowed maximum number of decimals for the GST category tax amount (BT-117-GST) is 2.
BR-NG-01-GST-SG (fatal)	An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the GST category code (BT-151-GST, BT-95-GST or BT-102-GST) is "NG" shall contain exactly one GST breakdown group (BG-23) with the GST category code (BT-118) equal to "NG".
BR-NG-02-GST-SG (fatal)	An Invoice that contains an Invoice line (BG-25) where the Invoiced item GST category code (BT-151-GST) is "NG" shall not contain the Seller GST identifier (BT-31), the Seller tax representative GST identifier (BT-63-GST) or the Buyer GST identifier (BT-48-GST).
BR-NG-03-GST-SG (fatal)	An Invoice that contains a Document level allowance (BG-20) where the Document level allowance GST category code (BT-95-GST) is "NG" shall not contain the Seller GST identifier (BT-31-GST), the Seller tax representative GST identifier (BT-63-GST) or the Buyer GST identifier (BT-48-GST).
BR-NG-04-GST-SG (fatal)	An Invoice that contains a Document level charge (BG-21) where the Document level charge GST category code (BT-102-GST) is "NG" shall not contain the Seller GST identifier (BT-31-GST), the Seller tax representative GST identifier (BT-63-GST) or the Buyer GST identifier (BT-48-GST).
BR-NG-08-GST-SG (fatal)	In a GST breakdown (BG-23) where the GST category code (BT-118-GST) is "NG" the GST category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the GST category codes (BT-151-GST, BT-95-GST, BT-102-GST) are "NG".
BR-NG-09-GST-SG (fatal)	The GST category tax amount (BT-117-GST) in a GST breakdown (BG-23) where the GST category code (BT-118-GST) is "NG" shall be 0 (zero).
BR-NG-11-GST-SG (fatal)	An Invoice that contains a GST breakdown group (BG-23) with a GST category code (BT-118-GST) "NG" shall not contain other GST breakdown groups (BG-23).
BR-NG-12-GST-SG (fatal)	An Invoice that contains a GST breakdown group (BG-23) with a GST category code (BT-118) "NG" shall not contain an Invoice line (BG-25) where the Invoiced item GST category code (BT-151-GST) is not "NG".
BR-NG-13-GST-SG (fatal)	An Invoice that contains a GST breakdown group (BG-23) with a GST category code (BT-118-GST) "NG" shall not contain Document level allowances (BG-20) where Document level allowance GST category code (BT-9-GST5) is not "NG".
BR-NG-14-GST-SG (fatal)	An Invoice that contains a GST breakdown group (BG-23) with a GST category code (BT-118-GST) "NG" shall not contain Document level charges (BG-21) where Document level charge GST category code (BT-102-GST) is not "NG".
PEPPOL-EN16931-R004-SG (fatal)

Singapore BIS 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. GST 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. Goods and Services Tax (GST)

5.1. Line GST Information

5.2. Document level allowance or charge

5.3. GST Breakdown

5.4. Invoice total GST amount

5.5. GST accounting currency

6. Rounding

7. Calculation

7.1. Calculation of totals

7.1.1. UBL syntax calculation formulas

7.1.2. Element for rounding amount, the PayableRoundingAmount

7.2. Calculation on line level

7.2.1. Item net price (BT-146)

7.2.2. Invoice line net amount (BT-131-GST)

7.3. Calculation of allowance/charge amount

7.4. Calculation of GST

8. Examples of selected parts of the transaction

8.1. Parties

8.1.1. Seller (AccountingSupplierParty)

8.1.2. Buyer (AccountingCustomerParty)

8.1.3. Payment receiver (PayeeParty)

8.1.4. Sellers Tax Representative (TaxRepresentativePary)

8.2. Delivery Details (Date and Location)

8.3. References

8.3.1. Purchase order and sales order reference

8.3.2. Buyer reference

8.3.3. Invoiced object identifier

8.3.4. Contract reference

8.3.5. Despatch and receipt advice references

8.3.6. Tender reference

8.3.7. Project reference

8.4. Preceding invoice references

8.5. Allowances and Charges

8.6. Payment means information

8.6.1. GIRO

8.6.2. Card Payment

8.6.3. Payment by PayNow Corporate

8.7. Item information

8.7.1. Item identifiers

8.7.2. Item classification

8.8. Price information

8.9. Unit of measure

9. Code lists

9.1. Code lists for coded elements

9.1.1. Code list for invoice type code (BT-3)

Specific code lists for the invoice

Invoice Type Code

Specific code lists for the credit note

Credit note Type Code

9.1.2. Country code

9.1.3. Currency code

9.1.4. GST category codes

9.1.5. Unit of measure

9.1.6. Allowance reason codes

9.1.7. Charge reason codes

9.1.8. Media type code of attached document

9.1.9. Payment means type code

9.2. Code lists for identifier schemes

9.2.1. Identifiers used for Singapore businesses