Datanovel know-how
Duplicates in the vendor file: good or bad?
Understand why a record exists before deciding to remove it.
Several records for the same supplier can be an error, a legacy constraint or an intentional part of the operating model. A successful deduplication exercise separates these cases.
When multiple records have a purpose
Separate records may support different supplier locations, payment currencies, payment terms, bank arrangements, tax treatments or approval processes. A supplier may also exist legitimately in several systems.
Look for an explicit relationship to the primary record, a documented operational reason and meaningful differences in the fields used for transactions. Missing links are a reason to investigate, not proof that a record is unnecessary.
When duplication creates avoidable work
A new record may have been created because an existing supplier could not be found under an old name, or because several functions can create records without a shared search. A formerly useful record may also have lost its purpose.
These cases can fragment spend, confuse users and multiply maintenance. Check usage and open transactions before proposing a record for retirement.
Choose between linking and retiring
Retain and link necessary records. Define which identity fields should remain aligned and which operational fields must differ. For unnecessary records, agree the surviving record and a controlled transition with procurement and finance.
Datanovel combines entity matching with investigation of the business purpose. The deliverable is a reasoned action for each candidate, rather than a list of similar names labelled for deletion.