Segments in X12 EDI contain a group of logically related elements that are combined to communicate specific information between two trading partners. Each X12 transaction consists of segments sent in a pre-defined sequence, where each segment is separated from one another by segment terminators (e.g., ~, \n, etc.). For example, here is a snippet of an 850 Purchase Order that contains a BEG and CUR segment.

BEG***00*AB*308174864**20220321~
CUR***BY*USD~

The X12 standard defines a list of thousands of segments, and each segment has a unique segment ID, name, description, and a set of elements that it contains. These segment attributes are fixed; they do not change, regardless of what transaction set they are sent in. Most segments appear in many transaction sets, while others are unique to individual transaction sets.

When a segment is used in a transaction set, the X12 standard provides additional attributes, such as its sequence, requirement, and repetition. These attributes are variable; they change based on which transaction set the segment is found in.

​
Segment attributes

​
IDs

Each segment is given a unique ID that can be two to three characters in length, and may be a combination of letters, or letters and numbers. For example, the Party Identification segment has the ID N1, the Tax Reference segment has the ID TAX, and the Date/Time segment has the ID G62. Sometimes, the segment ID is referred to as the segment name or tag.

​
Names

Each segment is given a name, which is a short, generic description of what the purpose of the segment is. For example, the name of the ACK segment is Line Item Acknowledgement, the name of the AT1 segment is Bill of Lading Line Item Number, and the name of the ITA is Allowance, Charge or Service. While each segment is given a name, in practice, the segment ID is used for identifying the segment, not the name.

​
Descriptions

In addition to the segment name, X12 provides a longer description to explain what the segment represents and how it is used. For example, the BEG segment (Beginning Segment for Purchase Order) has the following description:

To indicate the beginning of the Purchase Order Transaction Set and transmit identifying numbers and dates.

​
Elements

Every segment contains one or more elements sent in a pre-defined order. Regardless of which transaction set the segment is found in, the segment always contains the same list of elements. However, depending on the element requirements of that segment and your trading partners implementation guide, some elements are considered optional.

You can read more about elements and how they are used in the Elements in X12 EDI article.

​
Sequence

For every transaction set, the X12 standard defines which segments can be sent and in what order. The order is defined by the sequence number (sometimes called position) that the segment has in the context of that transaction set.

For example, in the 180 Return Merchandise Authorization and Notification transaction, the ST segment (Transaction Set Header) is the first segment that indicates a new transaction is being sent and so it is given the 0100 position of the transaction. The BGN segment is next up in the sequence, and has the 0200 position. RDR has 0300, PRF has 0400, and so on. The position number has no semantic meaning, it is purely to indicate where a segment goes in the context of its neighbors. Even if a segment is not used or sent, the position of the following segments do not change.

Depending on the transaction set, the same segment can be used multiple times in different positions. The sequence number is useful here because it can help disambiguate which iteration of the segment a trading partner is referring to.

For example, the DTM (Date/Time Reference) segment is found four times in the 180 transaction; once at the 0500 position, again at the 0520 position, again at the 1300 position, and finally at the 1900 position. On the other hand, the 252 Insurance Producer Administration transaction only contains one DTM segment at the 0040 position.

While segment positions are useful for validation and debugging, in practice they are rarely used to describe a segment. For example, it’s rare to hear someone refer to the DTM as “the DTM at the 140 position.” Moreover, these positions are not always correctly calculated in the implementation guides so you shouldn’t rely on them. Instead, use the logical structure of the transaction set (e.g., heading, detail, summary, and/or loops) to explain the position.

For example, the implementation guide of the 810 invoice below defines three REF segments with positions 050, 110 and 120. So, instead of using the positions (050, 110, or 120) you can refer to them as:

  • REF under the Heading
  • REF in the N1 loop
  • REF under detail

​
Requirements

When a segment is used in a transaction set, the X12 standard specifies two types of segment requirements: mandatory or optional. In addition to the X12 requirements, trading partners will often deviate slightly from the standard to suit their business needs.

  • Mandatory: segments marked as mandatory (M) must be present in the EDI transaction.
  • Optional: segments marked as optional (O) may be present in the EDI transaction.

According to X12, trading partners can mark optional segments as mandatory, but they should not mark mandatory segments as optional. Additionally, while some implementation guides will mark the first segment of a loop as optional, technically all segments that are the first segment in the loop are required.

​
Repetition

While some segments might be present in more than one position in a single transaction set, repetition pertains to something else. The repetition attribute determines how many time the same segment or loop can be repeated in the same position. On implementation guides, this is usually referred to as the Max Use of a segment.

The repetition of a segment in a transaction set can be indicated by one of the following:

  • 1, which means this segment cannot be repeated.
  • Any number greater than one, which means this segment may be repeated up to, but no more than, the number indicated.
  • >1, which means that this segment can be repeated an infinite number of times

Was this page helpful?

Relational conditionsSegments - Requirements