The journey of an EDI interchange

Seven steps separate the moment an order is validated in a buyer's ERP from the syntactic acknowledgment returned by the supplier's information system. This page follows each one, timestamps included, on an EDIFACT D.96A ORDERS message carried over AS2.

Overview — seven steps

An EDI interchange journey breaks down into seven sequenced operations spread across two information systems, with the network serving as a wire between them. Four operations are on the sender side, three are on the receiver side, and the last step — the business response — can be followed symmetrically in the reverse direction:

1. Generation of the business document from the ERP.
2. EDIFACT enveloping: UNB/UNH added around the message.
3. MIME packaging and S/MIME signature: encryption and cryptographic signature.
4. Transport via AS2 (or OFTP2, SFTP, AS4) over the internet.
5. Reception and MDN: the receiver cryptographically acknowledges receipt.
6. Unwrapping and parsing: decryption, signature verification, EDIFACT tokenisation.
7. CONTRL acknowledgment then business response: ORDRSP sent, reverse journey.

1. Generation from the ERP

The ACME Retail user validates an order in their ERP — SAP, Oracle Fusion, Microsoft Dynamics, Sage X3, it doesn't matter which. The ERP enriches the order with partner data (supplier GLN, delivery terms, referenced master contract), then invokes a mapping module that transforms the internal ERP model into an EDIFACT D.96A structure. That mapping is usually maintained by an EDI integrator: GXS/OpenText, Generix, B2BRouter, Cleo, Edicom, Pagero, Stedi, Tenor — or by an in-house engine in the most mature groups. The result is a character string respecting ISO 9735 syntax.

2. EDIFACT enveloping

The ORDERS message itself is framed by two levels of envelopes:

• Message level: the UNH (Message Header) and UNT (Message Trailer) segments delimit an individual message and carry its type, version (here ORDERS:D:96A:UN:EAN008) and local reference number.
• Interchange level: the UNB (Interchange Header) and UNZ (Interchange Trailer) segments delimit the outer envelope. UNB carries the character set (UNOC:3), the sender and recipient GLNs with their qualifier (14 = GLN/EAN), the production date and time, and the interchange control reference — here CTRL000042, unique per identifier pair.

A service string advice UNA:+.? ' can precede the UNB to override separators if the payload contains apostrophes, plus signs or colons in free strings. A typical result for our order:

UNA:+.? '
UNB+UNOC:3+5410000000123:14+5410000000456:14+260514:0930+CTRL000042++ORDERS'
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+ORDER789+9'
DTM+137:202605140929:203'
DTM+2:20260520:102'
NAD+BY+5410000000123::9++ACME RETAIL SA'
NAD+SU+5410000000456::9++DELTA SUPPLY GMBH'
RFF+CT:CONTRACT-2026-Q2'
LIN+1++3520000001234:EN'
IMD+F++:::CARTON DARK CHOCOLATE 100G'
QTY+21:24'
PRI+AAA:1.20'
UNS+S'
CNT+2:1'
UNT+12+1'
UNZ+1+CTRL000042'

3. MIME packaging and S/MIME signature

The AS2 agent (Cleo Harmony, IBM Sterling B2B Integrator, OpenAS2, BizManager, etc.) picks up the outgoing EDI file and turns it into a MIME payload. RFC 4130 §4.2 lists admissible MIME types; for EDIFACT, application/EDIFACT must be declared in Content-Type. The agent then signs the payload with the ACME-Retail private key for the partnership and encrypts it with the supplier's S/MIME public key. The result is a multipart/signed (RFC 1847), optionally re-wrapped in an encrypted application/pkcs7-mime (CMS, RFC 3851/3852).

4. AS2 (or OFTP2, SFTP, AS4) transport

The sending agent opens a TCP/443 connection to the partner's AS2 URL — typically https://as2.delta-supply.example/edi/receive — and sends an HTTP/1.1 POST carrying the mandatory AS2 headers (RFC 4130 §6):

• AS2-Version: 1.1
• AS2-From: "ACME-RETAIL"
• AS2-To: "DELTA-SUPPLY"
• Message-Id: <20260514093001@acme-retail.example>
• Disposition-Notification-To: as2@acme-retail.example
• Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha256

The sender-receiver pair may also have negotiated an alternative channel: OFTP2 (RFC 5024) for automotive OEMs, SFTP for low-volume flows between trusted partners, AS4 (OASIS ebMS 3.0) inside the PEPPOL eDelivery network. The principle — encryption, signature, acknowledgment — remains the same.

5. Reception and MDN

The supplier's AS2 agent receives the POST. It verifies the S/MIME signature against the public key on file for partner ACME-RETAIL, decrypts the payload if encrypted, and computes a MIC (Message Integrity Check) over the received content. It then returns a signed MDN (Message Disposition Notification) containing that MIC. If the sender finds the same MIC it computed at sending time, it has a cryptographic proof of non-repudiation of receipt (NRR, RFC 4130 §2.3.1).

The MDN may be synchronous (body of the HTTP response to the initial POST, easy to correlate) or asynchronous (a new inbound POST a few seconds later, reconciled via Original-Message-ID). The choice is negotiated at partner enrolment.

6. Unwrapping and parsing

The cleartext EDIFACT payload is then handed to the supplier's EDI engine. Three consecutive passes follow:

1. Syntactic tokenisation — a parser reads segment by segment respecting the separators declared by UNA or by default (', +, :, ? as escape).
2. Envelope validation — UNB/UNZ consistency check (same interchange control reference, interchange counter) and UNH/UNT consistency (same message reference, segment counter).
3. Semantic validation — check that every present segment is licit for an ORDERS message in the D.96A directory (mandatory segments present, forbidden segments absent, valid qualifier codes). This is exactly the role of ediverse's EDIFACT validator, which runs these three passes locally in the browser.

7. CONTRL acknowledgment and business response

If every validation passes, the engine immediately — typically within the second — emits a CONTRL message of positive reception. CONTRL is the syntactic acknowledgment message defined by ISO 9735 part 4. The UCI segment references the acknowledged interchange (here CTRL000042), and the 7 code in component 0083 means "Interchange received".

UNB+UNOC:3+5410000000456:14+5410000000123:14+260514:0931+CTRL000043'
UNH+1+CONTRL:D:96A:UN'
UCI+CTRL000042+5410000000123:14+5410000000456:14+7'
UCM+1+ORDERS:D:96A:UN+7'
UNT+4+1'
UNZ+1+CTRL000043'

In a second time — a few seconds to a few minutes later, the time the business application qualifies the order against catalogue, stock and customer credit — the supplier system emits an ORDRSP message that travels in the reverse direction, going through exactly the same steps 2 to 6 in the opposite order. The interchange loop is then closed.

Timed example

On a nominal exchange between operational partners, the "order validated → CONTRL received" latency is typically between 3 and 15 seconds. The "order validated → ORDRSP received" latency depends on the supplier's information system and the complexity of qualification: a few minutes to a few hours.

Where it breaks — failures at joints

Trouble nearly always lives at the joint between two steps:

• Step 2 → 3 — A non-ASCII character (è, é, ç) in free data while the character set declared in UNB is UNOC:3 (ISO 8859-1). Depending on tolerance, the receiver may reject syntactically.
• Step 4 → 5 — Wrong certificate. The S/MIME signature fails to verify: the receiving agent returns an error MDN, the sender never receives a CONTRL, and the buyer's information system keeps waiting.
• Step 6 → 7 — Incorrect UNT counter (wrong segment count), or UNH reference not matching UNT. The validator emits a negative CONTRL; fix on the mapping side.
• Step 7 → ORDRSP — Application processing time exceeds the buyer's ORDRSP SLA, triggering a manual chase. The ratio of partners "out of SLA" is usually the most-tracked KPI in an EDI operations team.

Further reading

• EDIFACT ORDERS D.96A — the full structure of the message used in this example.
• EDIFACT CONTRL D.96A — the structure of the syntactic acknowledgment.
• AS2 — the full detail of the transport protocol and the MDN loop.
• Protocols, in brief — the AS2 / OFTP2 / SFTP / AS4 / VAN comparison.
• EDIFACT Validator — to test each step on your own message.