EDI 816 Organizational Relationships: Store Lists

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, 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 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 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 and the 856 ASNs 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.

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 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:

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.

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~

HL: Hierarchical Level

Each HL starts one organization or location.

HL*2*1*36~

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~

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~

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.

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

Paste any 816 into the free 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 and 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 to see it parsed, or book a 15-minute walkthrough to see your own store-level orders processed.

Frequently Asked Questions