Elements in X12 EDI
Elements in X12 EDI are the primary source of information exchanged in an EDI transaction. Segments logically group elements together in order to convey specific information. You will always see elements inside of a segment, and elements are separated from the segment and other elements by delimiters (e.g.,
Outside the context of a segment, the X12 standard defines an ID, a name, description, data type, and min and max length for every element. These element attributes are fixed; they do not change, regardless of what segment the element is found in.
When an element is in the context of a segment, the X12 standard provides additional attributes, such as the element’s position and its requirement. These attributes are variable; they change based on which segment the element is contained in.
For example, each element in the BEG segment below has its own fixed attributes, and then additional attributes based on the fact they are used in the
BEG segment. For example, the 373 Date element always has the
date data type and a min and max length of eight characters; but when it is used in the fifth element of the
BEG segment (e.g., the
20220610 below), it is always mandatory.
Each element is given a unique ID that can be one to four characters in length. There are more than 2,000 unique elements in the X12 EDI standard. For example, the
Purchase Order Type Code element has the ID
92, whereas the Date element has the ID
373. The IDs of simple elements are numeric, but composite data elements are prefixed with a
C, and elements found in interchange segments are prefixed with
You can see the full list of elements and their IDs here.
Each element is given a name, which is a short, generic description of what data the element represents. For example, the name of the
324 element is
Purchase Order Number and the name of the
100 element is
Currency Code. While the element is given a unique element ID, in practice, the element name is used for identifying the element, not the ID.
You can see the full list of elements and their names here.
In addition to the element name, X12 provides a longer description to explain what the element represents and how it is used. For example, the
373 Date element has the following description: date expressed as
CC represents the first two digits of the calendar year.
When an element is in the context of a segment, X12 will occasionally provide semantic notes, which explain how that element is used specifically inside of the segment. For example, the
373 Date element has an extra note when it is in the
BEG segment: in the
BEG, the Date element (
BEG05) is the date assigned by the purchaser to purchase order.
All elements in X12 have a specific data type: elements can be a string (i..e., alphanumeric), number, decimal, date, time, code, or binary. These data types dictate the kind of data that can be sent in a specific element and how it should be treated by external systems ingesting the EDI.
Note: Element separators (often
*), sub-element separators (often
:), and segment terminators (often
\n) cannot be used in any elements, regardless of data types.
|String / Alphanumeric||AN||May contain any alphanumeric characters, including letters (upper & lowercase), numbers, punctuation marks, spaces, and more.|
|Number||N0, N2||Must contain only digits (no decimals), and can contain a minus sign for negative values. The N indicates it is a number, and ||N0 |
|Decimals||R||May contain numbers with decimal points (if needed) and a minus sign for negative values.|
|Dates||DT||Date formats in X12 depend on trading partner specs and the version used. X12 versions before v4010 used YYMMDD format. After v4010, CCYYMMDD format is preferred, where CC represents the first two digits in the calendar year. ISA-09 (interchange date) is an exception and uses YYMMDD.||YYMMDD |
|Time||TM||Time is always expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99). Time elements are usually followed by a qualifier code representing time zone.||HHMM |
|Codes||ID||Most elements with "code" data types have a list of valid codes defined by the X12 standard. These codes are usually "qualifiers" or "values" that are shorthand for a value. Codes are never longer than 4 digits. Some codes are not provided by X12, like 156 (state or province code) or 24 (equipment type).||Qualifiers |
|Binary||B||Elements with the binary data type may contain binary data (i.e., a string of octets which can assume any binary pattern from hexadecimal 00 to FF. Note: The maximum length is 15 characters for binary data. Only the BIN and BDS segments support elements with a binary data type.|
To learn more about element data types in X12 EDI, click here.
Each element is given a minimum and maximum length that they need to adhere to, as per the X12 standard.
The minimum and maximum length can vary from element to element. For example, some elements have fixed lengths like
NTE01 (Note Reference Code) which have a minimum and maximum length of three characters. On the other hand, some elements can contain a wide range of characters, like
NTE02 (Description), which supports a minimum of one character and a maximum of 80.
For elements with the decimal data type (
R), the count of characters does not include the optional decimal point, minus sign, or trailing exponent indicator
Note: If an element is optional and is not used in a segment, the length restrictions do not apply.
When an element is used in a segment, it occupies a position in that segment. The X12 standard defines what element is used in every position of a segment. While elements can be referred to by their ID and name (e.g., the
373 Date element in the
BEG), in-practice element positions are referred to by the segment acronym (e.g.,
TDS), followed by the position of the element in the segment (e.g.,
01). For example, the second element in the
TDS02, and so on. This is useful for communicating trading-partner requirements, as you can refer to an element as the TDS05.
The same element can be found multiple times, in different positions of a single segment. The position, accompanied by semantic notes, determines how to use that element. For example, the element
610 (Amount) is used four times in the
TDS segment, where the
TDS01 is the total amount of the invoice, and the
TDS04 indicates the total amount of terms discount.
Note: If an element is not present, it still occupies a position.
When an element is in the context of a segment, the X12 standard specifies three types of element requirements: mandatory, optional, or conditional. In addition to the requirements given by X12, trading partners will often deviate slightly from the standard to suit their business needs.
- Mandatory: Elements marked as mandatory (
M) must be present in the segment.
- Optional: Elements marked as optional (
O) may be present in the segment.
- Conditional: The presence of an element in a segment marked as conditional (
X) is dependent on the relational condition syntax rule used.
To learn more about element requirements in X12 EDI, click here.
A composite element contains a collection of component elements (also known as sub-elements). Component elements are functionally the same as the simple elements we explored above, only they have the composite element as the parent, not the segment.
Composite elements also have their own IDs, which begin with
C. For example,
C040 (Reference Identifier) is a composite data element.
For composite elements, the same position notation (e.g.,
REF04) is used, however, for component elements, the position is given as the name of their parent composite element +
C + position. For example, the second component element in
REF04 would be referred to as