Peppol BIS Billing 3.0 explained for invoice senders

The four-corner model

Peppol is not a website you send invoices to. It is a network of certified access points. You (corner one) hand an invoice to your access point (corner two), which looks up where the recipient receives documents, validates the file and delivers it to the recipient’s access point (corner three), which passes it to the recipient’s system (corner four). Every access point follows the same rules, so you can reach any Peppol receiver through one provider.

This is why a file from Draftbill is not “sent”. Draftbill produces the document; a Peppol access point, often offered by an accounting system or a bank, sends it.

What BIS Billing 3.0 is

Peppol BIS Billing 3.0 is a specification that tells senders how to fill in the European invoice standard EN 16931 in the UBL 2.1 XML syntax. It adds rules on top of EN 16931 (called a CIUS) that make files predictable for the receivers. Every file identifies itself with a customization identifier, urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0, and a profile identifier, urn:fdc:peppol.eu:2017:poacc:billing:01:1.0. Draftbill writes both.

Data Peppol insists on

Besides the invoice content, the Peppol rules require several things that ordinary PDF invoices do not carry:

• An electronic address (endpoint) for the seller and for the buyer, each with a scheme code from the Peppol Electronic Address Scheme list, for instance 0007 for a Swedish organisation number or 0208 for a Belgian enterprise number (rules PEPPOL-EN16931-R020 and R010).
• A buyer reference or a purchase-order reference (rule PEPPOL-EN16931-R003). Many public buyers route invoices by this value.
• The seller’s VAT identifier with the country prefix, where the seller is VAT-registered, a tax category and rate on every line, and a tax breakdown that adds up to the totals.
• No empty elements anywhere in the document (rule PEPPOL-EN16931-R008). Optional elements are omitted instead of left blank.
• Amounts with the same currency throughout, apart from the optional VAT amount in the tax currency.

Why files get rejected

Most rejections come from the same few causes: a missing buyer reference, a Peppol address the receiver is not registered under, a VAT number without a country prefix, a tax subtotal that does not equal the sum of its lines because of rounding, or an exemption category without a reason. Draftbill’s preflight check catches the first, third and last of these and calculates the tax with the EN 16931 rounding rules so totals agree.

Draftbill cannot check whether your customer is registered at the address you entered. Ask the customer for the exact identifier, or search the Peppol Directory.

What Draftbill validates and what it does not

Draftbill checks, in your browser, that every mandatory element of the specification is present with a value and that no element is empty. It does not run the full set of Peppol validation rules, the schematron, which access points apply. A file can therefore pass Draftbill and still be rejected by a rule that is not covered, especially national add-ons. Run the file through your access point’s validator, or through the validation tools published on the Peppol documentation site, before you depend on it.

Where Peppol is not the right format

Peppol BIS Billing 3.0 is not the working format everywhere. Italy routes domestic invoices through the Sistema di Interscambio in FatturaPA format, Poland through KSeF, France through approved platforms, and German public authorities often require XRechnung. Australia and New Zealand use a different Peppol customization (PINT A-NZ). The country pages say which situation applies.

Sources

• Peppol BIS Billing 3.0
• Peppol BIS Billing 3.0: UBL Invoice syntax
• Peppol Directory
• Peppol BIS Billing 3.0: rules