An AS2 MDN and an EDI acknowledgment answer different questions. The MDN reports what happened to the AS2 message envelope. An X12 997, X12 999 or EDIFACT CONTRL reports what happened when an EDI system examined the business-document syntax or implementation rules.
A positive MDN therefore does not mean an invoice, order or ASN was accepted by the partner’s ERP. Reliable B2B monitoring keeps transport evidence, EDI validation and business processing as separate states.
The acknowledgment chain
| Layer | Typical evidence | Question answered |
|---|---|---|
| Network | TCP/TLS/HTTP result | Could the endpoints communicate? |
| AS2 transport | MDN | Did the receiver process the AS2 package? |
| EDI syntax/implementation | 997, 999 or CONTRL | Did the EDI translator accept the interchange or report errors? |
| Business application | Order response, application event or manual confirmation | Did the business process accept and apply it? |
The chain can stop at any layer. For example, an AS2 package can receive a positive signed MDN and later generate a rejected 999 because a required EDI element is missing.
What an AS2 MDN is
An MDN is an AS2 protocol receipt. It normally references the original Message-ID and contains a disposition. A signed MDN can also include a Message Integrity Check (MIC), allowing the sender to compare the receiver’s digest with the value calculated over the sent message.
The MDN is produced by the AS2 layer after operations such as decryption, signature verification and MIME processing. It may be returned synchronously in the original HTTP response or asynchronously to a callback endpoint.
The MDN does not need to understand the commercial meaning of an EDI invoice. It reports the handling of the AS2 package that carried it.
What an X12 997 is
The X12 997 Functional Acknowledgment communicates receipt and syntactical analysis of one or more X12 functional groups. It can identify accepted, accepted-with-errors or rejected groups and report structural problems.
A 997 is an EDI transaction set inside an X12 interchange. It is not an HTTP response and not an AS2 receipt. It can itself be transported back through AS2 and receive its own MDN.
Trading-partner implementation guides define expected timing and how much error detail a 997 contains. Do not infer business acceptance beyond what the guide and acknowledgment codes actually state.
What an X12 999 is
The X12 999 Implementation Acknowledgment reports syntactical and implementation-guide validation at a more detailed level than many 997 workflows. It is commonly used with implementation conventions that need segment and data-element error reporting.
Like the 997, a 999 is a business payload transported by a communication protocol. If sent over AS2, the 999 message also generates an AS2 MDN. That MDN confirms delivery of the acknowledgment, not acceptance of the original invoice.
What an EDIFACT CONTRL is
CONTRL is the EDIFACT syntax and service report message. It can acknowledge receipt of an interchange and report syntactical results for parts of that interchange, depending on the implementation and codes used.
CONTRL is the closest EDIFACT concept in this comparison, but it is not identical to every X12 997 or 999 use. Always apply the relevant EDIFACT directory, partner guide and agreed response semantics.
A concrete example
Imagine that Supplier A sends an X12 810 invoice to Retailer B over AS2:
- Supplier A submits the 810 to its AS2 service.
- Retailer B’s AS2 server decrypts the package and validates the signature.
- Retailer B returns a positive signed MDN with a matching MIC.
- Retailer B’s EDI translator reads the 810 and finds an invalid required element.
- Retailer B sends a rejected 999 to Supplier A.
- Supplier A returns an MDN for the AS2 message carrying that 999.
The original invoice achieved AS2 delivery but failed EDI validation. Both MDNs may be positive because both transport envelopes were handled correctly.
Why teams confuse them
Many dashboards show a single “delivered” state. If that state is set when the MDN arrives, users assume the partner accepted the business document. The missing distinction becomes visible only when orders fail to appear or invoices remain unpaid.
Another source of confusion is terminology: people may call every response an “EDI acknowledgment,” including the MDN. Use explicit names in systems and support conversations:
- AS2 MDN verified;
- EDI 997 accepted/rejected;
- EDI 999 accepted/rejected;
- EDIFACT CONTRL accepted/rejected;
- business application accepted/rejected.
Correlation keys
The AS2 Message-ID correlates an MDN to its transport message. EDI standards use their own control references inside the payload. Business applications then use order, invoice or shipment identifiers.
Store the mappings:
- internal submission ID;
- AS2 Message-ID;
- payload checksum;
- interchange and group control numbers;
- transaction reference;
- acknowledgment Message-ID and control references;
- ERP document ID.
Do not rely only on filename. Partners can rename files, and retries can reuse or change filenames without changing the business transaction.
Monitoring deadlines
Define a deadline for each layer:
- network connection: seconds;
- synchronous MDN: within the HTTP timeout;
- asynchronous MDN: partner-specific minutes or service window;
- 997/999/CONTRL: partner-specific response window;
- business response: process-specific hours or days.
An overdue business acknowledgment should not trigger blind AS2 retransmission when the MDN is already positive. First determine whether the partner processed the interchange and whether a response was lost.
Error ownership
| Failure | Likely owner |
|---|---|
| TLS or endpoint unavailable | Infrastructure/AS2 operations |
| Unknown AS2 ID | AS2 partner configuration |
| Signature or decryption failure | AS2/security administrators |
| Missing or invalid MDN | AS2 operations |
| 997/999/CONTRL rejection | EDI mapping or partner EDI team |
| Valid EDI but ERP rejects | Application/business operations |
Routing by layer reduces time lost asking the transport team to fix a missing product code or asking the ERP team to rotate an AS2 certificate.
What to show in a dashboard
For each business document, show:
- partner, direction and document type;
- business identifier;
- AS2 Message-ID;
- transmission timestamp and retry count;
- MDN disposition, signature and MIC status;
- expected EDI acknowledgment type and deadline;
- acknowledgment code and error details;
- ERP or business state;
- current owner and next action.
Aggregate alerts should distinguish transport failure rate from EDI rejection rate. They are different service-quality signals.
Frequently asked questions
Can a 997 or 999 replace an MDN?
No. It can provide a later EDI validation result, but it does not replace the AS2 protocol receipt and its message-integrity evidence.
Can an MDN replace a 997, 999 or CONTRL?
No. The MDN does not report detailed EDI syntax or implementation-guide acceptance.
Does a rejected 997 mean AS2 failed?
Not necessarily. If the original message has a valid positive MDN, AS2 delivery succeeded and the EDI content failed at a later layer.
Does an acknowledgment sent by AS2 get its own MDN?
Yes. A 997, 999 or CONTRL sent as an AS2 payload is itself an AS2 message and can request an MDN.
Which acknowledgment is required?
The EDI standard, transaction set, industry convention and trading-partner guide determine it. Record the requirement during onboarding and test the exact codes used.
Read the AS2 MDN guide for receipt mechanics and AS2 transaction monitoring for operational state design.
