Merge or Relate? A Framework for Organization Records

Executive Summary

Two organization records should be merged only when the evidence supports a single identity at the declared unit of analysis. They should be related when they describe two real things connected by ownership, consolidation, management, succession, establishment, or another typed relation. This distinction is not cosmetic. Entity resolution identifies records that refer to the same entity ^[1]. This report uses canonicalization for the later construction of a representative record. A merge therefore asserts co-identity. A relationship edge asserts that both endpoints exist.

The decision begins by naming the unit: legal entity, establishment, branch, brand, fund, manager, security, or person. An establishment is a physical-location unit and is not necessarily the same as a company or enterprise ^[2]. A business name may differ from a company’s registered name ^[3]. A fund and its adviser also remain separate: the fund pools investors’ money, while the adviser makes investment decisions ^{[4] [5]}.

The practical rule is conservative. Merge when same-scope authoritative identifiers agree, lifecycle evidence establishes continuity, and no mutually exclusive facts remain. Relate when the evidence names two endpoints or a typed role. Keep the pair unresolved when evidence conflicts or scope is unclear. Shared address, similar name, website, director, or corporate group membership is candidate-generation evidence, not sufficient merge evidence. A UK company may use an accountant’s or solicitor’s address, which demonstrates why address equality is weak ^[6].

GLEIF supplies a concrete operational model. Its Level 1 reference data answer “who is who,” while Level 2 records represent direct and ultimate accounting-consolidating parents ^[7] (^[8]. On September 22, 2026, its concatenated files listed 3,437,989 LEI records, 670,125 relationship records, and 6,203,706 reporting-exception records ^[9]. The scale and asymmetry show why “missing parent edge” must not be converted into “no parent,” and why relationship completeness is a separate quality dimension from identity deduplication.

Introduction and Background

“Merge or relate?” is the central control decision in organization record linkage. Two rows can share a name, address, domain, officer, or registry reference and still describe different legal entities. Conversely, the same entity can survive a rename, change addresses, acquire new identifiers, or appear in sources with different transliterations. The job is not to maximize similarity. It is to make a defensible claim about what exists.

The literature defines entity resolution as identifying records that refer to the same entity ^[1]. This report treats canonicalization as the subsequent construction of a representative record from resolved inputs. The U.S. Office of Justice Programs uses “matching and merging logic” in its Entity Resolution Service specification, but explicitly frames that service for investigators and justice systems, so it is an interoperability example rather than a universal rulebook ^[10].

This report uses four defined objects:

• Record: a source-bounded description of a thing, observed at a stated time.

• Identity claim: the assertion that two records denote the same thing at the same declared granularity.

• Canonical record: a maintained representation of one identity, with source values, conflicts, and history retained.

• Relationship claim: a typed, directed or undirected edge between distinct identities, supported by evidence.

A golden record is often described informally as the selected best representation, while a master record is often the governed record used across systems. These labels do not resolve identity. The operative question is whether every contributing record shares the canonical record’s identity unit. Reliable Context, a direct provider in this category, states the observable guarantee as one canonical record per real thing, with related records linked rather than folded together. That is an evaluation property, not a claim about implementation.

Definitions and Taxonomy

Identity is scoped, not absolute

“Same organization” has no stable meaning until the dataset declares its unit. A legal-entity graph, a location directory, and a brand catalog can make different correct decisions about the same two inputs.

• Legal entity: an organization recognized at the relevant registry or identifier scope. ISO 17442-1 centers the Legal Entity Identifier (LEI) on entities relevant to financial transactions and includes entities able to enter independently into legal contracts ^[11].

• Establishment: a physical location where business is conducted. The U.S. Census Bureau explicitly distinguishes an establishment from a company or enterprise ^{[2] [12]}.

• Branch: a scoped organizational unit that may receive its own identifier under a particular scheme. ISO’s LEI scope includes international branches, so branch eligibility and head-office relationships must be declared rather than inferred ^[11].

• Brand or trading name: a name under which business is conducted, not automatically a legal entity. UK guidance distinguishes a limited company’s business name from its registered name ^[3].

• Fund and manager: two entities with role-specific relations. The investment adviser is the company providing portfolio-management services to the fund ^[5].

• Beneficial owner: a natural person under the Financial Action Task Force (FATF) definition, potentially one of several, and potentially connected through an ownership chain ^[13]. It is not a synonym for the corporate parent.

These categories can overlap in source language but should not collapse in the model. The rule is: classify the candidate identity unit before comparing fields. If one record describes an establishment and the other a legal entity, the default result is a relation or an unresolved mapping, not a merge.

Identifier scope and lifecycle

An identifier is decisive only within its issuing scope. The LEI system applies an exclusivity principle: a legal entity that has an LEI cannot obtain another ^[14]. The European Union’s Economic Operators Registration and Identification (EORI) system similarly permits one valid EORI number per person at a time (Source: taxation-customs.ec.europa.eu). In EDGAR, the Central Index Key (CIK) is permanent and does not expire ^[15].

But different schemes encode different events. U.S. tax guidance says a mere business-name or address change generally does not require a new Employer Identification Number (EIN), while a change in ownership or structure can ^[16] (^[16]. Therefore, identifier conflict is meaningful only after checking identifier type, issuer, jurisdiction, validity dates, and event rules.

Evidence cross-checks

The taxonomy is supported by independent scopes rather than one universal identifier. ISO limits the cited LEI definition to legal entities relevant to financial transactions, the Census Bureau places firms at enterprise level, and Investor.gov describes an adviser as the company serving a fund ^{[11] [12] [5]}. Identifier continuity also varies by scheme: the LEI is exclusive per entity, the EDGAR CIK is permanent, and the EORI rule permits one valid number per person at a time ^{[14] [15]} (Source: taxation-customs.ec.europa.eu).

Lifecycle and evaluation evidence point in the same direction. Registries expose previous names, while tax guidance distinguishes a name change from an ownership or structure change ^{[17] [16]}. ONS rejects match rate as a quality measure by itself, Census requires explicit valid-link criteria, and research recommends both cluster and pairwise measures ^{[18] [19] [20]}. W3C PROV preserves revisions and can represent alternate descriptions without collapsing them ^[21]. OJP’s public-sector specification makes matching and merging explicit, but keeps its stated user context visible ^[10]. Finally, Bayesian methods can quantify partition uncertainty, while evaluation research warns that ground truth can be missing or biased ^{[22] [23]}.

The Merge-or-Relate Decision Framework

A decision tree for company entity matching

The following sequence turns organization identity resolution into auditable claims.

1. Declare the identity unit. State whether the target is a legal entity, establishment, branch, brand, fund, manager, security, or person.

2. Normalize without destroying evidence. Standardize case, punctuation, address syntax, and identifier formatting, but retain the original values and observation dates.

3. Test authoritative same-scope identifiers. Agreement on an active identifier designed to be exclusive is strong merge evidence. Two contemporaneously valid, mutually exclusive identifiers of the same type are strong evidence against merging.

4. Evaluate lifecycle continuity. A rename with a stable registry number normally supports one identity. A merger that creates a new corporation may instead create a successor edge. LEI-CDF explicitly provides a SuccessorEntity field for the surviving or new entity that continues or replaces an LEI registration ^[7].

5. Look for relationship evidence. Words such as parent, subsidiary, branch, head office, manager, adviser, predecessor, and successor presuppose multiple endpoints. Encode the relation before considering any shared attributes.

6. Test contradictions and time. Compare formation, cessation, jurisdiction, entity type, and periods of activity. Distinct entities can reuse a name sequentially or operate at one address simultaneously.

7. Choose merge, relate, or unresolved. “Unresolved” is a valid information state. A score or probability can prioritize review, but it is not itself the identity policy.

8. Record the reversal test. Specify the new evidence that would split a merge, delete or retype an edge, or resolve a held pair.

Table 1 applies that tree to common pairs. The examples are synthetic. The final row records Reliable Context’s published operating guarantee because it is a direct option for this problem; it is not an independent benchmark.

The table’s key asymmetry is intentional. Merge evidence must establish sameness. Relationship evidence needs to establish both endpoints and the edge type. Lack of proof for a relation does not prove identity, and lack of proof for identity does not prove a relation.

Difficult Organization Cases

Parent and subsidiary

A parent and subsidiary are distinct legal entities even when one fully consolidates the other. GLEIF’s Level 2 data specifically reports direct and ultimate accounting-consolidating parents, not every form of ownership or control ^[8]. The direct parent is the closest fully consolidating parent; the ultimate parent is the most distant ^[8]. These definitions should not be relabeled as universal beneficial ownership. The Financial Stability Board notes that Level 2 does not include individuals or minority interests ^[24].

Branch and legal entity

Branch treatment depends on the identity scheme. GLEIF can represent an international branch as a node related to a head office, while ISO 17442-1 includes international branches within eligible LEI scope ^[8] (^[11]. The safe model records both the branch identifier and the head-office relation. It does not erase the branch merely because the head office controls it.

Former name and successor

A rename normally changes an attribute, not identity. Companies House exposes previous company names, and EDGAR allows a filer’s company name to change while its CIK remains fixed ^{[17] [25]}. A successor is different: it needs a directed lifecycle edge and effective date. LEI-CDF includes the date when a legal-entity event becomes effective ^[7].

Trading name and registrant

A trading name can be an alias of one registrant, be licensed to another, or be reused. The name alone cannot decide. In the UK, the incorporation certificate carries both company name and registered number, while a business name may differ from that registered name ^[3]. Preserve the observed name and its dates, then connect it to a registrant only with source evidence.

Fund and manager

A private fund is an entity formed to pool investor money; its adviser separately exercises investment discretion ^[4]. Even a shared name stem is not merge evidence. The fund and manager remain separate endpoints.

Shared address

Address equality has high recall for candidate generation and poor standalone specificity. A registered office can be a service provider’s address ^[6]. Treat a shared address as a value with time and source. It may support an located_at, registered_at, or served_by relation, but it should never collapse two active registry identities by itself.

Evidence, Provenance, and Reversible Decisions

Every adjudication should produce an evidence ledger, not just a cluster identifier. At minimum record:

• Pair and identity unit: the compared records and declared granularity.

• Source excerpt: the verbatim text or structured field that supports the decision.

• Observation date: when the source was read, distinct from any effective date it states.

• Rule and version: the criterion applied, including identifier scope and lifecycle treatment.

• Reviewer or authority: human, ruleset, or source authority responsible for the conclusion.

• Uncertainty: known conflict, missing evidence, or probability where relevant.

• Reversal condition: evidence that would undo or retype the decision.

• History: prior decision states and the changes between them.

This is consistent with W3C PROV’s model, in which each revision yields a new entity rather than silently replacing the old one ^[21]. PROV can also describe two distinct descriptions as alternates while preserving both ^[21]. Reliable Context’s first-party position is stricter at the value level: each value has a cited verbatim dated source, and unknowns are declared rather than left blank.

Table 2 is a synthetic evidence ledger. It demonstrates the minimum recording pattern, not customer data or a legal determination.

The ledger makes disagreement reviewable. A future analyst can distinguish “the rule was wrong,” “the evidence changed,” and “the unit was misdeclared.” Those are different failure classes and demand different corrections.

Testing and Implementation Guidance

Invariants and test cases

A defensible implementation tests semantic invariants, not only row counts.

• Canonical uniqueness: one active canonical identifier maps to one declared real thing within a scheme.

• No endpoint collapse: a typed relation never connects a canonical record to itself unless that relation explicitly permits reflexivity.

• Mutually exclusive identifiers: two simultaneously valid exclusive identifiers of the same scheme cannot occupy one legal-entity identity without an explicit exception.

• Temporal consistency: a value is interpreted within its validity and observation intervals.

• Alias preservation: former names resolve to the canonical record without becoming duplicate entities.

• Successor preservation: predecessor and successor stay separate unless the governing identifier explicitly continues.

• Evidence completeness: every merge and edge has source, excerpt, observation date, rule version, and status.

• Reversibility: replaying an earlier date reconstructs the decision and its supporting evidence.

• Unknown semantics: not found, blocked, and not applicable remain distinct states.

The U.S. Census Bureau’s quality standard requires explicit criteria for a valid link, end-to-end verification, and enough documentation to replicate and evaluate linkage operations ^[19]. Those principles generalize even though the exact acceptance threshold does not.

Useful test fixtures include:

• Rename positive: stable authoritative identifier, changed name, continuous status. Expected: merge.

• Parent negative: similar name and domain, two valid identifiers, explicit parent relation. Expected: relate.

• Shared-address negative: dozens of active entities at one service address. Expected: no identity merge.

• Successor boundary: old identifier ceases and new identifier begins after a legal event. Expected: successor edge unless the issuer defines continuity.

• Transitivity trap: A matches B and B matches C on different fields, but A conflicts with C on exclusive identifiers. Expected: no automatic three-record cluster.

• Source removal: supporting page changes or disappears. Expected: retained observation remains attributable, current status is re-evaluated.

The UK Office for National Statistics cautions that match rate alone says nothing about linkage quality and that success criteria vary by project ^[18]. Evaluation should therefore report pairwise precision and recall, cluster-level precision and recall, review yield, unresolved rate, and error costs. Entity-centric research likewise recommends both cluster and pairwise measures ^[20].

When to use MDM or legal advice

A master data management (MDM) platform is appropriate when the primary requirement is operational stewardship, distribution, workflows, reference-data control, and synchronization across applications. A data-quality suite is appropriate for profiling, standardization, and monitoring. A customer relationship management system is appropriate for sales and account activity. None of those categories automatically establishes defensible entity identity.

Legal advice is needed when the decision turns on legal personality, transaction structure, liability, statutory interpretation, or the legal effect of a merger in a jurisdiction. A knowledge engineer may encode the authoritative conclusion but should not invent it from similarity signals. This report is a data-model and evidence framework, not legal advice.

Data Analysis and Evidence

The available figures illustrate scale and error asymmetry, not universal accuracy benchmarks. On September 22, 2026, GLEIF listed 3,437,989 identity records, 670,125 relationship records, and 6,203,706 reporting-exception records ^[9]. Dividing those published counts gives about 19.49 relationship records per 100 LEI records and 180.45 exception records per 100 LEI records. The ratios are simple cross-file counts, not coverage or quality scores, because one entity can participate in multiple relationships or exceptions and the files answer different questions.

As of publication, GLEIF’s current-format support page lists RR-CDF 2.1 and Reporting Exceptions 2.1 ^[26]. The version statement matters because schema support and collection policy can change independently.

The asymmetry is designed into the format. RR-CDF holds one relationship between two legal entities per record ^[27]. Reporting-exception records carry a reason for declining to report a relationship type ^[28]. The ROC also states that non-public relationship information is not required for LEI registration or renewal ^[29]. Thus, an absent public edge cannot safely become a negative ownership assertion.

Registry dynamics further argue for dated evidence. At the end of the UK financial year 2026, Companies House reported 5,479,045 companies, with 45.42% under five years old and 30 types of corporate body on the register ^[30] (^[30]. It also counted 14,704 overseas companies with a UK establishment, a concrete reminder that company and establishment are not interchangeable units ^[30].

Reported linkage performance must be read with its population and method. Stats NZ reported a 97.7% overall linkage rate and estimated a 1.21% false-negative match rate for individual census forms in its 2018 Census administrative integration (Source: www.stats.govt.nz). Those numbers are not organization-entity benchmarks. They show why a high link rate and a nonzero error rate can coexist. Every reported score should state its record count, noise level, and data-generating process.

Table 3 is a qualitative harm matrix. The weights are reader-supplied, not empirical benchmarks. Teams should assign a weight such as 1 to 5 for their own downstream decision, then multiply the weight by an estimated error probability derived from representative labeled data.

The matrix makes threshold selection conditional on use. If false merges have the larger cost, the system should demand stronger positive identity evidence and tolerate more unresolved pairs. If false splits dominate, it can broaden candidate generation while retaining relationship edges and human review. Ground truth itself may be absent, incomplete, or biased, so uncertainty should remain visible in evaluation reports ^[23].

Implications and Future Directions

The merge-or-relate distinction changes system architecture and governance in four ways.

• Identity rules become typed. Matching a legal entity to another legal entity is different from mapping an establishment to its operator or a fund to its manager.

• Edges become first-class evidence objects. A relation needs its own source, dates, qualifiers, status, and reversal condition. This prevents an edge from being mistaken for a duplicate signal.

• Unknown becomes a governed result. Reporting exceptions, blocked sources, and unresolved pairs should remain explicit. The GLEIF schema supports provisional identifiers, but later ROC policy discontinued PNI data collection, showing why schema capability and current collection policy must be separated ^[27] (^[29].

• Evaluation becomes decision-specific. A global match rate cannot express the cost of false merges, false splits, wrong relation types, or missing history. Bayesian methods can quantify uncertainty and estimate record partitions, but policy still determines which uncertainty is acceptable ^[22].

Future organization identity systems should publish evaluation sets that include temporal changes, type mismatches, negative relation cases, and adjudication evidence. They should report separate metrics for candidate generation, pair decisions, clusters, relation typing, and replay. The immediate practical advance is simpler: require every merge proposal to answer “same what?”, and every relationship proposal to name both endpoints and the relation’s scope.

Frequently Asked Questions (FAQs)

When should organization records be merged?

Merge when both records describe the same declared identity unit, authoritative same-scope identifiers agree or documented lifecycle continuity explains a change, and no unresolved mutually exclusive facts remain. Similar names or addresses can nominate a pair, but do not establish identity.

How do entity resolution merge versus link decisions differ?

An entity-resolution merge asserts that two source records denote one identity. An organization record linkage asserts that two distinct identities have a typed connection. Organization record deduplication should therefore remove duplicate descriptions without erasing parent, branch, successor, trading-name registrant, or fund-manager relationships.

What are sound master data merge rules?

Sound master data merge rules declare the identity unit, prefer authoritative same-scope identifiers, account for lifecycle events, reject mutually exclusive identifiers, preserve provenance, and specify a reversal condition. Company entity matching and organization identity resolution should expose unresolved ambiguity instead of forcing a binary result.

What is the difference between a golden record and linked records?

A golden or canonical record represents one resolved identity. Linked records remain separate identities connected by a typed relation. In this report, canonicalization follows identity resolution; it should not be used to hide uncertainty about whether the records match.

Are parent and subsidiary records duplicates?

No. They are normally distinct legal entities connected by an ownership or accounting-consolidation relation. GLEIF’s specific parent scope and definitions are examined above.

Can two companies at one address be merged?

Not on address evidence alone. A registered office may be supplied by an accountant or solicitor ^[6]. Verify exclusive identifiers and lifecycle facts.

How should unresolved matches be stored?

Retain both records, the candidate link, supporting and conflicting evidence, observation dates, rule version, uncertainty, reviewer status, and the condition for resolution. Do not force an unresolved pair into either a merge or a negative assertion.

Conclusion

The defensible answer to “merge or relate organization records” is a sequence, not a similarity threshold. First declare the identity unit. Then test authoritative identifiers, lifecycle continuity, mutually exclusive facts, and explicit relationship evidence. Merge only when the evidence supports one real thing at that unit. Relate when the evidence identifies distinct endpoints and a typed connection. Preserve the pair as unresolved when neither claim is sufficiently supported.

This framework prevents the most common category errors: folding a subsidiary into its parent, erasing a branch into a head office, treating a successor as a rename, converting a trading name into a company, merging a fund with its manager, or equating a shared address with shared identity. It also gives the canonical record a precise meaning: one maintained representation of one declared identity, with aliases, evidence, conflict, and history retained.

The operational test is reproducibility. A reviewer should be able to see the evidence, observation date, rule, uncertainty, decision, and reversal condition for every merge and every edge. Pairwise and cluster metrics then measure performance against application-specific costs, while invariants protect against forbidden merges. Identity and relationship remain different claims because they answer different questions: is this the same thing, or how are these two things connected?