Status messages | eConnect

Status messages are the mechanism through which the recipient of an invoice automatically feeds back the processing status to the sender. Via the Peppol network, the supplier receives a status message (Invoice Response) indicating whether the invoice has been received, is being processed, approved, or paid. eConnect has supported status messages since 2015.

How do status messages work?

The principle is straightforward: after receiving an e-invoice, the receiving organisation sends an Invoice Response back to the sender. This message contains a status code indicating the processing stage the invoice is in.

The Invoice Response message travels through the same Peppol network as the original invoice, but in the opposite direction. The sender receives the message automatically in their eConnect environment and sees the status appear alongside the relevant invoice.

Tip: to receive Invoice Response messages as a sender, your organisation must be registered for receiving Invoice Responses. This requires an SMP configuration with the capability invoiceResponse set to on.

Status codes

Every Invoice Response contains a status code indicating the processing stage. The statuses form a logical sequence, from initial receipt to full payment.

Code

Status

Meaning

Acknowledged

The invoice has been received and is readable. This is the first confirmation that the invoice arrived correctly.

In Process

The invoice is being processed by the recipient. Assessment is still ongoing.

Under Query

There is a question about the invoice. The recipient needs additional information from the supplier before processing can continue.

Conditionally Accepted

The invoice has been conditionally accepted. There are minor points of attention, but the invoice is in principle approved.

Rejected

The invoice has been rejected. This is a final status. The recipient indicates that the invoice will not be processed. The supplier must take action, for example by sending a new invoice.

Approved

The invoice has been approved and the next step is payment.

Fully Paid

The invoice has been fully paid. This is a final status.

The status codes RE (Rejected) and PD (Fully Paid) are final statuses: no further updates follow after these. The other statuses can succeed each other as processing progresses.

The following diagram shows how the statuses succeed each other, from initial receipt to the final statuses.

Clarification Reasons

With certain statuses (especially UQ and RE), the recipient can include a reason indicating why the invoice is being held or rejected.

Code

Reason

REF

Incorrect references (order number, contract number)

LEG

Legally incorrect

REC

Recipient unknown

QUA

Quality problem with delivered goods or services

DEL

Delivery problem

PRI

Prices do not match

QTY

Quantity does not match

ITM

Items do not match

PAY

Payment terms incorrect

UNR

Invoice not recognised

FIN

Financial problem

OTH

Other reason

Clarification Actions

In addition to the reason, the recipient can also indicate which action they expect from the supplier:

Code

Action

NOA

No action required

Provide additional information

NIN

Send a new invoice

CNF

Credit the invoice in full

CNP

Partially credit the invoice

CNA

Refund the amount

OTH

Other action

Receiving status messages on the platform

When a recipient sends an Invoice Response, the status appears alongside the relevant invoice in your eConnect environment. The status change is normally communicated within three days of being updated by the recipient.

You receive status messages automatically, provided that:

Your organisation is registered for receiving Invoice Responses via the SMP
The recipient of your invoice supports the Invoice Response process

Not all recipients support status messages. It is a feature that is being adopted ever more broadly, but at present it is not yet universal.

The difference with MLS

In addition to Invoice Response, there is also Message Level Status (MLS). The difference is important:

Invoice Response (status messages) is a business-level message. It is sent by the receiving organisation (Corner 4) and concerns the substantive processing of the invoice: has it been approved, rejected, paid?
MLS is a transport-level message. It is sent by the receiving Access Point (Corner 3) and concerns the technical delivery: was the document successfully delivered to the recipient?

Both message types complement each other. MLS tells you whether the invoice has arrived technically, Invoice Response tells you what the recipient does with it.

MLS becomes mandatory: phase-in T2 and T3

Since Peppol Network Policy (PNP) v1.0.0 and SBDH v2.0.2 (both in force since 2 July 2026), MLS (v1.1.0) is no longer optional. The obligation follows a two-phase timeline:

Phase

Deadline

Requirement

28 February 2027

MLS reception operational and SMP-registered. Not met constitutes a breach of PNP MLS-1/MLS-2.

31 March 2027

MLS sending active, full PNP MLS-1 through MLS-4 compliance. From this point the Service Level Requirements are enforceable.

From T3 onwards, two enforceable Service Level Requirements (SLRs) apply, measured monthly: SLR MLS-1 requires that 99.5% of MLS messages (payload smaller than 10 MB) is delivered within 20 minutes of the original document; SLR MLS-2 requires that 99.5% reaches the sender within 25 minutes.

MLS in the PSB: webhooks and rejections

The PSB publishes MLS status information via two webhook topics. When an MLS is received (from the counterparty or the other Access Point), you receive a MessageLevelStatusReceived event. When the PSB itself sends an MLS on your behalf as receiving SP to the sending SP, the MessageLevelStatusSent topic follows. Both payloads contain the statusCode used, a description, the refToDocumentId of the original document and the documentId of the MLS message itself.

For a manual MLS rejection, a specific reason can be included per error. The PSB accepts a lines array with a statusReasonCode and additional description per line. Commonly used codes are FD (failure of delivery, document permanently undeliverable), SV (XML schema validation error), BV (business rule violation, fatal Schematron error) and BW (business rule warning, only together with fatal errors). These lines map one-to-one to the Status Reason Codes in the UBL ApplicationResponse sent over Peppol, so the sender can see exactly which error occurred at which location.

Want to enable status messages for your organisation? Contact support for help configuring the Invoice Response capability.

Validate your invoice