How it worksPricingDocsTry the decoder

What is EDIFACT?

EDIFACT is the international standard for exchanging business documents electronically between organisations. If you have been handed an EDIFACT file and have no idea what you are looking at, this page is for you.

The short version

EDIFACT stands for Electronic Data Interchange For Administration, Commerce and Transport. It is a standard developed by the United Nations in the 1980s that defines a common format for business documents like purchase orders, invoices, and shipment notices. The idea was that if every company used the same format, they could exchange documents automatically without any human involvement.

The standard worked, to a degree. It became the dominant format for large retailers, logistics companies, and manufacturers in Europe, Australia, and much of Asia. Today, billions of dollars of transactions flow through EDIFACT every day. If you supply goods to a major retailer, a fuel company, or a distributor, there is a good chance they require EDIFACT.

The problem is that EDIFACT was designed in a different era. It is dense, cryptic, and completely unlike any modern data format. Developers who encounter it for the first time almost universally find it confusing.

What an EDIFACT message looks like

Here is a simple EDIFACT ORDERS message, the kind a retailer might send to a supplier when they want to place a purchase order:

Raw EDIFACT - ORDERS message
UNB+UNOA:2+5412345000013:1+4012345000014:1+260524:1000+1'
UNH+1+ORDERS:D:96A:UN'
BGM+220+PO-48291+9'
DTM+137:20260524:102'
NAD+BY+5412345000013::9++ACME Corp+123 Main St+Sydney++2000+AU'
NAD+SU+4012345000014::9++Supplier Co'
LIN+1++4012345678901:SRV'
QTY+21:100:PCE'
PRI+AAA:29.99:CA'
UNS+S'
CNT+2:1'
UNT+11+1'
UNZ+1+1'

If you have never seen EDIFACT before, that probably looks like noise. Each line is a segment. Each segment starts with a three-letter tag that identifies what kind of data it contains. Values within a segment are separated by plus signs. The apostrophe at the end of each line marks the end of a segment.

Breaking it down

Here is what each segment in that message actually means:

UNBInterchange envelopeIdentifies the sender and receiver of the message, the date and time, and an interchange control number.
UNHMessage headerMarks the start of an individual message and identifies the message type. ORDERS:D:96A:UN means this is an ORDERS message using version D96A of the UN/EDIFACT standard.
BGMBeginning of messageThe document function code (220 = purchase order), the order number, and a message function code (9 = original).
DTMDate/time periodA date or time relevant to the message. The qualifier 137 means this is the message creation date. 20260524 is the date. 102 is the date format code (CCYYMMDD).
NADName and addressIdentifies a party in the transaction. BY = buyer, SU = supplier. The GLN (Global Location Number) is used to uniquely identify each organisation.
LINLine itemEach product or service line in the order. The GTIN (barcode) identifies the specific product.
QTYQuantityThe quantity ordered. Qualifier 21 = ordered quantity. 100 units, PCE = pieces.
PRIPrice detailsThe price. AAA = calculation net price. 29.99 per unit. CA = catalogue price.
UNSSection controlSeparates the detail section from the summary section.
CNTControl totalA count for validation. 2:1 means there is 1 line item.
UNTMessage trailerMarks the end of the message and includes a count of segments for validation.
UNZInterchange trailerMarks the end of the interchange and includes a count of messages.

Why EDIFACT is so difficult to work with

It is not self-describing

A JSON or XML file tells you what each field means. EDIFACT uses two and three letter codes that mean nothing without the specification document.

Every partner does it differently

EDIFACT is a standard with a huge amount of flexibility. Each trading partner uses segments, qualifiers, and field positions differently. What works for one partner breaks for the next.

Dozens of versions exist

EDIFACT has been updated regularly since the 1980s. D96A, D01B, D04A are all different versions. Partners may use different versions and even mix elements between them.

Qualifiers everywhere

Almost every value in EDIFACT is accompanied by a qualifier code that gives it context. The DTM segment alone has over 100 different qualifier codes for different types of dates.

The specification is enormous

The complete UN/EDIFACT specification runs to thousands of pages. Most developers never read it and instead reverse-engineer messages from examples.

It leaks into your architecture

Once you start parsing EDIFACT, segment names and qualifier codes tend to spread into your database schemas, API responses, and internal models.

Common EDIFACT variants

Several industry-specific subsets of EDIFACT exist with their own rules and conventions:

EANCOMRetail and FMCG globallyA subset of UN/EDIFACT developed by GS1, widely used in retail and consumer goods. Most Australian supermarkets and large retailers use EANCOM.
GS1 EANCOM D.01BModern retail standardThe most common version of EANCOM in use today. If you supply to Woolworths, Coles, or similar retailers, you are likely using this.
EDIFACT D96AOlder retail and general useAn older version still widely used, particularly by partners who have not upgraded their systems in some time.
ODETTEEuropean automotiveAn EDIFACT subset used in the European automotive supply chain.

EDIFACT vs X12

If you have worked with US trading partners, you may have encountered X12, also called ANSI X12. X12 is the North American equivalent of EDIFACT. Both serve the same purpose but use different syntax and segment names.

EDIFACT is the dominant standard in Europe, Australia, New Zealand, and most of Asia. X12 dominates in the United States and Canada. If you are dealing with APAC trading partners, you are almost certainly dealing with EDIFACT.

Got an EDIFACT message you need to decode?

Paste any raw EDIFACT message into our free decoder and get back a plain English breakdown of every segment and field.

Try the free decoderEDIFACT message types