MDNs and Proof of Delivery: How B2B Receipts Actually Work

Strip away the certificates and the encryption, and the reason companies tolerate AS2's complexity comes down to one artifact: the receipt. A trading partner who receives your invoice hands back a small, cryptographically signed message saying "we received exactly these bytes and processed them." Months later, when someone disputes whether a document arrived on time — or arrived at all — that receipt ends the argument. No other mainstream file transfer method produces anything like it.

This article is entirely about that receipt: the MDN. You will learn what is inside one, what the MIC verification at its heart actually proves, the two very different ways receipts travel back to you — synchronous and asynchronous — and the unglamorous but critical discipline of storing receipts so they are still findable when a dispute finally happens. It is part of our AS2 & B2B Exchange series and assumes you know the basic message journey from AS2 explained for admins.

What an MDN Is

MDN stands for Message Disposition Notification. The name comes from email standards — an MDN was originally a machine-readable "read receipt" for mail — and AS2 (Applicability Statement 2, the business-to-business exchange specification) borrowed the format for its delivery receipts. An AS2 MDN is a small structured message the receiving station sends back to the sender after handling an inbound message. It has two parts bundled together:

• A human-readable part — a short plain-text summary, something like "The message was received and successfully processed." Useful when a person is reading logs; ignored by software.
• A machine-readable part — rigid header-style fields that the sender's station parses and acts on. This part carries the legal weight.

A simplified machine-readable part looks like this:

Reporting-UA: partner-as2-station
Original-Recipient: NORTHWIND
Final-Recipient: NORTHWIND
Original-Message-ID: <a91f42c7-33d8-42be@your-as2-station>
Received-Content-MIC: kZoq7mA31xTfSm2GJz0zGqhkq2Fq8vXo0iZ1YQnEw5s=, sha-256
Disposition: automatic-action/MDN-sent-automatically; processed

Field by field: Original-Message-ID quotes the unique identifier your station stamped on the outbound message — this is how a receipt gets paired with the message it answers, even when hundreds are in flight. Received-Content-MIC is the heart of the receipt, covered in the next section. And Disposition is the verdict. The value processed means success. Two other patterns matter:

• processed/error: ... — the message arrived but something went wrong, with a category such as decryption-failed, authentication-failed, or insufficient-message-security. These categories are the vocabulary of AS2 troubleshooting; each points at a different broken piece.
• failed/failure: ... — the receiving station could not even get far enough to evaluate the message properly.

Finally — and this is the property everything else depends on — the MDN is normally signed with the receiving partner's private key, because the sender's original message explicitly requested a signed receipt. An unsigned "got it" is a courtesy. A signed MDN is evidence: only the partner's key could have produced it, so the partner cannot later disown it.

MIC Verification: What the Receipt Actually Proves

The MIC — message integrity check — is a cryptographic hash of the message content: a short fingerprint computed by feeding the payload through a hash algorithm (the receipt above used SHA-256, the algorithm the sender requested). Hashes have the property that makes receipts meaningful: change one byte anywhere in the file and the fingerprint changes beyond recognition, and nobody can construct a different file that produces the same fingerprint.

The verification is a two-sided ritual. When your station sends a message, it computes the MIC over the outbound content and stores it. When the partner's station receives the message, it decrypts, verifies your signature, and computes its own MIC over what it actually received — then places that value in the Received-Content-MIC field of the MDN. Your station compares the returned MIC against the stored one. When they match, mathematics — not trust — establishes three facts at once:

1. Delivery: the message reached the partner's station (they could not have fingerprinted content they never had).
2. Integrity: the bytes that arrived are identical to the bytes you sent — nothing corrupted, truncated, or tampered with them in transit.
3. Attribution: because the MDN is signed by the partner and quotes your Message-ID, the receipt is bound to this exact exchange between these exact parties.

Together with the signature on your original message, this creates non-repudiation: you cannot plausibly deny sending the message, and the partner cannot plausibly deny receiving it. That mutual lock is the contractual foundation of AS2 trading relationships.

Be equally clear about what a clean MDN does not prove. It proves the partner's AS2 station received and processed the transmission. It says nothing about whether the document inside made sense, parsed in their translator, or was acted on by their business. Those confirmations happen at higher layers — the functional acknowledgment and the business response documents described in EDI basics for admins (EDI being Electronic Data Interchange, the document-standards layer riding inside AS2 messages). "MDN received, 997 missing" is a perfectly possible state, and it means the transport worked while the translation choked.

Synchronous MDNs: the Receipt on the Same Call

Now to the two delivery styles, because "sync or async?" appears on every partner connection form and each choice changes your infrastructure obligations. A synchronous MDN travels back inside the HTTP response of the very request that delivered the message. One connection, one round trip, message out and receipt back before the connection closes.

The diagram below shows the synchronous flow: a single connection that stays open while the receiver does its cryptographic work, then carries the receipt home in the reply.

Synchronous receipts have real virtues. Pairing is trivial — the receipt arrives on the same connection as the message, so nothing can mismatch. The sender needs no inbound listener for receipts, which matters for companies whose security policy resists opening inbound paths. And the sender knows the outcome immediately: when the response arrives, the exchange is fully settled.

The weakness is time. The connection must stay open while the receiver decrypts, verifies, and fingerprints the payload. For a small purchase order that takes a second. For a very large payload — or a receiver whose station is busy — the work can outlast connection timeouts on either side, or in any firewall and proxy between them. When that happens the sender sees a timeout and cannot tell whether the message was processed, which is an ugly, ambiguous state. That is precisely the problem asynchronous receipts exist to solve.

Asynchronous MDNs: the Receipt That Arrives Later

An asynchronous MDN decouples the receipt from the delivery connection. The sender's message includes an extra header — Receipt-Delivery-Option — containing a return URL: "deliver my receipt to this address, separately." The receiver immediately answers the delivery request with a bare transport-level acknowledgment (no receipt inside — just "transmission accepted") and closes the connection. Then, once its processing is done — seconds or minutes later — the receiver opens a brand-new connection to the sender's return URL and delivers the signed MDN there.

Asynchronous mode removes the timeout problem completely — the receiver can take as long as it needs — which is why partner specifications commonly require async for large files and high-volume batch windows. But it shifts burdens onto the sender, and these become your operational responsibilities:

• You must run an inbound endpoint. Your station's MDN URL has to be reachable from the partner's network: public name resolution, firewall rules, and a valid TLS certificate (Transport Layer Security — the HTTPS encryption layer) if the URL is HTTPS. A sender that cannot receive is a sender that never gets receipts.
• Pairing becomes real work. The receipt arrives on a different connection, possibly much later, and is matched to its message by Original-Message-ID. Your station tracks messages in a "sent, awaiting MDN" state and must alarm when the wait exceeds an agreed window.
• A new failure mode appears: delivery succeeded but the receipt could not travel — because your inbound endpoint was down, your firewall changed, or the partner recorded your return URL wrong. From your side this looks identical to a failed delivery until you investigate. It is one of the classic scenarios in troubleshooting AS2.

Choosing Between Sync and Async

Often the partner's connection form simply dictates the answer — the larger company's standards win. When you do get a choice, the tradeoff is compact:

A sensible default for a new, low-volume partnership exchanging ordinary business documents is synchronous — fewer moving parts, fewer things to monitor. Move to asynchronous when payload sizes or processing delays start causing sync timeouts, or when the partner requires it.

The Disputes Receipts Resolve

Receipts feel like bureaucracy until the first real dispute. Some patterns you can expect over the life of a trading relationship:

• "We never received your invoice, so we're not paying it yet." You produce the signed MDN: their station attested to receiving those exact bytes on that date, disposition processed. The conversation shifts instantly from "did you send it?" to "where did it go inside our systems?" — their problem, not yours.
• "The file you sent was corrupted." The matching MIC in their own signed receipt proves the bytes that arrived were identical to the bytes you sent. If something was malformed, it was malformed before sending (a translation-layer issue) or mangled after receipt — transit is mathematically exonerated.
• "Your shipping notice arrived late — here's the chargeback." Large partners levy penalty fees for documents that miss deadlines. The MDN's timestamps, paired with your send logs, establish exactly when the exchange completed. Sometimes the evidence defends you; sometimes it shows your batch really did run late — in which case it points you at the schedule to fix.
• "You sent that order twice, and we shipped twice." Message-IDs and your MDN archive establish exactly how many distinct messages were exchanged and when, which settles whether the duplication happened on your side, their side, or in a retry storm.

Notice what makes each resolution work: the receipt was signed by the other party. You are never asking anyone to trust your logs; you are producing their own cryptographic attestation. That is the practical meaning of non-repudiation, and it is what bare SFTP (SSH File Transfer Protocol) relationships lack — a gap explored honestly in AS2 vs SFTP for partner exchange.

Storing Receipts as Evidence

All of the above assumes one thing: when the dispute arrives — often months later — you can actually find the receipt. That is a storage discipline, and it does not happen by default. AS2 station software keeps message and MDN histories, but frequently in rotating logs or databases trimmed for disk space, tuned for operations rather than evidence. Treat receipts the way finance treats invoices:

• Keep the full evidence set together: the original outbound message (or at minimum its Message-ID, MIC, and metadata), the complete signed MDN, and the timestamps of both. A MIC without the signed receipt around it proves little.
• Index by the keys disputes use: partner, date range, Message-ID, and — where your tooling allows — the business document number the payload carried, because the partner will say "invoice 8842," not "message a91f42c7."
• Retain for the dispute horizon, not the disk-space horizon. Commercial disagreements surface on business timescales — chargeback reviews, audits, contract ends. Align retention with your finance and legal teams' answer, which is usually measured in years, and archive accordingly.
• Move archives out of the station's working storage. Export or sweep completed exchanges to durable, backed-up storage on a schedule. This is ordinary file-moving work: a folder-monitoring tool such as Sysax FTP Automation can watch the export folder and ferry each batch to an archive share as it appears, so evidence preservation runs unattended instead of relying on someone remembering.
• Test retrieval once. Pick a random six-month-old exchange and time how long it takes to produce the message, receipt, and MIC. If the answer is "we can't," fix it before a dispute makes the lesson expensive.

Receipts Without AS2

A final honest note for the relationships in your estate that run over SFTP instead of AS2. There, no protocol-level receipt exists. Delivery evidence is assembled from weaker parts: your transfer logs, the server's activity log on whichever side hosts the endpoint, checksum manifests exchanged alongside files, and sometimes partner-generated confirmation files. That evidence is one-sided — your logs are your own claims, not the partner's attestation — which is acceptable for many relationships and inadequate for some. If your company hosts the endpoint, the server's activity log is the strongest artifact you have: a server such as Sysax Multi Server records each partner login and file operation, which pairs with checksum manifests into a respectable delivery narrative. Agree on those evidence habits at onboarding time, not dispute time — and where the stakes genuinely demand a receipt the partner cannot disown, that is precisely when AS2 earns its operational cost.

The Short Version

An MDN is the receiving station's signed statement of what it received and what happened, anchored by the MIC — a fingerprint the sender can compare against its own to prove byte-exact delivery. Synchronous receipts ride back on the delivery connection and keep life simple; asynchronous receipts arrive later on a new connection, scale to large payloads, and obligate you to run a reachable return endpoint and a pairing queue. Signed receipts settle disputes because they are the other party's own cryptography — provided you stored them somewhere you can search. For what to do when receipts go missing — and how to tell whose side of the wire lost them — continue to troubleshooting AS2.

Frequently Asked Questions