# EDI 894 Delivery/Return Base Record: DSD Guide
> EDI 894 explained for direct store delivery: G82, G83, G84, G86 and G85 segments, delivery vs return examples, DEX vs NEX, the 895 response, and common errors.
The EDI 894 Delivery/Return Base Record is the X12 transaction a direct store delivery (DSD) supplier uses to record what a route driver delivered to, or picked up from, one retail store. It lists each item, quantity, unit cost and total, and carries the store receiver's electronic signature. The retailer answers with an 895 to accept or adjust it.
**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](https://x12.org/products/transaction-sets), 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](https://x12.org/products/transaction-sets) defines the 894 and 895 structures and their segment order
- [GS1 US](https://www.gs1us.org/industries-and-insights/standards) 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.
| | Warehouse model | Direct store delivery |
|---|---|---|
| **Who decides the order** | Retailer buyer sends an 850 | Supplier's route rep, often from a store walk or scan data |
| **Where goods arrive** | Retailer distribution center | Each individual store, through the back door |
| **Shipment notice** | 856 ASN before arrival | 894 at or before the delivery |
| **Who counts the goods** | DC receiving | Store receiver, at the back door, with the driver |
| **Returns** | Separate RMA and credit process | Picked up on the same stop, recorded as an 894 credit |
| **Typical categories** | General merchandise, center-store grocery | Soft drinks, beer, bread, snacks, dairy, ice, greeting cards |
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](/blog/grocery-edi).
## 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](/guides/edi/832-price-sales-catalog).
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.
| Position | Segment | Name | Usage | Notes |
|---|---|---|---|---|
| Header | **ST** | Transaction Set Header | Mandatory | `ST01` = `894` |
| Header | **G82** | Delivery/Return Base Record Identifier | Mandatory | Delivery or return, record number, receiver, supplier, date |
| Header | **N9** | Reference Identification | Optional | Extra references some retailers require (route, driver, order) |
| Header | **G62** | Date/Time | Optional | Delivery time window or actual arrival time |
| Detail loop | **G83** | Line Item Detail (DSD) | Mandatory, repeats | One per item: quantity, UOM, UPC, item ID, cost, pack |
| Detail loop | **G22** | Pricing Information | Optional | Retail price and price multiple for the store shelf |
| Detail loop | **G72** | Allowance or Charge | Optional | Line-level allowances, deals or charges |
| Detail loop | **G23** | Terms of Sale | Optional | Line-level terms where the retailer uses them |
| Summary | **G84** | Delivery/Return Record of Totals | Mandatory | Total quantity and total amount |
| Summary | **G86** | Signature Identification | Optional, often required | Receiver's electronic signature and name |
| Summary | **G85** | Record Integrity Check | Mandatory in most DEX guides | Check value computed over the record |
| Summary | **SE** | Transaction Set Trailer | Mandatory | Segment count and control number |
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~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **G8201** | Credit/Debit Flag Code | `D` | `D` = delivery (a debit to the store). `C` = return (a credit to the store) |
| **G8202** | Supplier's Delivery/Return Number | `DSD-118734` | Your ticket number. The retailer pays and adjusts against it, so it must be unique |
| **G8203** | Receiver ID | `069854900` | The retailer, usually by DUNS number |
| **G8204** | Receiver Location Number | `0147` | The store number |
| **G8205** | Supplier ID | `123456789` | The supplier, usually by DUNS number |
| **G8206** | Supplier Location Number | `0001` | The supplier's depot or branch that ran the route |
| **G8207** | Delivery/Return Date | `20261103` | The date of the delivery or pickup |
| **G8208** | Purchase Order Number | | Used where the retailer issued a store order |
| **G8209** | Purchase Order Date | | The date of that order |
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~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **G8301** | Assigned Number | `1` | Line sequence number |
| **G8302** | Quantity | `10` | Units delivered or returned |
| **G8303** | Unit of Measure | `CA` | `CA` case, `EA` each, and other codes the retailer allows |
| **G8304** | UPC (Consumer Package Code) | `614141001293` | The UPC the store scans at the register |
| **G8305** | Product/Service ID Qualifier | `VN` | What the next element is. `VN` = vendor item number |
| **G8306** | Product/Service ID | `SBC-COLA-12C` | Your item number |
| **G8307** | UPC Case Code | `614141001286` | The case-level code, when the line is in cases |
| **G8308** | Item List Cost | `8.95` | Cost per unit of measure. Must match the retailer's cost file |
| **G8309** | Pack | `2` | Consumer units inside one case |
| **G8310** | Cash Register Item Description | `COLA 12PK CAN` | The short description the store prints on receipts |
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~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **G8401** | Quantity | `20` | Sum of `G8302` across all lines |
| **G8402** | Monetary Amount | `17890` | Total cost of the record, with two implied decimals ($178.90) |
| **G8403** | Amount | | Total deposit amount, used for bottle and container deposits where they apply |
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`.
| | Delivery | Return |
|---|---|---|
| **G8201** | `D` (debit) | `C` (credit) |
| **Effect on the store** | Store owes the supplier | Supplier owes the store |
| **Typical reasons** | Scheduled delivery, fill-in order, new item launch | Out of code, damaged, recalled, discontinued, overstock pull |
| **Quantities and amounts** | Positive | Positive. The flag, not a minus sign, makes it a credit |
| **Who else cares** | Store receiving, AP | Store receiving, AP, and often a category or loss team tracking shrink |
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](/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](/guides/edi/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.
| Document | Sent by | Purpose | Used in DSD? |
|---|---|---|---|
| **894 Delivery/Return Base Record** | Supplier | Records items delivered to or returned from one store, with cost and receiver signature | Core DSD document |
| **[856 Ship Notice/ASN](/guides/edi/856-ship-notice)** | Supplier | Tells a DC what is in a shipment before it arrives, down to pallet and carton | Rarely. Some retailers ask for an 856 on DSD, most use the 894 |
| **[810 Invoice](/guides/edi/810-invoice)** | Supplier | Bills for goods. General purpose | Some retailers require an 810 after the 894 is reconciled |
| **[880 Grocery Products Invoice](/guides/edi/880-grocery-products-invoice)** | Supplier | Grocery invoice with catch-weight and allowance detail | Some grocery chains bill DSD on the 880 |
| **[861 Receiving Advice](/guides/edi/861-receiving-advice)** | Retailer | Reports what a DC actually received | The 895 does this job in DSD |
| **895 Delivery/Return Acknowledgment** | Retailer | Accepts or adjusts an 894 | Core DSD document |
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](/guides/edi/832-price-sales-catalog). Promotional deals may arrive on an 889 Promotion Announcement.
2. **Store order (optional).** Some retailers send a store-level [850](/guides/edi/850-purchase-order) or [875](/guides/edi/875-grocery-product-purchase-order). 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](/guides/edi/810-invoice) or [880](/guides/edi/880-grocery-products-invoice), for retailers that do not pay from the 894.
6. **Payment.** The retailer pays, often with an [820 remittance advice](/guides/edi/820-payment-order) 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](/guides/edi/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
| Error | What happens | Prevention |
|---|---|---|
| **Cost mismatch in `G8308`** | Store adjusts every line down to its cost file; you get paid less | Sync costs from the retailer before routes load. Review 895 cost adjustments weekly |
| **Unknown UPC** | Line rejected or held at the door | Confirm new items are set up at the retailer (888 or 832) before the first delivery |
| **Wrong unit of measure on returns** | Loose units credited at case cost, or cases at unit cost | Force the unit and cost together on the handheld; check pack in `G8309` |
| **`G84` totals do not match lines** | Whole record rejected | Compute totals from the lines at build time, never key them |
| **Implied decimal error in `G8402`** | Amount read as 100 times too large or small | Send whole cents with no decimal point, per the guide |
| **Integrity check out of date** | Record rejected after a late edit | Recalculate `G85` after every change |
| **Duplicate delivery/return number** | Second record rejected as a duplicate | Number from a single sequence per supplier, never per handheld |
| **Delivery and return netted together** | Negative quantities rejected, or credit lost | Always send returns as their own 894 with flag `C` |
| **Missing signature** | No proof of delivery when the quantity is disputed | Do not close the stop without `G86` |
| **Allowance not on file** | `G72` removed at check-in; deal disputed later | Load deal codes and dates from the buyer agreement, and end them on time |
Most of these surface as [retail chargebacks](/glossary/retail-chargeback) 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](/edi-compliance) and the [EDI document types reference](/edi-document-types) 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](/edi-inspector) to see it parsed segment by segment with a plain-English summary, read more about [EDI for DSD distributors](/edi-for/dsd-distributors) and [beverage distribution](/edi-for/beverage-distribution), or [book a 15-minute walkthrough](/book-call) to see your own orders processed.
## Frequently Asked Questions
### What is an EDI 894 used for?
The EDI 894 records a direct store delivery. A DSD supplier uses it to tell a retailer exactly which items, quantities and costs were delivered to or returned from a specific store, with the receiver's electronic signature. The retailer checks it against its own item and cost files and replies with an 895.
### What is the difference between an EDI 894 and an EDI 856?
The 856 ASN describes a shipment heading to a retailer's distribution center, down to pallets and cartons, before it arrives. The 894 records a delivery made directly to a store, item by item with cost, at the time of check-in. DSD retailers use the 894 because there is no DC receipt to reconcile against.
### What is the G82 segment in an EDI 894?
G82 is the 894 header. G8201 flags the record as a delivery (D) or a return (C), G8202 is the supplier's delivery or return number, G8203 and G8204 identify the retailer and store, G8205 and G8206 identify the supplier and its depot, and G8207 is the date.
### How are returns sent on an EDI 894?
Returns go in their own 894 with G8201 set to C, which makes the record a credit to the store. Quantities stay positive; the flag makes them a credit. Do not net returns into a delivery record with negative lines.
### What is the difference between the EDI 894 and EDI 895?
The supplier sends the 894 to record a delivery or return. The retailer sends the 895 back to accept the 894 as sent or to report the quantity and cost adjustments the store receiver made. The adjusted 895 figures are what the retailer pays against.
### What is DEX in direct store delivery?
DEX (Direct Exchange) is the in-store exchange of 894 and 895 records between the driver's handheld and the store's receiving system at the back door, completed before the driver leaves. NEX (Network Exchange) sends the same records over a normal EDI connection instead.
### Is the EDI 894 an invoice?
It depends on the retailer. Some pay directly from the reconciled 894 and 895, so the 894 works as the invoice of record. Others require a separate 810 or 880 invoice that references the 894 delivery number. The retailer's DSD implementation guide says which.
### What does G85 mean in an EDI 894?
G85 is the record integrity check, a value computed over the content of the record using the algorithm in the retailer's guide. The store system computes the same value and rejects the record if they differ, so G85 must be recalculated after any change.