> ## Documentation Index > Fetch the complete documentation index at: https://stedi.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Element Requirements in X12 EDI When an [element](https://www.stedi.com/edi/x12-008010/element) is in the context of a [segment](https://www.stedi.com/edi/x12-008010/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 `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 an `M` 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](https://www.stedi.com/edi/x12-008010/segment/BIG) used in all [X12 810 Invoices](https://www.stedi.com/edi/x12/transaction-set/810) are mandatory elements. You cannot send an invoice without the invoice number and date. Image of Mandatory usage in the BIG Segment ### Optional Optional elements are marked with an `O` 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](https://www.stedi.com/edi/x12-008010/810) 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. Image of Optional usage in the BIG Segment ### Conditional Conditional elements, marked with either a `C` 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. Image of Conditional usage in the DTM segment 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 typical `M`, `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](https://www.stedi.com/edi/x12/segment/MEA) with multiple elements and composite elements which are considered optional or conditional by the X12 v4010 standard, but all marked as `Must use`: Image of Trade Partner Deviating from the spec for MEA Segment 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 | When you are building EDI integrations, make sure you pay close attention to element requirements, and how they deviate from the base X12 standard.