--- title: "How to deduplicate a supplier master" summary: "Duplicate vendors, payment leakage, remittance conflicts and parent concentration. The accounts payable playbook for finding which vendor records are one company, with a citation for every finding." canonical_url: https://entitybind.com/guides/how-to-deduplicate-a-supplier-master last_updated: 2026-10-12 copy: full --- # How to deduplicate a supplier master > Duplicate vendors, payment leakage, remittance conflicts and parent concentration. The accounts payable playbook for finding which vendor records are one company, with a citation for every finding. Canonical page: https://entitybind.com/guides/how-to-deduplicate-a-supplier-master Last updated: 2026-10-12 For the team that owns a company master and has to defend it. A supplier master duplicates faster than a CRM and for a structural reason: a vendor record gets created whenever somebody needs an invoice paid this week, and the person creating it is optimising for that rather than for the integrity of the master. The consequences are specific — duplicate payments, group terms applied to one of five records, concentration risk spread across records nobody knows are the same company, and remittance conflicts that look identical whether they are fraud or a legitimate account change. This is how to find them, and what each finding is and is not evidence of. - Reading time: 12 min read - Sections: 9 - Questions answered: 6 - Key takeaways: 7 The same measurement, on your rows: A first file is a few hundred of your own rows with the matches you already have beside them. The numbers in this article come back measured on your data, and we write nothing to your systems. [Start free →](https://app.entitybind.com/app?signup=1) Self-service. Create your workspace online and verify your email to start matching company records. Free starts with 300 credits and no card. Paid monthly plans are available in workspace Billing; VAT is added where applicable. Usage is tracked without automatic overage charges. [Trust and security](https://entitybind.com/trust) A stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, counterparty onboarding that has to survive an audit. Read the argument here, take the takeaways at the foot into your next vendor conversation, and send us a file when you want the same measurement on your own rows. Playbooks · 2,246 words · every figure carries the population it was measured over By [James Rooney](https://entitybind.com/about), founder of Entity Bind · Last revised 12 October 2026 ## Why a vendor master is worse than a CRM Three forces push in the same direction. The first is urgency: a new vendor is created under time pressure by somebody whose objective is a payment run, and a search that returns nothing in four seconds is a search that ends in a new record. The second is that the name on an invoice is frequently not the name in the register — it is the trading name, the division, the brand, or the group. The third is that remittance details are collected per record rather than per company, so the same supplier ends up with different bank details attached to different rows because they were captured at different times from different people. The result is a table where one company appears as a legal name, a trading name, an abbreviation, a name with the division appended, and a name with a typo, and where none of those rows knows about the others. That is not a tidiness problem. It is money. ## What the duplicates cost, by mechanism Name the mechanisms separately. They have different owners and different fixes, and a project scoped as "clean the vendor master" gets defunded by whichever owner was not in the room. - Duplicate payment. Two vendor records receive the same invoice through two routes and both pay. Recovery audit firms are paid a percentage to find these years later, which is a market signal about how often it happens. - Terms leakage. Payment terms and a discount are negotiated with a corporate group and applied to one of its five vendor records. The other four pay list, and nothing in the master reveals that they are the same counterparty. - Invisible concentration. A treasurer asks what share of the payment run goes to one corporate group. The exposure is spread across records that are not linked, so the answer produced is confidently too low. - Remittance conflict. Two records for one company carry different bank details. That is exactly the shape a payment fraud takes and exactly the shape a legitimate account change also takes, and the master holds nothing that separates them. - Reporting that cannot be reconciled. Spend by supplier, supplier count, and single-source risk are all computed over rows rather than over companies, so every one of them is wrong by an amount nobody can quantify. ## The extract: the columns AP has, and the ones it thinks it has Take the vendor master with your own supplier id first, and take every identifying column even where the fill is poor. A registration number column populated on a fifth of rows decides that fifth deterministically, with no model call and no egress: the identifier tier measured 100% (317/317) on the live-adjudicated fixture of 2026-08-29. Two columns in a vendor master routinely promise more than they deliver, and both are worth checking before you map them. Check these four before you size anything: - The VAT number field. A VAT number is a real identifier and is not a qualifying signal here: the UK publishes no lawful bulk name-to-VAT source, so there is nothing to measure a rate against and no tier for it. Map it, carry it, and do not plan the run around it. - The supplier contact email domain. Strong where it is the company's own domain and misleading where it is a personal mailbox, a shared accounts inbox at an outsourcer, or a group address. It is treated as a digital signal, and a conflicting one is recorded as a weak disagreement rather than as a decision. - The remittance address. The postcode is the part that carries, and a remittance address is frequently a factoring house or a shared service centre rather than the company. Where there is no usable postcode, a full address behaves as context — retrieval evidence that ranks candidates rather than an identifying field that decides them. - The name column, if it has been through middleware. Truncation is common in older ERPs and it is the weakest measured shape: 58.10% (61/105), with the remainder returning a ranked shortlist rather than a guess. ## Duplicate candidates with evidence rather than similarity A pair agreeing on a registration number or an LEI is decided by an identifier rule and never scored. A pair agreeing only on a name is scored, and if the score lands in the borderline band a language model is asked to judge it — adjudication — with the register's own evidence written into the prompt: each rival candidate's town, register status, previous names and legal form. What comes back is a decision with a register page attached, rather than a candidate list for your team to work through from the same two strings the matcher had. Previous names are where a register beats string matching outright. [Companies House](https://find-and-update.company-information.service.gov.uk/) and several other registers publish former names with validity dates, and those are stored as facts on the entity with their own provenance. So a vendor record raised under the old name and one raised under the new name resolve to one company, and the receipt shows the register page carrying both. No amount of fuzzy matching over the name column finds that pair, because the two strings genuinely are not similar. The merge guard is the other half. A merge is blocked outright on one disagreeing strong identifier — a registration number, an LEI — or on two or more disagreeing weak signals such as a domain and a phone together. One weak contradiction is noise; several agreeing that these are different companies is evidence. An agreeing strong identifier short-circuits the weak check, which is how a supplier that relocated and changed every contact detail still resolves to itself. ## Remittance conflict is a statement about your master, not about intent Where two records we believe are one company disagree on a weak signal, the disagreement blocks the merge and is recorded with the attribute that disagreed named, rather than averaged away. That output is the list of places where your supplier master holds two different answers about one company. It is not fraud detection and it must not be sold internally as fraud detection. A remittance conflict is consistent with a mandate fraud, with a stale record, with a factoring arrangement, and with a genuine second legal entity sharing a brand. Which of those applies is not visible from the master, so what you receive is the conflict and the evidence behind it rather than a flag with an implication. It is also not account ownership verification. Confirming that a bank account belongs to a company needs a payment service provider or an aggregator feed, and we have neither, so we make no claim about it. What resolution contributes is the counterparty: the account check your bank or treasury system performs runs against a resolved registered company with a citation, rather than against a name somebody typed into a form. ## Parent concentration, cited per edge, with its basis stated Ownership rides along from the global LEI system's relationship records and, for UK companies, from the persons-with-significant-control register, one hop by default and up to ten on request, cycle-safe and bounded, failing closed on ambiguous or name-only owners. Read the basis of an edge before you read the number. A parent from the LEI system means accounting consolidation under the applicable accounting standards, not majority ownership. Rendering that as the same claim a credit bureau's parent field makes is wrong in a way that is invisible on a concentration report, so every edge states its basis and its certainty. Control bands are published as bands and are never multiplied or converted to a midpoint: an indirect percentage appears only where every hop carries an exact published figure, and otherwise the response says the arithmetic was refused and why. The absence is a finding too, and it is not the same finding as a zero. An incomplete ownership path is an absence of coverage rather than an absence of owners, and the traversal always reports what it did not walk, so you cannot infer depth from an empty field. For a concentration report that distinction is the difference between "this supplier has no parent" and "we could not establish one", and only the second is usually true. ## The France problem, and why it is a register problem A vendor master with European suppliers behaves differently by register, and the largest single effect is [name uniqueness](https://entitybind.com/research/company-name-uniqueness). [Companies House](https://find-and-update.company-information.service.gov.uk/) holds 5,464,811 live companies of which 99.53% carry a name no other live company shares. [SIRENE](https://annuaire-entreprises.data.gouv.fr/) holds 5,841,117 legal persons and the figure is 67.96%. A third of French companies share their exact name — 1,003 live companies sit on one name. A French file needs a town or postcode column, and with one it measured 2,998 of 3,000 on the postcode tier. So a French supplier row carrying only a name returns a shortlist far more often than a British one, and that is the register rather than the engine. The remedy is the column the note above names. Combined three-region parity against the UK baseline measured 0.999955 against a 0.9565 bar, measured with no model spend at all, on identifier and digital tiers plus retrieval and fragmentation, using the same seeded, sibling-complete builder in every register. It does not carry the live-adjudicated name tiers across, which rest on jurisdiction-free calibration keys and have been recorded in the UK only. There is also a hole to know about before you scope. Germany is not limited coverage; it is an absence, because there is no lawful bulk source. The measured registers do not cover a supplier master weighted towards German vendors, and the first call is a cheaper place to learn that than month three. ## What to do with the output, in an ERP with a payment run tomorrow Nothing is written to your ERP, your procurement system or your payment run. What arrives is a proposal, and the sequence that survives an internal audit is boring on purpose. - Block, do not merge, first. Marking the losing vendor records as blocked for new transactions stops the leakage immediately and is reversible in an afternoon. Merging vendor records in most ERPs is not. - Take the identifier-decided clusters first. They are the cheapest, the most defensible, and they carry a register page rather than a score. - Route the blocked-merge list to controls rather than to master data. A remittance conflict is a controls question and the master data team cannot answer it. - Work the abstentions by typed cause. The ones marked as needing more input are a data request; the ones that normalised to no identifying signal are your own export to fix. - Attach the decision id to every master data change ticket. It reopens at a URL and it is the artefact that answers why, which a score is not. ## The recovery number is yours, and it has to be The question at the end is always what this saved. We cannot compute that. Turning a set of duplicate clusters into a recovered amount requires your invoice and payment history, your own definition of a duplicate payment, and a validation step we do not perform. Any recovered figure is yours, measured by you, and it would be labelled as yours on any page of ours it appeared on. What can be measured on our side is narrower and checkable. How many vendor records collapsed into how many companies. How many merges the guard refused, and on which attribute. How many suppliers turned out to sit under a shared parent, with the basis of each edge stated. And whether the pack's totals reconcile — every input row landing in exactly one ledger, distinct source references equalling rows in — because a finance team checks that first and a run that cannot reconcile exits non-zero rather than shipping. ## What to take away - A vendor master duplicates faster than a CRM because records are created under payment-run pressure, under invoice names rather than register names, with remittance details captured per row. - Name the cost mechanisms separately — duplicate payment, terms leakage, invisible concentration, remittance conflict, unreconcilable reporting — because they have different owners. - Previous names are register facts. A record under the old name and one under the new name resolve to one company; no fuzzy match over the name column finds that pair. - A remittance conflict is a statement that your master disagrees with itself. It is not fraud detection and it is not account ownership verification. - An LEI parent means accounting consolidation, not majority ownership, and an incomplete ownership walk is an absence of coverage rather than an absence of owners. - Register shape dominates: 99.53% [name uniqueness](https://entitybind.com/research/company-name-uniqueness) in [Companies House](https://find-and-update.company-information.service.gov.uk/) against 67.96% in [SIRENE](https://annuaire-entreprises.data.gouv.fr/). A French file needs a postcode column before a name tier means anything. - Block before you merge, route conflicts to controls, and treat any recovery figure as yours to measure rather than ours to promise. Those takeaways hold for anybody's data. The number for yours comes out of your own rows — a few hundred of them, with the matches you already have beside them. [Start free →](https://app.entitybind.com/app?signup=1) ## Read next Each article names its own further reading. These pick up a question this one raises and leaves open. - [How to deduplicate a CRM](https://entitybind.com/guides/how-to-deduplicate-a-crm) (12 min read): Export, preview, tier the file, run it, review the abstentions, merge with receipts, measure. The full sequence for deduplicating a CRM account object without making a wrong merge you cannot undo. - [Survivorship and golden records](https://entitybind.com/guides/survivorship-and-golden-records) (10 min read): Merging records is only half the job. Field-level survivorship, source precedence, temporal facts, per-field provenance, and why last-confirmed beats first-seen. - [Company identifiers explained](https://entitybind.com/guides/company-identifiers-explained) (13 min read): Company number, LEI, CIK, ticker, SIREN and SIRET, DUNS, VAT, EUID and ISIN. What each identifies, who issues it, what it does not guarantee, and which ones actually decide a match. - [What is entity resolution?](https://entitybind.com/guides/what-is-entity-resolution) (9 min read): Entity resolution decides which records refer to the same real-world thing. What it is, why company identity is hard, deterministic versus probabilistic matching, and why fuzzy matching is not entity resolution. - [ISO 20022 structured address requirements](https://entitybind.com/guides/iso-20022-address-requirements) (11 min read): CBPR+ payment messages are to stop accepting fully unstructured postal addresses. Swift delayed the 14 November 2026 date on 27 August 2026. What changes, and the identity work it forces. Or try your own rows: create your Free workspace and upload a company CSV to inspect its results. Contact us for an assisted measurement against your labelled data, with the working handed back. [Start free →](https://app.entitybind.com/app?signup=1) ## Where this article is applied 2 pages name this method as the working behind what they claim. - [Supplier master and accounts payable](https://entitybind.com/use-cases/supplier-master-and-ap) (Use case): Duplicate vendors, remittance conflicts and concentration you cannot see. - [Snowflake](https://entitybind.com/integrations/snowflake) (Integration): An integration pattern over the HTTP API rather than a connector. Unload the rows, post them in requests of up to 500, and load the results back. ## Is this your file? The article is for anyone. The measurement behind it is worth commissioning for one kind of team. ### Built for Teams with a company master they have to defend — an MDM or stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, or counterparty onboarding that has to survive an audit. ### Wrong for Buying breadth as the product: we hold a fraction of an incumbent’s records and are not building a global company graph. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy. ## Sources The papers, regulators and registers this article quotes, each with the caveat that travels with it. - [Companies House register search](https://find-and-update.company-information.service.gov.uk/): The register the United Kingdom figures were measured on. A name-uniqueness share is a property of the register, not of any resolver. - [Open Government Licence v3.0](https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/): The instrument Companies House publishes under. It is what makes those facts storable and resellable rather than return-only. - [Annuaire des Entreprises](https://annuaire-entreprises.data.gouv.fr/): The keyless government search route to the SIRENE universe. What it cannot fix is that a third of French companies share their exact name. - [Licence Ouverte 2.0 (Etalab)](https://www.data.gouv.fr/pages/legal/licences/etalab-2.0): The licence SIRENE data is reused under. It permits free reuse, including commercial reuse, with attribution. ## The basis for every figure above Internal fixtures only. The historical 2026-08-29 per-tier recording covers 317 GB companies with identifier-rich arrivals seeding the catalogue first; the context tier includes country and registered-town prose. Its legacy replay has no full-prompt-verified calls and cannot certify current calibration. The September 5 CI reports cover 1,176 labelled pairs and 705 records over 250 companies using offline stubs. These are not independent customer holdouts or live production validation; the 99% minimum-input product target remains unmet. Scope is company and organisation identity only — not people, vessels, bank-account ownership, sanctions or emissions. Results may not be used for eligibility decisions about individuals, including employment, credit and tenancy. Figures read off the product repository on 2026-09-05. The per-tier rates come from the live-adjudicated 317-company recording of 2026-08-29; the gate figures come from the stub-adjudicated continuous-integration run and are a floor rather than a ceiling. The two are never averaged. Entity Bind holds no SOC 2, no ISO 27001 and no other certification, and claims none. Every figure, with the population it was measured over and the method behind both recordings, is set out on [the accuracy page](https://entitybind.com/accuracy). The retention, erasure, tenancy and sub-processor detail a security review asks for is under [Trust and security](https://entitybind.com/trust), with where assurance stands: no external validation of the accuracy figures and no customer holdout. ## The same measurement, on your own rows. Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration. [Start free](https://app.entitybind.com/app?signup=1) · [Plans and prices](https://entitybind.com/pricing) 300 credits. No card. For a guided review of your file, explore [the Merge Safety Sprint](https://entitybind.com/audit-pack). ## The questions this article answers ### Will you tell us how much duplicate spend we can recover? No, and not after we have seen your file either. A recovery figure quoted before anyone has seen your file comes from somebody else's data. What we tell you is which supplier records are the same company, with the evidence behind each decision. Turning that into a recovery figure needs your invoice and payment history, your own definition of a duplicate payment, and a validation step we do not perform. Any recovered amount is your number, measured by you. ### Can you check whether a bank account belongs to the supplier? No. Verification of payee cannot prove account ownership without a payment service provider or an aggregator feed, and we hold neither. What we can do is resolve the counterparty behind the account — establish which registered company this vendor record actually is, with a citation — so that the account check your bank or your treasury system performs runs against a registered company that has actually been identified, rather than against a name typed into a form. ### Is a remittance conflict a fraud alert? It is not, and presenting it as one internally will cost you credibility the first time a legitimate account change is escalated as a fraud. A remittance conflict is the statement that two records you hold for one company disagree about bank details, with the disagreeing attribute named. Which of the four possible explanations applies — mandate fraud, stale record, factoring, or a genuine second legal entity — is a controls judgement made with the evidence rather than without it. ### Does this work for our non-UK suppliers? Per register rather than per continent, and the list is short. Measured registers are the United Kingdom, the United States via Colorado and via SEC filers, France and Norway. Adapters for Finland, Czechia and Poland are wired but have no evaluation fixtures, so they carry no measured quality figure. Germany is a hole rather than limited coverage — there is no lawful bulk source — and Delaware sells no data at any price. Combined three-region parity against the UK baseline measured 0.999955 against a 0.9565 bar at zero model spend, over United Kingdom, United States (Colorado) and EMEA (France and Norway). Outside those registers there is no measured quality to quote. ### What is the smallest useful first run? A few thousand rows of the real master, not a curated sample. A curated sample proves the easy rows, and the interesting rows are the ugly ones. Have us run the free preview over the whole file first — it calls no model and no registry, spends nothing, and tells you which of your populated columns are unusable and why — then run a slice through the cascade and check the results by hand against the register pages cited on each decision. ### Can this replace our vendor master or our MDM platform? No, and it is built to run beside one. Keep the vendor master or the MDM platform you already have and put this alongside it: it is a decision and evidence layer that judges the matches that system proposes, accepting them, withholding them or contradicting them with a citation you can open. It is not a master data management platform and it holds no vendor lifecycle, no onboarding workflow and no approval hierarchy. It also holds no trade payment behaviour, no payment experience data, no credit score and no risk rating, and there is no open equivalent of those, so they will not arrive later either. --- Historical results on an internal UK fixture with a preloaded catalogue. The September 5 replay has no full-prompt-verified calls and cannot establish current calibration. No independent customer holdout or global coverage claim. This is the Markdown copy of https://entitybind.com/guides/how-to-deduplicate-a-supplier-master, assembled from the same data the page renders and carrying every sentence, table row, figure and question the page's main content carries. The HTML page is canonical; it adds the layout, the navigation and the interactive parts (the ask panel, the forms), which a copy can name but not run. Every page on the site, with a line on each: https://entitybind.com/llms.txt.