A calm, ordered checklist for Belgian Odoo users when Peppol starts failing without a clear explanation.
If the XML is present and Odoo says sent, do not assume the document is the problem. Most Belgian failures start with identifiers, stale registrations, or access-point state.
Look for the exact symptom first: sent but not delivered, invalid signature, or partner not found.
Check the recipient as a full Peppol participant identifier, not just a company name.
For Belgian companies, compare the enterprise-number route under 0208 against any VAT-number route under 9925.
Bring the participant ID, the symptom text, and the last send attempt together before opening a support ticket.
That turns a vague support request into a provider-ready incident.
If 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 pageThe revalidation prompt usually signals stale participant metadata or a registration mismatch. This page shows what to refresh before you resend.
Open issue pageAn invalid request signature is usually a provider credential or environment problem, especially after database copies or restores.
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 pageRestores and cloned environments often leave Odoo Peppol bindings out of sync. This page isolates the exact symptoms that usually follow and how to recover cleanly.
Open issue pageThis exact Odoo Peppol message usually appears after a restore, duplicate database, or half-reset receiving setup. The result is a blocked receiving registration and a sender-only fallback that still does not restore the real workflow.
Open issue pageThis contradiction usually means Odoo has the wrong identifier, wrong scheme, or stale participant evidence. This page breaks down the mismatch clearly.
Open issue pageThis exact Odoo message usually means the ERP is validating the wrong participant identity, stale evidence, or the wrong identifier scheme rather than proving the customer is truly unavailable.
Open issue pageIf Odoo marks every customer as not on Peppol all at once, treat it as an environment or provider incident first, not a data-cleanup job on every partner record.
Open issue pageBranch setups and commercial-company relationships can send Peppol traffic through the wrong legal entity. This page isolates the exact binding problem and how to correct it.
Open issue pageIf Odoo's endpointverification flow says a customer is not on Peppol while other evidence shows they are, the mismatch is usually in the exact route Odoo is verifying rather than in the customer's existence.
Open issue pageWhen Odoo or the verification path fails on the upstream ISO6523 resolver host, it looks like every customer is wrong even though the real problem is infrastructure or resolver state.
Open issue pageBeing listed in the Peppol directory is not always enough to receive invoices. This page isolates the Odoo receiving-side failures that leave inbound invoices stuck even after registration.
Open issue pageGuides are useful when the pattern is familiar. When the latest failure still feels fuzzy, run the analyzer with the exact provider message or XML so you can separate routing, profile, and provider-state problems.