EDI Transaction Sets Explained
EDI transaction sets are the standardized documents trading partners exchange for purchase orders, acknowledgments, shipments and invoices. Each has a specific job in the order lifecycle: an 850 starts it, an 855 confirms it, an 856 announces the shipment, an 810 bills for it, and a 997 confirms the message itself arrived.
+ RULES
The scope, and what has to get right.
-
850Purchase order. Fires when a trading partner wants to buy. Commonly breaks when item, quantity or cost fields do not map cleanly to your own SKU and pricing structure. -
855Purchase order acknowledgment. Fires in response to an 850, confirming what you can actually fulfil. Commonly breaks when the confirmed ship date or quantity is not honored downstream. -
856Advance ship notice (ASN). Fires once a shipment leaves the warehouse. The most commonly rejected transaction, usually on a carrier, pack structure or appointment mismatch against what was agreed. -
810Invoice. Fires after shipment to bill for the order. Commonly breaks when it does not match the ASN line for line, often from an unrecorded substitution. -
846Inventory advice. Fires on a schedule or trigger to report stock levels to the partner. Only useful if the source ERP data is actually accurate. -
997Functional acknowledgment. Fires automatically on receipt of any transaction. Its absence, rather than an error message, is usually the first sign of a connectivity or file-naming problem. -
824Application advice. Fires when a partner rejects a transaction at the application level, explaining what was wrong and why, distinct from a 997's simple receipt confirmation. -
812Credit/debit adjustment. Fires to correct a billing discrepancy after the fact, commonly tied to a chargeback or pricing dispute. -
753/754Routing request and routing instructions. Fires before a shipment moves in a collect-freight arrangement. These are routing documents used by Amazon Vendor Central Wholesale and other retailers that manage collect freight. See EDI 753 and 754 routing.
Other common X12 transaction sets
These are the other transaction sets you are most likely to meet in US retail and third-party logistics. They are included here as reference, to explain what each document is for. They are not part of the set listed above as the ones we run in production.
-
940Warehouse shipping order. A seller tells a third-party logistics warehouse to ship an order. It is the instruction that starts the pick and pack. -
945Warehouse shipping advice. The warehouse confirms back what actually shipped. It is the reply to a 940 and the basis for the ship notice that goes to the buyer. -
832Price and sales catalog. Product and price data sent to a trading partner, so the partner holds the same item and pricing information as the seller. -
860Purchase order change request. The buyer changes a purchase order it has already sent, for example a quantity, a date or a line. Buyer initiated. -
865Purchase order change acknowledgment. The seller accepts or rejects the change the buyer requested in an 860, line by line. -
820Payment order and remittance advice. Payment details and the remittance information that explains which invoices a payment covers. -
816Organizational relationships. Store and location lists for a trading partner, used to keep ship-to and bill-to locations aligned on both sides. -
857Shipment and billing notice. A ship notice and an invoice combined in one document, used by partners who prefer a single transaction to a separate 856 and 810.
Inside the system, not bolted on.
Mapped against your own ERP data model
Every transaction set is mapped to your actual item, order and shipment records, not a generic middleware template.
Every transaction logged, raw and parsed
The original file and the parsed result are both stored, so a dispute over what was sent or received can be checked directly.
Built per trading partner's real rules
Two partners using the same transaction set number can still have different requirements. Each is mapped to what that partner actually expects.
Multi-marketplace ERP, EDI and logistics automation for a US consumer electronics brand
- Off Sage, with the operating history intact: Customers, vendors, items and transaction history were migrated from Sage into a browser-based ERP covering order-to-cash and procure-to-pay, with a full general ledger, receivables and payables, so the business changed systems without losing its records.
- Native EDI inside the ERP: Every X12 document, including 850, 855, 856, 810, 846 and 997, is read and generated inside the ERP using the EdiFabric .NET library, with the mapping in its own code and no external translation service. Amazon Vendor Central (Wholesale and Direct Fulfillment) and Adorama connect directly over SFTP. Best Buy Optics, Costco Wholesale and Colony Brands run through SPS Commerce. Best Buy Purchasing, Bluestem Brands, QVC, Staples Advantage and Staples the Office Superstore run through CommerceHub (Rithum). BI Worldwide and Mason Companies run through Radial. The ERP uploads its own files to each network's FTP and reads the files the network delivers, and the network validates them and delivers them to the retailer. HSN, Harco Industries, Knocking and Verdi Commerce run on automated file exchange over FTP. Scheduled EDI jobs poll FTP on schedules as short as every ten minutes. Walmart runs through its API. The Walmart API integration imports WFS and seller-fulfilled orders, sends shipment confirmation and tracking back for seller-fulfilled orders, marks WFS orders shipped and invoices them automatically, turns returns into credit memos, and creates WFS inbound shipments. Every job is tracked on a monitoring dashboard.
- Every channel in one order queue: Amazon Vendor Central and Seller Central (SP-API), Walmart, HSN, QVC, Costco, several Shopify storefronts, eBay and direct wholesale accounts land in one system. Vendor Central purchase orders are accepted or rejected back to Amazon from the same screen that shows system, 3PL and allocated stock.
- Multi-warehouse and multi-3PL stock: Real-time inventory across an owned warehouse operated with a logistics partner, a second third-party warehouse and Amazon fulfillment locations, with warehouse transfer orders and an Amazon inbound shipment request action for FBA.
- FBA inbound shipment automation: End-to-end FBA inbound automation via SP-API: shipment creation, selection of the lowest-cost shipping plan, packing slip generation, label download and routing to the warehouse.
Common questions.
What is the difference between an 855 and a 997?
An 855 acknowledges the content of a purchase order, confirming quantity, price and ship date. A 997 simply confirms that a transaction, any transaction, was received without checking its content.
Why does an 856 get rejected more than other transaction sets?
It carries the most physical detail, carrier, pack structure, appointment, that has to match reality exactly. Any of those can drift out of sync between the warehouse and what the ASN says.
Do all trading partners use the same transaction sets?
The transaction set numbers are standardized by ANSI X12, but each partner's implementation guide sets its own required fields and business rules within that standard.
What happens if a 997 never arrives?
It usually means the transaction never reached the partner at all, a connectivity or file-naming issue rather than a data problem. It is the first thing worth checking before assuming a rejection.
Is a 753/754 the same as a standard ASN?
No. 753/754 is a routing request and instruction exchange that happens before an ASN in a collect-freight arrangement. It is used by Amazon Vendor Central Wholesale and other retailers that manage collect freight.
What is the difference between a 940 and a 945?
A 940 is an instruction and a 945 is a confirmation. The seller sends a 940 telling the warehouse to ship an order; the warehouse replies with a 945 stating what it actually shipped. One goes out before the goods move, the other after.
Is an 860 the same as an 855?
No, and they travel in opposite directions. An 855 is the seller acknowledging the buyer's original purchase order. An 860 is the buyer asking to change a purchase order it already sent, which the seller then accepts or rejects with an 865.
Where this connects.
Which transaction set is giving you trouble?
Tell us the code and what the rejection says, and we will tell you what it most likely means before you resend anything.