by CData Arc Marketing | December 27, 2020

How to Understand EDI Documents and Avoid Costly Errors

money concept

Electronic document interchange (EDI) enables organizations to work efficiently with business partners by automating the exchange of trading-related documents, such as purchase orders, invoices, and shipping notifications. Unfortunately, because EDI was designed for use by primitive machines in the 1960s, the format is nearly incomprehensible to humans.

So what are you looking at in an EDI document? More pertinently, how do you know your EDI files don't contain any costly syntactical errors that lead to missed orders, delays, or costly inventory inaccuracies?

In this article, we walk you through the main components of an example X12 standard EDI 850 Purchase Order document so you can better understand what you're looking at and more easily determine when something has gone wrong. These pieces will not perfectly correspond to other documents, but the structure broadly applies to other X12 EDI files.

Elements of an EDI Document


The message structure for all X12 standard EDI documents includes three key components illustrated in the diagram below:

  • Interchange
  • Functional Group
  • Transaction Set

The Interchange and Functional Groups work together and serve as an address that directs the message to the proper destination, while the Transaction Set describes the message itself. The two-to-three-character codes at the right of the X12 Document Structure diagram indicate these structural components.

EDI Codes

Here, we show how these codes look in an EDI document where they describe structural components. The text below is an example of an EDI transaction document, in this case, an 850 Purchase Order.

As you can see, the document is comprised of strings of unintelligible characters. But they can be understood as a collection of segments.

  • Each line of the document is called a segment
  • Segments are composed of one or more elements
  • Each segment is followed by a terminator/separator (usually a tilde)

In this example, we've placed each segment on its own line to make it easier to distinguish. But beware that EDI files typically come in a big block with no carriage return, only the terminator/separator.

      ISA*00*          *00*          *ZZ*AMAZONDS       *01*003025392      *160623*1448*U*00401*000000013*0*P*+~
N1*ST*Charlie Dinkins~
N3*11254 Main St*Suite 112~
N4*Seattle*WA*98104*US*CC*United States~
N1*LW*Amber Baker~
N3*123 Anderson Avenue~


The interchange consists of a header and footer that identify the company you're sending the document to. X12 uses the codes ISA for the header and IEA for the footer.

The ISA header provides metadata about the exchange. For example, it includes a unique identifying number for the transaction, which can also be used after the document is received as an acknowledgement. The IEA code at the end of the document completes the exchange.

Functional Group

The functional group directs the message more specifically to a particular area or department in the company. For example, the functional group might include all the invoices bound for the accounting department. X12 uses the code GS for the Functional Group header and GE for the footer, which are located respectively in the second and penultimate lines of the above document. If the company is small or the address is simple, the GS may simply repeat the ISA code.

Transaction Set

The transaction consists of the main body of the message, such as the order details. The following codes define various aspects of the transaction. ST stands for Start Transaction and defines the type of message being sent. Here, the ST is 850, meaning the document is a purchase order. The SE (in the third to the last line above) is the closing tag that ends the transaction that began with the ST.

You'll typically find a number of different codes within each transaction.

  • ST2 —Each interchange can include multiple transactions, such as multiple 850s, an 850 and an 810, or some other combination. ST2 identifies each one.
  • BEG — Stands for Beginning and includes high-level metadata about the 850, such as PO number, PO date, order number and so on.
  • REF — A reference identifier. Companies have broad flexibility to choose from a range of identifiers, such as customer order number, customer reference number, sales program number, or a special processing code.
  • N1 — Identifies a party to the exchange, such as the buyer, the shipper, or the remit-to party using information such as their name, role, and identifier.
  • N3 and N4 identify the address of the party referenced in N1.
  • PO1 — A purchase order can include multiple items. The PO1 identifies each item with a unique ID. Companies have flexibility to define what kind of identifier they use; e.g. a UPC or an ISBN. The PO1 also describes the quantity ordered and price per unit.
  • PID — Part of the PO1, the PID can provide additional identifying information, such as color, weight, and dimensions.
  • CTT — Aggregates the total number of line items and the total cost of all those items.

Seeing the Codes More Clearly

While you can now see and understand the basic EDI segments, translating the EDI document to another format makes it easier to understand your EDI documents at a glance. For example, if you convert an EDI file to XML format in a simple point and click process, you can easily insert comments that document what each segment does, making it easier to read and understand.

CData Arc: Automate EDI with Drag-and-Drop EDI Mapping

CData Arc is a powerful EDI suite that makes it easy to translate your documents into XML, Excel, CSV, or any flat file format. CData Arc supports EDI mapping and translation for EDI 850, 837, 810, 270 and hundreds more standard EDI documents across more than a dozen major EDI standards.

To test out the CData Arc translation process, download a trial version of CData Arc today and learn how to automatically convert EDI files into business formats in our EDI Mapping Tutorials.

See How EDI Mapping Works