The EDI 816 organizational relationships document is how a retailer sends you its location hierarchy: stores, distribution centers, and which store belongs to which DC. It is the cure for shipping to a store that closed.
Retailers open, close and renumber stores constantly. Your ship to master does not update itself, and a carton routed to a store that closed in March is a reship, a deduction and an unhappy buyer. The 816 organizational relationships document is how a retailer sends you its own location hierarchy so you do not have to maintain it by hand.
The EDI 816 communicates a hierarchy of organizations and locations, and how they relate to each other. In retail that normally means a chain sending a supplier its store and distribution center list: identifiers, addresses, which distribution center serves which stores, and which locations are opening or closing.
It is a master data document rather than a transactional one. Nothing is being ordered, shipped or paid. It exists so that both sides agree on what a location number means before an order references it.
Most brands maintain retailer location data by hand, from a spreadsheet a buyer emailed at onboarding. That works until the chain opens twelve stores and closes five, which is a normal quarter for a large retailer. The 816 is the structured alternative, and the reason to care about it is entirely downstream: every 856 ASN, every GS1-128 label and every bill of lading depends on a ship to that actually exists.
Retail usage varies, so this is the information typically conveyed rather than a fixed layout. Work from the mapping guide your retailer issues.
| Location identifiers | The store or distribution center number the retailer will use on purchase orders and expects on labels and ASNs. Often a GLN as well as an internal number. |
| Names and addresses | Full physical address for each location, which is what actually prints on a carton label and a bill of lading. |
| Hierarchy | Which parent each location reports to. In practice, which distribution center serves which stores, and which division or region a store sits in. |
| Status and dates | Whether a location is active, opening or closing, and the effective date. This is the part that saves you money. |
| References and contacts | Additional identifiers such as a DUNS number, and receiving contact details where the retailer supplies them. |
The carton arrives, there is nobody to receive it, and it comes back. You pay the freight both ways, the order is late, and on most accounts there is a compliance charge attached. Entirely avoidable with a current location list.
Cross dock programs route store level cartons through a specific distribution center. Send them to the wrong one and the load is broken down and reworked at your cost, if it is accepted at all.
An order references a location your system has never seen. Somebody adds it manually under time pressure, usually with an address typed from an email, and the label is wrong in a way nobody notices until receiving does.
Pack by store and prepack allocation depends on knowing how many doors exist. Planning a buy against a store list that is two quarters old distributes the wrong quantities to the wrong places.
AIMS360 holds retailer locations as structured data against the account rather than as free text on an order. Where a retailer sends an 816, the hierarchy and status updates apply to that master, so a closed store stops being a valid ship to and a new one is available the moment it is announced.
An 850 referencing an unknown or inactive location is flagged on arrival rather than discovered at the packing bench.
The address on the GS1-128 label, the VICS BOL and the ASN all come from the same record.
Where a retailer publishes a store list in a portal instead, the same master is maintained from that, so the downstream behaviour is identical.
Pack by store and prepack logic runs off the current door count rather than a spreadsheet from onboarding.
It communicates a hierarchy of organizations and locations and how they relate. In retail that usually means a chain sending a supplier its store and distribution center list: identifiers, addresses, which DC serves which stores, and which locations are opening or closing. It is master data, not a transaction, and it exists so both sides agree what a location number means before an order references it.
Less common than the core order documents. Plenty of retailers distribute location data another way: a store list in a vendor portal, a flat file, or a spreadsheet at onboarding. Macy's, Inc. asks vendors to load Store to DC listings during onboarding rather than sending an 816. Ask how your account distributes location data rather than assuming there is no feed at all.
The expensive version is shipping to a location that has closed: freight both ways, a late order and usually a compliance charge. The quieter version is planning a buy or a pack by store allocation against a door count that is two quarters old, which distributes the wrong quantities to the wrong places and looks like a demand forecasting problem rather than a data problem.
Typically both. Location identifiers are what appear on purchase orders and ASNs, and the physical address is what prints on the carton label and the bill of lading. Many implementations also carry a GLN alongside the retailer's internal number, plus status and effective dates for openings and closings.
You can, and most brands do. It works while the chain is stable and fails quietly when it is not, because nobody is told a spreadsheet has gone stale. The practical test is whether your packing process can ship to a location your system has never validated. If it can, the spreadsheet is not the control you think it is.
Last reviewed 7 August 2026 by the AIMS360 EDI team. The 816 is described here by the information it typically carries rather than by a fixed segment layout, because retail usage varies. Confirm how your own account distributes location data before building.
See AIMS360 hold retailer locations as validated master data, in a 30 minute demo.
