The invoice was not delivered
A send can fail in three different places, and the message you get says which one. Read it before changing anything, because the fix for each is different: the receiver's registration, the receiver's server, or the document itself.
The receiver's registration
These mean the network could not tell where to deliver the document. Nothing is wrong with your invoice.
"The receiver is not registered for the specified document type in the Peppol network." The participant exists, but has not published the document type you are sending. A company registered only for orders cannot receive invoices, and a company registered only for Peppol BIS cannot receive a French CIUS document. Ask your partner which document types their provider published for them.
"The receiver supports the document type, but publishes no endpoint for the process and transport profile this document was sent with." Either their registration is incomplete, or the document went out under the wrong process. This one is worth sending to support with the invoice number, because it can be a mismatch on either side.
"The receiver participant is not registered in the Peppol network." The identifier itself is unknown. Check it character by character against what your partner gave you, and remember that a French participant identifier is the scheme 0225 plus the SIREN.
"The receiver is not registered in the Peppol network — the DNS lookup for its SMP returned 'no such name'." Same conclusion, reached through DNS: the identifier is not on the network.
"The receiver's participant ID could not be turned into a valid DNS name." The identifier is malformed. It has to be written as scheme and value, for instance 0225:271688503.
"The SMP request was rejected." The participant identifier or the document type identifier has a format problem.
The receiver's server
These are not your problem to fix, and most of them resolve on their own.
| Message | What it means | Retried automatically |
|---|---|---|
| Connection timed out | Their access point did not answer in time | Yes |
| Could not establish a connection | Their endpoint is down | Yes, transient cases |
| No AS4 signal message received | The document went out, no acknowledgement came back | Yes |
| The hostname could not be resolved | The endpoint URL published in their SMP is wrong | No |
| SSL/TLS handshake failed | Certificate mismatch on their side | No |
| The remote access point returned an error | They received it and refused it | No |
| DNS lookup failed temporarily | Their SMP could not be located right now — their registration is not in question | Yes |
Where the table says the send is retried, wait before doing anything: a second manual send can produce a duplicate at the receiver. Where it says no, the receiver has to fix their side; send them the message text as it stands, since it names the exact fault.
The document itself
"Required parameters are missing or invalid." Sender identifier, receiver identifier, document type or process is missing. This is a document problem, not a network one — reopen the invoice and complete it.
"Invoice already sent via Peppol." The document left the platform earlier. Look at its lifecycle before sending again; a genuine correction is a credit note or a corrective invoice, not a second send.
French lifecycle rejections
On the French route the PPF can also refuse a document after it was accepted for transmission. The reason code tells you whether you have anything to do:
| Code | Meaning | Your action |
|---|---|---|
REJ_SEMAN | Format or semantic error | Correct the document and resubmit |
REJ_COH | Data consistency error — tags or referential values disagree | Correct the data and resubmit |
REJ_UNI | Duplicate submission, already processed | None; the first submission stands |
REJ_PER | Period mismatch in a report | None; handled on the platform side |
Other rejection codes (REJ_ADR, REJ_HAB, REJ_RG) appear as a plain rejection. Those concern the address, the authorisation or a business rule at the PPF, and support can read the raw rejection for you.
221 ERREUR_ROUTAGE is a routing error: the PPF could not resolve the recipient. Check the buyer's identifier, and whether the establishment you addressed exists as an active line in the directory.
"My supplier says they sent it, but I do not see it"
Look from the receiving side before assuming it was lost.
- Check the company selector at the top of the screen — an invoice addressed to another of your companies will not appear under this one.
- Widen the Registration Date filter on Purchases Invoice; it defaults to a narrow range.
- Ask the supplier which participant identifier they sent to, and compare it with the ACTIVE registration on Register e-Invoice. An invoice addressed to an identifier you own but have not activated does not arrive.
- Ask them for the tracking or message identifier from their own platform. With that, support can tell whether the document ever reached us.
A supplier can also have sent to an identifier that once belonged to you and is no longer registered — a removed registration, or one migrated to another provider. Their platform will have accepted the send and the document will have gone nowhere.