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 812, credit/debit adjustment: the itemized deduction or chargeback claim behind the dollars netted out on the 820 — the document deduction-management tooling reads to validate and dispute invalid claims.
• 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?.

What EDI mapping is

An EDI document arrives in a fixed, standardized layout: numbered segments and elements in a set order, the same shape no matter who sent it. Your own systems do not speak that layout. An order in your ERP has fields named for your business: item code, case pack, ship-to location, requested date. EDI mapping is the work of translating between the two. It defines which segment and element in an incoming 850 becomes which field in your order record, and which of your fields becomes which segment when you send an 810 back.

Mapping is per partner, not once for the company. The EDI standard fixes the structure, but it leaves room, and every retailer fills that room differently. One partner puts the buying location in a segment another partner uses for the warehouse. One sends a UPC where another sends an internal item number. So a brand selling into a dozen retailers maintains a dozen maps, each tuned to how that partner actually populates the document rather than how the standard says it could.

Why mapping is where the work and the errors live

The transactions themselves are stable once they run. The maps are where things break, because they sit on top of two systems that both keep changing. A retailer adds a field, renames a location code, or starts sending a qualifier it never sent before. You add a SKU, restructure your item master, or switch ERPs. Any of those can quietly break a map, and a broken map does not always fail loudly. It can pass a malformed order straight through to fulfillment.

That is why mapping errors show up as operational problems rather than EDI problems. A unit-of-measure element mapped wrong turns a case order into an each order, and the short shipment looks like a fulfillment miss. An item number that maps to the wrong SKU ships the wrong product. A ship-to that lands in the wrong field routes the truck to the wrong DC. The 850 was valid EDI; the map read it wrong. Treating the EDI feed as a data source, as the order-as-demand-signal section above argues, depends on the map being right, because everything downstream inherits whatever the map produced.

Electronic data interchange as a standard, not a pipe

It helps to separate the two things electronic data interchange refers to. There is the standard, the agreed format and document numbers that let two companies exchange business records without re-keying them by hand. And there is the connection, the network or protocol that carries those documents between you and the retailer. Mapping belongs to the first. It is about meaning: what each element means and where it goes. The connection only moves bytes.

This is why a brand can have a connection that works perfectly and still get bad data. The documents arrive on time, fully valid against the standard, and the map still drops them into the wrong fields. Reading EDI as data, lining an order up against a shipment, an invoice, and a scan, only works when the mapping underneath is sound. For where the sell-through side of that comparison comes from, see POS data.