Identifiers and hierarchies are boring until they break reporting, billing, routing, and accountability.
Every system wants its own ID. CRM has account IDs. Billing has customer IDs. Product has workspace or tenant IDs. Support has organization IDs. Finance has legal entity IDs. None of that is inherently bad. The trouble starts when the company cannot reliably connect them.
Hierarchy makes it harder. A global parent has regional subsidiaries. A customer has multiple workspaces. A reseller buys on behalf of an end customer. A legal entity pays invoices for several operating units. Sales wants one view, finance another, product another. Again, nobody is automatically wrong. The business needs named hierarchy rules.
Systems of record should define the identifiers that matter, how they map, who can merge or split records, and which hierarchy is used for which decision. Revenue reporting may follow legal entity. Customer success may follow operating account. Product usage may follow workspace. The semantic layer can label those meanings, but systems of record decide where the authoritative structures live.
Reconciliation should be routine. If records cannot be matched, create a queue with an owner. If two systems disagree on parentage, use a rule and keep an exception log. If a merge changes history, note which reports or workflows are affected.
The worst pattern is hidden manual matching. It works until the person who understands it leaves or the volume doubles.
Good identifier discipline feels fussy. It is also what lets the business answer simple questions without three exports and a prayer.
This is part 6 of 10 in Systems of Record.
