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.

The Grocery EDI Set: 875, 880 and the UCS Subset

Grocery runs a partly different transaction set from general retail, and a brand that only knows the 850/810/856 trio will meet two more the first time it ships to a grocery wholesaler. The distinction is not that grocery invented its own standard. ASC X12 publishes the 875 and 880 exactly as it publishes the 850 and 810. What is grocery-specific is the implementation guideline: the Uniform Communication Standard, or UCS, an X12 subset administered from 1983 by what was then the Uniform Code Council and is now GS1 US.

The 875 and 880 do the same jobs as the 850 and 810, so the impact is integration work rather than new process: your provider maps both sets, and the mapping is where the errors live. Which set a partner wants is a per-partner fact, not a per-industry one.

The document worth understanding on its own is the 180, Return Merchandise Authorization and Notification. It is a general X12 document rather than a grocery-only one, and the ordering catches people out. Under UCS it carries return product detail in support of a Credit/Debit Adjustment that was already sent, and references that adjustment's number. So the 812 comes first and the 180 explains it, which is the opposite of the general-retail reading where an RMA authorizes a return before it ships.

That ordering matters when reconciling deductions. The 812 above is the claim; the 180 is the itemized return detail behind it. If the two do not tie out, match on the adjustment number the 180 references rather than pairing documents by date.

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.