James Allman | JA Technology Solutions LLC
EDI X12: What's Inside an 850, 810, and 856
A developer-level walkthrough of the three transaction sets at the center of every EDI trading relationship — and the segments that trip people up.
If you have recently inherited an EDI integration, been handed a trading partner's implementation guide, or found yourself staring at a raw X12 file trying to figure out what went wrong, this article is for you. It is not a beginner overview — if you need that, start with EDI 101: What Business Leaders Need to Know. This goes deeper, into the segments and structure that developers, analysts, and IT staff need to understand when they are building, debugging, or maintaining EDI integrations.
Three transaction sets make up the backbone of most B2B trading relationships: the 850 Purchase Order, the 810 Invoice, and the 856 Advance Ship Notice. Between them, they cover the core cycle of ordering, shipping, and billing. A fourth document, the 997 Functional Acknowledgment, closes the loop by confirming receipt. If you understand these four, you can navigate the majority of EDI work you will encounter in retail, grocery, distribution, and manufacturing.
I will walk through each document's key segments, explain the envelope structure that wraps them, and call out the failure patterns I have seen repeatedly over 35 years of EDI integration work. Where it helps, I will point to free tools on this site that let you inspect and build these documents yourself.
The X12 Envelope: ISA, GS, and ST
Before you can read any transaction set, you need to understand the three-layer envelope that wraps every X12 document. Think of it as nested packaging: the outer box identifies the sender and receiver, the middle box groups related documents by type, and the inner box contains the actual business content.
The outermost layer is the ISA/IEA (Interchange Control Header and Trailer). The ISA segment is always exactly 106 characters, making it one of the only fixed-length segments in X12. It identifies the sender and receiver by qualifier and ID (elements ISA05/ISA06 and ISA07/ISA08), specifies the date, time, and a control number, and — critically — declares the element separator, sub-element separator, and segment terminator that the rest of the file uses. If your parser cannot read an EDI file, the ISA is the first place to check: element 16 defines the sub-element separator, and the character immediately after ISA16 is the segment terminator. Most files use asterisks, tildes, and colons, but nothing in the standard requires those specific characters.
Inside the interchange sits one or more GS/GE (Functional Group Header and Trailer) pairs. The GS segment groups transaction sets by type: all 850s together, all 810s together, and so on. GS01 contains the functional identifier code — "PO" for purchase orders, "IN" for invoices, "SH" for ship notices. The GS also carries its own control number, sender and receiver codes, and a version identifier (like "005010" for the widely used 5010 release).
The innermost layer is the ST/SE (Transaction Set Header and Trailer). ST01 holds the transaction set identifier code — 850, 810, 856, or 997. ST02 is a control number that must match the SE02 value in the corresponding trailer. The SE segment also includes a count of all segments between ST and SE inclusive. Getting that count wrong is one of the most common causes of document rejection, and it is entirely preventable. You can paste any raw file into the EDI Parser to see these envelopes broken out and labeled.
The 850 Purchase Order: What the Buyer Wants
The 850 is where most EDI transactions begin. It is the electronic equivalent of a purchase order — a buyer telling a seller what they want, how much, at what price, and where to deliver it. In retail and grocery environments, an 850 might originate from a retailer's replenishment system and arrive at the supplier's system within minutes of the need being identified.
The document opens with a BEG segment (Beginning Segment for Purchase Order) that contains the transaction set purpose code (BEG01 — typically "00" for original), the purchase order type (BEG02 — "SA" for standalone is most common), and the buyer's PO number (BEG03). That PO number becomes the reference that ties together every subsequent document in the transaction cycle: the ASN, the invoice, and the payment. If your system does not store and cross-reference it reliably, downstream matching breaks.
DTM segments carry dates — requested ship date, requested delivery date, cancel date. N1 loops identify the parties involved: the buyer (N101 = "BY"), the ship-to location (N101 = "ST"), and sometimes the bill-to (N101 = "BT"). Each N1 can include N3 and N4 segments for address details, plus REF segments for additional identifiers like DUNS numbers or department codes. The PO1 loop is where individual line items live. PO101 is the line number. PO102 is the quantity ordered. PO103 is the unit of measure. PO104 is the unit price. PO106 through PO125 carry product identification qualifiers and values — UPC codes (qualifier "UP"), vendor part numbers ("VP"), buyer item numbers ("IN"), and others.
The document closes with a CTT segment containing the total number of line items. This is a simple but frequently mishandled integrity check. If CTT01 does not match the actual number of PO1 segments, the document will be rejected. I have seen this happen most often when developers build EDI output by concatenating strings rather than tracking line counts programmatically. You can explore the full segment structure interactively using the X12 Segment Reference, or build a complete 850 with the EDI Purchase Order Builder.
The 810 Invoice: What the Seller Is Owed
The 810 is the seller's response to the purchase order — an electronic invoice requesting payment. In most trading relationships, the 810 is expected to match the 850 line for line: same items, same quantities (adjusted for what actually shipped), same prices. Any discrepancy triggers a hold on payment, and in large retail environments, potentially a chargeback.
The key opening segment is BIG (Beginning Segment for Invoice). BIG01 is the invoice date. BIG02 is the invoice number. BIG04 is the purchase order number from the original 850 — this cross-reference is what allows the buyer's system to match the invoice to the order. If BIG04 is missing or does not match an open PO, the invoice goes into an exceptions queue. In my experience, mismatched PO references are the single most common reason invoices fail automated processing.
Line items appear in IT1 loops. IT101 is the line number. IT102 is the quantity invoiced. IT103 is the unit of measure. IT104 is the unit price. Product identification follows the same qualifier pattern as the 850 PO1 segment. The TDS segment (Total Monetary Value Summary) carries the total invoice amount in cents — not dollars. TDS01 of 125050 means $1,250.50. This catches people unfamiliar with the convention. SAC segments handle service charges, allowances, and adjustments — things like freight charges, volume discounts, or promotional allowances. SAC01 distinguishes between allowances ("A") and charges ("C").
A common failure pattern with 810s involves price discrepancies. The buyer's system compares the IT1 unit price against the price on the original 850, and even a one-cent difference can trigger a rejection. This often happens when the seller's ERP calculates price differently than the buyer's — due to rounding, promotional pricing, or unit-of-measure conversions. The fix is almost always in the mapping, not the business logic. The EDI Invoice Builder lets you construct a valid 810 and test the output before sending to a trading partner.
The 856 ASN: The Hardest Document to Get Right
The 856 Advance Ship Notice is the document that causes the most trouble in EDI implementations. It is structurally different from the 850 and 810, and that structural difference is the source of most of the difficulty. Where the PO and invoice are essentially flat lists of line items, the ASN is hierarchical. It describes a physical shipment — what is on the truck, how it is packed, and how the contents map back to the original purchase order.
The hierarchy is built using HL (Hierarchical Level) segments. Each HL segment has three key elements: HL01 is the ID of the current level, HL02 is the ID of the parent level (blank for the top), and HL03 is the level code that identifies what kind of node this is. The standard level codes are "S" for shipment, "O" for order, "P" for pack (carton or pallet), and "I" for item. A typical ASN reads top-down: one shipment level containing one or more order levels, each containing one or more pack levels, each containing one or more item levels.
The shipment level (HL03 = "S") usually carries a BSN segment (Beginning Segment for Ship Notice) with the ASN number, date, and time. The TD1, TD5, and TD3 segments at this level describe the total shipment — number of cartons, carrier information, routing. The order level ties back to the PO with a PRF segment containing the PO number. The pack level is where things get particularly tricky: each carton or pallet needs a MAN segment with the SSCC-18 barcode that the buyer's receiving dock will scan. If the SSCC-18 on the physical label does not match the SSCC-18 in the ASN, the shipment cannot be received electronically.
At the item level, SN1 segments carry the quantity shipped, and LIN segments provide the product identification. The entire hierarchy must be internally consistent: the sum of item quantities across all packs under an order must match the order total, and the sum across all orders must match the shipment total. Getting this hierarchy wrong — nesting items under the wrong pack, miscounting HL parent references, or omitting a level entirely — produces ASNs that parse without error but fail validation at the trading partner. You can build and validate an 856 structure using the EDI ASN Builder.
The 997 Functional Acknowledgment: Closing the Loop
The 997 is the simplest of the core documents, but skipping it creates real operational risk. It is a receipt — a formal acknowledgment from the receiver that a functional group was received and syntactically processed. It does not confirm that the business content was accepted, only that the document could be parsed.
The key segment is AK1, which identifies the functional group being acknowledged (AK101 is the functional identifier code from the original GS, and AK102 is the group control number). AK9 carries the overall result: AK901 of "A" means accepted, "R" means rejected, "E" means accepted with errors. If errors were found, AK3 and AK4 segments drill down to the specific segment and element that failed.
In practice, the 997 is the first line of defense against silent failures. Without it, a sender has no way to know whether their document was received and readable. I have worked with organizations that disabled 997 processing to reduce what they saw as noise, only to discover weeks later that invoices had been failing silently the entire time. Every production EDI integration should generate and monitor 997s. The EDI 997 Builder can help you construct acknowledgments for testing.
How the Documents Flow Together
In a complete transaction cycle, the documents follow a predictable sequence. The buyer sends an 850 Purchase Order. The seller acknowledges receipt with a 997. The seller may also send an 855 Purchase Order Acknowledgment confirming they can fulfill the order (though not all trading partners require the 855). When the goods ship, the seller sends an 856 ASN. The buyer acknowledges with a 997. The seller then sends an 810 Invoice, and the buyer acknowledges with another 997. Finally, the buyer may send an 820 Remittance Advice when payment is issued.
The cross-references between these documents are what hold the cycle together. The PO number from the 850 BEG03 appears in the 856 PRF segment and the 810 BIG04. The invoice number from BIG02 may appear on the 820. If any of these references are missing, truncated, or reformatted along the way, the buyer's system cannot perform three-way matching — comparing the PO, the ASN, and the invoice to confirm that what was ordered matches what was shipped matches what was billed.
Three-way matching failures are among the most expensive EDI problems because they delay payment. In large retail environments, a failed match typically means the invoice goes into a hold queue where it sits until someone manually reconciles the documents. That reconciliation costs labor, and the delayed payment costs float. For suppliers operating on thin margins, a systematic three-way matching problem can create significant cash flow pressure.
Common Failure Patterns
After decades of building and troubleshooting EDI integrations, I see the same failure patterns recur regardless of the platform, the trading partner, or the industry. Knowing these patterns saves significant debugging time.
Segment count mismatches are the most mechanically simple and the most preventable. The SE01 segment count must include every segment from ST through SE inclusive. The CTT line item count must match the actual number of detail loops. These are off-by-one errors that happen when developers hardcode counts or calculate them before the document is fully assembled. The fix is always the same: count segments programmatically as the last step before output.
Missing or incorrect qualifier codes cause rejections that are harder to diagnose. An N1 segment with an entity identifier of "ST" (ship-to) instead of "SF" (ship-from) sends address data to the wrong field in the receiver's system. A product ID qualifier of "UP" when the trading partner expects "UK" (UPC with check digit versus without) causes item lookups to fail. These errors are usually mapping errors — the developer either misread the implementation guide or the guide itself was ambiguous.
Date format issues are surprisingly common given how simple dates should be. X12 dates are CCYYMMDD (eight digits) in version 5010, but some older implementations use YYMMDD (six digits). Mixing the two produces dates that parse without error but land in the wrong century or the wrong month. Timezone handling adds another layer: a shipment that crosses a date boundary can have a different ship date depending on which system generates the timestamp.
Segment Delimiters and Encoding
One of the more subtle sources of EDI failures is delimiter collision — when a data value contains a character that the document is using as a delimiter. If your element separator is an asterisk and a product description contains an asterisk, the parser will split the segment at the wrong point and every element after the collision will be offset by one position.
The X12 standard allows any character as a delimiter, and the ISA segment declares which characters are in use. Most implementations use asterisk (*) as the element separator, tilde (~) as the segment terminator, and colon (:) as the sub-element separator. But some trading partners use different conventions — pipe characters, carets, or even non-printable characters. Your parser must read the delimiter declarations from the ISA before attempting to parse anything else.
Character encoding is another area where assumptions cause failures. X12 is historically an ASCII standard, and most North American EDI stays within the printable ASCII range. But when data originates from systems using extended character sets — accented characters in names or addresses, special symbols in product descriptions — those characters can either be stripped, replaced with question marks, or cause outright parsing failures depending on how each system in the chain handles encoding. The safest approach is to sanitize outbound data to the basic ASCII range before EDI translation.
Reading an Implementation Guide
Every trading partner publishes an implementation guide (sometimes called a companion guide or mapping spec) that defines exactly how they expect each transaction set to be structured. These guides are the authoritative reference for any integration, and they routinely override the base X12 standard. A segment that is optional in the standard may be mandatory for a specific partner. An element that the standard allows in multiple formats may be constrained to one.
Implementation guides typically include a segment-by-segment table showing which segments are required ("M" for mandatory), optional ("O"), or conditional ("C"), along with the allowed values for qualifier codes, maximum field lengths, and loop repeat counts. Read these tables carefully. The most common onboarding mistake I see is building a map based on the generic X12 standard rather than the partner-specific guide.
When the guide is ambiguous — and they often are — the right move is to ask the trading partner for a sample file. A working sample is worth more than any written specification because it shows you exactly what the partner's system actually produces or expects, as opposed to what someone thought it should produce or expect when they wrote the guide. You can paste any sample file into the EDI Parser to see how it breaks down.
Debugging with the Right Tools
When an EDI document fails — whether it is a 997 rejection, a chargeback from a retailer, or a silent processing failure — the debugging process follows a consistent pattern. First, obtain the raw document. Do not trust a translated or rendered view; you need the actual X12 file as it was sent or received. Second, validate the envelope: check that the ISA, GS, and ST control numbers are sequential and that the trailer counts match. Third, inspect the business content: are the qualifiers correct, do the cross-references match, are the dates in the expected format.
I built the free tools on this site specifically for this kind of work. The EDI Parser breaks any X12 file into labeled, readable segments so you can see exactly what is in the document without manually counting asterisks. The X12 Segment Reference lets you look up any segment or element to understand what it means and what values are valid. The builder tools — for 850s, 810s, 856s, and 997s — let you construct test documents from scratch to verify your mapping logic before sending to a trading partner.
All of these tools run entirely in the browser. Nothing is uploaded or stored. That matters when you are working with production EDI files that contain real customer data, pricing, and transaction details.
When You Need More Than a Reference Guide
Understanding the structure of these documents is the starting point, not the finish line. Real EDI integration work involves mapping these structures to and from your business system, handling edge cases that the implementation guide does not cover, monitoring transmissions for failures, and maintaining integrations as trading partners update their requirements.
With over 35 years of experience building EDI integrations across grocery retail, distribution, warehousing, and manufacturing, I have worked with these transaction sets in just about every configuration — different ERPs, different VANs, different trading partners, different platforms. Whether you are onboarding a new trading partner, troubleshooting a chargeback, or modernizing an EDI system that someone built years ago and no one fully understands, I can help. Visit the EDI services page for more about what I do. Ask James to start a conversation.