Agentic Master Data Governance: Catching Duplicate and Conflicting Records Before They Corrupt ERP Transactions
written by Cooter:Labs
published on August 6, 2026
Introduction
Master data — the vendor, customer, and item records every transaction in an ERP ultimately points back to — doesn't get corrupted by one bad decision. It erodes one entry at a time: a sales rep creates a new customer record because the search didn't surface the existing one under a slightly different name, a procurement clerk sets up a new vendor because the old record has a stale remit-to address, a warehouse team adds a new SKU because the existing one was miscategorized and never showed up in the right filter. None of these are database errors. Each one is a locally reasonable decision that leaves the system with two records referring to the same real-world entity, and every downstream process — spend reporting, credit limits, reorder points, three-way matching — now has to guess which one is authoritative. Most ERPs have some duplicate-detection built in, usually an exact-match check on a tax ID or a name field, which catches the obvious cases and misses almost everything else.
The reason this is hard to fix after the fact is that by the time a duplicate is noticed, it usually isn't just sitting there unused — it has purchase orders, invoices, or sales history attached to it, which turns a simple delete into a data-migration problem. That asymmetry is what makes an agentic approach to master data different from a periodic cleanup project: the highest-leverage moment to catch a duplicate is at the point of creation, before anything references it, not six months later during a data-quality audit.
A vendor record for "Acme Industrial Supply, Inc." and one for "Acme Industrial Supply LLC" at the same address with a transposed digit in the phone number will sail past an exact-match check on name or tax ID, because one of those fields is usually missing or wrong on one side of the pair. Catching this requires fuzzy matching across multiple fields at once — name similarity, address normalization, phone and email overlap, and where available, tax ID or DUNS number — weighted so that a strong match on one field (a shared tax ID) can outweigh a weak mismatch on another (a different legal-entity suffix). An agent doing this well isn't running a single similarity score; it's checking several independent signals and reasoning about which combination is strong enough to flag versus strong enough to auto-block outright.
Once two records are identified as likely duplicates, someone or something has to decide what the merged "golden record" looks like when the two disagree — one has the correct current address and the other has the correct payment terms negotiated more recently. A naive merge that always keeps the older or newer record loses real information either way. An agent handling this needs field-level provenance: which system last touched each field, when, and ideally why, so it can prefer the more recently verified address while still preferring the contractually negotiated payment terms even if they're the older entry. Where that provenance doesn't exist because the source systems never tracked it, the agent is guessing, and that's a case that should route to a person rather than auto-resolve.
Running deduplication as a nightly or quarterly batch job finds problems after they've already been referenced by transactions, at which point fixing them means updating every PO, invoice, and sales order that pointed at the now-merged record — a much bigger blast radius than preventing the duplicate in the first place. An agent wired into the record-creation workflow itself can run the same fuzzy-match check the moment a user submits a new vendor or customer form, and either block the submission with a specific pointer to the likely existing record or require an explicit override with a reason logged. This shifts the cost from a data-migration problem to a five-second interruption in a form submission, which is a much easier trade for most organizations to accept.
A duplicate customer record mostly causes reporting and credit-limit problems. A duplicate or miscategorized SKU corrupts inventory counts, reorder point calculations, and demand forecasts, because the system now thinks it's tracking two items with independent stock levels when it's actually one item split across two records. Resolving this requires the agent to check not just name and description similarity but also unit-of-measure, supplier part-number cross-references, and — where the catalog is large — image or spec-sheet similarity, since item descriptions in ERPs are notoriously inconsistent between the person who created the record and the person searching for it later.
Looking Ahead: Challenges and Innovations
Legitimate near-duplicates look identical to real ones on paper
A national vendor with regional subsidiaries, a customer with multiple ship-to locations under slightly different legal names, or a franchise structure can produce records that are genuinely distinct but score just as similar as an actual duplicate would. An agent that flags these as duplicates too aggressively trains users to ignore its warnings, which defeats the purpose faster than having no automated check at all. The practical fix is to let confirmed "these are related but distinct" decisions become durable exceptions the agent remembers, rather than re-flagging the same pair every time a new transaction touches either record.
Merging records that already have transaction history attached is a one-way operation with real consequences
Once a duplicate has open purchase orders, unpaid invoices, or active credit terms attached, a merge isn't just a data cleanup — it can change which entity a payment is legally owed to or which credit limit applies to open orders. An agent should have authority to prevent new duplicates from forming and to flag existing ones for review, but merging records with live financial exposure attached needs a human sign-off with visibility into what's actually outstanding on both sides, not just a data-quality score.
Someone still has to own the master data model itself, or the agent has nothing authoritative to check against
An agent can enforce consistency against a schema — which fields are required, which formats are valid, which fields count toward a duplicate score — but it can't invent that schema from nothing, and it can't resolve genuine organizational disagreement about what counts as "the same vendor" (one legal entity vs. one negotiated relationship, for instance). Deploying agentic master data governance without first getting agreement on the underlying data model just automates enforcement of an ambiguous standard faster, which surfaces the ambiguity as noise rather than resolving it.
The metaverse
As ERPs increasingly connect procurement, sales, and inventory data live rather than through nightly batch syncs, master data governance is shifting from a periodic cleanup discipline into a continuous, transaction-time check — closer to how identity resolution already works in CRM and fraud-detection systems than to the annual data-quality project most ERP teams are used to. The organizations getting the most out of this aren't the ones with the most sophisticated matching algorithm; they're the ones that already have a clear, agreed-upon definition of what a "vendor" or "customer" record is supposed to represent, which is what actually determines whether an agent's decisions are trustworthy enough to act on automatically.
Conclusion
Master data governance has always been less a technology problem than a discipline problem — the tools to detect duplicates have existed for years, but catching them at the moment of creation, resolving conflicts with real field-level provenance, and knowing when a near-match is actually a distinct entity all require judgment that a rules engine doesn't have and a nightly batch job applies too late to matter. An agentic approach earns its value the same way it does elsewhere in the ERP: not by matching faster, but by investigating each case with the context a static rule can't hold, while still routing the transactions with real financial exposure to a person before anything gets merged.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.