Skip to content
Chokmah

Glossary · Integration

EDI and EDIFACT

EDI is the structured, computer-to-computer exchange of business documents; EDIFACT is the United Nations standard, defined by ISO 9735, that specifies the syntax those documents use in trade and transport.

EDI is the structured, computer-to-computer exchange of business documents. EDIFACT is the United Nations standard, defined by ISO 9735 and maintained by UN/CEFACT, that specifies the syntax those documents use in shipping, freight and customs. It nests from interchange to message to segment to data element.

  • EDI is computer-to-computer exchange of business documents in a standard format.
  • EDIFACT is the UN standard for EDI syntax, defined by ISO 9735 and maintained by UN/CEFACT.
  • Its hierarchy: interchange (UNB/UNZ), message (UNH/UNT), segment, composite, data element.
  • Directories are versioned like D.24B; message types include IFTMIN, COPARN, BAPLIE, VERMAS.
  • In logistics the automatable workflow is the exception queue, not the happy path.

Also known as: electronic data interchange, UN/EDIFACT

EDI is the structured, computer-to-computer exchange of business documents; EDIFACT is the United Nations standard, defined by ISO 9735, that specifies the syntax those documents use in trade and transport.

Where EDI is the practice (machines exchanging orders, invoices and shipping instructions without paper or email) EDIFACT is one specific grammar for it, and the dominant one in international shipping, freight and customs.

How EDI and EDIFACT work

UN/EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce and Transport) is maintained by UN/CEFACT and its syntax is the ISO 9735 standard. A message is a strict nested hierarchy. The interchange is the outer envelope, opened by a UNB segment and closed by UNZ. Inside sit one or more messages, each wrapped by a UNH header and UNT trailer. Each message is an ordered sequence of segments; each segment carries composite data elements and simple data elements, drawn from standardised directories that are versioned by release: for example D.24B, the second release of 2024.

That rigidity is the point: two systems that have never met can parse the same file identically because the structure is fixed. Transport uses a well-known set of message types: IFTMIN and IFTMBF for booking instructions, IFTSTA for status, COPARN for container announcements, BAPLIE for vessel stowage, VERMAS for verified gross mass, CUSDEC for customs. In practice, trading partners layer their own required elements and conventions on top of the base standard, which is where the real complexity lives.

Why EDI and EDIFACT matter for enterprise AI adoption

For a logistics, freight or shared-services GCC, EDI is the nervous system of the operation: every booking, movement and customs filing flows through it. And it is exactly the kind of high-friction, rule-dense, measurable back-office workflow where AI value is real, provided you point it at the right part.

The right part is the exception queue, not the happy path. Standard-conforming messages are already handled automatically by mapping software; nobody needs AI for those. The cost accumulates when a partner sends a message that fails validation, uses a non-standard mapping, or omits a required element. It drops out for a human to diagnose at the segment level. That queue is where hours disappear, and where triage, classification and drafted corrections can genuinely help. This is a natural fit for tool use over a parser and for retrieval over partner-specific mapping rules.

Common mistakes with EDI and EDIFACT automation

The first mistake is aiming AI at the happy path, where deterministic mapping already works and adds nothing but risk. The value is in the messy exceptions, not the clean 95%.

The second is letting an agent silently alter a legally binding document. An EDIFACT booking or customs filing has legal weight; a system that rewrites a segment without human sign-off is exactly the workflow you should refuse to fully automate. Keep a human in the loop on any change to a binding trading-partner document. The third is treating partner-specific quirks as noise. They are the domain knowledge, and a pipeline that does not encode them will misclassify the exceptions that matter most.

Related terms

How Chokmah approaches EDI and EDIFACT

This is our domain wedge, and the expertise is real even though the engagement would be new to your operation. We have debugged EDIFACT at the segment level in production, and we bring that to a workflow sprint aimed squarely at the exception queue (triage, classification and drafted corrections) while the happy path stays with the deterministic mapping that already handles it. Non-negotiably, nothing that changes a legally binding trading-partner document ships without a human sign-off. It is the one workflow on the site where our claim is not a definition we read but a thing we have shipped.

Sources

  1. UNECE / UN/CEFACT, Introducing UN/EDIFACT (ISO 9735 syntax standard). https://unece.org/trade/uncefact/introducing-unedifact

Frequently asked questions

EDI is the general practice: exchanging business documents machine-to-machine in a structured format instead of by email or paper. EDIFACT is one specific standard for doing it: the United Nations syntax, defined by ISO 9735, that dominates international shipping, freight and customs. Other EDI standards exist, such as ANSI X12 in North America. So all EDIFACT is EDI, but not all EDI is EDIFACT; EDIFACT is the grammar, EDI is the activity.

As a nested hierarchy. An interchange is the outer envelope, opened by a UNB segment and closed by UNZ. Inside are one or more messages, each wrapped by a UNH header and UNT trailer. Each message is a sequence of segments; each segment holds composite and simple data elements. The composites and elements draw on standardised directories, versioned by release such as D.24B. This rigid structure is what lets two systems parse the same file identically.

Transport and freight use a well-known set: IFTMIN and IFTMBF for firm booking instructions, IFTMBC for booking confirmation, IFTSTA for shipment status, COPARN for container announcements, COARRI and CODECO for terminal movements, BAPLIE for vessel bay plans and stowage, and VERMAS for verified gross mass. Customs adds CUSDEC and CUSCAR. Each has a defined segment sequence, and trading partners often layer their own required elements on top.

The happy path is already automated by mapping software; the value is in the exception queue. When a partner sends a message that fails validation, uses a non-standard mapping, or omits a required element, it drops out for a human to fix, and that queue is where cost and delay accumulate. AI can triage, classify and draft corrections for those exceptions. What it must not do is silently alter a legally binding trading-partner document; that step keeps a human in the loop.

Put the concept to work

We install working agentic workflows, not vocabulary. Book a free AI Reality Check.