A finance system and a clearance platform can disagree about whether an invoice exists. When they do, the platform wins. That is not a technical footnote — it is the whole difference between sending a document and clearing one, and it outlives every change of format and every change of government.
In a four-corner network, "sent" is a rough approximation of "delivered", because the file you handed to your provider is the file the buyer eventually gets. In a clearance model it is not an approximation of anything. The status flag your system sets when it releases a document records exactly one fact: that your outbound queue emptied. Whether a valid invoice now exists is a question only the platform can answer, and it answers later, asynchronously, in a separate document that most implementations treat as noise.
Italy has run this arrangement long enough that the consequences are observable rather than theoretical, which makes it the useful worked case. The mechanics below are Italian. The problem is structural, and every clearance mandate reproduces it.
Submission is a request, not an event
The supplier does not deliver to the buyer. The supplier delivers to the exchange system, which validates the document against the rules of the national XML format and then either refuses it or passes it on to the address the buyer registered.
Everything downstream of that arrangement follows from one property of it: the evidence of what happened is generated by a third party. This is the practical content of the distinction between four-corner and five-corner architectures — not that a tax administration is watching, but that the record of issuance moved out of your building.
What the platform can tell you
The notices carry Italian names and two-letter abbreviations, and learning them is a morning's work. What matters is that they fall into a small number of classes, and that the classes have different legal consequences. Confusing two of them is how duplicates and missing invoices get created.
| What arrives | What the platform is saying | Status of the document | What the sender does next |
|---|---|---|---|
| Delivery receipt (ricevuta di consegna) | Validated, and handed to the buyer's registered channel | Issued. The transmission date stands | Store the receipt against the invoice. Nothing further |
| Rejection (notifica di scarto) | Failed validation. Nothing was delivered to anyone | Never issued. The document does not legally exist | Correct and resubmit within the period that preserves the original date. Never raise a credit note against it |
| Failure to deliver (notifica di mancata consegna) | Valid and accepted, but the buyer's channel could not receive it | Issued. Delivery is completed by another route | Make the document available to the buyer and tell them it is there. Do not reissue |
| Buyer outcome, acceptance or refusal | In the public-sector flow, the receiving administration has responded | Issued either way. A refusal is a dispute, not a validation failure | Resolve commercially. A refused invoice is still an invoice |
| Expiry of the response period | The buyer's window closed without a response | Issued. The absence of a response is itself the outcome | Close the item and move on. There is nothing to resubmit |
| Nothing at all | The platform has not spoken | Unknown — and unknown is not "sent" | Investigate the channel. Silence is an incident with an owner and a deadline |
The last row is the one that costs money, because it is the only state your own system will happily render as success.
Rejected and undeliverable are opposite problems
These two get conflated constantly, and the conflation is expensive in both directions.
A rejection is a statement that no invoice was issued. The obligation is unfulfilled, the number you allocated is hanging, and the correct response is to fix the defect and send the same document again. Raising a credit note to "cancel" a rejected invoice cancels something that never existed, and leaves a ledger with a credit note whose original the administration has no record of.
A failure to deliver is the reverse. The invoice passed validation, so it was issued, and the issue date holds. What failed is the last hop — the buyer's registered channel was unreachable, or the addressing element pointed at a destination that could not accept the document. The supplier's duty in that case is to make the invoice available to the buyer directly and say so. Reissuing produces a duplicate that both parties then have to unwind.
An undeliverable invoice is a valid invoice with an unhappy buyer. Nobody is chasing it, because your ledger shows it as issued and theirs shows nothing at all. It surfaces at the first payment run that misses, or later, at reconciliation, and by then the payment terms have already run.
The clock that counts is not yours
Three timing facts are worth stating flatly.
The platform timestamps, not your ERP. The transmission and receipt times recorded by the exchange system are the ones that appear in the notification, and they are the ones that will be produced in any argument about when the invoice was issued. Your application log is a description of your own behaviour.
Notifications are asynchronous and unpredictable in latency. Nothing in the design promises an answer inside a given number of minutes. A submission made at the close of business is a document in an unknown state overnight.
Correction windows are fixed by the administration and are short. A rejection received in the middle of a VAT period is an inconvenience. The same rejection on the final day of the period is a document that may not be issued in the period the accounting entry assumes, and the difference between those two situations is entirely a question of whether anybody was watching the queue.
The receipt is the evidence, and it is not in your accounting system
The VAT Directive requires a taxable person to assure the authenticity of the origin and the integrity of the content of an invoice, and to keep it. Under clearance, the platform's notification is what connects the document you hold to the act of issuing it. Without the notification you have a well-formed XML file and an assertion.
So the storage rule is simple and widely broken: archive the notification alongside the invoice, linked by the platform's own identifier, for the same retention period. Not in a support ticket, not in a provider's web console that expires after a rolling window, not in the mailbox of whoever configured the integration.
Any service provider will show you receipts in a portal. The question to ask is whether you can export them in bulk, in their original form, with the platform's identifiers intact, and whether that export survives the end of the contract. If the answer is a screen, you are renting your evidence.
Somebody has to be watching
None of this is difficult. All of it requires a named person and a queue, because outcomes arrive after the invoice run has finished and after the person who pressed the button has gone home. The work is small, uneven, and impossible to schedule, which is precisely the profile of work that gets absorbed into somebody's afternoon and then quietly stops happening. That is the operational subject of running an exception queue at volume, and it is the same conclusion Italy's longer record supports in a decade of live clearance.
What decides whether transmission hurts is not the platform and not the format. It is whether your reconciliation runs against the platform's answers or against your own outbox. One of those two records is admissible.
