Peppol Invoice Message Responses (IMR)
IMR lets buyers send structured accept, reject, or dispute responses over Peppol. Learn how business-level invoice responses differ from email replies and from technical delivery acknowledgements.
Updated
Business feedback on a structured invoice
When a supplier sends a Peppol invoice, the buyer often needs to say more than “we received your PDF.” Did accounts payable accept it for payment? Is there a dispute on quantities or prices? Is it still under internal review?
Invoice Message Responses (IMR) answer that need. IMR is the Peppol document type (technically a UBL ApplicationResponse under the Peppol BIS Invoice Response profile) that carries a business-level status about a specific invoice already exchanged on the network. It is a pan-European Peppol concept: the same response model is defined for cross-border use, not as a Belgian-only format.
IMR does not replace booking the invoice, approving payment, or issuing a credit note. It is the standardised signal between trading partners that a received Peppol invoice has been accepted, rejected, questioned, or moved to another defined business state.
IMR is not an email reply
Email replies break down in structured e-invoicing. Threads rarely link machine-readably to the Peppol document or invoice number; wording like “looks fine, we’ll pay next month” is ambiguous for automation; and Peppol logs delivery and business responses through Access Points while email has no federation model.
IMR is sent on Peppol, references the original invoice explicitly, and uses coded statuses from the Peppol BIS Invoice Response specification. Your software can display the response next to the invoice, notify the supplier, and keep an audit trail without parsing free-text email.
IMR versus technical delivery acknowledgements
Peppol also uses message-level responses (sometimes called MLR in product UIs) that confirm whether a message was syntactically valid and delivered. Those are transport-layer signals.
IMR expresses commercial processing intent about the invoice content: accepted for payment, rejected with a reason, under query, and so on. Confusing the two leads suppliers to think an invoice was business-accepted when only network delivery succeeded.
How an IMR travels on the Peppol network
- The buyer decides a business status for a received Peppol invoice.
- Their system or Access Point builds an ApplicationResponse XML referencing that invoice.
- The response travels through Access Points to the supplier.
- The supplier receives a structured response linked to the outbound invoice.
Because Peppol is a federated European network, buyer and supplier may use different Access Point providers. IMR works when both sides support the Invoice Response transaction (Peppol BIS Billing Invoice Response 3.x).
Response code categories (Peppol BIS Invoice Response)
Peppol defines two-letter response codes mapped to business categories. Legal effect can still depend on contract and national practice, but the categories are standardised across the network.
| Category | Typical business meaning |
|---|---|
| Accepted | Acknowledged for further processing or payment without objection at this stage. |
| Rejected | Not accepted; should not be paid as submitted. A structured reason is expected. |
| Conditionally accepted | Accepted only under stated conditions (pending clarification or a corrected document). |
| Under query | Not finally accepted or rejected; questions raised or internal review ongoing. |
| Accepted with errors | Processing continues despite known discrepancies the buyer tolerates or handles separately. |
| In process | Still under review; no final business decision recorded yet. |
| Paid | Optional status some implementations use after payment (support varies). |
Codes such as AP, RE, CA, UQ, AB, and IP correspond to these categories in Peppol BIS 3.0 material. Treat the category as the stable concept; the two-letter token is what systems exchange.
Do not invent meanings for codes outside published Peppol codelists. Consult your Access Point provider or OpenPeppol Invoice Response documentation for unfamiliar codes.
Status reasons when the answer is not a plain “yes”
For rejected, conditionally accepted, or under query responses, Peppol expects a status reason code from the OPStatusReason codelist, plus optional free text. Reason codes group typical issues (references, prices, quantities, delivery, and similar categories in the specification), helping suppliers route disputes to the right team.
Who sends IMR, and when?
Buyers send outbound IMR after receiving a Peppol invoice; suppliers receive inbound IMR linked to invoices they sent. Timing is a process choice: some send accepted after validation, others after internal approval. Under query or rejected should be sent early so suppliers do not assume payment.
Belgium’s B2B mandate focuses on sending and receiving Peppol invoices. IMR is not always mandatory for every SME, but it matters when customers expect automated acceptance signals, you want fewer status emails, or you need an audit trail beyond informal correspondence. Supporting IMR improves interoperability across Peppol countries.
- IMR (Invoice Message Response)
A Peppol ApplicationResponse document that communicates a standardised business status (accepted, rejected, under query, and related categories) about a specific invoice exchanged on the network.
Practical checklist
- Confirm your Access Point and software support Invoice Response send and receive.
- Ensure users distinguish network delivery from business acceptance.
- Include reason codes in rejection and query workflows with clear internal ownership.