The vendor master record: the fields that decide whether an invoice can be automated at all

A vendor master record holds everything true about a supplier that no individual invoice states: their legal identity, the names they trade and bill under, tax registrations, the entity money is remitted to, bank details, payment terms, currency, and the variance their invoices are permitted. It is read on every invoice that arrives and written far less often than that, which is exactly why its gaps stay invisible.

Calling it a table understates what it has to be. A table is somewhere to put data. A system of record has an owner per field, a change history, and a defined moment at which a value becomes true — which matters because "the bank account changed" and "the bank account changed on the 14th, requested by this person, verified by that one" are different facts, and only the second is usable when a payment goes wrong.

Six groups, and what fails downstream when each one is thin

The first five groups appear in every ERP's supplier screen. The sixth usually does not exist at all, and it is the one a matching engine depends on most.

The four fields almost nobody stores

• The names the supplier actually bills under. Your record says "Northgate Industrial Supplies Ltd". The invoice header says "Northgate", the remittance advice says "NIS Group", and the bank narrative says something shorter still. Without an alias list, every one of those is an unmatched supplier, and the resolution is done from memory by whoever has been in the team longest.
• Remit-to entity, held separately from the contracting entity. You contracted with the UK company and are asked to pay the Irish one; after a group reorganisation the invoice arrives from an entity you have never traded with. Collapsing the two into one address field means the control that should catch a redirection has nowhere to live.
• A per-supplier tolerance profile. A commodity supplier whose prices move weekly and a fixed-rate licence supplier cannot share a variance threshold without either drowning you in exceptions or waving real overbilling through — the argument set out in tolerance rules and what a matching engine may wave through.
• The identifier the supplier prints on its own documents. Most suppliers hold an account number for you and quote it on every invoice and statement. Storing it turns statement reconciliation and portal lookups from a search problem into a key lookup, and it is the single cheapest field on this list to capture at onboarding.

Two more fields are worth the same attention because matching reads them directly. The unit-of-measure convention a supplier bills in — cases where you order pallets, hours where you order days — is a property of the supplier, not of the invoice, and holding it here is what prevents unit-of-measure drift recurring on every line. And the date basis the terms run from belongs to the supplier record rather than to a company-wide setting, because a supplier who dates invoices weeks before sending them makes the choice of date a real one, as invoice date, received date or approval date sets out.

How one supplier becomes five rows

Duplicate supplier records are created by ordinary events: a second site onboards the same supplier, a name changes after an acquisition, someone types a name with a trailing space, a one-off payment is set up in a hurry. The consequence is that spend is understated per supplier, duplicate-payment checks scoped to a supplier id stop working, and negotiated terms apply to one row and not the others.

1. Normalise names before comparing anything: case-fold, strip punctuation, and remove legal-form suffixes such as Ltd, Limited, GmbH, Pvt and Inc. A large share of apparent duplicates collapses on this step alone.
2. Group by tax registration number where you hold one. This is high precision and low recall — it finds real duplicates confidently and misses every record where the field is blank, which is usually most of them.
3. Group by bank account. This is the strongest signal on the list, because two rows paying the same account are the same payee whatever they are called, and it also surfaces the case you least want to find: two different suppliers sharing an account.
4. Group by remit-to address and postcode, then by the domain of the contact email. Domain matching catches group companies that name themselves differently and bank separately.
5. Rank the surviving clusters by combined 12-month spend and work down. Merging suppliers is disruptive to open POs and history, so the payback has to justify it, and the tail of tiny one-off records is usually better deactivated than merged.
6. Close the source: make the search on the create-supplier screen run the same normalisation, so the sixth row is refused rather than found later.

Electronic invoicing standards do not remove the problem. EN 16931, the European eInvoicing standard behind Directive 2014/55 — which requires public bodies to be able to receive and process invoices conforming to it — standardises the invoice document. It does not standardise your supplier record. A conforming invoice still arrives carrying the supplier's own identifiers, and something on your side still has to resolve them to exactly one row before the three-way match can even begin.

Most accounts payable automation failure is a master-data failure wearing a matching costume. The engine is doing exactly what it was told, against a record nobody has been accountable for since it was created.

Payment terms read from this record also interact with the banking day: a payment released on the due date does not always settle on it, which is what settlement cutoff and the day boundary works through. That combination — a record that decides behaviour, and an operational reality that decides outcomes — is why we usually treat the supplier record as an internal tools and operations build in its own right rather than a configuration step inside a larger one. The rest of invoice to pay: capture, matching and approvals assumes this record is trustworthy, and across our finance operations work it is the assumption that most often turns out to be false.

• vendor master
• supplier data
• accounts payable
• master data