Peppol BIS Billing 3.0 for Developers: What to Build

An invoice can look completely correct inside an ERP, billing platform, or SaaS application and still fail when it reaches a trading partner through the Peppol network. The problem is often not broken XML. It is a missing buyer reference, an incorrect electronic-address scheme, unreconciled totals, an unsupported VAT category, or a country-specific rule the application was never built to handle.

That is the real implementation challenge behind Peppol BIS Billing 3.0. The standard gives developers a common framework for turning invoice data into structured, interoperable UBL documents that can be exchanged through Peppol. But generating XML is only one part of the job. A reliable integration also needs accurate ERP-to-UBL mapping, valid Peppol participant IDs, controlled code lists, Schematron validation, recipient discovery, error handling, and a way to keep pace with evolving Peppol and local compliance rules.

What does Peppol BIS billing 3.0 actually cover?

Peppol BIS Billing 3.0 is a Core Invoice Usage Specification based on EN 16931, the European standard for electronic invoicing. It defines how developers should structure EN 16931-compliant invoice data in UBL 2.1 XML for interoperable exchange through the Peppol network. Its core Peppol document types are the seller-issued Invoice and Credit Note.

The specification covers the invoice payload rather than the entire Peppol ecosystem. In other words, it tells your application what invoice data to include, how to structure it, which code lists to use, and what validation rules to meet. It does not independently define Access Point operations, network transport, or recipient discovery.

For a developer, that distinction matters:

• Peppol BIS Billing 3.0 defines the UBL invoice structure, business terms, cardinalities, VAT data, code lists, and validation rules.
• Peppol eDelivery enables secure document exchange between the sender’s and recipient’s Access Points.
• Participant discovery identifies whether a buyer can receive a specific document type and where it should be delivered.
• National rules can add local requirements on top of the core Peppol billing standards.

A Peppol invoice is therefore not simply a PDF sent digitally. The invoice must contain structured, machine-readable data, typically UBL XML, and comply with the relevant EN 16931, Peppol BIS Billing 3.0, and country-specific requirements. Peppol is widely used in European e-invoicing ecosystems, including Belgium, Norway, Sweden, and the Netherlands, but each country can apply the framework differently.

Which UBL invoice and credit note elements are required?

Peppol invoices use UBL 2.1 as their underlying document syntax. Your generator must create either an invoice or UBL Credit Note root document and populate the business terms required by the applicable Peppol BIS Billing rules.

At a minimum, developers should plan to map the following UBL elements:

A typical invoice header begins with elements such as:

<cbc:CustomizationID>

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

</cbc:CustomizationID>

<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>

<cbc:ID>INV-2026-0042</cbc:ID>

<cbc:IssueDate>2026-02-14</cbc:IssueDate>

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>

Credit notes follow the same general structure, but use a CreditNote root element, CreditNoteTypeCode and CreditNoteLine instead of their invoice equivalents.

Do not copy internal ERP accounting conventions directly into UBL. For example, negative credit-note values may not always translate directly to the required Peppol structure. Validate the complete document against the applicable BIS Billing rules, including payment requirements such as providing a due date or payment terms when the payable amount is positive.

What code lists and Peppol IDs do you need?

Most failed e-invoicing Peppol integrations begin with a data problem, not a transport problem. An ERP may store a VAT number, customer name, and tax rate but Peppol expects a correctly qualified endpoint identifier, a valid tax category, and controlled values from relevant code lists.

Key code lists include:

• ISO 3166 alpha-2 country codes for party and delivery addresses.
• ISO 4217 currency codes for document currency and monetary values.
• UNCL1001 invoice type codes for invoices and credit notes.
• UNCL5305 VAT category codes, restricted by EN 16931 and Peppol rules.
• Electronic Address Scheme (EAS) codes for the schemeID attribute of EndpointID.

A Peppol participant identifier is commonly represented as a scheme plus identifier value, such as 0088:1234567890123. In the UBL document, however, map the identifier value into cbc:EndpointID and the scheme separately into its mandatory schemeID attribute.

xml

<cbc:EndpointID schemeID="0088">1234567890123</cbc:EndpointID>

Both seller and buyer electronic addresses are required. The scheme must come from the maintained Electronic Address Scheme list, otherwise validation can fail with errors including BR-CL-25 and PEPPOL-EN16931-CL008.

Build this as a governed data service, not a manually maintained free-text field. A sound implementation will:

• Store the buyer’s registered endpoint and scheme separately.
• Validate endpoint formats before sending the first live invoice.
• Maintain country and scheme-specific lookup logic.
• Refresh recipient capabilities through your Access Point or service metadata process.
• Avoid deriving identifiers from a VAT number unless the relevant scheme explicitly supports that value.

How to validate Peppol BIS billing 3.0 invoices across country rulesets

Peppol BIS Billing 3.0 validation goes beyond checking whether your UBL XML is technically valid. Your invoice must also meet EN 16931 business rules, Peppol requirements, controlled code-list rules, and any applicable country-specific validation rules.

Use this four-step workflow before sending a document through a Peppol Access Point:

1. Validate the UBL XML structure
   Run UBL 2.1 XSD validation to confirm that the document is well formed and uses the correct Invoice or CreditNote structure.
2. Apply Peppol and EN 16931 rules
   Use Schematron validation to check totals, VAT calculations, mandatory endpoint IDs, code lists, and conditional fields such as payment details.github+1
3. Apply country-specific invoice rules
   Check the national rules relevant to the seller’s country and transaction. These may add local requirements for tax identifiers, buyer references, public-sector routing, or invoice data.
4. Validate before transmission
   Run all applicable checks before submitting the invoice. Store validation results, error codes, ruleset versions, and rejected XML so your team can correct and resend documents efficiently.

Common validation failures include unreconciled invoice totals, missing schemeID values for buyer or seller EndpointID, invalid VAT categories, incorrect VAT breakdowns, and missing payment terms or a due date where the payable amount is positive.

What message types does BIS 3.0 support in the Peppol exchange model?

BIS Billing 3.0 itself covers Invoice and Credit Note documents. Related Peppol specifications support adjacent workflows, including Self-Billing, Invoice Response, and Message Level Response. Do not describe these as four message types inside BIS Billing 3.0, they are separate but connected specifications in the wider ecosystem.

The standard Peppol exchange uses a four-corner model:

• Corner 1: The supplier or document sender.
• Corner 2: The sender’s Peppol Access Point.
• Corner 3: The receiver’s Peppol Access Point.
• Corner 4: The buyer or receiving organisation.

Do not treat invoice delivery as a single synchronous API call that ends when you upload XML. Capture submission status, technical delivery outcomes, retryable failures, and in workflows that support it business-level Invoice Response messages.

This is where Peppol compliance requirements become operational rather than theoretical. A document can pass your internal generator and still fail because a recipient’s country rules, endpoint configuration, or permitted document process differs from your assumptions.

Accelerate BIS 3.0 compliance with a unified e-invoicing API

For software teams, the challenge is not simply generating UBL XML. It is maintaining the compliance layer around it, endpoint handling, validation rules, code-list updates, country-specific requirements, archiving and invoice delivery. DDD Invoices provides an API-first infrastructure layer that helps ERP, accounting, CRM, payment and SaaS platforms manage these requirements without building and maintaining separate compliance connectors for every market.

With DDD Invoices, platforms can send normalised invoice data through a single integration and handle structured XML generation, local compliance transformations, invoice lifecycle management and Peppol exchange where applicable. This reduces the ongoing maintenance burden and helps keep invoice workflows aligned as Peppol specifications, code lists, trading-partner requirements and local e-invoicing rules change. 

FAQs

What is Peppol BIS 3?

Peppol BIS 3 refers to the Peppol Business Interoperability Specifications version 3 family. Peppol BIS Billing 3.0 is the billing specification for structured Invoice and Credit Note documents based on EN 16931 and UBL syntax.

What is the Peppol invoice format?

The Peppol invoice format for BIS Billing 3.0 is a structured UBL 2.1 XML Invoice or Credit Note that follows EN 16931 semantic requirements and Peppol-specific business rules. A standalone PDF is not, by itself, a Peppol BIS Billing 3.0 invoice.

What Peppol document types should developers support?

For core billing, support UBL Invoice and UBL Credit Note. Consider related documents such as Self-Billing Invoice, Self-Billing Credit Note, Invoice Response, and Message Level Response only when the relevant business workflow requires them.

How do I validate a Peppol BIS Billing 3.0 invoice?

Validate the XML structure, then apply the current Peppol BIS Billing 3.0 Schematron rules and any relevant country-specific rules. Check mandatory endpoint IDs, EAS schemeID values, code lists, VAT logic, totals, payment details, and recipient-specific requirements before transmission.