Skip to main content

What the Peppol MLS means for your invoice

Every Peppol access point tells the access point that sent it a document what happened to that document. The answer is a Message Level Status, or MLS: a short, machine-readable status message that travels back over the network.

GoRoute handles the MLS on both sides for you. You never write one and you never send one. This page says what it means for the documents you send and for the documents you receive.

What an MLS says​

An MLS is about the message, not about the business decision: it tells the sender whether the document was taken in and handed over to the recipient. It is not your buyer approving or disputing the invoice; that would be an Invoice Response, which is a different document.

CodeMeaning
APAccepted: the document was delivered to the recipient, and the hand-over is confirmed
ABAcknowledged: the document was received and is valid; its hand-over to the recipient is not confirmed yet
RERejected: the document failed the receiving access point's checks or could not be delivered. The message says why

An MLS is addressed to the sender's service provider (for documents you send through GoRoute, that is GoRoute's own Peppol identity 0242:000991), never to you. GoRoute matches it to your document by the transmission message ID it quotes back.

When you send a document​

GoRoute asks the receiving access point to answer each document you send over the Peppol network, whether it went through or not, so you normally see AP (or AB) as well as RE. An access point that has not implemented the MLS yet sends no answer, so a document can get none at all. That is normal: your transaction's own status (delivered, with its AS4 receipt) is the proof of delivery, and an MLS never changes it.

When an answer does come, GoRoute sends it to the organisation that owns the document, as two webhook events naming your transaction: mls.received and the response.* event for its code (response.rejected for RE, response.accepted for AP, response.received for AB). Subscribe to them like any other event.

  • Only the first answer counts. That is the network's rule: if a second status message arrives for the same document, it is ignored and not sent to you.
  • Timing. The receiving access point is expected to send its MLS within 20 minutes of receiving your document, and the MLS to reach GoRoute within 25 minutes of the send. A rejection can still arrive later, and is sent to you when it does.
  • A rejection (RE) means the document did not get through in good order. The event's description carries the receiving access point's reason. Correct the document and send it again, and check with your buyer if you are not sure what they have.

Documents to and from Omani taxpayers follow Oman's own reporting flow, which has its own status messages and events; see the Oman country guide.

When you receive a document​

GoRoute checks each document that arrives for you against the Peppol rules for its type (the document's schema, then the Peppol business rules for that kind of document) before it hands the document over to you, and answers the sender's access point on your behalf:

The documentWhat happens to itWhat GoRoute sends back
Passes the checksHanded over to you: status delivered, your transaction.received webhook, and its content to downloadAP once your copy has been handed over (your transaction.received webhook delivered, or no webhook to deliver it to) if the sender asked for every answer, or AB if that hand-over is not confirmed within 15 minutes; nothing if the sender asked for failures only (the network's default)
Fails the checksRefused: status failed, error_code MLS_CORE_REJECTED, and the reason in error_message. No webhook is sent for it, and its content cannot be downloaded (409 DOCUMENT_REFUSED)RE, with every reason, so the sender can correct it and send it again

While a document is being checked it is listed in your transactions with status held. No webhook has been sent for it yet, and requests for its content answer 409 DOCUMENT_BEING_CHECKED: ask again shortly, or wait for the transaction.received webhook, which comes once the check has passed. If GoRoute cannot run the check for about 15 minutes, it hands the document over to you without it rather than keep it from you.

Documents addressed to Omani taxpayers follow Oman's own reporting flow and are handed over as they arrive.

You do not need to do anything for this. Two more things you may notice:

  • GoRoute's answers appear in your transaction list as documents sent from your account, of the eDEC MLS document type, addressed to the sender's service provider (an identifier that starts with 0242:), and in your Activity Feed. Their metadata names the document they answer (received_transaction_id) and the code sent (response_code). To keep them out of an invoice register, list transactions with exclude_reporting_legs=true; see Tracking Delivery.
  • They fire no webhooks. No transaction.* event is sent for GoRoute's own status messages, so your webhook endpoint hears only about your own documents.

Test and production​

Both GoRoute environments handle the MLS this way: the test environment (app-test.goroute.ai) since 9 October 2026, and production (app.goroute.ai) since 11 November 2026. A received document that fails the Peppol rules is refused: it is never handed over to the organisation it was sent to, and GoRoute answers the sender's access point with an MLS RE that gives the reasons.

For integrators: fix a refused document rather than retry it, because the same document is refused again. If you sent it through GoRoute, the refusal reaches you as the mls.received and response.rejected events on it. The sandbox recipients (9999:test-…) on the test environment are not affected: documents sent to them never leave GoRoute, and each keeps its fixed outcome.

Next steps​

Last updated on