The EDIFACT Envelope: UNA, UNB, UNG, and UNH Explained

Every UN/EDIFACT interchange is wrapped in nested envelopes that handle delimiters, routing, and control. Understanding this structure lets you find where messages begin and end, identify the trading partners, and read the message version. The EDIFACT envelope uses UNA, UNB, UNG, and UNH.

The levels, from outside in

• UNA - an optional service string that declares the delimiters.
• UNB / UNZ - the interchange envelope, the outermost wrapper.
• UNG / UNE - an optional functional group.
• UNH / UNT - the message header and trailer, wrapping one business document.

This parallels the X12 ISA/GS/ST structure, but with EDIFACT syntax and a few differences worth knowing.

UNA: the service string advice

The optional UNA segment, when present, sits at the very start of the interchange and declares the six special characters in a fixed order: component separator, element separator, decimal mark, release character, a reserved character, and the segment terminator. A typical UNA reads UNA:+.? '. If a file has no UNA, the defaults apply (:, +, ., ?, space, '). A parser reads UNA first so it can correctly split everything that follows.

UNB: the interchange header

The UNB identifies the interchange. Unlike the fixed-width X12 ISA, the UNB is delimiter-based and variable length. Its key data includes:

• Syntax identifier and version, such as UNOC:3, which says which character set and syntax level the interchange uses.
• Sender and receiver identification, often with a qualifier indicating the code scheme (for example 14 for a GLN).
• Date and time of preparation.
• Interchange control reference, which the closing UNZ must match.

UNG: the functional group (optional)

The UNG groups messages of the same type, similar to the X12 GS. It is optional in EDIFACT and many interchanges omit it, placing messages directly inside the UNB. When present, it carries a group reference that the closing UNE echoes.

UNH: the message header

The UNH is where an actual message begins, and it carries something X12 handles differently - an explicit version. A header like UNH+1+ORDERS:D:96A:UN reads as message reference 1, message type ORDERS, directory D, release 96A, controlling agency UN. That version string is essential: it tells the receiver exactly which dictionary of segments and codes to apply, because message definitions change between releases like D96A and D01B. The closing UNT repeats the message reference and states the segment count.

How references tie it together

As in X12, each level's header and trailer must agree:

• UNB interchange control reference = UNZ reference
• UNG group reference = UNE reference (when groups are used)
• UNH message reference = UNT reference

These matched references are integrity checks that detect truncation or malformed structure.

A skeleton example

UNA:+.? '
UNB+UNOC:3+5790001234567:14+5790007654321:14+240220:0900+REF00001'
UNH+1+ORDERS:D:96A:UN'
... message body ...
UNT+11+1'
UNZ+1+REF00001'

Reading the envelope: a UNA declares standard delimiters; the UNB shows an interchange from GLN 5790001234567 to GLN 5790007654321 on 2024-02-20, reference REF00001; inside is one ORDERS message under directory D96A. The references REF00001 and 1 match their trailers.

Why this matters when troubleshooting

• The UNA (or its absence) tells you how to split the whole file.
• The UNH version determines which segment definitions apply - a frequent source of partner mismatches.
• Mismatched control references point to structural corruption.

Frequently asked questions