Synthetic demo

Vendor Brain runs entirely on invented vendors, sites and account numbers. Full disclaimer below.

Color scheme

Vendor master data reconciliation - built by Julia Broberg

Vendor Brain

One real-world supplier, entered by hand into four different systems, four different ways. This is the method that finds it and merges it back into one record - shown here on data invented for the purpose.

Synthetic reconstruction

The production system runs inside a global, multi-site, NASDAQ-listed life-sciences manufacturer, where I built it to give the enterprise its first unified view of its vendors. The same supplier existed under a different account number in each of the company's separate ERP systems, and no system had ever reconciled them. This public demo rebuilds the method on entirely invented data - every vendor, site, account number, and figure below is fictional - so the technique is visible while the real vendor data stays private.

9,214 vendor accounts reconcile down to 7,980 golden records, collapsing 1,234 duplicate accounts, with 22 items pending human review.

5 sites 4 ERP systems 10 golden records shown below 0 rows of real data

The problem

One supplier, four account numbers

A global manufacturer runs several separate ERP systems across its sites. The same real-world supplier shows up as a different vendor account number in each one, so spend cannot be rolled up per supplier, and nobody can answer a simple question: how much do we actually spend with this vendor, across every site, combined. Vendor Brain answers it by reconciling the accounts into one record per real vendor.

Riverton

Atlas AX

Shares its ERP instance with Halden, separated only by a company-code column.

Halden

Atlas AX

Same physical database as Riverton. One system, two company codes, still two sets of vendor accounts.

Kobe

Sage-90 K

Its own standalone Sage-90 instance, with its own numbering scheme for vendor accounts.

Turin

Sage-90 T

A separate Sage-90 instance again - same product family, unrelated account numbers.

Lyon

Sage-90 L

A fourth, independent instance. Four systems in total, none of them aware of the others.

How it works

Normalize, block, score, cluster, resolve

Five steps turn 9,214 raw accounts into 7,980 golden records. The first four are mechanical; the last one is where a person steps in.

01

Normalize

Strip legal suffixes, punctuation and case; fold whitespace, so raw names become comparable strings.

->
02

Block

Group accounts into candidate sets by cheap keys - first token, site, ERP - so scoring never compares every account to every other one.

->
03

Score

Compute a name-similarity score from 0 to 1 for each candidate pair inside a block.

->
04

Cluster (union-find)

Union every pair scoring at or above the auto-merge floor; the structure chains multi-hop matches into one connected set.

->
05

Golden records

Each connected set collapses to one canonical vendor. Borderline scores route to a human review queue instead of merging blind.

The threshold control

Where the line falls between a match and a miss

A score of 1.00 means exact after normalize, and 0.92 and above always auto-merges - those are not up for debate. Below that, this single control decides how much gets pulled into human review versus written off as a separate vendor. Move it and watch the golden records table below react live.

Review threshold 0.85

Candidates scoring at or above this line but below 0.92 go to the review queue. Below the line, they are treated as separate vendors and dropped from the count. Try lowering it to 0.83 or below - a real near-duplicate, "Calderon Sci.", is sitting just under the default line, which is the illustrative edge case this control exists to show.

Review queue

0 awaiting a decision

    The golden records

    Ten suppliers, reconciled from twenty-four raw accounts

    Every row below is a canonical vendor. Open one to see the source accounts that fed it - the site, the ERP, the raw account number, the raw name as it was entered, and the similarity score that decided its fate. This table reads the same threshold and reviewer decisions as the control above.

    Golden recordSource accountsSitesERPsStatus

    Flagged intercompany accounts (excluded from external spend)

    What the score actually measures

    A score is a lead, not a verdict

    Two ideas do the real work here: cutting the comparison space down before scoring, and letting the same threshold logic run everywhere on the page instead of being hand-tuned per screen.

    Blocking before scoring

    Comparing every account to every other account does not scale - 9,214 accounts is over 42 million possible pairs. Block groups accounts by a cheap shared key first, so Score only ever runs inside a small candidate set, not the whole table.

    This demo shows the aliases already grouped under their golden record for clarity. In production, blocking is the step that finds those groups in the first place.

    One threshold, everywhere

    The slider above, the review queue, and every chip in the golden records table all read the same classifyAlias function and the same state. Move the threshold once, and every view updates together - there is no second copy of the rule to drift out of sync.

    A reviewer's merge or keep-separate decision is stored as an override on that one alias, so it survives further threshold changes until it is undone.

    What this demo is, and isn't

    This is a working illustration of a record-linkage method on invented data. It is not a live system, not connected to any real ERP, and not a claim that any real operation holds exactly these numbers. Every account, name and score is a scenario input chosen to make the method legible in a couple of minutes.

    The headline totals in the stat row (9,214 accounts down to 7,980 golden records) are a fixed, invented scenario figure, separate from the ten illustrative golden records shown in the table, which are small enough to read in full.