X12 Standard
Element Requirements in X12 EDI
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. This is both expected and valid.
Trading partners share these requirements as implementation guides, usually via PDF. Most X12 implementation guides used in the industry were built using a tool called SpecBuilder, which creates a standard PDF format. We will use SpecBuilder PDFs and their terminology to explain element requirements below, but your trading partner might send these requirements in different format (e.g., CSV, Word, custom PDF).
In these implementation guides, the element requirements given by X12 are found in a column called Requirement (or Req for short). The Req column displays these requirements as
When you are building EDI integrations, make sure you pay close attention to element requirements, and how they deviate from the base X12 standard.
M for mandatory, O for optional, and C or X for conditional. If a trading partner deviates from the specifications given by X12, those deviations are usually found in a column called Usage or Attributes, and they use a different syntax, like Must use, Used, and Dependent.
X12 types
Mandatory
Mandatory elements are marked with anM in most implementation guides, but R (required) is used as well. If an element is defined as mandatory in a segment, then you cannot send X12 data without it. In most cases, transactions that are missing mandatory elements will either be stopped by the sender or rejected by the recipient.
For example, the BIG01 (Invoice Date) and the BIG02 (Invoice Number) in the BIG segment used in all X12 810 Invoices are mandatory elements. You cannot send an invoice without the invoice number and date.
Optional
Optional elements are marked with anO in most implementation guides.
These elements sometimes carry additional information in the notes section of the PDF, such as when the element should be used. If an element is marked as optional, it can be omitted in the data and the transaction would still be valid.
For example, the BIG03 (Purchase Order Date) and BIG04 (Purchase Order Number) in X12 810 Invoices are optional elements. According to X12, you can send an invoice without the corresponding purchase order number and date, and it would still be a valid transaction.
Conditional
Conditional elements, marked with either aC or an X, are a special case. Their usage depends on the other elements within the same segment. In some situations these elements might be mandatory, and in others – optional.
Whenever there is an element marked with a C or an X, there will be a corresponding Syntax Rules block on the same page. For example, on the DTM segment page below, the syntax rules appear below the last element definition.
In order to understand how and when to use an element that is marked as conditional, you first need to understand the X12 syntax rule used. Every syntax rule begins with an identifier: P, R, E, C, or L. The identifier is followed by two or more elements involved in the condition, where each element occupies two digits (e.g., 01, 05, 11).
Conditional rule definitions:
| Letter | Name | Condition | Example |
|---|---|---|---|
| P | Paired | If the first element is present, then all the other elements must be present. | P0102 |
| R | Required | At least one of the elements must be present. | R020304 |
| E | Exclusive | Only one of the elements may be present. | E0305 |
| C | Conditional | If the first element is present, then all the other elements must be present. | C0102 |
| L | List conditional | If the first element is present, then at least one of the other elements must be present. | L010308 |
Trading partner specific element requirements
The element requirements defined by the X12 standard dictate which elements are optional, mandatory, or conditional when used in a segment. However, most businesses do not use all the elements in the standard - and for those that they use, they often need to change their requirements. As such, they use the elements, and change their requirements, to best serve their business requirements. For example, your trading partners may decide that some elements—whether optional or conditional as per the standard—must be present in the data (e.g., are mandatory). On the other hand, this does not work in reverse; according to the X12 standard, you cannot mark elements that are mandatory as optional or conditional in your guide. In practice, some businesses break the X12 standard and ask trading partner’s to conform to their specification nonetheless. When a trading partner deviates from the base X12 specification, their implementation guide will usually contain a column titled Usage or Trading Partner Name Requirements. Instead of using the typicalM, O, C, and X syntax, they will use other terms like Must Use, Used, or Dependent.
Below is an example of an MEA (Measurement) segment with multiple elements and composite elements which are considered optional or conditional by the X12 v4010 standard, but all marked as Must use:
Below is a table which explains the relationship between the customer defined usage and standard X12 codes:
| Customer Defined Usage | Equivalent X12 type | Definition |
|---|---|---|
| Must Use | M | May be sent on the EDI transaction |
| Used | O | May be sent on the EDI transaction |
| Not used | N/A | Must not be sent on the EDI transaction |
| Recommended | O | Should be sent on the EDI transaction |
| Not Recommended | N/A | Should not be sent on the EDI transaction |
| Future | N/A | Should not be sent on the EDI transactions, but reserved for future use |
| Dependent | C or X | Conditional based on syntax rules |