Peppol BIS Billing explained: what is inside an e-invoice

A Peppol BIS Billing 3.0 e-invoice is an XML file in UBL 2.1. It opens with two identifiers naming the rules it follows, then holds the header, seller and buyer, payment details, VAT totals and lines, each in a fixed element the receiver's software reads.

BIS stands for Business Interoperability Specification. OpenPeppol, the association behind the Peppol network, publishes it at docs.peppol.eu together with the syntax reference, the validation rules, the code lists and sample files. Hardly anyone writes this XML by hand, since invoicing software produces it. Knowing what sits inside still pays off when an invoice bounces, or when a customer's accounts team asks why a particular value matters.

Where the specification comes from

The European standard EN 16931 describes the meaning of an invoice's contents. Peppol BIS Billing is a CIUS of that standard, a core invoice usage specification: it keeps the standard's model, narrows a few choices and adds rules for the network. The background on the standard itself is in what EN 16931 is, and how the Peppol network works covers the delivery side.

OpenPeppol updates the documentation in periodic releases, each named after its month. A release can add or adjust rules and code lists, so invoicing software keeps up with them over time.

The file, block by block

An invoice file follows the order of the UBL schema. These are the blocks you will meet when you open one:

Block	UBL element	What it holds
Identifiers	cbc:CustomizationID, cbc:ProfileID	The specification and the business process the invoice follows
Header	cbc:ID, cbc:IssueDate, cbc:DueDate, cbc:InvoiceTypeCode, cbc:DocumentCurrencyCode	Number, dates, kind of document and currency
References	cbc:BuyerReference, cac:OrderReference	The reference the buyer asked for, or their order number
Seller	cac:AccountingSupplierParty	Name, address, VAT number and electronic address
Buyer	cac:AccountingCustomerParty	The same details for the customer
Delivery	cac:Delivery	Where and when the goods or services were provided, when given
Payment	cac:PaymentMeans, cac:PaymentTerms	How to pay: a payment means code, the account, the payment reference and the terms
Allowances and charges	cac:AllowanceCharge	Discounts or surcharges on the invoice as a whole
VAT	cac:TaxTotal with cac:TaxSubtotal	The VAT total and a breakdown per VAT category and rate
Totals	cac:LegalMonetaryTotal	Sum of lines, totals without and with VAT, any prepaid amount, the amount due
Lines	cac:InvoiceLine	Quantity, unit, net amount, item, price and VAT category for each line
Attachments	cac:AdditionalDocumentReference	Supporting documents embedded in the file

The seller and buyer blocks each carry a cbc:EndpointID, the party's electronic address on the network, with a schemeID attribute taken from the Electronic Address Scheme code list. Which values a business needs to collect is covered in identifiers and required fields for Peppol.

The two identifiers at the top

Before a receiver looks at amounts, it reads two values that say which rule set applies. For Peppol BIS Billing 3.0 they are:

• Customization ID (the specification): urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0
• Profile ID (the business process): urn:fdc:peppol.eu:2017:poacc:billing:01:1.0

The specification notes that these strings contain no spaces. A stray space or an outdated value is enough for a file to be refused, which is why software fills them in rather than people.

Invoice or credit note

UBL has two separate document types, so a Peppol invoice and a Peppol credit note have different root elements and namespaces: Invoice in urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 and CreditNote in urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2. Inside, the type code tells them apart: 380 for a commercial invoice and 381 for a credit note. Other codes exist, and the specification maps each onto one of these two. A seller can also credit with a negative invoice; the specification supports both routes.

How the rules check a file

A Peppol invoice is checked in layers, and each rule has an identifier you will see in error messages:

1. Syntax. The file must be valid against the UBL schema: right elements, right order, right data types.
2. EN 16931 rules. Identifiers starting with BR check the standard's business logic, for example that the totals add up and that both electronic addresses have a scheme.
3. Peppol rules. Identifiers such as PEPPOL-EN16931-R001 or PEPPOL-COMMON-R040 add the network's own constraints.
4. Country rules. Some countries add checks that apply to their own sellers, with identifiers that carry a country prefix, such as DE-R for Germany.

OpenPeppol publishes these rules as Schematron files, so any software can run the same checks. In practice the sending side normally validates a file before it goes out, and a file that breaks a rule is refused with that rule's identifier. Once an invoice is delivered, the receiver can also answer with a status message; message level responses explain those replies.

Numbers, rounding and the VAT breakdown

• Two decimals for amounts. Document-level amounts and each line's net amount are rounded to two decimals. Unit prices and quantities may carry more.
• A breakdown per rate. The specification asks for one VAT breakdown for each distinct combination of VAT category and rate, so an invoice with two rates carries two subtotals.
• Discounts in two places. An allowance or charge in the header applies to the whole invoice; one on a line changes that line's amount.
• Rounding the amount due. A separate payable rounding amount lets a seller round the final figure without bending the totals above it.

Sums that do not reconcile after rounding are a common reason for a rejected file, which is why invoicing software calculates these values rather than copying them from a PDF.

Attachments travel inside the file

A timesheet or a signed delivery confirmation does not go as a separate email. It is embedded in the XML as a binary object, with a MIME code and a filename that are both mandatory, and receivers are expected to accept the media types on the specification's list. That keeps the invoice and its evidence together from sender to receiver, a point the difference between a PDF and an e-invoice also touches on.

National variations

Peppol BIS Billing is one specification shared across many countries, with country rules for the details that differ. Some countries take a different route and run national platforms with a structured format of their own; Poland's KSeF is one example. Before invoicing abroad, check which format and channel the buyer's country expects, and whether your Peppol access point handles it.

Frequently asked questions

What does BIS stand for in Peppol BIS Billing?

Business Interoperability Specification. It is the name OpenPeppol gives to its specifications for documents on the network, and Billing is the one for invoices and credit notes.

Is Peppol BIS Billing the same thing as EN 16931?

Not quite. EN 16931 is the European standard for the contents of an electronic invoice. Peppol BIS Billing builds on it as a usage specification, keeps its model and adds Peppol's own rules, so a valid Peppol invoice also meets the standard.

What is the difference between the customization ID and the profile ID?

The customization ID names the specification the invoice follows, here Peppol BIS Billing 3.0 on top of EN 16931. The profile ID names the business process, which for ordinary invoicing is the billing profile. Receivers read both before anything else in the file.

How can I read a Peppol XML invoice without special software?

OpenPeppol's documentation offers an XSLT stylesheet and an HTML viewer that turn the XML into a readable page, along with sample files to compare against. Many e-invoicing tools also show a readable view of every incoming and outgoing invoice.