X12 to EDIFACT: the crosswalk that actually matters
The transaction set mappings between X12 and EDIFACT are the easy part. The differences that break integrations are in structure, qualifiers and acknowledgement behaviour.
Every EDI introduction includes a table lining up X12 transaction sets against their EDIFACT
equivalents. 850 to ORDERS, 810 to INVOIC, 856 to DESADV. The table is correct and it is
also close to useless, because the mapping between message types is the part that never causes
trouble.
Where the real differences live
Acknowledgement behaviour. X12 gives you the 997 or 999. EDIFACT gives you CONTRL, which
covers both syntax acknowledgement and interchange receipt, and partners differ widely on whether
they send one at all. A flow that depends on a functional acknowledgement to close the loop needs
rethinking.
Qualifier philosophy. X12 tends toward dedicated segments with positional meaning. EDIFACT leans
on qualified composites, so the same NAD segment carries buyer, seller, ship-to and bill-to
depending on the qualifier in the first element. Mapping logic that assumes segment identity equals
party role will break on the first multi-party message.
Separators and release characters. EDIFACT has a release character, X12 does not. If your parser was written for X12 and you hand it an EDIFACT file containing an escaped separator inside a free text field, it will split the segment in the wrong place and the error will surface three steps downstream.
The practical takeaway
Treat them as two different languages that happen to describe the same business documents, rather than two dialects of one. The crosswalk table is a starting index, not a mapping specification.