In this guide, we cover:
How EDI files are structured, from transaction sets and segments to individual data elements
How envelopes, delimiters, and validation rules help systems process EDI documents accurately
The most common EDI transaction sets used in retail supply chains
EDI implementations depend on precise file structure. Every transaction follows a defined standard, using transaction sets, segments, data elements, qualifiers, delimiters, and control envelopes to communicate business data in a format that receiving systems can process.
For developers, implementers, and operations teams, understanding this structure is essential when mapping data, troubleshooting failed transactions, validating partner specifications, or configuring integrations. A file can contain the correct business information and still fail if a required segment is missing, a qualifier is invalid, or the transaction does not meet a trading partner’s implementation requirements.
This guide breaks down the hierarchy of an EDI document, from interchange envelopes to individual data elements. It also explains the transaction sets most commonly used in retail supply chain workflows and the requirements that often vary by trading partner.
At a high level, an EDI file is organized in the following hierarchy:
Interchange envelope: Identifies the sender, receiver, date, time, and control information for the full transmission.
Functional group: Groups related transaction sets, such as purchase orders or invoices, within the interchange.
Transaction set: Represents a specific business document, such as an EDI 850 Purchase Order or EDI 856 Advance Ship Notice.
Segment: A line of related data within a transaction set, identified by a segment ID.
Data element: An individual field within a segment, such as an order number, item quantity, date, or product identifier.
Qualifier: A code that defines how a data element should be interpreted.
Delimiter: A character that separates segments, elements, and components within the file.
The sections below explain how these components work together and where common transaction types fit within an EDI architecture.
How EDI Files Are Structured
EDI files follow a defined hierarchy that allows systems to identify the sender and receiver, recognize the document type, and validate the data before processing it.
In X12 EDI, that hierarchy typically looks like this:
Interchange: The full transmission between two trading partners.
Functional group: A collection of related documents within the interchange.
Transaction set: One business document, such as an EDI 850 Purchase Order or EDI 856 Advance Ship Notice.
Segment: A group of related data within a transaction set.
Data element: An individual value within a segment, such as a quantity, date, product ID, or purchase-order number.
For example, an EDI 850 contains segments for purchase-order details, shipping instructions, and line items. Each line-item segment contains individual elements such as quantity, unit of measure, price, and product identifier.
PO1*1*24*EA*12.50**UP*012345678905~
In this example, PO1 identifies the line-item segment, 24 is the quantity, EA is the unit of measure, 12.50 is the unit price, and 012345678905 is the UPC. The asterisk separates data elements, while the tilde marks the end of the segment.
How Data Moves Through an EDI File
An EDI file is processed from the outside in. First, the receiving system reads the interchange envelope to identify the sender, receiver, and file-control information. It then reads the functional group, identifies each transaction set, and processes the segments and elements within each document.
In X12, the main control segments are:
ISA and IEA: Begin and end the interchange
GS and GE: Begin and end a functional group
ST and SE: Begin and end an individual transaction set
The control numbers and segment count in these opening and closing segments must match. If they do not, the file may be rejected before the business data is processed.
Delimiters and File Formatting
EDI does not rely on visual formatting like rows and columns. Instead, it uses delimiters to separate data.
Common X12 delimiters include:
* for data elements
: for component elements
~ for segment endings
These characters are defined in the file interchange header. If a delimiter is missing, changed unexpectedly, or included in a free-text field without proper handling, the receiving system may be unable to parse the transaction correctly.
X12 and EDIFACT Differences
X12 and EDIFACT both organize data into structured segments and elements, but they use different envelope formats and transaction identifiers.
X12 is widely used in North American retail and identifies documents with numeric transaction-set codes, such as EDI 850 for a Purchase Order. EDIFACT is common in international trade and uses message names, such as ORDERS for a purchase order and INVOIC for an invoice.
X12 uses control segments including ISA, GS, and ST. EDIFACT uses UNB for the interchange envelope and UNH for individual messages. The business purpose may be similar, but the file structures and mapping requirements are different.
How EDI Documents Are Validated
EDI documents are typically validated at three levels:
Syntax validation: Confirms the file follows structural rules, including segment order, required fields, delimiters, control numbers, and segment counts.
Trading partner validation: Confirms the document follows a retailer’s implementation guide, including required qualifiers, codes, and references.
Business-rule validation: Confirms the data is usable for the transaction, such as whether a purchase order exists, an item is active, or an invoice price matches the agreed-upon amount.
An EDI 997 or EDI 999 acknowledgment can confirm that a file was received and passed basic syntax checks. It does not necessarily confirm that the retailer accepted the order, shipment, or invoice for business processing.
What Are the Most Prevalent EDI Document Types for Retail Suppliers?
Some document types are more relevant to retail supply chains than others. The list below is composed of some of the most prevalent document types in the retail industry. Knowing what these are and how they function is fundamental to supplier success.
Retailers have unique subsets of documents that they use in their own receiving process. What makes EDI so important for the retail supply chain world is precisely that it is needed to facilitate clear communication between supplier and buyer. This process involves a careful understanding of each retailer’s inner workings.
EDI 810: Invoice
This transaction document is used for billing goods and services provided. The data in these documents varies widely depending on the goods/services being purchased. In the context of retail supply chains, however, they always include:
Invoice number
Date of the invoice
Services/items rendered
Date that the items shipped out on
Payment terms
More often than not, in the retail industry, the sender is the supplier, and the receiver is the retailer.
EDI 846: Inventory Inquiry
EDI 846s are designed to communicate inventory information between parties, usually, in the case of retail supply chains, between manufacturers, suppliers, and retailers. A variety of quantities can be communicated through this transaction document: quantities on hand, committed quantities, on-order quantities, and backorder quantities, to name just a few.
EDI 850: Purchase Order
This transaction document contains all of the materials requested by the buyer (in this context, usually the merchant at the retailer).
Purchase orders (POs) contain important details within merely the items requested, namely, the item description, UPC item or case code, unit prices, payment terms, discounts, and requested delivery dates, all of which are important pieces of information to keep on hand for records.
EDI 855: Purchase Order Acknowledgment
This transaction document communicates the seller’s acknowledgment of a buyer’s purchase order. In the case of vendor-generated orders, this document can also be used as a notification of an order creation.
EDI 856: Ship Notice/Manifest (a.k.a. “Advance Ship Notice” or ASN)
This transaction document is one of the more commonly used transactions in the retail industry, and it is therefore at the heart of compliance policies and protocols (see EDI 856: Ship Notice/Manifest or “ASN Not Downloaded” Defect for more context).
These are essential to successfully communicating the contents of a shipment to a buyer. They often include:
Carrier information
Description of products and their respective quantities
Tracking numbers
Purchase order numbers
Barcodes for each container/carton
Types of packaging used
Configuration of items in the shipping container/transportation equipment
EDI 875: Grocery Products Purchase Order
The grocery industry has its own form of POs with its own EDI code. This transaction set is used by grocery wholesalers and retailers. These are different from the EDI 850 general merchandise POs because grocery POs do not need the level of detail that EDI 850s need.
EDI 879: Price Information Advice
This document type communicates price information, especially price changes, between sellers and buyers. Pricing is a difficult and fraught factor in the retail industry, and it usually causes quite a bit of miscommunication.
EDI 879s are important for clarifying these issues in the compliance and/or dispute process surrounding pricing. Post audits that retailers send out due to pricing discrepancies will need to be disputed, at least in part, using these.
EDI 940: Warehouse Shipping Order
This transaction document functions as a means of communicating between the sellers/suppliers and third-party logistics providers (3PLs) as a request for shipment of goods from a supplier’s warehouse to a buyer’s location (usually a DC).
These almost always include the following:
Warehouse order details (timing and quantities)
The PO number associated
The destination address (buyer’s location)
Contact information for the receivers
And more information related to the order
EDI 997: Functional Acknowledgment
EDI 997s function almost as a meta-transaction in data interchange, to acknowledge the acceptance of a group of or an individual EDI transaction.
For example, the “ASN Not Downloaded” defect in the Supplier Quality Excellence Program (SQEP) depends on the receipt of the ASN. If an EDI 997 has been sent from Walmart to the supplier confirming the receipt of the ASN (the EDI 856), it can be used to file a dispute of the fine.
How AI Supports Modern EDI Workflows
EDI remains the standardized format that businesses use to exchange transactional data. The underlying business documents and trading partner requirements still need to be accurate, structured, and compliant. AI can help teams work with EDI data more efficiently once it enters their systems.
For example, AI-enabled tools can help identify exceptions, surface missing or inconsistent information, prioritize transactions that need attention, and provide teams with clearer visibility into order status and fulfillment risks. When connected to EDI workflows, AI can also help translate operational data into more actionable insights for customer service, supply chain, finance, and fulfillment teams.
The quality of the EDI data still matters. AI can help teams interpret and act on information faster, but it cannot resolve incomplete, inaccurate, or noncompliant transactions on its own. Clean data, reliable mappings, and well-managed trading partner requirements remain the foundation.
EDI Field Limitations
It is important to be aware of the EDI field limitations when filling out the various document types. These limitations are important for avoiding problems with EDI providers and miscommunication across retail supply chains.
Each retailer, however, has their own sets of valid codes and values, and a document that may be valid for one retailer may not be for another one. For example, Amazon has stopped accepting PODs/BOLs as legitimate proof documentation for disputing a shortage deduction, whereas, at most other retailers, such documents are essential for winning back invalid shortage deductions.
Put EDI Structure into Practice
EDI structure may be technical, but its purpose is straightforward: to ensure that critical business information moves accurately between trading partners. Every envelope, transaction set, segment, qualifier, and data element plays a role in helping systems recognize, validate, and process documents without manual intervention.
For suppliers, understanding the structure behind EDI documents makes it easier to diagnose errors, meet retailer-specific requirements, and protect the flow of orders, shipments, invoices, and inventory data. It also creates a stronger foundation for automation and AI-enabled workflows that depend on accurate, connected operational data.
As you evaluate your own EDI environment, start by identifying the transaction sets your retail partners require, reviewing each partner’s implementation guide, and confirming that your systems can validate and monitor exceptions before they disrupt fulfillment.
For a broader look at the documents suppliers may need to exchange, explore The Complete List of EDI Transactions and EDI Document Codes.