How Vendor Identification Actually Works
Before anything on an invoice can be checked, one question has to be answered: which vendor sent this?
Everything downstream depends on it. The purchase order search is filtered by vendor. Duplicate detection is keyed by vendor. The tolerance policy is the vendor’s. Get the vendor wrong and every subsequent check runs against the wrong records — and, worse, runs cleanly, because it is comparing consistent things that simply belong to somebody else.
The ladder, strongest signal first
1. Tax registration number. The strongest signal available. It is issued by a tax authority, it is unique to a legal entity, and it appears on the invoice because the law requires it. It is not a name someone typed.
2. GLN (Global Location Number). A registered identifier for a specific trading location. Strong where it appears, which is mainly in retail and grocery supply chains.
3. Bank details (IBAN or account number). Strong, and interesting for a different reason: this is the identifier that says where the money goes. Two invoices bearing the same company name but different bank details are worth a very close look regardless of anything else.
4. Name similarity. The weakest signal, used last. Company names are not unique, are frequently abbreviated, and are legitimately similar between unrelated entities. “Northern Supply Ltd” and “Northern Supplies Limited” might be the same company or two competitors.
The ordering is not arbitrary and it is not a weighting to be tuned. It reflects how forgeable, how ambiguous and how authoritative each identifier actually is.
Why name matching last is not a technical detail
Name matching is where most invoice-handling systems fail in a way that is hard to see.
Fuzzy name matching produces a plausible answer for almost any input. It rarely says “I don’t know”. It says “87% match to Northern Supply Ltd” — and 87% is high enough to feel decisive and low enough to be wrong.
A system that reaches for name matching first will be confidently wrong on exactly the vendors where it matters: similarly named entities, subsidiaries of the same group, and companies that recently rebranded.
Name matching is a reasonable last resort, once the identifiers that mean something have been tried and produced nothing. It is a bad first move.
The three failure modes
A well-designed identification step has three distinct ways of not knowing, and they need different responses.
Nothing cleared the floor. No identifier resolved, and the best name match was too weak to act on. The honest answer is “I don’t know” — ask a person. Guessing here is how the wrong vendor gets bound.
Two candidates are too close. Two vendors both match, within a hair of each other. This is ambiguity, not ignorance, and the response is the same: ask.
Two strong signals contradict. The tax number points at vendor A; the bank details point at vendor B.
That third one deserves care. It is tempting to resolve it by taking the higher-weighted signal — the tax number outranks the bank details, so pick A. Do not.
A contradiction between two strong identifiers is not noise to be arbitrated. It is a finding. The realistic explanations are: your master data is wrong, the vendor has changed banking details and not told you, two vendor records exist for one entity — or somebody has altered the payment details on a real invoice.
That last possibility is the reason. Invoice redirection fraud works precisely by keeping everything about a document correct except where the money goes. A system that quietly resolves the contradiction in favour of the “stronger” signal defeats the one check that would have caught it.
The correct behaviour is to stop and show a person both signals and both candidates. Some contradictions should never be resolved automatically at all, no matter how confident either side is.
Self-match
One more case worth handling explicitly: the “vendor” resolves to your own company, an intercompany partner, or a record you have excluded from identification.
This happens more than you would expect — your own tax number appears on plenty of documents that pass through accounts payable, including ones a vendor has helpfully quoted it on. Treating that as a vendor match produces nonsense downstream.
Like a contradiction, this should not be overridable. There is no legitimate case where the right answer is “yes, bill ourselves”.
Learning, done safely
Every manual binding is information. When a person says this invoice is from vendor X, the identifier that appeared on the document can be recorded against X, so the next invoice carrying it identifies itself.
That is genuine learning, and it is safe because a human made the assertion and it is recorded as an exact identifier rather than a fuzzy impression. It shrinks the exception queue over time as your real vendor population gets covered.
What must not happen is the system learning from its own guesses. An unconfirmed match that gets recorded as fact will reinforce its own error, and the second occurrence will look more confident than the first.
Proposed is not bound
The subtle distinction that keeps the rest of the system honest: a vendor can be automatically bound (identified unambiguously) or merely proposed (probably this one, not certain).
A proposed vendor should never be treated as confirmed for the purposes of anything that reaches the ledger. Even if every downstream check then passes, the result should be routed to a person rather than allowed through automatically — because the whole chain rests on a guess nobody has confirmed.
Getting that distinction right is worth more than any improvement to the matching itself.
What this means practically
The single highest-value thing you can do to reduce vendor exceptions is put tax registration numbers on your vendor cards. It costs one afternoon and it moves your vendors from the weakest rung of the ladder to the strongest.
Bank details help too, and they carry a second benefit: with them recorded, a mismatch becomes visible instead of invisible.