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.

​
String/Alphanumeric (AN)

Elements with the string data type are symbolized by the code AN. Strings may contain any sequence of characters, including letters, digits, spaces, punctuation marks, spaces, tabs, and/or special characters.

Typically, elements with the string data type are used in free-form fields, where the element name or description explains what information should be contained in the element, and how to interpret it.

While elements with a string data type can support any character, they must not contain the element separator (often *), sub-element separator (often ^ or :), or segment terminator (often ~) specified in the envelope; those are reserved solely for those functions. Furthermore, for any EDI transaction that specifies a release character in the ISX segment (v7040 or later), you cannot use that release character in any element.

Examples of string elements include:

  • Red
  • Working hours: from 9AM to 5PM
  • New York
  • X253N0123

​
Numeric (N0, N2, N4, N6)

Elements with the numeric data type are symbolized by N. All elements with a numeric data type must contain only digits and an optional minus (-) sign to indicate a negative value.

The N indicates that the data type is numeric, and the 0, 2, 4, or 6 indicate the number of implied decimal positions. N0 implies the number is an integer (i.e., whole numbers), N2 implies the number contains two decimal positions, N4 implies the number contains four decimal positions, and N6 implies the number contains six decimal positions,

For example, if a number is sent in an element with the data type N0, it should be interpreted as a whole number, exactly as it is shown.

Examples of N0 elements include:

  • 1
  • 100
  • -645
  • 812

If a number is sent in an element with the data type N2, it should be interpreted as if it has two decimal places.

Examples of N2 elements include:

  • 123.45 would be sent as 12345
  • -5 would be sent as -500
  • 100 would be sent as 10000

In practice, the N2 data type is often used in elements that describe a monetary amount. For example, the 610 (Amount) element is used in the TDS01 to represent the invoice total amount, and has a data type of N2. This implies the value of TDS01 has two decimals. For example: TDS*1000 implies a dollar value of $10, not $1000.

​
Decimal number (R)

Elements with the decimal number data type are symbolized by the code R. In an element with a decimal data type, decimals are optional for all integers, but are required for all fractional values. Decimal numbers also support a leading minus (-) sign, if needed, whereas the absence of a minus sign implies a positive value. Therefore, the plus sign (+) should not be transmitted.

The minus sign and the decimal point are not counted when determining the length of the data element. Additionally, all leading zeros in an element with a decimal number type should be suppressed, unless needed to satisfy minimum length requirements.

Examples of decimal elements include:

  • 12.345
  • 2000
  • 765.000
  • -95

​
Dates (DT)

Elements with the date data type are symbolized by the code DT. Based on the X12 version, data formats are treated differently.

Before v4010, all dates were in the YYMMDD format, where YY represents the last two digits of the calendar year, MM represents the month (01 to 12), and DD represents the day of the month (01 to 31).

Examples of dates in YYMMDD format include:

  • 980127, which indicates January 27th, 1998
  • 220815, which indicates August 15th, 2022

Starting from v4010, all dates are represented in the CCYYMMDD format, where CC represents the first two digits of the calendar year, YY represents the last two digits of the calendar year, MM represents the month (01 to 12), and DD represents the day of the month (01 to 31).

Examples of dates in CCYYMMDD format include:

  • 20230202, which indicates February 2nd, 2023
  • 20220120, which indicates January 20th, 2022

Note: The ISA09 (interchange date) only supports the YYMMDD date format, regardless of which X12 version is used.

​
Time (TM)

Elements with the time data type are symbolized by the code TM. Time in the X12 standard is expressed in a 24-hour clock format (e.g.,HHMM, HHMMSS, HHMMSSD, or HHMMSSDD). HH is the numeric expression of the hour (00 to 23), MM is the numeric expression of the minute (00 to 59), SS is the numeric expression of the second (00 to 59), and DD is the numeric expression of the decimal seconds. Decimal seconds are expressed as follows: D = tenths (0 to 9) and DD = hundredths (00 to 99).

Examples of time elements include:

  • 1845, which represents 18:15 in HHMM format
  • 091530, which represents 09:15:30 in HHMMSS format
  • 10220302, which represents 10:22:03:02 in HHMMSSDD format

Note: Time elements are often accompanied by another element in the same segment, indicating which timezone the time is in.

​
Identifier (ID)

Elements with the identifier data type, sometimes referred to as a code, are symbolized by the code ID. An element with an ID data type must always contain a value from a predefined list of values that is maintained by X12, other bodies that are recognized by X12, or are universally known (e.g., Standard Carrier Alpha Codes (SCACs), or state/province codes). The intent of the identifier data type is to allow computers to validate data elements based on a standard list of codes, without having to agree upon the meaning of each code.

For the elements that contain a predefined list of X12 identifiers, each one has a code and a description (e.g., ST and Ship To). An extended code definition, which provides additional information to help explain the meaning of the code, may also be supplied in addition to the identifier description.

Examples of pre-defined X12 identifier codes include:

  • ST - ship to
  • Z7 - mark for party
  • YC - bail payor

In addition to elements with a predefined list of X12 identifier codes, there are several elements that have the ID data type without a predefined list. Here are some examples:

  • Element 156 (State or province code) should contain the two-digit code of a US state (e.g., CA for California), Canadian provinces (e.g.,ON for Ontario), or any other state/province/region code specific for a given country (must be exactly two characters).
  • Element 26 (Country Code) should contain a two-letter country code defined by ISO 3166 (e.g., US for the United States of America, IN for India).
  • Element 140 (SCAC) should contain a two- to four-character code that represents a carrier, as defined by the National Motor Freight Traffic Association (NMFTA). However, in practice, SCACs are often sent as mutually agreed upon values.

While X12 is standardized, in practice, many trading partners will deviate from these predefined lists. X12 provides a mechanism for doing this, by supporting “mutually-defined” codes, signified by the codes Z, ZZ, or ZZZ. While mutually-defined codes are available, some trading partners might choose to “break” the X12 standard by utilizing their own custom codes and descriptions in their implementation guides. Lastly, some trading partners will interpret the predefined codes differently (e.g., they will use the WH (warehouse) qualifier code, as opposed to the SF (ship from) code).

​
Binary (B)

Elements with the binary data type are symbolized by the code B. A binary data element contains a sequence of bytes. Those bytes may include characters that normally have special meaning, like the segment separator, or the element separator. For that reason, binary data isn’t parsed like the rest of the X12 document. Instead, binary data always comes with a length, so that it’s clear where the binary data ends.

There are only a few segments with a binary data element.

  • BIN is used to transfer files. It always comes as part of a loop that also include the EFI segment. EFI contains the metadata of the file, BIN contains the contents.
  • BDS (v4020 and up) is also used to transfer files, but it’s paired with OOI instead of EFI. OOI is a more flexible way to encode a file’s metadata. Unlike BIN, BDS includes an element that tells you how the binary data is encoded, for example base64, uuencoding, no encoding, etc.
  • S3S and S4S are used for sending data securely. They both use binary (v4020 and up) to send encrypted and/or compressed data.

Stedi supports reading and writing binary encodings that are valid UTF-8 strings such as ASCII and Base64. It does not support unfiltered binary data.

Was this page helpful?

Elements - RequirementsRelational conditions