EDI Segments and Elements, Explained

What are EDI segments and elements?

A segment is a single line inside an EDI file, identified by a short code like N1, REF, or DTM, that groups related pieces of data together. An element is one individual field inside that segment, separated from the others by a delimiter character. SPS Commerce defines a segment as a group of related data within a transaction set, with a data element being an individual value within it, such as a quantity or date.

If you've read our earlier posts on the 856 ASN, the 214 shipment status, or the 810 invoice, you already know these transaction sets by name and purpose. This post is about the layer underneath them: the actual grammar the file is written in. Once you can read segments, elements, and qualifiers, you can open any raw EDI payload during a support call and know what you're looking at, without waiting for someone to run it through a translator first.

Segment vs. element vs. qualifier: the part everyone confuses

These three terms get used interchangeably in meetings, which causes real confusion when someone says "check the qualifier" and a junior analyst goes hunting through the wrong part of the file. They're not the same thing, and the difference matters when you're debugging.

A segment is the line itself. EDI Basics defines a segment as a part of an EDI message made up of related data elements separated by a delimiter, conveying part of the business transaction. Segments are named by a segment identifier, a short code such as REF, DTM, or N1, that tells the parser what kind of data follows.

An element is a field inside that segment. EDI Basics calls the element the smallest item of information in the standard, and elements are referenced by position, so the second field in an REF segment is REF02, the third is REF03, and so on. Stedi's docs note that elements always sit inside a segment and are separated from each other and the segment ID by delimiters such as an asterisk or pipe character.

A qualifier is a special kind of element: a short code that tells you how to interpret the element sitting next to it. It doesn't carry the business data itself, it tells you what the following field means. One element is said to "qualify" the second element and is therefore called a qualifier, and these are often two to three-digit codes defined in the ANSI standards. Take the DTM segment. The first element of a DTM segment is the date/time qualifier and the second element is the date itself, the same pattern applies to REF, where the first element is the reference identification qualifier and the second is the actual reference number. Without the qualifier, "20260415" is just a string of digits. With DTM*011 in front of it, it's a shipped date. With DTM*017, it's an estimated delivery date. Same eight digits, completely different meaning to the receiving system.

Don't confuse any of this with a delimiter, which is simply the character that separates one piece from the next. Element separators are often an asterisk, sub-element separators are often a caret or colon, and segment terminators are often a tilde or newline, and none of these characters are allowed to appear inside the actual data, because that would break the parser.

How segments and elements nest inside the envelope

Segments don't float free in a file. They sit inside a transaction set, which sits inside a functional group, which sits inside an interchange envelope. The X12 message structure runs from the Interchange Envelope, identified by the ISA/IEA pairing, down through the Functional Group, identified by GS/GE, down to the Transaction Set, identified by ST/SE. The transaction set itself, an 856 or an 850, is the collection of segments in a specific order. Inside those segments are your elements, and inside some elements are sub-elements, called composite elements, when a single field needs to carry more than one piece of information at once.

EDIFACT users work with the same logic under different labels. Instead of ISA/GS/ST you get UNB (interchange header) and UNH (message header), and instead of an asterisk you'll typically see a plus sign as the element separator and a colon as the sub-element separator. EDIFACT's segment delimiter is an apostrophe, its element delimiter is a plus sign, and its sub-element delimiter is a colon, and just like X12, a composite data element in EDIFACT typically has the value in the first position and the qualifier in the second. If you work with European automotive OEMs on EDIFACT DELFOR or DESADV messages, the nesting is identical, only the segment names and punctuation change.

Reading a real EDI 856 ASN fragment, segment by segment

Here's a simplified fragment of what an 856 Advance Ship Notice looks like on the wire, the kind of file a retail supplier sends after a truck leaves the dock:

ST*856*0001~
BSN*00*SHIP0001*20260414*0800~
DTM*011*20260414~
HL*1**S~
TD5*B*2*FDEG*M~
HL*2*1*O~
REF*BM*BOL998877~
DTM*017*20260416~
HL*3*2*I~
LIN*1*UP*012345678905~

Walking it line by line:

• ST*856*0001 is the transaction set header segment, marking the start of the 856 and assigning a control number that must match the SE segment later in the file.
• DTM*011*20260414 uses qualifier 011, meaning shipped date, so April 14, 2026 is when the shipment left the origin, not when it's expected to arrive.
• HL*1**S is a hierarchical level segment marking this as the shipment level. The Hierarchical Level detail segment is the only required detail segment in an 856, and it establishes the content hierarchy and dependencies among groups of data segments. HL loops nest, so shipment contains order, order contains item, exactly like the ISA/GS/ST envelope nests around the whole file.
• TD5*B*2*FDEG*M carries carrier and routing information: mode of transport, routing sequence code, and the carrier's SCAC-style identifier.
• REF*BM*BOL998877 uses the BM qualifier, meaning this reference number is a bill of lading number, not a purchase order number (which would use a PO qualifier instead).
• DTM*017*20260416 uses qualifier 017 this time, estimated delivery date. Notice it's the same segment ID as before, DTM, but a different qualifier changes what the date means entirely.
• LIN*1*UP*012345678905 identifies the item using a UP qualifier, meaning UPC code.

This is exactly why qualifiers matter for compliance. If your mapping software sends DTM*017 (estimated delivery) when the trading partner spec calls for DTM*011 (shipped date), the file will parse fine and pass basic validation, because 011 and 017 are both valid qualifier codes. Nothing breaks at the syntax level. But the retailer's system now records the wrong date type against your shipment, which shows up later as a chargeback for an ASN that "doesn't match" the actual delivery, even though every number in the file was technically correct. There are more than 100 qualifiers available in the EDI standards just for date and time segments alone, which is exactly why getting the right one matters more than it looks like it should.

Why this still matters when everyone is moving to APIs

JSON and REST payloads encode the same logical structure, they just use different punctuation. A nested object is a segment. A key-value pair is an element. An enum value that changes how a sibling field is interpreted is a qualifier by another name. If you can read a DTM segment, you can read a shipDate versus estimatedDeliveryDate field in a carrier's API schema without much translation effort.

Modern TMS and carrier-connectivity platforms hide most of this from end users. Tools like MercuryGate, Descartes, Transporeon, and carrier tools like ShipEngine or Sendcloud present a clean UI on top of what is still, underneath, a mapping between segment-based EDI and field-based API calls. Cargoson's cloud-based TMS connects directly with carriers through pre-built API and EDI integrations, and lets customers request new carrier connections that get built for free within weeks. But when a carrier integration fails at 2am and the error message just says "invalid reference qualifier," the person on call still needs to know that REF01 is a code, not the data itself, to figure out whether the problem is a wrong qualifier or a missing element.

FAQ

Is a segment the same as a transaction set?
No. A transaction set, like an 856 or 850, is the whole document, built from many segments in a defined sequence. The segment is one line within that document.

What's the difference between a qualifier and a code?
A qualifier is a specific type of code: one whose job is to tell you how to interpret an adjacent element. Not every code in an EDI file is a qualifier, but every qualifier is a code.

Do EDIFACT and X12 use the same segment names?
No. EDIFACT wraps its data in UNB and UNH envelope segments, while X12 uses ISA, GS, and ST. The layered logic, envelope containing groups containing transaction sets containing segments, is the same in both standards; only the labels and delimiter characters differ.

Can I read raw EDI without special software?
For a short fragment like the one above, yes, once you know the segment IDs and qualifier codes for that transaction set. At production volumes across hundreds of trading partners, you need a mapper or translator to validate structure, apply partner-specific implementation guides, and catch qualifier mismatches before they become chargebacks.

Why do wrong qualifiers cause compliance failures instead of outright errors?
Because a wrong qualifier is still a syntactically valid code. The file parses, passes basic validation, and gets accepted, but the receiving system now stores the data under the wrong meaning. That mismatch surfaces downstream, often as a chargeback, long after the file itself was "successfully" transmitted.