Transaction explainers · September 9, 2026

EDI 816 Organizational Relationships: The Complete Guide (2026)

How the EDI 816 delivers store, DC, and ship-to hierarchies, why stale location tables break orders and ASNs, and how to keep cross-references current.

Every EDI document that moves goods depends on a quiet assumption: when the partner says ship to location 4127, you know what and where 4127 is. Retailers open stores, close stores, renumber DCs, and re-district their networks constantly — and the EDI 816 Organizational Relationships transaction is how they tell you. It's pure reference data, no goods and no money, which is exactly why it gets underestimated until the week a location table goes stale.

A directory in document form

The 816 transmits a partner's organizational structure as a hierarchy: parent company, divisions or banners, distribution centers, and the stores or ship-to points beneath them. N1 loops carry each entity's identifier, name, and address; HL hierarchy levels express who belongs under whom — this store receives through that DC, this banner bills through that corporate entity. Some partners send the full network every time; others send changes: locations added, moved, or deactivated.

What you're meant to do with it is equally concrete: maintain the cross-reference between the partner's location codes and your own customer/ship-to records, so every document that mentions a location can be resolved without a human looking anything up.

Why location data rots — and what it breaks

Location tables decay in a specific, predictable way. The initial setup is correct, because someone built it carefully during onboarding. Then the retailer opens a wave of stores, consolidates two DCs, or re-points a region — announced via 816, which nobody is parsing — and the table quietly drifts from reality. The symptoms show up downstream, disguised as other problems:

  • An 850 order arrives for a ship-to your ERP doesn't recognize, and stalls in an exception queue while its ship window runs.
  • SDQ store-distribution lines reference new stores that explode into nothing, silently shorting the allocation.
  • An 856 ASN transmits with a location the partner has retired, and fails their validation — or worse, passes and routes freight to a closed dock.
  • Invoices bill entities that no longer exist in the partner's payables structure and age unpaid.

None of these announce themselves as "your location table is stale." Each burns hours of investigation before someone finds the root cause — which an unread 816 had announced weeks earlier.

Processing it properly

The right handling is unglamorous automation. Inbound 816s are acknowledged with a 997 like anything else, then applied: new locations create ship-to records (or queue them for enrichment with delivery details), changes update in place, deactivations flag records so future documents referencing them get caught immediately. The hierarchy matters too — knowing which DC serves which stores lets your systems validate that an order's ship-to makes sense and helps logistics plan consolidated freight.

Two habits make the difference in practice. First, treat deactivations as seriously as additions — shipping to a closed location is costlier than failing to ship to a new one. Second, keep an audit trail of applied changes, because when a document fails on a location code, the first question is what the table said on the day that document was built.

EDISQ applies 816s automatically against the partner cross-reference tables it maintains for you, so the location data your 850s, ASNs, and invoices resolve against tracks the partner's network without a standing calendar reminder. Retail suppliers juggling many partners' networks can see how this fits the larger picture in our retail solution.

What it costs to stay current

Reference documents are infrequent, so they barely register on a per-document bill. With EDISQ's pricing, an 816 comes out of the same monthly pool as your orders and invoices — first 25 documents free, then from $0.50 sliding to $0.10 per document at scale, marginal billing, zero mapping or setup fees, transport included. Staying synchronized with a partner's org structure costs a few cents a month; the exception queue it prevents costs considerably more.

FAQ

What is an EDI 816 used for?

Distributing a partner's organizational structure — stores, DCs, ship-to and bill-to locations, and how they relate — so your systems can resolve the location codes that appear on orders and route documents correctly.

How often do 816s arrive?

On the partner's schedule: some send periodic full refreshes, others send updates when locations open, close, or change. Either way, the file supersedes whatever location data you were holding.

What happens if I ignore an 816?

Orders start referencing ship-tos your system does not recognize — new stores, redistricted DCs — and documents fail or freight goes to the wrong place. Location errors are among the most common ASN failures.

What do 816s cost to process?

They are ordinary documents on EDISQ's meter: 25 free monthly, then from $0.50 each with tiered volume discounts and no other fees.