Peppol invoice errors: 10 causes and fixes

Peppol provides a standardized infrastructure for exchanging electronic invoices and other business documents. But standardization does not mean that every transaction will work automatically.

An invoice can fail because its data is invalid, the recipient cannot be found, the wrong business process is used or the buyer rejects it after delivery. In enterprise environments, the underlying cause may sit anywhere between the ERP, invoice mapping, master data, Peppol discovery services and the Access Point.

This guide explains ten common Peppol invoice errors. Each section starts with the practical problem in plain language and then examines the relevant technical details for enterprise and ERP integration teams.

Technical scope: Reviewed against Peppol BIS Billing 3.0 version 3.0.21 and the OpenPeppol eDelivery specifications available in August 2026. Country-specific requirements and specifications continue to change.

Before troubleshooting, determine where the failure occurred.

These failures require different responses. Resending an unchanged invoice will not correct invalid data. Changing the invoice will not help if the recipient’s Peppol registration is incomplete. A successful transport receipt does not mean the buyer has approved the invoice.

A Peppol ID works like a network address, but entering the right organization number is not always enough. The identifier must use the correct scheme and exactly match the identifier under which the recipient is registered.

A seemingly minor difference—such as the wrong prefix, a removed leading zero or use of a VAT number instead of a national business identifier—can prevent Peppol from finding the recipient.

Store the Peppol identifier as controlled master data rather than free text. The identifier scheme and value should be held separately and validated before invoicing.

Before sending:

A company can be present in Peppol without being able to receive every type of Peppol document.

For example, a recipient may be registered to receive standard Peppol BIS Billing invoices but not a particular PINT invoice, ordering message or business process. The Peppol ID is valid, but the requested receiving capability is not available.

Do not treat registration as a simple yes-or-no attribute in the ERP. The relevant question is whether the recipient can receive the exact combination of document type and business process being sent.

Your integration should:

Even when the invoice and Peppol ID are correct, the network may temporarily look in the wrong place.

This can happen when a company changes Peppol service provider, when old routing information remains cached or while changes are being propagated. The sender may see an error suggesting that the recipient does not exist, although the actual problem concerns outdated discovery information.

ERP applications should not attempt to reproduce the complete Peppol discovery process themselves unless this is a deliberate part of the product architecture. Discovery, certificate validation, routing and retry handling are normally better managed by the Peppol service provider.

ERP and enterprise teams should still ensure that:

Every Peppol invoice states which rules it follows and which business process it belongs to. If these identifiers are missing or incorrect, the receiving system cannot safely interpret the document.

This often happens when an ERP exports an old invoice template, a converter inserts the wrong value or a mapping designed for one country or process is reused elsewhere.

Profile and specification identifiers should be centrally controlled. They should not be editable by users or reconstructed separately in every ERP connector.

For multi-market environments:

The invoice needs information that tells the buyer who ordered the goods or which purchase order the invoice belongs to.

Without that reference, the buyer may not know where to route the invoice. Peppol therefore requires either a buyer reference or a purchase order reference.

Adding “N/A” may make the field look complete, but it does not give the buyer usable information.

Capture the required reference before the invoice is created. Do not rely on accounts receivable teams to repair missing information after the invoice has failed.

A scalable process should:

An invoice can contain the correct total amount but still fail because the VAT information does not make sense.

The selected VAT category, VAT rate and exemption reason must agree with one another. Additional national requirements may apply depending on the countries involved.

Do not treat VAT as a formatting issue handled by the invoice converter. Tax determination should occur in the appropriate ERP or tax engine before the invoice is generated.

Enterprise controls should cover:

A structurally valid invoice is not necessarily based on the correct legal tax treatment. Uncertain tax scenarios should be reviewed by a qualified tax specialist.

The numbers on the invoice must add up according to defined calculation rules.

Problems often occur when the ERP, tax engine and invoice converter calculate the same values differently. A one-cent difference may be enough to cause a fatal validation error.

Use one documented calculation and rounding model throughout the invoice pipeline.

Pay particular attention to:

Always validate the final XML produced for transmission. Validating only the source ERP data will not detect errors introduced by the mapping or conversion layer.

A structured invoice is not a digital version of a paper invoice. Blank rows, visual separators and arbitrary text should not be converted into invoice lines.

Every field and line has a defined meaning. Using a field for something else may pass data to the buyer, but it prevents reliable automation.

ERP mappings should be semantic rather than visual. Map information according to what it means, not where it appears on a rendered invoice.

Common controls include:

A PDF or other file can be attached to a Peppol invoice, but the recipient should not have to open it to understand or process the transaction.

If the purchase order number, payment details, VAT information or line descriptions exist only in the PDF, the buyer loses much of the automation that structured e-invoicing is intended to provide.

Treat attachments as supporting material. Keep required and operationally important information in structured invoice fields.

Attachments may be appropriate for:

Also confirm media type, filename and size requirements. Service providers and receiving systems may impose operational limits even when the file type itself is supported.

“Delivered” does not mean “approved for payment.”

Peppol may successfully transport a technically valid invoice, but the buyer can still query or reject it because the price is incorrect, the purchase order does not match, goods have not been received or the wrong legal entity was invoiced.

ERP and finance users need more than a sent/failed status. The integration should distinguish:

Responses should be connected to the original invoice and presented in a way that enables the responsible team to act. Automatic retries must not create duplicate invoices.

Reliable e-invoicing requires more than generating valid XML. The complete process must manage:

For enterprise organizations, these capabilities should be centralized rather than rebuilt independently in every ERP, subsidiary or market.

For ERP and platform partners, Peppol connectivity should be exposed as a managed service with stable APIs, clear error categories and actionable responses. Users should not need to understand SMP records or Schematron rules to correct an invoice—but the integration must handle them correctly underneath.

Qvalia provides full Peppol connectivity for enterprises, ERP providers and software platforms through APIs and file-based integrations. The platform manages structured document exchange, participant discovery, validation, response messages, error handling and transaction traceability.

Explore the Qvalia Peppol Access Point.