EDI X12 viewer

How an X12 file is put together

An X12 file is a string of segments, each made of elements. The file declares its own punctuation: the fourth character of the ISA segment is the element separator (usually *), and the character after the sixteenth element is the segment terminator (usually ~). The viewer reads both from the file instead of assuming them, which is why files from partners who use | or line breaks still parse.

Three envelopes nest inside each other. ISA/IEA is the interchange: who sent it, who receives it, a control number, and a test or production flag. GS/GE is a functional group of one kind of document. ST/SE is one transaction set, the actual order or invoice, and ST01 says which kind it is. One file can carry many transaction sets, so the viewer shows each one separately.

The 850 purchase order

BEG opens the order: BEG03 is the PO number and BEG05 the order date. CUR sets the currency and ITD the payment terms. Each party is an N1 loop, identified by a code in N101 (BY buyer, ST ship to, BT bill to, SE selling party), with N3 and N4 for the address and PER for a contact. Every line is a PO1: line number, quantity, unit of measure, and unit price, then pairs of qualifier and value for the item, such as BP (buyer's part), VP or VN (vendor's part), and UP (UPC). A PID after the line carries its description. CTT counts the lines and AMT gives the order total.

The 810 invoice

BIG carries the invoice date (BIG01), invoice number (BIG02), and the PO it bills (BIG04). If BIG07 is CR or CN, the document is a credit, and the original invoice is referenced in REF*OI. Lines are IT1 segments, laid out like PO1. The total is TDS01, which has two implied decimals: TDS*116068 means 1,160.68. SAC segments carry charges and allowances, also with implied decimals, while TXI02 tax amounts carry an explicit decimal point. Getting those two rules backwards moves a payable by a factor of 100, a classic way for a hand-built EDI import to go wrong.

The 855 acknowledgment and the 860 change

An 855 is the supplier's answer to an 850. BAK02 says whether the order was accepted as sent, accepted with changes, or rejected, and each PO1 line is followed by an ACK with a status such as IA (accepted), IB (backordered), or IR (rejected). The line statuses are what matter: a header that says “accepted” over a backordered line still means part of the order is not coming.

An 860 is the buyer revising an order. BCH replaces BEG: BCH01 is the purpose (01 cancels the whole order, 04 changes it) and BCH05 the change sequence. Lines are POC segments, and POC02 says what happened to each one: QI quantity increased, PC price changed, DI deleted, AI added.

The 856 ship notice and the 997

An 856 describes a shipment as a hierarchy of HL levels: shipment, order, pack, item. BSN carries the shipment ID and date, PRF the PO it fills, LIN the item identifiers, and SN1 the quantity shipped. The viewer flattens the hierarchy to one row per item.

A 997 functional acknowledgment reports whether a group of documents was received and passed syntax checks, not whether anyone agreed to the business terms. AK1 names the group being acknowledged, each AK2/AK5 pair gives one transaction set's result (A accepted, E accepted with errors, R rejected), and AK9 totals them: sets declared, received, and accepted.

Where the viewer stops

This page reads files; it does not answer them. Trading partners expect a 997 within hours and an 855 inside a stated window, and a late one can mean a chargeback. DynamoDocs EDI integration reads the same transaction sets with the production parser this page was ported from, validates each order, posts it to your ERP, and sends the 997, 855, 865, 856, and 810 back over AS2, SFTP, or your VAN.