# EDI 816 Organizational Relationships: Store Lists
> EDI 816 explained: how Walmart and other retailers send store and DC location lists, the BHT, HL, N1 and ASI segments, full and change file examples.
The EDI 816 Organizational Relationships is the X12 transaction a retailer or other parent organization uses to send partners its locations and how they relate: head office, stores and distribution centers, each with an ID such as a GLN, an address and a store number. Suppliers load it to turn store codes on orders into real addresses.
**The EDI 816 is the retailer's location master, sent to you as EDI.** A store-level purchase order often names the ship-to by a store number or a GLN and nothing else. The 816 is the document that tells you store 0147 is a real building at a real address, which DC sits above it, and when it opens, moves or closes.
This guide covers what the 816 carries, how retailers such as Walmart use it, every segment you will map, two live examples (a full location list and a change file), and the errors that leave orders pointing at stores your system has never heard of.
## What Is an EDI 816?
**An EDI 816 is the Organizational Relationships transaction set defined by the [ASC X12 standards body](https://x12.org/products/transaction-sets), used to send information about a parent organization, its members, and how each member relates to the parent or to another member.** X12 describes the parent as an association, a multi-hospital system, a chain of retail stores or a holding company. In retail supply chains, the parent is the retailer and the members are its stores, distribution centers and offices.
Authoritative references for 816 work:
- The [X12 transaction set catalog](https://x12.org/products/transaction-sets) defines the 816 structure: a BHT header, then an HL loop per organization or location, each with its own name, address, contact and reference segments
- [GS1's Global Location Number (GLN) standard](https://www.gs1.org/standards/id-keys/gln) governs the 13-digit location identifiers many retailers use in the 816 to name each store and DC
- Each retailer that sends an 816 publishes its own implementation guide, which sets the version, the codes it uses, how often it sends the list and whether it expects a 997 back
**Who sends it?** The parent organization. In retail, that is the retailer, sending to its suppliers.
**Who receives it?** The supplier, or the supplier's EDI provider, which loads it into a customer location table in the ERP or EDI system.
**When is it sent?** On the retailer's schedule. A common pattern is one full list when you start trading, followed by regular change files as stores open, move or close.
**Why does it matter?** Your [850 purchase orders](/guides/edi/850-purchase-order) and the [856 ASNs](/guides/edi/856-ship-notice) you send back use location codes. If your location table is out of date, a new store's order cannot be routed, and an ASN or invoice can go out with a ship-to the retailer no longer recognizes.
## Why Suppliers Receive an 816
Retail orders are built around location codes, not addresses. A store replenishment 850 typically identifies its ship-to in the `N1` segment with a qualifier and a code, for example `N1*ST*STORE 0147*92*0147` (a buyer-assigned store number) or `N1*ST**UL*0851234001475` (a GLN). Orders that split one PO across many stores often carry the store numbers in `SDQ` segments, with no address at all.
Your system has to turn each of those codes into a delivery address, a carrier route and, for DC-bound freight, the right DC. That needs a location table keyed by the same codes the retailer uses, and kept current. The 816 is how many retailers keep that table current for you, rather than emailing a spreadsheet of store openings every month.
| Without an 816 | With an 816 |
|---|---|
| Store list comes as a spreadsheet, a portal download, or not at all | Location data arrives as EDI on a schedule |
| New store numbers fail order import until someone adds them by hand | New stores are in your table before their first order |
| Relocated stores keep their old address in your system | Address changes arrive with an effective date |
| Closed stores stay active, so freight can be routed to them | Deletes arrive as explicit actions |
| GLN to store number cross-reference kept by hand | Both identifiers arrive together for each location |
## How Walmart Uses the EDI 816
Walmart is one of the best-known senders of the 816, which is why "EDI 816 Walmart" is a common search. Walmart lists the 816 among the documents in its supplier EDI program and uses it to send location address information: each location's GLN, shipping address, phone number, internal store or DC number, and effective dates. In practice it works as an address listing that suppliers load into their own systems.
What varies by supplier, and what only Walmart's own documentation can tell you:
- Whether you are set up to receive the 816 at all. It is not part of every supplier's document set
- Which X12 version you receive, and which locations are included
- How often full lists and change files are sent
- Whether a 997 is expected in return
Get those answers from the implementation guide in your Walmart supplier EDI documentation, or from your EDI provider. For the wider list of documents Walmart requires, see our [Walmart EDI requirements](/edi-compliance/walmart) guide. Other retail chains and buying groups use the 816 for the same purpose, and some use it for membership lists or purchasing eligibility instead, which is why the retailer's guide matters more than the standard here.
## Full Lists and Change Files
Most retail 816 programs send two kinds of file, told apart by the purpose code in `BHT02`:
| | Full list | Change file |
|---|---|---|
| **BHT02** | `00` (original) | `04` (change) |
| **Contents** | Every location in scope | Only locations that were added, changed or removed |
| **ASI segment** | Usually absent | Present on each location, saying what to do with it |
| **How to load it** | Replace or reconcile your whole table for that retailer | Apply each action to the one location it names |
| **Typical use** | Onboarding, or a periodic resync | Ongoing maintenance |
The most damaging 816 bug comes from mixing these up. Treat a change file as a full list and every location not in it looks closed. Treat a full list as a change file and stores that closed months ago stay active forever.
## Interactive Example: Full Location List (816, Purpose 00)
A fictional grocery chain, Lakeshore Markets, sends its full location list to a supplier. `BHT` flags it as an original (`00`). The heading `N1*FR` names the sender. The first `HL` (level `35`, company) is the corporate office. Each following `HL` (level `36`, operating unit) points to the corporate office as its parent and describes one location: two stores with GLN, address, phone and store number, and the distribution center (`N1*WH`).
Use the **Plain English** tab for a readable summary, or click any segment to break it down element by element.
## Interactive Example: Location Change File (816, Purpose 04)
A week later the chain sends a change file. `BHT02` is `04`. Store 0152 is relocating: its loop carries the full new address, an effective date in `DTM*007`, and `ASI*2*001`, which tells you to replace the whole record. Store 0133 is closing: `ASI*2*002` deletes it from the effective date. Only the affected locations are included.
## 816 Structure at a Glance
The 816 has a short heading that identifies the sender, then one HL loop per organization or location.
| Position | Segment | Name | Usage | Notes |
|---|---|---|---|---|
| Heading | **ST** | Transaction Set Header | Mandatory | `ST01` = `816` |
| Heading | **BHT** | Beginning of Hierarchical Transaction | Mandatory | Structure code, purpose, reference number and date |
| Heading | **DTM** | Date/Time Reference | Optional | Dates that apply to the whole list |
| Heading | **REF** | Reference Identification | Optional | References for the whole list |
| Heading N1 loop | **N1** | Name | Mandatory | Usually `FR`, the organization sending the list |
| Heading N1 loop | **N2, N3, N4, PER, REF** | Name, address, contact, references | Optional | Details for the sender |
| Detail HL loop | **HL** | Hierarchical Level | Mandatory, repeats | One per organization or location |
| Detail N1 loop | **N1** | Name | Mandatory | The organization or location: entity code, name, ID |
| Detail N1 loop | **N2** | Additional Name Information | Optional | Longer names |
| Detail N1 loop | **N3** | Address Information | Optional | Street address |
| Detail N1 loop | **N4** | Geographic Location | Optional | City, state, postal code, country |
| Detail N1 loop | **PER** | Administrative Communications Contact | Optional | Phone, fax or email for the location |
| Detail N1 loop | **REF** | Reference Identification | Optional | Store number, DUNS or other IDs |
| Detail N1 loop | **QTY** | Quantity | Optional | Counts some partners attach to a location |
| Detail N1 loop | **DTM** | Date/Time Reference | Optional | Effective dates for this location |
| Detail N1 loop | **LQ** | Industry Code | Optional | Classification codes some partners use |
| Detail N1 loop | **ASI** | Action or Status Indicator | Optional | What to do with this location in a change file |
| Summary | **SE** | Transaction Set Trailer | Mandatory | Segment count and control number |
The functional group code in `GS01` is **OR**. Retailers use only a subset of these segments. Treat "optional" as "optional unless your partner's guide says otherwise".
## Key Segments Explained
### BHT: Beginning of Hierarchical Transaction
`BHT` says how the HL loops are organized and whether this is a full list or a change.
```
BHT*0065*00*LM20261102FULL*20261102~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **BHT01** | Hierarchical Structure Code | `0065` | The order of HL levels. Retail store lists commonly use `0065`, company then operating unit |
| **BHT02** | Transaction Set Purpose Code | `00` | `00` original (full list), `04` change. The retailer's guide lists any others it uses |
| **BHT03** | Reference Identification | `LM20261102FULL` | The sender's ID for this list. Mandatory in the 816 |
| **BHT04** | Date | `20261102` | The date the list was created. Mandatory in the 816 |
| **BHT05** | Time | | Optional creation time |
### HL: Hierarchical Level
Each `HL` starts one organization or location.
```
HL*2*1*36~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **HL01** | Hierarchical ID Number | `2` | A unique number for this level within the transaction |
| **HL02** | Hierarchical Parent ID Number | `1` | The `HL01` of the parent. Blank on the top level |
| **HL03** | Hierarchical Level Code | `36` | What this level is. Retail lists commonly use `35` (company) and `36` (operating unit) |
The parent link is where the "relationships" in the name come from. In the examples every store and the DC point to the corporate office. A retailer that wants to tell you which DC serves which store can nest store levels under DC levels instead. Its guide will show the structure it uses, and your loader should follow `HL02` rather than assume a flat list.
### N1: Name (the location itself)
The `N1` inside each HL loop identifies the organization or location.
```
N1*SN*LAKESHORE MARKET 0147*UL*0851234001475~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **N101** | Entity Identifier Code | `SN` | What kind of party. `CQ` corporate office, `SN` store, `WH` warehouse are common in retail lists |
| **N102** | Name | `LAKESHORE MARKET 0147` | The location's name |
| **N103** | Identification Code Qualifier | `UL` | The ID type in `N104`. `UL` is a GS1 Global Location Number. `1` is a DUNS number, `92` a buyer-assigned code |
| **N104** | Identification Code | `0851234001475` | The ID itself |
The heading `N1` uses `FR` (message from) to name the sender of the list. That one does not describe a location.
### N3, N4 and PER: Address and Contact
```
N3*1820 BEACON AVENUE~
N4*MUSKEGON*MI*49441*US~
PER*IC**TE*2315550147~
```
`N3` carries the street address, `N4` the city, state, postal code and country, and `PER` a contact. In the example, `IC` is an information contact and `TE` marks a telephone number. This is the data your carrier labels, routing and ASN ship-to blocks depend on.
### REF: Reference Identification
```
REF*ST*0147~
```
`REF` carries other identifiers for the location. `ST` is the store number, the code that appears on most store-level orders. Retailers also use `REF` for DUNS-based IDs and other cross-references. Store numbers often have leading zeros, so store them as text, never as numbers.
### DTM: Effective Date
```
DTM*007*20261116~
```
`DTM01` qualifier `007` means effective. The date in `DTM02` is when the location record, or the change to it, takes effect. A store relocating on the 16th should keep its old address in your system until then.
### ASI: Action or Status Indicator
```
ASI*2*001~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **ASI01** | Action Code | `2` | `2` is change (update) |
| **ASI02** | Maintenance Type Code | `001` | `001` change, meaning replace the whole record for this location. `002` delete |
| **ASI03** | Status Reason Code | | Optional reason |
`ASI` usually appears only in change files. The maintenance codes a retailer uses, including the one it sends for a brand-new location, are listed in its guide. Map them from the guide, not from an example file, because a code you have not mapped will be ignored or misapplied.
## EDI 816 vs Other Master Data Documents
The 816 is one of several documents that keep your data in line with a retailer's. People searching for it are often trying to work out which one carries what.
| Document | Sent by | Carries | How it relates to the 816 |
|---|---|---|---|
| **816 Organizational Relationships** | Retailer | Locations: stores, DCs, offices, their IDs and addresses | The location master |
| **[832 Price/Sales Catalog](/guides/edi/832-price-sales-catalog)** | Supplier (or retailer) | Items, prices and product attributes | The item master. Locations and items together drive order validation |
| **[850 Purchase Order](/guides/edi/850-purchase-order)** | Retailer | An order, with ship-to as a store number or GLN | Uses the codes the 816 defines |
| **[856 Ship Notice](/guides/edi/856-ship-notice)** | Supplier | Shipment contents and ship-to | Must carry a ship-to the retailer recognizes |
| **[810 Invoice](/guides/edi/810-invoice)** | Supplier | Billing, often repeating the ship-to | A wrong location here can cause a matching failure |
| **[997 Functional Acknowledgment](/guides/edi/997-functional-acknowledgment)** | Supplier | Receipt and syntax check of the 816 | Only if the retailer's guide asks for one |
## Loading an 816: Step by Step
1. **Receive and acknowledge.** Translate the file and send a 997 if the retailer's guide requires one.
2. **Check the purpose.** Read `BHT02`. A full list and a change file need different load logic.
3. **Walk the hierarchy.** Build each location from its HL loop, and record its parent from `HL02`.
4. **Key on the retailer's codes.** Store each location under the identifiers your orders will use: GLN, store number, or both.
5. **Apply actions with dates.** For change files, apply each `ASI` action from the `DTM` effective date, not the file date.
6. **Flag, don't silently drop.** A delete for a location that still has open orders, or a change for a location you have never seen, needs a person to look at it.
7. **Use it on the next order.** When the next 850 arrives, its ship-to codes resolve against the updated table.
## Common 816 Errors and How to Prevent Them
| Error | What happens | Prevention |
|---|---|---|
| **Change file loaded as a full list** | Every location not in the file is marked closed | Branch on `BHT02` before loading |
| **Full list loaded as changes** | Closed stores never get removed | Reconcile the whole table on a full list |
| **Leading zeros stripped from store numbers** | `0147` becomes `147` and orders stop matching | Store IDs as text |
| **Changes applied on receipt, not on the effective date** | Freight routed to a new address before the store moves in | Schedule changes from `DTM*007` |
| **Unmapped ASI maintenance code** | New stores never added, or deletes treated as changes | Map every code in the retailer's guide |
| **Hierarchy flattened** | DC-to-store relationships lost | Keep `HL02` parent links |
| **Matching on name instead of ID** | Two stores with similar names merged | Key on GLN or store number |
| **No 816 coming at all** | Store list drifts out of date silently | Confirm with the retailer whether you are set up to receive it, and on what schedule |
Paste any 816 into the [free EDI inspector](/edi-inspector) to see each location listed with its IDs, address and action in plain English, which is the quickest way to check what a change file is really asking you to do.
## 816 Implementation Checklist
Before you rely on an 816 feed from a retailer:
- Get the retailer's 816 implementation guide and confirm the X12 version
- Confirm which locations are included: stores, DCs, offices, or all of them
- Confirm the schedule for full lists and change files
- Map the `BHT02` purpose codes and every `ASI02` maintenance code the guide lists
- Decide which identifiers you key on (GLN, store number, DUNS) and store them as text
- Follow the HL parent links if the retailer uses them for DC relationships
- Apply changes from effective dates, not receipt dates
- Confirm whether the retailer expects a 997
- Alert when an 850 arrives with a ship-to code that is not in your table
If you are new to retail EDI, our [EDI document types reference](/edi-document-types) and [EDI for grocery and retail suppliers](/edi-for/grocery-and-retail-suppliers) explain where the 816 sits among the documents your customers may send.
## Matching Store-Level Orders With OrderSync
The 816 keeps a location table current. The table only pays off when every order is checked against it, and orders do not all arrive as EDI. The same retailer that sends an 850 may send a rush order by email, and a regional chain may send a PDF with a store number in the header.
OrderSync reads inbound orders in any format (EDI 850 and 875, PDF, email, spreadsheets), matches each customer, store, item and unit to your records, and outputs valid X12 or clean data for your ERP. Orders with a store code it cannot match are flagged for review instead of being keyed in with a guess. Paste an 816 or an order into the [free EDI inspector](/edi-inspector) to see it parsed, or [book a 15-minute walkthrough](/book-call) to see your own store-level orders processed.
## Frequently Asked Questions
### What is an EDI 816 used for?
The EDI 816 Organizational Relationships sends a list of an organization's members and how they relate. In retail, a retailer uses it to send suppliers its stores, distribution centers and offices, with identifiers such as GLNs and store numbers, addresses, contacts and effective dates, so suppliers can resolve the location codes on orders.
### Does Walmart send an EDI 816?
Yes. Walmart uses the 816 in its supplier EDI program to send location address information, including GLNs, addresses, phone numbers, store or DC numbers and effective dates. Whether you receive it, in which version and how often depends on your setup, so check the 816 guide in your Walmart supplier EDI documentation.
### What is the difference between an EDI 816 and an EDI 850?
The 850 is a purchase order. It names where to ship by a location code such as a store number or GLN. The 816 is the location list that tells you what those codes mean: the address, the parent organization and when each location opens, changes or closes.
### What is a GLN in an EDI 816?
A GLN (Global Location Number) is a 13-digit GS1 identifier for a physical location or legal entity. In an 816, it usually appears in N104 with the qualifier UL in N103, alongside the retailer's own store number in a REF segment.
### What does the ASI segment mean in an 816?
ASI tells you what to do with a location in a change file. ASI01 is the action code and ASI02 the maintenance type, for example a change that replaces the whole location record, or a delete. The retailer's guide lists the codes it uses, including the one for new locations.
### How do I tell an 816 full list from a change file?
Check BHT02. A value of 00 is an original, which retailers use for full lists. A value of 04 is a change, which carries only the locations that were added, changed or removed, each with an ASI action and usually an effective date.
### Do I need to send a 997 for an 816?
It depends on the retailer. Some require a 997 Functional Acknowledgment for every document, and some state that one is not required for the 816. The retailer's 816 implementation guide says which.