EDI Transactions in Retail, Explained

EDI transactions are the standardized electronic documents a brand and a retailer swap to run their trading relationship: purchase orders, advance ship notices, invoices, remittances, and a long tail of others. EDI stands for electronic data interchange. For most CPG brands it is invisible plumbing, the orders just show up, and nobody thinks about it. But the EDI flow is also a data source, and the brands that treat it that way catch problems their sales reports never mention.

The common retail EDI transactions

EDI documents are identified by number, and a handful of them carry most of the retail relationship.

• EDI 850, purchase order: the retailer's order, with items, quantities, ship-to, and dates.
• EDI 856, advance ship notice (ASN): what you are shipping and how it is packed; a late or wrong ASN is a classic source of compliance chargebacks.
• EDI 810, invoice: your bill for the shipment.
• EDI 820, payment and remittance advice: what the retailer actually paid, and what it deducted.
• EDI 852, product activity data: retailer sell-through and inventory, pushed as an EDI feed instead of pulled from a portal.

The 850, 856, 810, and 820 form the order-to-cash loop. The 852 is the odd one out. It is not a transaction in the trading sense at all; it is the retailer pushing POS-style data back to you.

Why EDI transactions count as a data source

It is easy to file EDI under IT plumbing, the kind of thing you set up once and never look at again. But the transaction flow carries real signal if you read it.

• The 850 stream is a demand signal: order patterns shift before sell-through reports catch up, and a run of smaller purchase orders is an early warning worth heeding.
• The 852, where a retailer sends it, is sell-through and inventory data, a direct feed that can stand in for a portal export.
• The 820 carries the deductions, so reading remittance detail is how you see what was actually paid against what you invoiced, which is the front end of deduction management.

EDI transactions tie the operational record to the sales record. An order that never turned into a scan, an invoice that came back short: those gaps live in the EDI flow, and they are visible there before they show up anywhere else.

EDI and the rest of retailer data

EDI is one channel among several, and it has limits worth naming. The 850 and 810 are operational, not sell-through. They tell you what was ordered and billed, not what shoppers carried out the door. For demand you still need POS data, whether that arrives by EDI 852, a portal, or a syndicated panel. The payoff comes from reading the operational EDI flow next to the sell-through feeds, so an order, a shipment, an invoice, and a scan can all be lined up against each other.

EDI transactions are one part of the retailer-data picture. For how they fit with portals, POS, and syndicated data, see What is retailer data?.