Define what you are trying to identify
Consider a procurement inbox containing messages from “Northline Supply”, “Northline Cairo” and an employee using a personal address. The ERP has two supplier records with similar names. Those observations could describe one entity with several contacts, two sites belonging to one entity or genuinely separate businesses.
Decide whether the match concerns a legal entity, purchasing account, delivery site or person. Those are different records. Combining every related name into one supplier can misattribute spend, performance and document history even when no financial fields are changed.
AWS Entity Resolution documents configurable matching rules and records both a match identifier and the rule producing the match. Its rule-based workflow guide provides an example of keeping the reason with the group. It does not establish that a matched group is an authorized supplier master update.
Separate the entity from its sites and contacts
| Record | Keep distinct |
|---|---|
| Entity | Verified organization identifiers with their jurisdiction and source |
| Supplier account | Purchasing-system reference and approved relationship |
| Site | Operational location and applicable delivery or billing details |
| Contact | Person, address, role and verified association |
| Alias | Observed name, source and confirmed entity relationship |
Keep history attached to its original references while adding confirmed relationships. A quote from a particular branch should remain identifiable as that branch’s quote. A supplier group’s shared website does not mean every group company shares the same purchasing account.
Entities, sites and uncertain matches
- Same entity
- Verified identifiers agree. Link aliases
- Separate site
- Entity matches, site differs. Keep the site
- Uncertain
- Evidence conflicts or is missing. Review the match
| Evidence | Meaning |
|---|---|
| Same entity | Verified identifiers agree. Link aliases |
| Separate site | Entity matches, site differs. Keep the site |
| Uncertain | Evidence conflicts or is missing. Review the match |
A link preserves separate source records.
Do not use bank details as the automatic merge key. Payment information belongs to its own controlled verification process. Matching two supplier descriptions should not authorize a changed payment destination.
Normalize carefully, then generate candidates
Preserve the original input alongside normalized fields. You can standardize case, repeated spaces and documented punctuation rules to improve candidate retrieval. Do not discard meaningful branch names, jurisdiction prefixes or identifier leading zeros just to increase the match rate.
Use stronger evidence to narrow candidate sets: a validated organization identifier and its issuing context, an existing accepted supplier reference, or a previously confirmed alias. A shared email domain, phone number or address can support a candidate but may be reused by related businesses.
Keep missing values explicit. Two records lacking a registration number do not match because both fields are blank. An unfamiliar identifier format needs validation or review rather than a normalization rule that turns it into a familiar number.
Work through a conflicting example
In a sample register, SUP-21 and SUP-37 have similar names and the same website. Their validated identifiers differ within the same identifier scheme and issuing jurisdiction. Treat them as separate entity candidates and ask the owner to explain the group relationship. Different identifier types alone would not establish a conflict. Do not let strong name similarity override contradictory identity evidence.
A third record, SUP-88, has the same validated identifier as SUP-21 but a different warehouse address. The likely task is to confirm the site relationship, not erase the second address. Retain the reviewer’s source and the scope of the link.
An AI model can propose name variants and summarize candidate evidence. Make its output a suggestion with reasons and conflicts. A confident explanation does not replace the organization’s authority to update master data.
Choose field ownership before accepting a link
Specify which system owns each accepted field. The ERP may own the active supplier account while procurement maintains contact preferences. A new quotation should not overwrite an accepted registered name or approved site simply because its header is more recent.
Distinguish linking from merging. A link can make aliases searchable while leaving source records intact. A merge changes references and may require downstream updates, a reversal plan and additional approval. Record the before-and-after mapping rather than deleting the evidence needed to undo an error.
Measure incorrect matches, not just grouped records
Use a reviewed sample containing related companies, branch accounts, stale contacts, missing identifiers and contradictory records. Track correct links, missed links, false links and unresolved candidates separately. A larger grouped percentage can hide dangerous combinations.
Define entity and site ownership in Trion’s procurement workflow before feeding linked history into the supplier scorecard.