Vendor names are the hidden data quality problem

One supplier routinely appears under several different names across your records — the trading name on the receipt, the legal entity on the invoice, and a payment-processor descriptor on your bank statement. Nothing looks broken. But every report that groups by vendor splits that supplier into pieces, and every rule you write catches only one of them.

Amounts get all the attention in receipt data quality. Vendor names cause more day-to-day damage.

Where the variants come from

The receipt shows a trading name, sometimes with a branch number: NORTHWEST TOOLS #4412.

The invoice shows the legal entity: NWTS Holdings Limited.

The bank statement shows a payment-processor descriptor, which is its own genre: SQ *NWTS HOLD 4412 LONDON GB. Processor prefix, truncated name, store identifier, city, country.

Online purchases may show a marketplace rather than the seller, so the vendor of record isn’t who you bought from.

Subscriptions often bill under a parent company you’ve never heard of.

Each of these is correct in its own context. Collectively they mean one supplier occupies five rows in any vendor list.

What it actually breaks

Categorisation rules. A rule keyed to one spelling silently fails on the others, so the same supplier posts to the right account sometimes and to a guess the rest of the time. This is the most expensive consequence, because it looks like the rule is working.

Vendor spend reports. Your largest supplier appears as three medium ones. Any question of the form “how much do we spend with X” gets an answer that’s too low, with no indication it’s incomplete.

Duplicate detection. Matching that considers vendor names will miss real duplicates where the two records came in through different channels.

Reconciliation. Matching receipts to statement lines by vendor fails on the descriptor mangling, which is why amount should always be the primary match key.

Search. You look for the supplier by the name you know, and find a third of their records.

None of these announces itself. That’s what makes it a hidden problem rather than a visible one.

Normalisation is a decision, not a lookup

The fix is to maintain a canonical name per supplier and map every variant to it. The important part is that you choose the canonical name, and you choose the one you’d search for — not the legal entity, not the descriptor.

If you think of them as Northwest Tools, the canonical name is Northwest Tools. Precision about legal entities is for contracts; your expense records need findability.

Then the aliases attach to it: the receipt spelling, the statement descriptor, the parent company on the subscription. Anything arriving as an alias becomes the canonical name in your data, with the original preserved on the record.

Doing it without it becoming a project

Start from volume, not completeness. Sort vendors by transaction count. The top twenty or so are most of your activity, and normalising just those fixes most of the damage. The long tail of one-off suppliers matters much less.

Normalise when a new vendor first appears. This is the natural moment — the record is in front of you, and handling it once prevents the variant establishing itself. It’s also exactly when a review queue should be showing you a first-time vendor.

Keep the original. Store both the canonical name and what the document actually said. The document is the evidence; changing what you recorded it as saying is not something you want in your history.

Treat statement descriptors as aliases, not names. They’re identifiers for machines. Never let one become a canonical vendor.

Expect drift. Processors change prefixes, businesses rebrand, subscriptions move between billing entities. A new variant of a known supplier will appear; the aim is that it gets mapped rather than becoming a sixth row.

Why automatic matching only goes so far

Fuzzy string matching helps and cannot finish the job. NWTS HOLD and Northwest Tools are not similar as strings — the connection is knowledge, not spelling. Meanwhile genuinely different suppliers can have similar names, and merging those is a worse error than leaving them split.

So automated similarity is useful for suggesting merges and unsafe for performing them. Same principle as duplicate receipts: flag the pair, let a person confirm, and record the decision so it applies from then on.

The check worth running

Once a quarter, list every vendor with its transaction count and total, sorted alphabetically rather than by size. Read it.

Alphabetical order puts variants of the same name next to each other, and the eye catches them immediately — Northwest Tools, Northwest Tools Ltd, NWTS HOLD. Ten minutes, and it finds the problems that no individual entry review would, because each of those entries is individually correct.

That’s the nature of this whole issue: the errors don’t exist in any single record. They only exist in the aggregate, which is why they need a check that looks at the aggregate.