There is a sentence that closes more internal discussions than it deserves to: we sent it. It is usually true, and on its own it is worth very little. What interests a buyer's ledger, a credit controller and eventually an auditor is not that a document left your system. It is that a document arrived somewhere a process will act on.
No specification closes that gap for you. Every transport architecture used in European e-invoicing has an answer to what happens inside it, and each allocates the risk of failure differently — usually in a schedule to a service agreement nobody in the finance function has read.
Failure is not one event either. It is at least five, with different detection paths, different owners and very different amounts of surviving evidence. Collapsing them into "delivery failed" is what produces a retry-shaped answer to problems retries cannot reach.
Two questions, asked of every failure
Who finds out? Not who is responsible — who receives a signal, how quickly, and whether that channel ends in front of somebody with capacity to act. A failure caught in four minutes by a queue monitor is an inconvenience. The same failure caught four months later in a supplier statement reconciliation is an argument about a write-off.
What evidence survives? A reason code and the rejected instance is a strong position. A transport receipt asserting successful delivery, in a case where the buyer never saw the document, is worse than no evidence at all: it proves the wrong proposition, and it proves it well.
| Failure class | What actually happened | Who finds out, and when | Who carries it | What evidence survives |
|---|---|---|---|---|
| Content rejection | The document reached a validator and broke a rule | The sender, at once or by a response message | The sender: the defect is in their data | A reason code and the failed instance |
| Addressing rejection | The recipient identifier resolved to nothing | The sender, at lookup or at the first hop | The sender, using data the buyer supplied | A lookup failure; no document downstream |
| Accepted, never collected | Transport succeeded; the buyer never picked it up | Nobody, until payment is chased | Contested: transport worked, business did not | A receipt proving delivery to a system, not to a function |
| Abandoned destination | A valid address pointing at a portal the buyer has left | Nobody, usually for months | The buyer in principle, the seller in practice | A receipt that positively asserts success |
| Lost in a migration | The address changed while documents were in flight | Nobody, or a reconciliation much later | Split between two providers, neither wholly | Two partial archives and no single chain |
The rejections are the good news
A content rejection is the healthiest thing that can happen to a bad invoice. Something read the document, applied a rule, refused it and said why. The defect is yours, the signal is unambiguous, the evidence is complete on both sides.
An addressing rejection is nearly as good, and it belongs to a different owner. An identifier is a scheme and a value together, and a value that is well formed but wrong behaves nothing like one that fails to resolve. Only the second fails loudly. How a participant identifier becomes a destination is set out in addressing and service lookup on Peppol; the practical point is that the data came from your customer, arrived on an onboarding form, and has been ageing quietly ever since.
Both classes share one property worth naming: the document did not arrive, and everybody knows it did not arrive. That is the whole difference between an exception and a loss.
Accepted by the network, collected by nobody
This is the class that produces the most confident wrong answers.
The transport layer does its job properly. A sending access point hands the document to a receiving one, gets back a signed receipt, and retries on a defined schedule when that receipt does not come — behaviour that is specified rather than left to each implementation, as the AS4 transport profile sets out. What the receipt attests is that one system took custody from another. It says nothing about whether a workflow, an ERP or a person ever saw the file.
So the seller holds a receipt, the buyer holds something nobody has opened, and the invoice is a month old before anyone notices. Nothing failed technically. This is a business process failure wearing a technical costume, and the receipt is what stops anyone investigating sooner.
The destination nobody monitors
Worse is the address that works perfectly and points somewhere dead. A provider relationship ended, a portal was replaced, a subsidiary was sold, and the registered endpoint was never updated. Documents keep arriving; receipts keep coming back clean.
Clearance models are better here, because the platform has to do something visible when it cannot complete delivery. In Italy an undeliverable document is not silently dropped: the outcome is reported to the sender and the document is made available through the recipient's tax portal, as described in the route a document takes through the Italian exchange system. That is a real improvement on a network that simply succeeds. It is not a fix, because a document deposited in a portal the buyer has never logged into is delivered in law and invisible in practice.
The gap in a migration
The last class produces no message at all, which is why it surfaces during an audit.
Changing provider means the published destination changes while documents are still moving against the old one. Anything in that overlap can be accepted by infrastructure being decommissioned. Nothing rejects. The dead letter queue on the outgoing platform — the holding place for messages that exhausted their retries — is emptied with everything else when the contract ends.
The obligation to keep an invoice readable, unaltered and demonstrably authentic for the whole retention period does not pause because you changed supplier. Receipts, response messages and transport logs are part of the audit trail behind authenticity and integrity, and they sit with a party whose contract you have just ended.
What a retry actually buys
Retries answer one thing well: the transient failure. The endpoint was down, a handshake failed, a connection dropped mid-transfer. Wait, try again, succeed. That failure would often have cleared itself, and the retry removed a manual step.
Against the other four classes, retry logic is inert. It cannot retry a document that was correctly rejected, or an identifier into resolving, or make anybody open a portal, or reach into a platform that no longer exists.
Only one of the five classes is a delivery problem. The rest are master data, contract scope, monitoring capacity and change management, and each arrives dressed as a message queue because that is where it becomes visible.
Who is on the hook, once you read the schedule
Most provider agreements undertake to transport a document to the endpoint the addressing infrastructure resolves to, and to produce evidence of having done so. Read that for what it is: a commitment about a leg, not an outcome. If the endpoint is wrong, the provider met it. If the buyer never processes what arrives, the provider met it.
That leaves the seller carrying the commercial consequence of every class except the first, and carrying it without a signal. The answer is not a better contract. It is somebody reconciling issued documents against acknowledged ones on a schedule, with a defined route for the difference — the unglamorous discipline of exception handling once volume is flowing.
The deadline is not suspended because somebody is retrying
The obligation to issue an invoice within a defined period comes from VAT law, and national mandates add their own timing on top. None of those rules contain a clause about your transport queue. A document sitting in a retry loop, resting in a dead letter queue, or delivered to an endpoint nobody reads has not been issued in any sense the deadline recognises — and under clearance, where the document exists legally only once the platform accepts it, that is not even arguable.
Delivery evidence protects you in a commercial dispute with a buyer. It does not protect you from a tax administration, which is not asking whether you tried. Retry logic was built for the first conversation. The deadline belongs to the second.
