Until today, when the platform on the other side answered your invoice — received it,
accepted it, refused it, paid it — the answer had no address to reach you at, and your
invoice stayed delivered whatever happened next.
What changed
A Peppol participant declares which document types it accepts. Ours declared invoices, and not the document that carries a recipient's answer, the Invoice Response. So nobody could send us one. Not by refusal — by absence of an address.
Every legal entity now declares both, at creation. Entities that predate the change are brought in line as well; in production that is already done.
What you may see now
Statuses that could never arrive before:
invoice.accepted— your recipient accepted the invoiceinvoice.refused— your recipient refused itinvoice.paidandinvoice.partially_paidinvoice.under_query,invoice.conditionally_accepted
The full per-axis state travels on invoice.status_changed, which is opt-in: the *
wildcard deliberately does not match it, so subscribe to it explicitly if you want it.
One existing event changed meaning
invoice.error used to mean one thing: we could not deliver the document. It can now
also mean the recipient's accredited platform received it and then rejected it — in
France, Rejetée, code 213. Both are final, and both ask for the same thing: fix the
document and send it again.
If your handler re-sends automatically on invoice.error, this is the one place to
look. A resend after a business rejection reaches the same recipient twice.
detail.platformFiscal on the invoice tells the two cases apart: a delivery failure
carries no national code, a platform rejection does.
France
This is what makes the French lifecycle reachable. The CDAR — the document that carries
a French status — is mandatory to receive under the French reform, and it travels on the
same capability. A fr:213 issued by an accredited platform now lands on your invoice as
failed, with detail.platformFiscal reading 213 / Rejetée, while the delivery axis
keeps the receipt it earned.