EDI 894 Delivery/Return Base Record: DSD Guide

The EDI 894 is the electronic delivery ticket of direct store delivery. When a beverage, bread, snack or dairy route driver backs up to a grocery store, the 894 is the record of exactly what came off the truck (or went back on it), at what cost, signed by the store receiver. For many grocery chains it is the document the store's books are built from, so an error on the 894 turns straight into a short-pay.

This guide covers what the 894 carries, how it moves (DEX at the back door or NEX ahead of the truck), every segment you will map, two live examples (a delivery and a return), the 895 response, and the errors that cause rejections and deductions.

What Is an EDI 894?

An EDI 894 is the Delivery/Return Base Record transaction set defined by the ASC X12 standards body, used by a DSD supplier to tell a retailer what was delivered to or returned from a specific store, item by item, with costs and totals. It grew out of the Uniform Communication Standard (UCS) used across the US grocery industry, which is why its segments use the grocery "G" prefix and why implementation guides often label the version 004010UCS.

Authoritative references for 894 work:

• The X12 transaction set catalog defines the 894 and 895 structures and their segment order
• GS1 US governs the UPC and GTIN identifiers carried in every 894 line, and the Global Location Numbers some retailers use in place of DUNS-plus-store codes
• Each DSD retailer publishes its own 894/895 implementation guide, which sets the required elements, the allowance codes it accepts, and its rules for returns and credits

Who sends it? The supplier, usually from the route driver's handheld or the route accounting system behind it.

Who receives it? The retailer: either the store's back-door receiving system or the chain's head-office EDI system.

When is it sent? At or just before the store delivery. One 894 covers one store, one delivery or return event.

Why does it matter? In DSD there is no distribution center to count the goods and no 856 ASN to reconcile against. The 894 is the count. If the store's receiver adjusts it, or the retailer cannot match it to its item and cost files, the difference comes off your payment.

How Direct Store Delivery Works

Most retail EDI follows the warehouse model: purchase order, ASN, receipt at a DC, invoice. DSD skips the DC. The supplier owns the product until it is on the shelf, and often places the order itself.

DSD suppliers make hundreds of stops a day, so every manual step multiplies. The 894 and its partner documents exist to make each stop a quick electronic exchange instead of a paper ticket that someone keys in later. For the wider landscape, see our guide to grocery EDI requirements.

DEX and NEX: Two Ways an 894 Travels

The same 894 structure moves through two channels. Your retailer's guide will say which it expects, and some chains accept both.

DEX (Direct Exchange). The driver's handheld connects to the store's receiving system at the back door, historically through a cable or cradle and on newer systems over a local network. The handheld sends the 894, the store system checks every item and cost against its own files, and the receiver accepts or adjusts on the spot. The store system returns an 895 to the handheld before the driver leaves. DEX is the original UCS use case, and the reason the 894 carries a signature segment and an integrity check.

NEX (Network Exchange). The supplier sends the 894 over a normal EDI connection (VAN, AS2 or SFTP) before or at the time of delivery, and the store receiver works from that record during check-in. The retailer returns an 895 later, through the same EDI channel. NEX removes the cable, but the record still has to match what the receiver counts.

In both cases the functional group code in GS01 is DX, and the version in GS08 is commonly 004010UCS or a later UCS release named in the retailer's guide.

The DSD Back-Door Check-In, Step by Step

A typical DEX delivery at a grocery store runs like this:

1. Route prep. The route accounting system loads the day's stops, the store-level item list and the agreed costs onto the driver's handheld. Item and cost data usually came from the retailer earlier, through 888 item maintenance or 832 price catalogs.
2. Build the delivery. At the store, the driver scans or keys what is coming off the truck. The handheld builds an 894 with G82 flagged D (delivery) and one G83 line per item.
3. Record returns. Out-of-code, damaged or recalled product picked up from the shelf goes into a separate 894 with G82 flagged C (return, a credit to the store).
4. Transmit. The handheld sends the 894s to the store's DEX receiving system.
5. Store verifies. The store system compares each UPC and cost against its own item file. Unknown items and cost mismatches are flagged for the receiver.
6. Receiver accepts or adjusts. The receiver counts the product. If everything matches, they accept. If not, they adjust quantity or cost.
7. Store responds. The store system sends an 895 back: accepted as sent, or accepted with adjustments.
8. Signature and close. The receiver's electronic signature is captured into G86, and the record is closed. The adjusted figures, not the driver's original ones, are what the retailer pays against.

Step 5 is where most DSD money is lost. A cost in the handheld that does not match the retailer's cost file gets adjusted down at the door, every time, until someone fixes the source data.

Interactive Example: DSD Delivery (894, Credit/Debit Flag D)

A beverage route driver delivers three case-packed lines to store 0147. The G82 header flags the record as a delivery (D), names the receiver by DUNS and store number, and dates it. Each G83 carries the consumer UPC, the supplier's item number, the case UPC, the cost per case and the pack. G84 totals 20 cases and $178.90 (sent as 17890 with two implied decimals). G86 holds the receiver's signature and G85 the integrity check.

Use the Plain English tab for a readable summary, or click any segment to break it down element by element.

Interactive Example: DSD Return (894, Credit/Debit Flag C)

On the same stop, the driver picks up a damaged case of cola and five loose out-of-date iced tea bottles. Returns go in their own 894 with G82 flagged C, so the amount is a credit to the store. Note line 2 is in eaches (EA) at the unit cost, because loose bottles are not a full case.

894 Structure at a Glance

The 894 is short. A typical record is a header, one loop per item, and a summary.

Retailer guides tighten these rules. Treat "optional" as "optional unless your partner's guide says otherwise", and read the guide before you build the map.

Key Segments Explained

G82: Delivery/Return Base Record Identifier

G82 is the header. It decides whether the record is a delivery or a return, and identifies both sides down to the store.

G82*D*DSD-118734*069854900*0147*123456789*0001*20261103~

The delivery/return number is the key the retailer reconciles on. Reusing one, even across stores, is a common reason an 894 is rejected as a duplicate.

G83: Line Item Detail (DSD)

Each G83 is one item on the delivery or return.

G83*1*10*CA*614141001293*VN*SBC-COLA-12C*614141001286*8.95*2*COLA 12PK CAN~

Two details cause most G83 trouble. The store matches on the UPC in G8304 (and sometimes the case code in G8307), so a UPC the store has never set up fails the line. And the cost in G8308 must be the cost for the unit in G8303: a case cost on an each line, or the other way round, multiplies the error by the pack.

G22: Pricing Information

G22 carries the shelf retail price and price multiple (for example 2 for $5.00) for the item. It matters for suppliers that maintain store pricing as part of the DSD service, and for retailers that check the supplier's suggested retail at receipt. Most deliveries omit it unless the retailer's guide asks for it.

G72: Allowance or Charge

G72 applies a deal, allowance or charge to an item line, or to the whole record when it appears in the summary. It carries an allowance or charge code, a handling method (for example, taken off invoice), a rate, the quantity it applies to, and a total amount. The codes a retailer accepts are listed in its 894 guide, and they must match the deal agreed with the category buyer. An allowance the retailer has no record of is removed at check-in. One the retailer expected and you left off becomes a later deduction.

G23: Terms of Sale

G23 carries payment terms where a retailer wants them on the delivery record itself. Many DSD retailers set terms in the vendor agreement instead, so this segment is often absent.

G84: Delivery/Return Record of Totals

G84*20*17890~

The store system recomputes both totals from the lines. If your G84 does not equal the sum of quantity times cost, net of allowances, the whole record is rejected, not just the line that is off. The implied decimal catches people out: 17890 means $178.90, and 178.90 in that element is read differently by many systems.

G86: Signature Identification

G86*B7E4D21A*M ALVAREZ~

G8601 holds the receiver's electronic signature (a code generated by the store system or captured on the handheld) and G8602 the receiver's name. It is the electronic equivalent of the receiver signing the paper ticket, and it is your proof of delivery if a quantity is disputed weeks later.

G85: Record Integrity Check

G85*3C9A7F21~

G85 carries a check value computed over the record's content. The store system computes the same value. If the two differ, the record was altered after it was built, and the store rejects it. Generate it with the algorithm in your retailer's guide, as the final step after every other element is final. Any edit after the check value is calculated, including a cost correction at the door, means recalculating it.

Deliveries and Returns: The Credit/Debit Flag

The single most important element in the 894 is G8201.

Keep deliveries and returns in separate 894s, even when they happen on the same stop. Do not net them into one record with negative lines; most store systems reject negative quantities in G8302. Where the retailer wants a return reason (out of code, damaged, recall), its guide names the segment and code list to use.

Units, Packs and Costs

DSD product moves in several units: a case of 24 bottles, a tray of bread, a single bottle pulled off the shelf. The 894 handles this through three elements on each G83 line that have to agree with each other and with the retailer's item file.

• Unit of measure (G8303) says what the quantity counts.
• Pack (G8309) says how many consumer units are inside one case.
• Item list cost (G8308) is the cost of one unit of the stated unit of measure.

If the retailer's item file says a cola case is 24 cans at $8.95 per case, an 894 line of 12*EA*...*8.95 bills twelve cans at the case cost, which the store system flags (or worse, accepts). Returns of loose product are the usual source of this error, because the handheld defaults to cases. The EDI inspector shows each line's quantity, unit and cost side by side, which makes these mismatches easy to spot in a sample file.

The 895 Response

The EDI 895 Delivery/Return Acknowledgment or Adjustment is the retailer's answer to an 894. It references the original record (by the delivery/return number and the integrity check) and either accepts it as sent or lists the adjustments the store receiver made.

An 895 typically carries:

• The original record's identification from G82, so you can match it
• A code saying whether the record was accepted, accepted with adjustments, or rejected
• For adjusted lines, the corrected quantity or cost per item
• The adjusted totals, a signature, and its own integrity check

Treat the 895 as the source of truth for what you will be paid. Post the adjusted quantities back to your route accounting, inventory and AR, and review the adjustments by store and by reason every week. Repeated cost adjustments on the same item point to a cost file that is out of sync; repeated quantity adjustments at the same store point to a receiving problem worth raising with the store manager. The 895 is a business response. The 997 Functional Acknowledgment still confirms only that the 894 arrived and was structurally valid.

EDI 894 vs 856, 810, 880 and 861

The 894 overlaps with several documents, which is why people searching "894 vs 856" are usually trying to work out which one their retailer actually wants.

The short version: the 856 describes a shipment going to a warehouse, the 894 records a delivery that already happened at a store. Whether the 894 also serves as the invoice depends on the retailer. Some pay directly from the reconciled 894 and 895. Others need an 810 or 880 that references the 894 number. Check the retailer's DSD guide, not its warehouse guide, since they often differ.

Where the 894 Sits in the DSD Document Flow

A full DSD relationship uses a small family of documents around the 894:

1. Item and cost setup. The retailer and supplier agree on the items and costs each store will receive, often through 888 Item Maintenance or an 832 Price/Sales Catalog. Promotional deals may arrive on an 889 Promotion Announcement.
2. Store order (optional). Some retailers send a store-level 850 or 875. Many DSD categories have no PO at all; the route rep decides.
3. 894 Delivery/Return Base Record. Sent at or before delivery for each store, one for the delivery and one for any returns.
4. 895 Delivery/Return Acknowledgment or Adjustment. The store accepts or adjusts.
5. Invoice (if required). An 810 or 880, for retailers that do not pay from the 894.
6. Payment. The retailer pays, often with an 820 remittance advice that lists which delivery numbers were paid and what was deducted.
7. Sales data (scan-based trading). Under scan-based trading, the supplier owns the stock until it scans at the register, and the retailer pays from 852 product activity data instead of from the delivery. The 894 still records what went into the store, so you can reconcile deliveries against scans and measure shrink.

Common 894 Errors and How to Prevent Them

Most of these surface as retail chargebacks or short-pays weeks later, far from the stop that caused them. Tracking 895 adjustments by reason code is the cheapest early warning you have.

894 Implementation Checklist

Before your first live 894 with a new retailer:

• Get the retailer's DSD 894/895 guide, and confirm DEX, NEX or both
• Confirm the identifiers it expects in G8203 to G8206 (DUNS, store numbers, GLNs)
• Load its item list and costs, and confirm every UPC you deliver is set up
• Confirm unit-of-measure codes and how loose returns must be sent
• Confirm whether it pays from the 894 or needs an 810 or 880 as well
• Get its allowance and charge code list for G72
• Implement the G85 integrity algorithm exactly as specified
• Agree a test plan: deliveries, returns, an adjusted delivery, and a rejected record
• Set up a process to post 895 adjustments back to your AR and route accounting
• Monitor 997s for structural rejections in the first weeks of production

If you are new to EDI as a whole, our EDI compliance guide and the EDI document types reference explain how the 894 fits alongside the other documents your retailers may require.

Handling DSD Orders With OrderSync

DSD suppliers usually have two order streams: the route, and everything else. Store and head-office orders arrive as EDI 850s and 875s, emails, PDFs, spreadsheets and phone calls, and someone keys them into the route system before the truck leaves.

OrderSync reads those orders in any format, matches the stores, items and units to your catalog, and outputs clean data to your ERP or route system, so the handheld starts each stop from the right order. Paste any 894 into the free EDI inspector to see it parsed segment by segment with a plain-English summary, read more about EDI for DSD distributors and beverage distribution, or book a 15-minute walkthrough to see your own orders processed.

Frequently Asked Questions