Peppol Readiness Checks

What this is for

Peppol addresses a party as scheme:identifier. The scheme — an EAS code — says what kind of identifier follows, and each has its own shape.

A well-formed address under the wrong scheme is the worst failure in e-invoicing: it delivers nowhere and reports nothing. Nobody notices until the customer asks where the invoice is.

Marking who uses Peppol

On the customer, tick Receives via Peppol. That turns the address checks into blocking ones for them, and leaves customers who take a PDF by email out of it.

The form then shows whether the address holds up and, when it does not, what is wrong with it in one sentence.

What is checked

• Shape per scheme — a GLN is 13 digits, a Belgian enterprise number is 10, Dutch VAT is NL + 9 digits + B + 2, Italian VAT is IT + 11, and so on for the schemes that turn up in European trade. A scheme with no rule here is left alone rather than assumed wrong.

• Country sanity — a Belgian VAT scheme on a German customer is usually a copy-paste. Only a warning: a group filing through one entity is a real arrangement.

• Our own address — receivers check the sender, and a company that sends without being reachable itself gets answers nowhere.

One pass over the customer list

Accounting ▸ Configuration ▸ Peppol Readiness rechecks every customer marked as receiving over Peppol and opens the ones that would not deliver. Onboarding onto Peppol is a data-cleaning job, and it is far cheaper in one pass than one rejected invoice at a time.

Known limits

• The shape is checked, not the existence. Only the Peppol directory can tell you whether a participant is actually registered — and core Odoo's account_peppol does that lookup where it is available.

• On 16.0 the two addressing fields do not exist in core, so this app declares them under the same names core uses from 17.0. A database upgraded later finds its data where Odoo expects it.