Why a valid invoice can still fail on Peppol
Passing XML validation is not enough. Routing, registration, and provider state can still block delivery. This page explains the gap.
What is usually actually broken
The delivery problem sits outside the XML payload itself.
Do these before you resend
- Separate document issues from routing issues.
- Check participant lookup evidence and provider symptoms together.
- Use the analyzer before escalating to support.
What people ask right before they get blocked
Participant resolution, network capability, provider state, and access-point configuration all sit outside basic XML validity.
Teams lose hours escalating the wrong failure class when a route problem gets mistaken for a document problem.
Go one level deeper before you resend
A fast decision guide for operators who need to know whether the next step is a resend, a partner-record fix, or a provider ticket.
Read the guideA practical guide for missing CustomizationID, profile markers, and other export-level metadata that leave XML looking valid but unusable in Peppol workflows.
Read the guideSimilar failure patterns worth checking
A Peppol invoice can contain the business data and still fail because the export is missing the profile marker tools expect to classify it correctly.
Open issue pageMulti-company setups, duplicates, and restored databases can leave Odoo pointing at the wrong Belgian participant even when the invoice itself looks fine.
Open issue pageIf Odoo marks an invoice as sent while the customer sees nothing, you are usually dealing with routing, registration, or access-point issues rather than broken invoice content.
Open issue page