James Allman | JA Technology Solutions LLC
Reading DSD Deliveries: DEX, EDI 894, and 895
Direct store delivery hands you the same delivery record two ways: at the dock as DEX, and over the wire as EDI 894/895. Here is what is inside each, and how to read it.
A direct-store-delivery vendor pulls up to the back of the store, rolls in the bread or the soda or the chips, stocks the shelf, and leaves a record of what was delivered. That record is the part that matters to everyone downstream. Receiving, accounts payable, and the item file all need to know exactly what came in, in what quantity, and at what cost. The delivery itself takes minutes. Reconciling the record behind it, if it arrives as paper, can take far longer.
DSD delivery data travels in one of two forms. At the dock it is often DEX, handed device to device. Over the wire it is EDI, specifically the 894 and 895 transaction sets. The useful thing to understand up front is that these are not two different datasets. They are the same delivery record in two different envelopes. Once you can read one, the other is mostly a matter of unwrapping.
Why DSD takes a different path
Most grocery inventory arrives through a distribution center. The retailer orders it, the DC ships it, and the goods move through the retailer's own replenishment and receiving systems. DSD skips the DC. The vendor owns the product all the way to the shelf, decides what to restock, delivers it directly, and bills for what was delivered. Bread, beverages, snacks, dairy, and beer are the classic categories, and a single store can take a dozen or more DSD vendors a week, each on its own schedule.
Because the vendor holds the delivery detail, the data has to cross from their system into yours at the moment of delivery. That single fact is why DEX exists, and why the 894 and 895 are shaped the way they are. The document is built to be produced by the party making the delivery and consumed by the party receiving it, with just enough structure to drive receiving and payment.
The 894 and 895: delivery and return as documents
The 894 is the Delivery/Return Base Record. It says what a vendor delivered to a store, or what it picked up as a return. The 895 is the Delivery/Return Acknowledgment and Adjustment, the response that confirms or corrects what the 894 reported. Both are UCS transaction sets, the grocery-industry dialect of ANSI X12, so they read like the EDI you may already know but use a grocery-specific G-series of segments. If X12 is new to you, my walkthrough of what is inside an 850, 810, and 856 covers the envelope and segment basics this article builds on.
The structure is compact. A G82 header opens the document with the single most important field on it: a credit or debit flag, where D marks a delivery and C marks a return. That one flag is why a single document type covers both directions. The header also carries the supplier and receiver identifiers, the store, the delivery document number, and the date. A G83 segment then repeats once per line item, carrying the UPC, the quantity, the unit of measure, and the cost. A G84 summary closes with the totals, and a G85 integrity check and G86 signature can follow.
Element positions in the G-series are not as uniform as people expect. Trading partners and software versions differ on which G83 element holds the case cost versus the unit cost, or how the embedded weight on a random-weight line is expressed. The segment identifiers are stable; the exact meaning of element seven is a thing you confirm against your partner's implementation guide. The X12 Segment Reference lists the sequences, and the explorer below shows you the raw segments so you can check.
DEX: the same documents, handed over at the dock
DEX, short for Direct Exchange, is how that delivery record moves when there is no EDI link to the vendor, which at the store level is common. Historically the driver's handheld plugged into a port on the store's receiving controller and pushed the data across; today the same handoff often happens over a short-range wireless or USB connection. Either way, DEX is a transport, not a new document format.
What DEX wraps is the UCS 894 and 895. A DEX transmission opens with a DXS application header that names the sender, the receiver, the version, and a control number, then carries one or more ordinary 894 or 895 transaction sets, then closes with a DXE trailer whose control number must match the DXS. If you have read an 894, you have read the inside of a DEX file. The envelope is the only new part, and its main job is to identify the two parties and prove the transmission arrived intact.
Reading one yourself
I built two free tools for exactly this. The EDI 894/895 Explorer takes a raw 894 or 895, whether it arrived bare or inside an ISA and GS envelope, and turns it into a readable delivery: direction, parties, a line-item table with UPC, quantity, and cost, and the document totals. The DEX/UCS File Explorer does the same for a DEX file, first parsing the DXS and DXE envelope and checking that the control numbers match, then decoding each embedded 894 or 895.
Both tools show two views. The structured view is the readable delivery, and it is best-effort, because as noted the G-series element positions vary by partner. The raw view labels every segment exactly as transmitted, and that view is always correct, because it is driven by the parser rather than by any assumption about element seven. When a delivery does not reconcile, the raw view is where you confirm what the document actually said. Everything runs in the browser, so a vendor's file never leaves your machine.
One related wrinkle worth a tool of its own: DSD leans heavily on random-weight items like packaged meat, where the price or weight is embedded in a number-system-2 barcode rather than tied to a fixed UPC. The Random-Weight UPC (Type 2) Decoder pulls those apart the same way these explorers pull apart a delivery record.
From delivery record to posted data
Reading a delivery is the start, not the finish. The work that actually saves time is what happens after: matching the delivery against the purchase order or the agreed cost, validating each line against the item file so an unrecognized UPC is caught at receiving rather than at the register, flagging cost changes the vendor slipped in, and posting the result to accounts payable without anyone rekeying it. Done well, the driver leaves and the delivery is already reconciled.
That is the integration I build: turning DEX and EDI 894/895 deliveries into clean, posted data inside grocery and retail systems, including the older host platforms a lot of this still runs on. If you are taking DSD deliveries on paper, or capturing DEX but rekeying it into your back office, there is usually a direct path to automating it. Read more about my EDI services and integration work, or get in touch to talk through your delivery data.