At first glance, sending an electronic invoice seems simple. The supplier creates a structured file, sends it to the customer, and the financial system processes the data automatically.
In practice, however, this requires much more than just an XML format.
Two systems can both support UBL and still make different choices. Which data fields are required? How is an organization identified? Which VAT codes may be used? How are rounding rules calculated? Where is the order reference located? And when is an invoice technically correct but still invalid in terms of content?
Peppol BIS Billing establishes concrete agreements for these types of questions.
The specification serves as an important foundation for electronic invoicing via Peppol in Europe. It brings together various standards and agreements, so that the sender and recipient do not have to redefine what an invoice should look like for every individual integration.
1. What is Peppol BIS Billing?
BIS stands for Business Interoperability Specification.
A Peppol BIS describes how organizations should use electronic messages within a specific business process. For invoicing, this is Peppol BIS Billing.
The specification focuses on the exchange of electronic invoices and credit memos between supplier and customer. It not only describes what data can be included but also specifies which information is required, which values are permitted, and what relationships exist between data elements.
Peppol BIS Billing is therefore neither a transport protocol nor a standalone file format.
It is a set of agreements built upon existing standards.
EN 16931 defines the semantic model of the European core electronic invoice.
UBL provides the technical XML structure in which that data can be recorded.
Peppol BIS Billing specifies how that data must be used within the invoicing process.
Peppol also provides the network and set of conventions that enable the final message to be exchanged between organizations.
2. Why isn’t UBL alone sufficient?
UBL is a comprehensive standard.
That’s an advantage, because the same language can be used for many different types of business documents and applications. But that flexibility also creates a problem.
When two organizations say they support UBL invoices, that does not automatically mean their systems expect the same data to be included.
UBL contains many elements, only some of which are required for a specific invoice. Furthermore, certain data can be included in different ways.
Technically, different files can all be valid UBL.
This is insufficient for reliable system-to-system processing.
That is why implementation specifications are needed to further limit and clarify the possibilities of UBL.
Peppol BIS Billing does exactly that.
For example, the specification defines:
- which information is required;
- which information is optional;
- how data is structured in UBL;
- which code lists may be used;
- which calculations must be correct;
- how parties are identified;
- and which business rules apply to the document.
3. EN 16931 defines what constitutes a European e-invoice
A second important component of Peppol BIS Billing is EN 16931.
This European standard was developed to establish a common semantic model for electronic invoices.
Semantics is all about meaning.
For example, if a field contains the total amount excluding VAT, all involved systems must understand that this field has exactly that meaning. The same applies to the invoice date, VAT amount, payment account, supplier, customer, and other data elements.
EN 16931 describes this information as business terms.
It thus primarily defines what business information is intended, not how that information should be technically written in XML.
UBL then handles the syntax.
Peppol BIS Billing connects the two.
4. A Peppol invoice must comply with business rules
One of the most important features of Peppol BIS Billing is that validation goes beyond simply checking whether an XML file is technically correct.
After all, an XML file can perfectly comply with the UBL schema and still contain an invalid invoice.
For example, suppose an invoice contains the following amounts:
Net: €1,000
VAT 21%: €210
Total including VAT: €1,190
The XML structure may be completely correct, while the calculation itself is incorrect.
Peppol therefore uses business rules.
These rules can, for example, check:
- whether required data is present;
- whether amounts have been calculated correctly;
- whether VAT categories are used consistently;
- whether permitted codes are used;
- whether a currency is valid;
- whether totals match the underlying invoice lines;
- and whether certain data fields become required as soon as a different value is used.
Within the specification, Schematron validations, among other methods, are used for this purpose.
These checks are an essential part of interoperability.
5. The Peppol BIS Billing standard also standardizes identification and references
An electronic invoice consists of more than just amounts.
To process a document automatically, the receiving system must also be able to reliably determine who the supplier and customer are and which transaction the invoice pertains to.
That is why Peppol places great emphasis on identification.
For example, parties can be identified using identifiers from standardized schemas. The specific identification schema used is also specified, ensuring that not only is a number sent, but it is also clear how that number should be interpreted.
An invoice may refer to:
- an order;
- a contract;
- a previous invoice;
- a project;
- a delivery location;
- or a specific contact person or department.
Within the semantic model, every relevant reference has its own meaning.
This is important for automated processing.
6. Peppol BIS Billing and PINT: International Standardization
Peppol has now expanded far beyond Europe.
Countries outside Europe also use Peppol for electronic document exchange. If every country were to develop its own completely distinct variant of Billing, fragmentation would arise once again.
That is why OpenPeppol has developed the Peppol International Invoice, PINT.
PINT provides a common model on which regional or national specifications can be based. The goal is to ensure that the same fundamental invoice structure remains usable internationally, while allowing countries to add supplementary rules where necessary.
That is why PINT-EU exists for Europe.
This does not mean that every invoice worldwide is completely identical. Local VAT laws, business identification, and reporting requirements may differ.
The model is structured as follows:
international core → regional or national specialization → local validation rules
This approach is becoming increasingly relevant as electronic invoicing becomes mandatory in more and more countries.
7. Peppol BIS Billing as the foundation for automated invoice processing
Ultimately, the greatest value of Peppol BIS Billing lies not in sending the invoice, but in what can be done with it automatically afterward.
A received invoice can first be validated against the agreed-upon technical and content-related rules.
The financial system can then determine which supplier the invoice belongs to, check whether an order reference is present, compare amounts, and link the invoice to an existing purchase order or receipt.
When all data matches, a large portion of the processing can take place automatically.
This shifts invoice processing from recognition to validation.
With a PDF, the first step is to determine what is on the document. OCR and document recognition, for example, attempt to find the invoice number, total amount, and order number.
With a Peppol BIS Billing invoice, the meaning of that information is already defined.
As a result, the system has less to interpret and can perform more deterministic checks.
That does not mean, however, that every company will receive only Peppol invoices.
In practice, various channels and formats coexist: Peppol, UBL via other channels, DICO, EDI, API, SFTP, and still PDF via email.
An integration layer such as 4CEE Exchange can bring these different streams together. Messages can be received, validated for both technical and content-related aspects, converted, and then presented to the financial or ERP system in a format that can be processed directly there.
Peppol BIS Billing plays an important role in such a landscape because the specification eliminates uncertainty from data exchange.