WM Blog · Clara

Name Normalisation Thresholds Spawn Phantom Suppliers

Name normalisation thresholds that ignore middle initials and trading-name suffixes create three supplier records from one legal entity the moment a second ERP feed arrives. Downstream AI models then train on split histories that show contradictory credit limits and invoice volum

Abstract illustration showing supplier records fracturing into duplicate entries on a dark grid background

Name normalisation thresholds that ignore middle initials and trading-name suffixes create three supplier records from one legal entity the moment a second ERP feed arrives.

The platform marks each record as mastered because the deduplication job only runs after the nightly batch window and applies a 0.92 similarity cut-off that the finance team never tuned for local abbreviations.

Procurement then issues three separate RFPs to the same company under different codes, locking in divergent pricing and delivery terms that no single contract register can reconcile.

When the AI spend-forecast model pulls from the master layer it averages across the fragments and underestimates committed volumes by the exact percentage of split records.

Finance teams discover the problem only after the first mismatched payment run, at which point reversing the duplicates requires manual intervention in every connected ledger.

Resetting the similarity threshold and adding phonetic rules on ABN cross-checks stops new splits, yet the existing fractured histories still poison any model retrained on the last twelve months of transactions.

The fix is not another data-quality dashboard but a hard gate that blocks any new supplier record until the incoming payload passes an ABN-plus-name phonetic match against the current master set.

Master Data Management Supplier Deduplication Entity Resolution Procurement Data