Nobody in a finance function has ever been asked to sign off a transport configuration, and nobody should be. This is the layer of a mandate that is legitimately somebody else's job, and the sensible division of work is that they run it and you never look at it.
That holds until the day a customer says your invoice never arrived. Somebody then hands you a receipt or a log line and asks you to treat it as proof. Whether it is proof, of what, and against whom depends entirely on which technical guarantee produced it. Disputes of that shape are argued badly: each side describes a different guarantee and neither says which.
Where the profile operates, and where it stops
In a four-corner arrangement the document makes three hops: you to your provider, provider to provider, and provider into the buyer's systems. AS4 governs the middle one, and only the middle one. The arrangement itself is set out in how the Peppol network is put together.
The other two hops are usually not AS4 at all. What you send your own provider is whatever that provider offers — an API call, a file drop, a connector inside your ERP. What the buyer's provider does at the far end is a private arrangement between those two parties. So the interoperable, certificate-backed part of the journey is the segment where neither you nor your customer is present. That is the design rather than a defect: the network specifies the hop crossing between two organisations with no contract between them. It does mean every assurance below applies to the middle of a chain that has ends.
What the profile actually is
AS4 is an OASIS profile of ebMS 3.0, the ebXML messaging specification. The base specification carries a great many optional features, so two products could both conform to it and still fail to exchange a message, each having implemented a different half of the options.
A profile fixes that by narrowing: it selects a subset, makes optional things compulsory, and settles details the base leaves to bilateral agreement — the same manoeuvre performed on the document side, where a national specification narrows the European standard instead of replacing it. Networks then narrow AS4 again with a profile of their own, which is where certificate policy, identifier schemes and the permitted exchange pattern get decided. Asking a vendor whether it supports AS4 is therefore close to meaningless. Which network profile it is certified against is the question.
A message is a header plus a payload
An AS4 message keeps two parts separate for the whole journey. The header carries routing and control information: the sending and receiving parties, the kind of exchange, a unique message identifier. The payload is the business document, carried as an attachment the messaging layer treats as opaque. Transport does not parse the invoice. It does not know that it is an invoice.
That separation lets one network move invoices, credit notes, orders and despatch advices without a new transport specification for each. It also creates a failure mode: two descriptions of the same transaction travel in one message and nothing checks that they agree.
Four guarantees, and the limit of each
| Transport guarantee | Business question it answers | Business question it leaves open |
|---|---|---|
| Signing and encryption applied to the message itself, not only to the channel | Could the document have been read or altered between the two providers? | Was the content right when it left your ledger? Security says nothing about accuracy |
| A signed receipt bound to the content received | Did the receiving provider take custody of this exact document, and can it deny that later? | Did the document reach the buyer's finance system, and did anyone act on it? |
| Retry with duplicate elimination | Did a transient failure quietly lose the document without anyone noticing? | What happens once the retries are exhausted, and who is told? |
| An envelope separate from the business document | Can the network route the document without understanding its contents? | Do the envelope and the invoice name the same buyer? Nothing here checks |
Read down the right-hand column. Every open question is a business question, and belongs to a person rather than to a specification.
The receipt, read precisely
When the receiving side accepts a message it returns a signed acknowledgement. Under the non-repudiation option it is bound to digests of the content received, so it does two things at once: it confirms arrival and fixes what arrived. The receiver cannot later argue that a different document turned up. That is stronger evidence than almost anything a paper or email process produces.
But notice whose signature is on it. The receipt is signed by the buyer's access point — a service provider — under the network's trust regime. It records that a provider took custody.
Custody is not consumption. A signed receipt establishes that your customer's provider holds the document. It does not establish that the document reached the buyer's accounts payable system, or that a human being ever saw it.
This is why "we never received your invoice" is such an unproductive argument. The receipt does not win it; it moves it. A dispute between you and your customer becomes one between your customer and their own provider, which is a better place for it and one where you no longer have to prove anything.
Reliability means retry, not arrival
The sender expects a receipt within a defined window; if none arrives it retries on a configured interval and count, and the receiver discards duplicates by message identifier, so a retry crossing a delayed receipt does not put two invoices in the buyer's ledger.
That handles the transient case, which is most cases. It cannot handle the persistent one. Retries end, and when the last attempt fails something has to happen that is not automatic: a queue somebody monitors, an alert somebody reads, a decision to resend. That capacity is the first thing cut at handover, and it is the subject of what happens when delivery fails. Retry is also hop-by-hop: a clean exchange between two providers says nothing about the last hop into the buyer's systems.
Where the envelope and the invoice disagree
Because transport never opens the payload, the header and the document can contradict each other and the message will still be delivered flawlessly to the wrong company. The envelope carries a participant identifier; the invoice carries the buyer's name, VAT identifier and address. Routing uses the first, your accounting the second.
A well-formed identifier belonging to the wrong participant produces no error anywhere. The document arrives, is acknowledged and receipted, and lands with a business that has no idea who you are. This is the transport-layer face of the problem examined in participant identifiers and the lookup services behind them, and it is why a clean transport log is not evidence that anything reached its intended reader.
The questions that are worth asking
- Do you pass the signed receipt through to me, in a form I can retrieve, export and keep for as long as the invoice itself must be kept
- How long do you hold receipts and transport logs, and what happens to them if I move to another provider
- What is your retry policy, and how am I told when the attempts are exhausted rather than having to notice
- On the final hop into a buyer's systems, what does the receiving provider do, and do you have any visibility of it
None of those are technical questions. They are evidential, they decide what you can demonstrate two years from now, and they belong in the provider selection conversation rather than in a technical annexe nobody reads.
The layer that works is the layer that decides least
Transport is the most thoroughly specified and most reliably functioning part of the whole apparatus, and it almost always does exactly what it claims.
It is also close to irrelevant to whether you get paid. That is decided by whether the buyer's provider passes the document on, whether the buyer's system accepts it, whether the order reference matches, and whether anyone approves it — all after custody, outside the specification, where the guarantees stop and the arrangements begin. A transport layer that works perfectly is a good reason to stop worrying about transport. It is a bad reason to assume the invoice is safe.
