One supplier arrives under six names, and none of them match the ledger

Twelve months of one client's purchase documents produce six supplier strings that are all the same shop: MAPLE & CO, Maple and Company Ltd, Maple Co (Northgate), Maple & Co. Limited, MAPLE NORTHGATE, and a card line reading SQ *MAPLE NORTH. The ledger holds three as separate suppliers and has never seen the other three. The instinct is to reach for fuzzy matching. Do not. Match on the identifiers the document already carries, and let the name break only the ties nothing else can.

String distance cannot separate the two failures you care about. Maple Foods Ltd and Maple Farms Ltd are two characters apart and are different companies. MAPLE & CO and SQ *MAPLE NORTH share almost no characters and are the same one. Any threshold loose enough to join the second will join the first, and joining is the expensive direction: two payees collapsed into one record produce a payment to the wrong bank account. Two records for one payee is merely untidy.

Count the names before you count the errors

The confirming check is a supplier-cardinality report, run per client rather than across the practice. It answers one question: how many distinct supplier strings the extraction produced, against how many distinct suppliers the ledger transacted with. A ratio well above one is the symptom, and the clients carrying it are rarely the ones anybody suspected.

1. Take twelve months of extracted purchase documents for one client. Normalise for whitespace and case only — do not strip suffixes yet, because suffix drift is part of what you are measuring.
2. Count distinct strings, and call that N. Count distinct ledger supplier records with at least one transaction in the same period, and call that L.
3. Compute N divided by L per client, then weight by volume. A ten-invoice client at a ratio of 4 matters less than a nine-hundred-invoice client at 1.4, and an unweighted sort ranks them backwards.
4. Take the top five clients and cluster their strings by the identifiers below, not by the names. Any cluster holding several strings and one registry identifier is a duplicate you are about to create.
5. Look for the inverse too. A cluster holding one string and two registry identifiers is a merge that already happened, and it is the one worth fixing this week.

Six names, one payee: where the duplicates actually come from

Each class has a distinct signature on the page, and the class tells you which field settles it. None needs a model to detect; every one is visible in the extracted field set, provided the field set is right.

That last row is why the approach has to invert. A name-similarity matcher scores those two franchisees at almost 1.0 and merges them; the first anyone hears of it is when one is paid for the other's invoices. The same matcher scores the card descriptor near zero and creates a seventh supplier. It is confidently wrong in both directions at once.

The supplier's name is the least stable field on the invoice, and it is the one nearly every pipeline matches on first.

The identifiers that survive a rebrand

Rank candidate identifiers by how hard they are to change, not by how often they happen to be populated. Coverage is a reason to hold a fallback, not a reason to promote a weak identifier above a strong one.

• A registry-issued number. A company or tax registration number changes only when a legal event forces it, which is exactly the property you want in a key. A match is decisive; a mismatch is blocking.
• A Legal Entity Identifier, where the counterparty has one. Twenty alphanumeric characters, defined by ISO 17442 and resolvable through the Global LEI Index published by GLEIF — verifiable without asking the supplier anything.
• The remittance bank account. Hard to change, printed on most invoices, and self-checking where it is an IBAN, whose country prefix and check digits reject a transcription error before anyone tries to pay it.
• The registered address, reduced to postcode plus building number rather than compared as free text. Strong for branches, weak for serviced offices and accountants' registered-office addresses.
• The email or web domain. Cheap, high-coverage, and unreliable for anyone trading through a marketplace or a shared reseller domain.
• Name similarity, last. Its only legitimate job is ranking candidates an identifier already narrowed, and surfacing a suggestion for a human.

Registry numbers are worth resolving, not merely storing. Companies House publishes a REST API over live company data in the UK, so a number lifted from an invoice footer can be checked against the register rather than against your memory of what the supplier used to be called. Confirm what equivalent lookup exists in each jurisdiction your clients buy from. That same number is what a statutory filing carries downstream, raising the separate question of whether transmission needs an approved provider.

A card descriptor names the processor, not the shop

Card and wallet lines generate more phantom suppliers than everything else combined. The descriptor is assembled by the acquirer, prefixed with the payment service's own tag, and truncated to a fixed field width. It changes when the shop switches terminal or app, and it names the party that processed the money rather than the party that sold the goods.

• A card line may attach to an existing supplier. It may never create one, carrying no identifier to create the record from.
• The receipt is the evidence, not the statement line — which makes capture quality the real constraint, and the reason the gate belongs at the client's phone, as argued in fixing receipt photos at the moment of capture.
• Unmatched card lines go to an explicit unidentified-payee state, descriptor preserved verbatim. Normalise it into something supplier-shaped and you lose the only string that recognises the same terminal next month.
• Whether the artefact is a purchase document at all is an upstream routing decision — the argument for shaping that taxonomy around handlers is in routing an incoming client file to the right handler.

Creating a supplier is a decision, not a side effect

The highest-value rule in this area is that supplier creation is never automatic. Three outcomes, one of them silent.

• Matched. A registry identifier or verified LEI hit an existing supplier. Post it, record which identifier fired, move on.
• Candidate. Name, address or domain agree but no registry identifier matched. Hold the document and show the reviewer both records side by side, differing fields highlighted.
• New. Nothing matched. Require an explicit create capturing the registry identifier, or a stated reason there is none — a foreign supplier below a registration threshold, a private individual, a one-off reimbursement. The reason is a field, not a shrug.

Insist on that gate, because supplier creation is a write into someone else's ledger. Merge behaviour differs between QuickBooks Online, Xero, Sage and NetSuite, some merges cannot be undone, and a supplier carrying posted transactions is often not deletable at all. It is the same refusal-to-emit discipline that makes a statement-to-transactions pipeline gate itself on balance continuity: the cheapest place to stop a bad record is before it exists.

What getting the supplier right still does not do

Identity and treatment are different problems. Conflating them is how a supplier-matching project turns into a coding project that never ships.

• It does not decide the expense account. Knowing exactly which entity billed you says nothing about whether the line is a subscription, a repair or a capital purchase.
• It does not clean a ledger that is already wrong. Retrospective de-duplication needs its own approval and rollback plan, and should never ride along inside a pipeline release.
• It does not survive a field set that never captured the identifier. With no registration-number field and no bank-account field in the extraction schema, none of this exists at runtime, and a reviewer confirming a merge has nothing to read.

If a model does the last-resort ranking — a reasonable job for one — remember that a supplier master is confidential data about a client's trading relationships, so where it may be processed is a procurement question, not an engineering preference; the trade-offs are in private LLM deployment. Designing the field set, the identifier hierarchy and the review gate together sits inside the extraction and classification topic for accounting and tax practices, and is the kind of narrow intake work we build under AI agents and automation.

• extraction
• supplier master
• data quality
• accounts payable