open it

Best Practice

This section summarises the additional comments for some of the fields rated as 'Best Practice'.

For the purpose of this guide, best practice fields are defined as the following: required by buyers and are vital to enable automatic invoice processing. If they are not provided, the invoice is highly likely to be rejected or payment will be delayed. 

Please refer to the full list of the Peppol fields with their relevant priority rating in the appendix of the best practice guide. A copy of the guide can be accessed here

1. Invoice Payment Due Date

Peppol mandates that either Payment due date and/or Payment terms needs to be provided. 

The group agreed that the due date is preferred as this information is structured. The Peppol format for dates is 'YYYY-MM-DD' and is relatively easy for systems to process. 

Some sellers do not have the capability to calculate and/or provide the payment date (as the date is implied in the payment terms). If so, it may be used as a once off or where there is a variation to the contract / agreement of the payment terms.

It should also be noted that payment terms is a free text field, thus due date is better for automation. However, this is subject to business needs and system capabilities. 

2. Supplier / Seller GST Identifier

It is a legal requirements in Australian that when a GST branch makes a taxable sale, the branch number must be provided (ABN and 3-digit branch number). 

New Zealand requires the GST number if the supplier is GST registered. Note that the New Zealand Business Number (NZBN) is not the GST number. 

3. Supplier / Seller Contact Details

According to the invoice specification, there are three fields for seller's contact details: email address, name and phone. 

Buyer's vendor master data details are often generic or out of date, therefore providing an email address will make it easier in case the seller needs to be contacted. The low adoption levels of Invoice Response capability in the market further augments the need to provide an email address for out of band responses. 

It was agreed that email address should be provided, while name and telephone are considered good practice. The email supplied is expected to be the one used if an out of band response is required. 

4. Payee Financial Account

It was suggested that payee financial account details are critical, as these details are commonly used for matching purposes, fraud risk management or part of internal control processes. Excluding this information could be adoption barrier especially for large corporations and those that engage in cross border transactions. 

Note: these fields should not be relied on to update a buyer's vendor master data. Buyers are expected to have internal controls and/or approval processes in place to update payment details. 

5. Payment ID / Remittance Information

This is the supplier-issued reference number that is used for reconciliation purposes. E.g. a customer reference number. It is expected to be included in the payment message to support reconciliation. 

Where unavailable, it is recommended that buyers use the invoice number as Payment ID.

6. Additional Description for Item

This field is generally used as a 'Long Description' of an item and needs to be looked at in context with the Item name field (the 'Short Description'), which is mandatory under Peppol. 

This was deemed important for ownership reasons. 

Where applicable, the Global Trade Item Number (GTIN) should be provided (in ...cac:item/cac:StandardItemIdentification/cbc:ID) to support automation. Where GTIN is not applicable (e.g. customised services), the long description will be beneficial and is considered best practice to provide to support the efficient processing of an invoice.

Best Practice Capability

This section describes elements that are often required. It is Best Practice for the supplier and their FMIS/ERP providers to support them, although they will not be required for every invoice. 

7. Reference Number (Purchase Order, Buyer Reference, Contract, Project, Tender)

Peppol supports referencing a number of different documents such as purchase orders, contract number and shipping notice etc. 

  1. Purchase order number
  2. Buyer assigned reference

Note: Peppol requirements are that at least one of Purchase Order or Buyer Reference must be provided.

If C1 operates a Purchase Order based process, then Purchase Order should be provided.

  1. Contract number
  2. Project number
  3. Tender number

Depending on the C4's procurement policy / processes, some require specific referencing to support automatic invoice processing. C1 should be capable of storing and providing this information as required by their trading partners. 

Note: Peppol also supports referencing to one or multiple preceding invoice, e.g. an invoice that adjusts or replaces an invoice that was sent previously (cac:Billing Reference). 

Although this field is not essential for invoice processing by C4, C1 should not use the same invoice number when it adjusts or replaces an old invoice, as it will be detected as a 'duplicate' and may cause processing delays or rejection. 

8. Other Supporting Documents and Attachments

Attachments (e.g. PDF or images) are supported by Peppol. It is desirable for service providers to support this capability as suppliers may need to attach supporting documents such as timesheets. 

URLs are not recommended for security reasons. 

Note: the attachments should only include documents that support the processing of an invoice. Other documents that are not directly related to invoice-processing (e.g. full copy of contract), were out of scope. 

Currently, there is demand from customers to include a PDF version of the invoice while they adjust to the e-invoicing process (i.e. a visual presentation of the invoice). It is often used as a trust mechanism and is expected to be phased out in the future.