This section provides the following information:
An overview of the X12 protocol, including the structure of an X12 envelope, data elements, and syntax.
An explanation of how to use the generic message structures provided as an add-on to eGate and eXchange, to help you quickly create the structures you need for X12 message transactions.
An example of how X12 is used in payment processing.
The X12 protocol is an electronic data interchange (EDI) standard, developed for the electronic exchange of machine-readable information between businesses.
Development of the X12 protocol was chartered by the American National Standards Institute (ANSI) in 1979 to develop uniform standards for the interindustry electronic interchange of business transactions, that is, electronic data interchange (EDI). The result was the X12 standard.
An organization called the X12 body develops, maintains, interprets, and promotes the proper use of the X12 standard. Data Interchange Standards Association (DISA) publishes the X12 standard.
The X12 body comes together three times a year to develop and maintain EDI standards. Its main objective is to develop standards to facilitate electronic messaging interchanges relating to business transactions, such as order placement and processing, shipping and receiving information, invoicing, and payment information.
X12 was originally intended to handle large batches of transactions. However, it has been extended to encompass real-time processing (transactions sent individually as they are ready to send instead of being held for batching).
X12 messages have a message structure that indicates how data elements are organized and related to each other for a particular electronic EDI transaction.
In Java CAPS, message structures are defined as Object Type Definitions (OTDs). Each OTD consists of the following elements:
Physical Hierarchy – The predefined way in which envelopes, segments, and data elements are organized to describe a particular X12 EDI transaction.
Delimiters – The specific predefined characters used to mark the beginning and end of envelopes, segments, and data elements.
Properties – The characteristics of a data element, such as the length of each element, default values, and indicators that specify attributes of a data part, for example, whether it is required, optional, or repeating.
Included with the ASC X12 PM product is the X12 OTD Library. See the X12 OTD Library User’s Guide for details.
The Transaction Set structure of an invoice sent from one trading partner (TP) to another defines the header, trailer, segments, and data elements required by invoice transactions. The X12 OTD for a specific version includes Transaction Set structures for each of the transactions available in that version. You can use these structures as provided, or customize them to suit your business needs.
eXchange uses OTDs based on X12 message structures to verify that the data in the messages coming in or going out is in the correct format. There is a message structure for each X12 transaction. The list of transactions provided is different for each version of X12.
The rules for X12 envelope structure ensure the integrity of the data and the efficiency of the information exchange. The actual X12 message structure has primary levels that are hierarchical. From highest to the lowest, they are:
Interchange Envelope
Functional Group
Transaction Set
A schematic structure of X12 envelopes is shown in Figure 2–1. Each of these levels is explained in more detail in the remainder of this section.
Figure 2–2 shows the standard segment table for an X12 997 (Functional Acknowledgment) as it appears in the X12 standard and in most industry-specific implementation guides.
Functional Groups, often referred to as the “inner envelope,” are made up of one or more Transaction Sets, all of the same type, which can be batched together into one transmission. The Functional Group is defined by the header and trailer segments.
The Functional Group Header (designated GS) segment appears at the beginning, and the Functional Group Trailer (designated GE) segment appears at the end. Many Transaction Sets can be included in the Functional Group, but all local transactions must be of the same type.
Within the Functional Group, each Transaction Set is assigned a functional identifier code, which is the first data element of the header segment. The Transaction Sets that constitute a specific Functional Group are identified by this functional ID code.
The GS segment contains:
Functional ID code (the two-letter transaction code; for example, PO for an 850 Purchase Order, HS for a 270 Eligibility, Coverage, or Benefit Inquiry) to indicate the type of transaction in the Functional Group
Identification of sender and receiver
Control information (the Functional Group control numbers in the header and trailer segments must be identical)
Date and time
The GE segment contains:
Number of Transaction Sets included
Group control number (originated and maintained by the sender)
See Figure 2–3 and Figure 2–4.
The Interchange Envelope, often referred to as the “outer envelope,” is the wrapper for all the data to be sent in one transmission. It can contain multiple Functional Groups. This characteristic means that transactions of different types can be included in the Interchange Envelope, with each type of transaction stored in a separate Functional Group.
The Interchange Envelope is defined by the header and trailer; the Interchange Control Header (designated ISA) appears at the beginning, and the Interchange Control Trailer (designated IEA) appears at the end.
As well as enveloping one or more Functional Groups, the ISA and IEA segments include:
Data element separators and data segment terminator
Identification of sender and receiver
Control information (used to verify message was correctly received)
Authorization and security information, if applicable
The sequence of information transmitted is:
ISA
Optional interchange-related control segments
Actual message information, grouped by transaction type into Functional Groups
IEA
See Figure 2–5 and Figure 2–6.
The following list describes the ISA segments shown in Figure 2–5:
Authorization Information Qualifier
Security Information Qualifier
Interchange ID Qualifier
Interchange Sender ID
Interchange ID Qualifier
Interchange Receiver ID
Date
Time
Repetition Separator
Interchange Control Version Number
Interchange Control Number
Acknowledgment Requested
Usage Indicator
Each Transaction Set also known as a transaction contains:
Transaction Set header (designated ST)
Transaction Set trailer (designated SE)
Single message, enveloped within the header and footer
A Transaction Set has a three-digit code, a text title, and a two-letter code, for example, 997, Functional Acknowledgment (FA).
The Transaction Set is composed of logically related pieces of information grouped into units called segments. For example, one segment used in the Transaction Set might convey the address: city, state, postal code, and other geographical information. A Transaction Set may contain multiple segments. For example, the address segment might be used repeatedly to convey multiple sets of address information.
The X12 standard defines the sequence of segments in the Transaction Set and also the sequence of elements within each segment. The relationship between segments and elements can be compared to the relationship between records and fields in a database environment. See Figure 2–7 and Figure 2–8.
The X12 messages are all in ASCII text, with the single exception that the BIN segment is binary. Each X12 message is made up of a combination of the following elements:
Data
Segments
Loops
Elements are separated by delimiters. The remainder of this section explains these elements.
The data element is the smallest named unit of information in the X12 standard. Data elements can be broken down into types. The distinction between the types is strictly a matter of how they are used. The types are:
Simple – If a data element occurs in a segment outside the defined boundaries of a composite data structure, it is called a simple data element.
Composite – If a data element occurs as an ordinally positioned member of a composite data structure, it is called a composite data element. A telephone number is a simple example of a composite. It has a three-digit area code, which must precede the three-digit central office code, which must precede the final four digits.
Each data element has a unique reference number, and it also has a name, description, data type, and minimum and maximum length.
A segment is a logical grouping of data elements. In X12, the same segment can be used for different purposes. This means that a field’s meaning can change based on the segment. For example:
The NM1 segment is for any name (patient, provider, organization, doctor)
The DTP segment is for any date (date of birth, discharge date, coverage period)
For more information on the X12 enveloping segments, refer to Structure of X12 Envelopes.
Loops are sets of repeating ordered segments. In X12 you can locate elements by specifying:
Transaction Set, for example 270 or 271
Loop, for example “info. receiver loop”
Occurrence of the loop
Segment, for example BGN
Field number, for example 01
Occurrence of the segment (if it is a repeating segment)
In an X12 message, the various delimiters are part of the syntax, dividing up the different elements of a message. The delimiters used in a message are defined in the interchange control header, the outermost layer enveloping the message.
For this reason, there is flexibility in the delimiters that are used. No suggested delimiters are recommended as part of the X12 standards, but the industry-specific implementation guides do have recommended delimiters.
The default delimiters used by the X12 OTD Library are the same as those recommended by the industry-specific implementation guides. The default delimiters in the X12 OTD Library are:
~ (tilde)
* (asterisk)
: (colon)
+ (plus sign)
Within eXchange, delimiters are specified at the enveloping level. The delimiters defined for an envelope apply to all transactions in the same business service (a predefined dialog between the two parties).
It is important to note that errors could result if the transmitted data includes any of the characters that have been defined as delimiters. Specifically, the existence of asterisks within transmitted application data is a known issue in X12 and can cause problems with translation.
See Element Separator for information on the ePM delimiter parameter.
The X12 standard includes a control number for each enveloping layer, as follows:
ISA13: Interchange
GS06: Functional Group
ST02: Transaction Set
The control numbers act as identifiers. These numbers are used for message identification and tracking. eXchange includes a flag for each control number. This feature allows you to choose not to assign control numbers to outgoing messages and not to store control numbers on incoming messages.
The remainder of this section provides a brief explanation of each of these control numbers’ usage.
The ISA13 control number is assigned by the message sender. It must be unique for each interchange. This is the primary means used by eXchange Integrator to identify an individual interchange.
The GS06 control number is assigned by the sender. It must be unique within the Functional Group assigned by the originator for a Transaction Set.
eXchange ensures that the Functional Group control number GS06 in the header must be identical to the same data element in the associated Functional Group trailer, GE02.
The ST02 control number is assigned by the sender and is stored in the Transaction Set header. It must be unique within the Functional Group.
eXchange ensures that the control number in ST02 is identical with the SE02 element in the Transaction Set trailer and is unique within a Functional Group (GS-GE). Once you have defined a value for ST02, eXchange always uses that same value for SE02.
Each version of X12 is slightly different. Each new version has some new transactions. In addition, existing transactions can change from version to version.
New versions of X12 are usually backward-compatible. However, this compatibility is not a requirement of the X12 rules. You cannot assume that different versions of X12 are always completely backward-compatible.
You can expect that when you analyze the differences, only a few minor changes are required in the message structures. Therefore, it is recommended that, when you are using a new version or messaging between different versions, you make sure to be thoroughly familiar with any possible compatibility issues.
In this context, “backward compatibility” means that software that parses one version can, in some circumstances, be unable to parse the next version, even if the software ignores any unexpected new segments, data elements at the end of segments, and sub-elements at the end of composite data elements. No backward compatibility means that required segments can disappear entirely, data elements can change format and usage, and required data elements can become optional.
This section provides, as an example, an overview of the normal processes involved in EDI payment processing, that is, how electronic payments processing is used. Not everything in this example applies to the use of X12 in all possible payments processing scenarios.
EDI payments processing encompasses both collection and disbursement transactions. The exchange of funds is accomplished by means of credit and debit transfers. Transfers can also include a related bank balances, as well as transactions and account-analysis reporting mechanisms.
Most nonmonetary EDI TP communications are handled either directly between the parties or indirectly through their respective value-added networks (VANs). However, the exchange of funds requires a financial intermediary. This “third party” is normally the bank or banks that hold deposit accounts of the two parties.
The EDI operations involve the exchange of remittance information along with the order to pay. The remittance information, which acts as an electronic check stub, can be sent in any of the following ways:
Directly between TPs or through their respective EDI VAN mailboxes
Through the banking system, with the beneficiary’s bank sending notice of payment to the beneficiary
By the originator to the originator’s bank as an order to pay, with the originator’s bank notifying the beneficiary
The TPs and the capabilities of their respective banks determine:
Routing of the electronic check stub
Whether payment is of the type:
Debit authorized by the payor and originated by the beneficiary
Credit transfer originated by the payor
The following types of information can be exchanged electronically between bank and customer:
Daily reports of balances and transactions
Reports of lock-box and electronic funds transfer (EFT) remittances received by the bank
Authorizations issued to the bank to honor debit transfers
Monthly customer account analysis statements
Account reconcilement statements
Statements of the demand-deposit account
The electronic payment mechanism, which is a subset of EDI, involves the following separate activities:
Exchange of payment orders, causing value to transfer from one account to another
Exchange of related remittance information in standardized machine-processable formats
An electronic payment can be either:
Credit transfer, initiated by the payor
Debit transfer, initiated by the payee as authorized by the payor
Regardless of how a credit transfer was initiated, the payor sends a payment order to its bank in the form of an X12 Payment Order/Remittance Advice (Transaction Set 820).
The bank then adds data in a format required by the United States by the National Automated Clearing House Association (NACHA) and originates the payment through the Automated Clearing House (ACH) system. A corporate-to-corporate payment then performs the following functions:
Transfers actual monetary value
Transfers notification of payment from payor to payee
When a credit transfer occurs, these two functions are sometimes treated as one, and sometimes treated separately. These functions can travel in either of the following ways:
Together through the banking system
Separately and by different routes
X12 Transaction Set 820 is a data format for transporting a payment order from the originator to its bank. This payment order can be:
Instructions to the originator’s bank to originate a credit transfer
Instructions to the TP to originate a debit transfer against the payor’s bank account
Once this decision has been made, Transaction Set 820 transports the remittance information to the beneficiary. The transfer can either be through the banking system or by a designated route separate from the transport of funds.
Whenever the Transaction Set 820 remittance information is not transferred with the funds, it can be transmitted directly from the originator to the beneficiary. It can also be transmitted through an intermediary, such as a VAN.
Before funds can be applied against an open accounts-receivable account, the beneficiary must reconcile the following data streams:
Payment advice from the receiving bank
Remittance information received through a separate channel
These data streams were separated during the transfer operation.
If this reconciliation does not take place, and if the amount of funds received differs from the amount indicated in the remittance advice, the beneficiary might have problems balancing the accounts-receivable ledger.
The value transfer begins when the originator issues a payment order to the originator’s bank. If a credit transfer is specified, the originator’s bank charges the originator’s bank account and pays the amount to the beneficiary’s bank for credit to the beneficiary’s account.
If the payment order specifies a debit transfer, the originator is the beneficiary. In this case, the beneficiary’s bank originates the value transfer, and the payor’s account is debited (charged) for a set amount, which is credited to the originator’s (beneficiary’s) bank account.
The payor must issue approval to its bank to honor the debit transfer, either before the beneficiary presents the debit transfer or at the same time. This debit authorization or approval can take one or more of the following forms:
Individual item approval
Blanket approval of all incoming debits with an upper dollar limit
Blanket approval for a particular TP to originate any debit
X12 uses an end-to-end method to route the 820 Payment Order/Remittance Advice from the originator company through the banks to the beneficiary. Use of this method means there can be several relay points between the sender and the receiver.
The Transaction Set 820 is wrapped in an ACH banking transaction for the actual funds transfer between the banks.
X12 includes the following types of acknowledgments:
TA1 Interchange Acknowledgment
997 Functional Acknowledgment
See Sample Scenario Business Description.
The TA1 Interchange Acknowledgment verifies the Interchange Envelopes only. The TA1 is a single segment and is unique in the sense that this single segment is transmitted without the GS/GE envelope structures. A TA1 acknowledgment can be included in an interchange with other Gs and transactions.
The Transaction Set 997 Functional Acknowledgment includes much more information than the TA1 (see Figure 2–2). This Transaction Set was designed to allow TPs to establish a comprehensive control function as part of the business exchange process.
There is a one-to-one correspondence between Transaction Set 997 and a Functional Group. Segments within this Transaction Set identify whether the Functional Group was accepted or rejected. Data elements that are incorrect can also be identified.
Many EDI implementations have incorporated the acknowledgment process into all of their electronic communications. Typically, Transaction Set 997 is used as a functional acknowledgment to a Functional Group that was transmitted previously.
Transaction Set 997 is the acknowledgment transaction recommended by X12.
The acknowledgment of the receipt of a payment order is an important issue. Most corporate originators want to receive at least a Functional Acknowledgment (Transaction Set 997) from the beneficiary of the payment. Transaction Set 997 is created using the data about the identity and address of the originator found in the ISA and/or GS segments.
Application acknowledgments are responses sent from the destination system back to the originating system, acknowledging that the transaction has been successfully or unsuccessfully completed.
The application advice (Transaction Set 824) is a generic application acknowledgment that can be used in response to any X12 transaction. However, it has to be set up as a response transaction; only TA1 and Transaction Set 997 transactions are sent out automatically.
Other types of responses from the destination system to the originating system, which can also be considered application acknowledgments, are responses to query transactions, for example, the Eligibility Response (Transaction Set 271) is a response to the Eligibility Inquiry (Transaction Set 270).