Transmits hierarchical organizational structure between trading partners - mapping corporate accounts to divisions, DCs, and store locations so that downstream transactions like POs, ASNs, and catalogs are routed to the right entity.
The EDI 816 Organizational Relationships transaction communicates the structure of an organization - the parent/child relationships between a corporate account, its divisions, distribution centers, and individual store locations. It is a master data document that establishes the "who is who" context that all other EDI transactions depend on. Without accurate org data, a purchase order sent to "Target" is ambiguous - does it belong to Target Northeast DC (GLN 0012345678901) or Target Southeast DC (GLN 0012345678902)?
The 816 is typically sent by a buyer to a supplier to define their account hierarchy. A retailer might send a 816 showing that their corporate parent contains 5 regional divisions, each with 2–3 distribution centers, which serve 400+ store locations. The supplier loads this hierarchy into their order management system so that future 850 purchase orders are automatically associated with the correct ship-to location and billing entity.
In DSD (Direct Store Delivery) grocery environments, the 816 maps which stores belong to which distributor accounts, enabling suppliers to generate store-level invoices that route correctly through the broker/distributor hierarchy. Updates to the org chart - new store openings, DC consolidations, franchise conversions - are delivered via replacement 816s, keeping both parties in sync without manual MDM (Master Data Management) updates.
National retailers use 816 to communicate their store-to-DC-to-corporate hierarchy to hundreds of suppliers. Each store has a unique GLN (Global Location Number), a parent DC, and a corporate billing account. Suppliers use this data to route 856 ASNs to the correct DC and generate 810 invoices to the correct billing entity.
In direct-store-delivery grocery programs, the 816 maps route structures - which delivery routes serve which store groups under which distributor. CPG suppliers need this to generate DSD invoices at the store level and reconcile them against the corporate account. Route changes (common in grocery resets) require frequent 816 updates.
Wholesale distributors send 816s to their supplier base to define which of their branches (ship-to locations) belong to which corporate account (bill-to location). This matters for volume rebate calculations - the supplier needs to aggregate orders across all branches to determine whether a customer hit their tier threshold.
Integrated delivery networks (IDNs) and group purchasing organizations (GPOs) use 816 to map member hospitals and clinics to their group contract. Medical suppliers must know which facilities belong to which GPO contract to apply the correct contracted price on invoices - the 816 is the mechanism that creates that mapping.
The primary identifying segment for each entity in the hierarchy. ORG01 = organization qualifier (ZZ = mutually defined, 1 = DUNS, 9 = GLN/D-U-N-S+4), ORG02 = the identifier value (e.g., the 13-digit GLN for a store or DC). ORG03 = organization level code indicating where in the hierarchy this entity sits: CO (corporate), DV (division), DC (distribution center), ST (store).
Full name and address for each organizational entity. N101 = entity identifier code: SU (supplier), BY (buying party), ST (ship-to). N102 = legal name. N103/N104 = identification type and value (GLN, DUNS). N3 = street address lines. N4 = city, state, ZIP, country. These addresses are what populate ship-to/bill-to in downstream 850s and 856s.
Defines the parent-child link between two entities in the hierarchy. REL01 = relationship code (01 = subsidiary of, 04 = division of, 06 = member of). REL02 = the parent entity's identification type, REL03 = parent entity ID. A store (GLN ending in -001) links via REL to its parent DC (GLN ending in -DC1), which links to its regional division, which links to corporate.
Optional per-location contact data for operational coordination. PER01 = contact function code (BD = billing, RE = receiving, IC = information contact), PER02 = contact name, PER03/PER04 = communication type and value (phone/email). This is useful for suppliers that need to reach DC receiving teams for appointment scheduling or exception handling.
Specifies when a location relationship becomes active or inactive. DTM01 = 007 (effective date) or 036 (expiration date). This is critical for managing store openings, closings, and renovations - a store under remodel may be temporarily inactive in the 816, preventing orders from routing there until reopened.
Opens the 816. BCO01 = transaction set purpose code: 00 (original), 04 (change), 05 (replace), 24 (deletion). BCO05 = reference identification for this 816 document. Using purpose code 05 (replace) sends a full new hierarchy; purpose code 04 (change) sends only the deltas - understanding which mode a trading partner requires is a critical onboarding question.
Purchase orders reference ship-to location IDs that are defined in the 816 hierarchy. Without the 816, suppliers must manually maintain location master data; with it, the 850's ship-to can be auto-resolved to the correct address and DC assignment.
ASNs are addressed to specific DCs and stores whose IDs and addresses come from the org hierarchy in the 816. Correct GLNs in the 816 ensure 856s route to the right receiving system and aren't rejected for unknown ship-to identifiers.
Catalogs and pricing tiers are often scoped to specific accounts or divisions defined in the 816. A supplier may send different pricing to a retailer's wholesale division vs. their direct-to-store program - the 816 establishes which accounts belong to which program.
Better EDI handles 816 mapping, testing, and trading partner certification so you don't have to.
Talk to an EDI Expert