Electronic Data Integration or EDI is the exchange of information electronically, instead of paper based documents. EDI has been used since the early 70s, and is based on widely adopted standards such as the US X12, or UN EDIFACT.
EDI document exchange can occur between businesses, government or regulatory authorities. This documentation will mostly detail EDI as applicable to X12 and EDIFACT, the most widely used EDI standards.
Various types of EDI document definitions exists for almost all types of business and domains, and these are usually called transaction sets. Different EDI standards would define similar documents or transaction sets to describe the same information. For example the X12 810 and EDIFACT INVOIC describe an invoice. The most recent X12 version 8010 defines 321 document types with 3-digit numbers. Here are a few examples.
- 100 Insurance Plan Description
- 101 Name and Address Lists
- 810 Invoice
- 850 Purchase Order
- 856 Ship Notice/Manifest
- 997 Functional Acknowledgement
The EDI standards used such as X12 or EDIFACT, defines the structure of the documents. The structure can depend on the version of the standard used. The X12 standard uses version numbers such as 4010, 5010 or 8010 etc, while EDIFACT versions are of the form D93A or D96A etc. The image below shows a page from a typical X12 document or transaction definition. The example is for an X12 810 transaction set, and this ‘overview’ page defines the overall structure of the document as a collection of ‘segments’.
The transaction set defines the document as starting with the segment ‘ISA’, and that segment being ‘Mandatory’ and occurring at most ‘1’ times at that position defined. This is followed by a ‘GS’ segment, also mandatory and occurring only once. Next an ‘ST’ and ‘BIG’ segment are defined in sequence, followed by an optional segment ‘REF’, which can occur at most 12 times at that position. So at a high level, one can form a mental picture of the EDI document structure defined, to be of the following form
ISA GS ST BIG REF REF .. ..
This is exactly what’s conveyed by the definition. Although we’ve used a line break in the example above to separate each segment, EDI usually does not use line breaks and instead uses a pre-defined ASCII character as the segment separator.
A Loop in EDI refers to a repeatable sub-collection of related segments. Consider the loop ‘N1’ in the above definition. Here the loop can repeat upto 200 times and each loop occurrence shall consist of the segments defined as that loop. In the example ‘N1’ loop, only a single segment ‘N1’ occurs once for each loop iteration. However, loops can be complex hierarchies and can contain other loops, such as the ‘IT1’ loop which contains two sub loops ‘PID’ and ‘SAC’.
EDI files typically does not contain line breaks. Instead, each segment will be separated by a special character chosen as the ‘Segment separator’. The segment separator can be chosen by each partner, and commonly used characters include the tilde
|, and the caret
^. Each segment contains one or more ‘elements’, with each such element separated by another chosen character, the element separator. The most commonly used element separator is the asterisk
* or the pipe
Each EDI message will start with a Header and end with a Trailer. In the case of ASCII X12, the header is defined by the
GS segment combination, and the trailer is defined by the
IEA segment combination. The ISA and GS headers will include details about the sender, recipient, date, versions, and the unique control numbers. The trailer will contain the corresponding control number, and include the number of segments between the header and trailer elements, so that any malformed document can be identified.
The sample below is a page from a sample EDI definition, describing the ‘BIG’ segmment, which is the beginning segment of an Invoice. Each element identified with its position allows references such as BIG01, BIG02 etc to refer to such data items. Each element is defined with a name, mandatory / optional flag, data type and minimum and maximum length. For example we see that BIG01 is a mandatory Date value of exactly 8 characters in length, while BIG02 is an alphanumeric string between 1 to 22 characters in length, and mandatory.
Usually large organizations override the standard EDI definition versions, and might want to state that a segment or element defined as optional as per the version of the specification used, is marked as mandatory by the client. This is the meaning of the last column ‘usage’, which exists to override such definitions.
Below listing shows a sample Invoice, in the X12 810 transaction set. Note that the line breaks have been inserted only for clarity. Notice the ISA/IEA header and trailer, and the GS/GE header and trailer. The ISA13 and the matching IEA02 are the Interchange Control numbers. IEA01 specifies the number of included functional groups (i.e. GS/GE pairs) which in this case is one. Similarly, the GS06 and GE02 specify the Group Control number, and GE01 states the number of included Transaction Sets, which in this case is one. The ST/SE pairs contain the Transaction information with ST02 and SE02 specifying the Transaction Control number, and SE01 specifying the number of segments within the transaction, which in this case is 19, including the ST and SE segments.
ISA*00* *00* *ZZ*ADRTPROD *08*925485US00 *210701*1017*;*00501*100100547*0*P*>~ GS*IN*ADRTPROD*925485US00*20210701*1017*200200547*X*005010~ ST*810*300300547~ BIG*20210704*WM0000001*20210624*5712201706***~ REF*IA*123456789~ REF*BM*BL123456789~ N1*ST*REGIONAL DISTRIBUTION CENTER 6285*UL*0078742090955~ N3*94-1420 MOANIANI ST~ N4*WAIPAHU*HI*96797*US~ N1*BT*WALMART INC.*UL*0078742090955~ N1*VN*SUPPLIER HAWAII LLC~ N3*12-345 BAKER ST~ N4*Laie*HI*12345*US~ DTM*011*20210703~ IT1**20*EA*3.75**IN*592351350*EN*7930526001294*UK*07930526001294~ IT1**20*EA*3.75**IN*592351352*EN*8801600264982*UK*08801600264982~ TDS*15000~ CAD*T***UPSN***BM*BL123456789~ ISS*02020*EA~ CTT*2~ SE*19*300300547~ GE*1*200200547~ IEA*1*100100547~