Every delivery on a four-corner network ends with a receipt. The receiving access point acknowledges the message at transport level, and the sending one records that acknowledgement as evidence. That is what the transport profile guarantees, and it is where many implementations stop.
A seller wants to know more than that. Did the buyer's system accept the file? Is somebody querying the price on line four? Has it been approved? Has it been paid? On paper those answers arrived by telephone, if at all. Peppol has a document for them: the Invoice Response, published by OpenPeppol as a BIS specification in its own right.
Two kinds of answer
It helps to separate three levels at which a delivered invoice can succeed or fail, because they are answered by different messages.
| Level | Question | Answered by | Who produces it |
|---|---|---|---|
| Transport | Did the message arrive intact at the receiving access point? | The transport receipt | The receiving access point, automatically |
| Technical | Could the receiver read and validate the document? | A message level response | The receiving system or its provider |
| Business | What did the buyer decide to do about the invoice? | The Invoice Response | The buyer, or a system acting for it |
The confusion between the second and third rows causes more trouble than either on its own. A technical rejection means the file was malformed or failed validation — the seller should fix and resend. A business rejection means the file was fine and the buyer does not accept the claim — the seller should talk to the buyer, and probably issue a credit note or a new invoice. Treating one as the other sends the problem to the wrong team. The failure modes of the first two levels are covered in delivery failures and retries; this piece is about the third.
The seven statuses
The Invoice Response carries one status from a closed list of seven, taken from a UN/CEFACT code list and restricted by the specification.
| Code | Name | Final? | Reason required? | What it tells the seller |
|---|---|---|---|---|
AB | Message acknowledgement | No | No | The buyer's system has received it and taken it in |
IP | In process | No | No | Someone is working on it; nothing is wrong yet |
UQ | Under query | No | Yes | Something needs clarifying before a decision |
CA | Conditionally accepted | No | Yes | Approved, subject to a condition stated in the response |
RE | Rejected | Yes | Yes | Will not be processed; a new document is needed |
AP | Accepted | No | No | Approved for payment |
PD | Paid | Yes | No | The invoice has been paid in full |
The specification sets out a natural order — acknowledgement, in process, under query, conditionally accepted, rejected or accepted, paid — but any status may be the first one sent, and any may be skipped. A buyer that only ever sends AP and RE is using the message correctly.
Two details matter in practice. RE is final: an invoice that has been rejected cannot later be accepted, so the only way forward is a new document, following the rules in corrections and credit notes. And PD can carry a clarification code for partial payment, in which case it is not final, because more is to come.
Reasons and requested actions
A status that requires a reason carries one from a defined list: legal information missing, references incorrect, prices wrong, quantities wrong, and so on. Alongside it the buyer can state what it wants the seller to do, again from a list — issue a new invoice, credit fully, credit partially, provide information. The codes are published with the specification rather than reproduced here, because the list is versioned and the version you implement should be the one in the current release.
What matters is that a reason and an action are data rather than prose. A seller's receivables system can route RE with a legal reason to the tax team, and UQ with a pricing reason to the account manager, without anyone reading the message first. That routing is the whole business case.
The Invoice Response is worth most to the seller, who learns about a dispute weeks earlier than a missed payment would reveal it. It costs most to the buyer, who has to send it. That asymmetry is why adoption depends on the buyer's incentive — a large buyer that wants fewer calls from suppliers asking about payment is the obvious candidate to drive it.
Why it is optional, and what that means
The specification is explicit: the seller is not obliged to support the Invoice Response and the buyer is not obliged to send one. On an open network, that is the only workable rule. A small supplier's software may not be able to receive it, and a buyer that has never sent one should not be in breach of the network agreement for that reason.
The practical consequence is that the capability has to be discovered, like everything else on the network. A seller that can process responses registers that capability for its identifier, and a buyer's system can look it up before sending — the same mechanism described in Peppol addressing. Sending a response to a participant that has not advertised the capability is an error, not a courtesy.
Where status reporting stops being optional
National reforms are starting to make lifecycle statuses compulsory, and when they do, the status is no longer only a message between two parties. The French reform is the clearest example: it defines a set of invoice statuses, of which a small number — including rejection, refusal and collection of payment — must be transmitted, some of them onward to the administration because they affect when VAT becomes due on services. How the platforms in the French model exchange those statuses is a national specification, not the Peppol one, though the concepts map closely.
That changes the design question for anybody building an accounts payable flow. If a buyer operates in a country where statuses are compulsory, the logic that decides when an invoice is rejected, accepted and paid has to produce data at those moments anyway. Emitting a Peppol Invoice Response to suppliers elsewhere is then a small addition to work that is already mandatory, rather than a project of its own.
What to decide
For a buyer, three decisions, in this order. Which statuses you can actually produce from your process — most can produce RE and AP, fewer can produce PD reliably. Which reasons you will use, mapped from the rejection categories you already have in the exception-handling process. And whether you will send responses to every supplier that advertises the capability, or only to those that ask.
For a seller, one decision: whether your receivables system will act on a response or merely store it. A response that nobody routes is a record of a dispute you learned about and did nothing with, which is arguably worse than not knowing.
