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, most commonly seen in Amazon's Direct Fulfillment program.
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: Direct trading-partner connections for Amazon Vendor Central, Walmart, HSN, QVC and Costco with 850, 855, 856, 810, 846 and 997 documents, polled on schedules as short as ten minutes. Every job is tracked on a monitoring dashboard, and there is no third-party EDI middleware in the chain.
- 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.
- International purchasing and landed cost: Ocean and air freight purchase orders carry ETD, bill of lading, ETA and vessel details, and the ERP calculates landed cost at receiving from tariff classification, duty, tariff, harbor surcharge and freight per item.
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, most commonly with Amazon Direct Fulfillment.
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.