Define what counts as the same entity
Two records with the same trading name may refer to separate legal entities, regional branches, or accounts. Establish the identity scope before writing a matching rule. A supplier organization, a supplier site, and a payee account should not be merged merely because a source uses one name for all three.
List the fields that carry identity evidence and their limitations. Tax identifiers may be jurisdiction specific, addresses can be shared, and email domains can represent a corporate group. Preserve each source key and source namespace even when a canonical entity is created. The original assertions remain essential for correction and audit.
Set matching and review thresholds
Start with deterministic rules supported by the business, such as an exact validated registration identifier within the correct jurisdiction. Normalize formatting without destroying meaningful distinctions. A probabilistic score can help prioritize candidates when evidence is weaker, but the score is not automatically a calibrated probability of identity.
Define separate thresholds for automatic acceptance, human review, and rejection. Tune these thresholds against a labeled sample that reflects real ambiguity and class imbalance. Evaluate false merges and missed matches independently because their costs differ. A payment workflow may require substantially stronger evidence than a duplicate suggestion in an analyst interface.
| Evidence | Potential use | Limitation |
|---|---|---|
| Registration identifier | Strong deterministic match | Check jurisdiction and validity |
| Normalized legal name | Candidate generation | Names can be shared or changed |
| Address similarity | Supporting signal | Group entities may share premises |
| Human review | Resolve ambiguous candidates | Record rationale and reviewer scope |
Make merges and splits reversible
Store the match decision, evidence, rule version, timestamp, and reviewer where applicable. Maintain an alias or membership history so downstream consumers can understand how source records relate to a canonical entity over time. A merge should not erase the records that supported it.
Plan the split path before enabling automatic merges. Correcting an identity may affect graph edges, aggregated balances, permissions, and cached recommendations. Publish a controlled correction event and rebuild affected projections. Review access policies carefully because a mistaken merge can expose information across business or tenant boundaries, not merely distort a report.
Monitor drift and disputed matches
Track acceptance and review rates by source, domain, and rule version. A sudden increase in matches may indicate a successful normalization fix or a dangerous change in source identifiers. Sample accepted matches and collect structured feedback from business users instead of relying only on aggregate score distributions.
Keep a test set of difficult cases, including renamed suppliers, parent and subsidiary organizations, recycled account identifiers and incomplete addresses. Run it whenever matching logic changes, and review results against the agreed identity definitions.