Master data agent: keeping ERP and CRM records clean

Almost every mid-market company we work with has run a data clean-up. Someone spent six weeks merging duplicate customers, standardising item descriptions, fixing supplier bank details. It worked. And within two or three quarters the dataset had drifted back, because nothing about the way records are created and maintained had changed.

This is the defining characteristic of master data: it is not a project with a completion state, it is a continuous condition. Records are created daily by people under time pressure who are trying to do something else — book an order, raise a purchase, log a lead. Every one of those moments is an opportunity for a duplicate, a malformed tax identifier, an inconsistent unit of measure. The rate of creation is constant, so any solution that is not also constant loses.

Which is what makes stewardship a strong fit for an agent. Not because detecting duplicates is technically difficult, but because the work is unending, unglamorous, and always the first thing displaced when a person has something more urgent to do.

This article covers the agent and the ongoing stewardship model. The prior question — what a customer actually is, and which system owns which field — is covered separately in One Customer Record, Two Systems, and the agent described here depends on those decisions already being made.

Why this matters

Master data quality is the substrate everything else runs on, so its failures appear as other people's problems. The sales team's forecast is unreliable. Procurement cannot see consolidated spend by supplier. The warehouse picks the wrong item because two records describe the same thing differently. Finance cannot compute customer profitability. Each of these is investigated as a separate issue and each traces back to the same cause.

The costs that are easiest to quantify are usually the least important. Duplicate supplier records are a genuine payment-fraud vector — a fraudulent bank detail change is materially harder to detect when three records exist for the same supplier. Inconsistent item data drives inventory inaccuracy, which drives both stockouts and write-offs. And under GDPR, an erasure or access request cannot be reliably satisfied if you cannot state with confidence which records refer to the same person.

There is a compounding effect too. Every integration, every report, every automation built on top of poor master data inherits the problem and adds its own logic to work around it. Two years of that produces a systems estate where nobody can explain why two reports disagree, and the answer is always the same.

At a glance: what the agent monitors and what it may decide

The supplier bank detail row is the one to internalise. An agent that can update supplier payment details is an agent that can be socially engineered into redirecting your payments. That authority should not exist, however convenient it would be.

What works, and what to be honest about

What works:

Prevention at the point of creation, ahead of detection after it. An agent that warns a salesperson mid-entry that a similar account already exists prevents a duplicate at almost zero cost. Detecting the same duplicate a week later costs a steward several minutes and a merge decision. Weight your effort accordingly — most implementations get this backwards.

A confidence band with three zones. Above the upper threshold, merge automatically with an audit trail. Below the lower threshold, ignore. Between them, route to a steward. The middle band is where the design effort belongs, and its width should narrow as the agent accumulates resolution history.

Reversibility on every automated action. Every merge, standardisation and overwrite must be individually reversible with the prior state retained. This is what makes automated merging acceptable to auditors and to the people whose records are being changed, and it is what allows conservative thresholds to be tightened over time.

One named steward per domain. Customer, item and supplier data need an owner — a person, not a committee. The agent does the work; the steward decides the ambiguous cases and owns the quality metric. Deployments without a named steward accumulate an unattended queue and quietly fail.

Divergence as a visible metric. Count of divergent records, duplicates detected, time to resolution, records created without validation. Once these are on a dashboard someone is accountable for, behaviour changes upstream — which does more for data quality than any amount of downstream cleaning.

What to be honest about:

The agent cannot fix an undefined data model. If there is no agreed answer to whether a group and its subsidiaries are one customer or five, the agent will apply that ambiguity consistently and at scale. Definitional work comes first and cannot be automated away.

Fuzzy matching produces both false positives and false negatives, permanently. There is no threshold that eliminates both. You are choosing which error to prefer, and for master data the right preference is almost always to tolerate duplicates rather than risk wrong merges — a duplicate is an inconvenience, a wrong merge can put one customer's transactions on another's account.

A backlog needs clearing separately, and it is the expensive part. The agent keeps a clean dataset clean. It does not efficiently clean a dirty one, because a large historical backlog is mostly ambiguous cases requiring human judgement. Budget for backlog clearance as its own workstream.

Item data is much harder than customer data. Customers have tax identifiers — a strong, near-unique matching key. Items typically do not. Matching items relies on descriptions, specifications and inconsistently applied internal codes, and automated item de-duplication is correspondingly less reliable and needs a wider human-review band.

Some divergence is legitimate. A customer's billing address differing from their delivery address is not an error. A supplier known by a trading name in the CRM and a legal name in the ERP may be entirely correct. Rules that treat all difference as error generate a queue of non-problems and train stewards to dismiss the queue.

Decision framework: where to start

Run in order. Stop at the first match.

1. Do you have an agreed data model and field-level ownership matrix?
If not, start there — see the companion article. Every subsequent step depends on it, and an agent deployed without it will systematise your current ambiguity.

2. Is there a named steward for each master data domain?
If not, appoint them before building anything. The agent creates a decision queue; a queue without an owner is worse than no queue, because it produces the appearance of governance without the substance.

3. Are duplicates and malformed records still being created daily?
If yes, fix creation first: mid-entry duplicate warnings, tax identifier validation by country, mandatory field enforcement, controlled vocabularies for item attributes. This is cheaper than everything else on this list and has the largest effect.

4. Do you have a significant historical backlog?
Clear it as a defined workstream with a confidence threshold, an audit trail, and a quarantine for the ambiguous remainder. Accept that a residue will persist permanently. Do not attempt this before step 3, or you will be cleaning a dataset that is still deteriorating.

5. Are you able to measure divergence and duplication?
Instrument it before deploying the agent, so you have a baseline. Without one you cannot demonstrate that the agent is working, and these deployments are frequently questioned in month four.

6. All of the above in place?
Deploy, starting with monitoring and detection only — no automated merging — for the first month. Review what it would have merged. Then enable automated action in the high-confidence band, and widen from there as evidence accumulates.

7. Deployed and records still drifting?
The problem is upstream behaviour rather than stewardship. Look at whether people are creating records in the wrong system, whether the owning system's entry process is so cumbersome that it is being bypassed, and whether the ownership matrix is actually enforced by permissions rather than merely documented.

Indicative cost and effort

Assumes one CRM and one ERP instance at mid-market record volumes. Multiple CRM instances following acquisitions, or item masters in the hundreds of thousands, extend these materially. Get a quote for a scoped estimate.

Frequently asked questions

Can the agent merge records without human review?
In the high-confidence band, yes — same tax identifier, same legal name, no conflicting transactional history — provided every merge is logged and reversible. In the ambiguous band it should never merge autonomously, because the cost asymmetry is severe: an unmerged duplicate is untidy, a wrongly merged pair mixes two companies' financial history.

How do we handle the group-and-subsidiary problem?
As a modelling decision, not a matching problem. Decide whether the group is one record with a hierarchy or several linked records, encode that structure in both systems, and then the agent has something unambiguous to enforce. Treated as a matching problem it produces either constant false-positive duplicates or genuine duplicates left undetected.

What about supplier bank details?
The agent detects and flags a change and must never apply one. Bank detail changes require out-of-band verification with the supplier through a known contact — a phone call to a number you already held, not a reply to the email requesting the change. This is one of the most common and most costly frauds against mid-market companies, and automation here would be actively dangerous.

Does this require a separate MDM platform?
Usually not at mid-market scale. An agent operating across your existing CRM and ERP with a defined ownership matrix and a steward queue achieves most of the benefit without introducing another system to maintain. Dedicated MDM platforms earn their cost at larger scale, with many source systems or genuinely complex hierarchies.

How long until we can trust the data?
Creation-side prevention improves things within weeks. Trusting a cross-system number — pipeline reconciled to revenue, consolidated spend by supplier — typically takes two to three quarters, because it requires the backlog cleared plus a period of clean operation before the figures are defensible.

How quickly can the agent be connected to both systems?
The connection itself is fast — a certified implementation partner like Stacksync can have real-time, bidirectional CRM–ERP sync running within weeks, which is exactly the data layer this kind of agent needs. What takes longer is the governance work above: agreeing field ownership and merge rules. Connect the agent to clean definitions, not just clean pipes.

Closing — Next steps

Master data is a maintenance function that most companies fund as a project, which is why the same clean-up gets commissioned every few years. The agent changes the economics of maintenance enough to make it continuous rather than periodic — but only on top of a defined model, an enforced ownership matrix and a named human who owns the ambiguous decisions.

A useful diagnostic that takes an afternoon: count your customer records in each system, attempt a match on tax identifier, and count how many records were created in the last quarter without a valid one. The first number tells you the size of your backlog. The second tells you whether it is still growing — and that determines which step of the framework you actually start at.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• Oracle NetSuite, entity and item record documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• DAMA International, Data Management Body of Knowledge (DMBOK) — master data and data quality dimensions — https://www.dama.org
• European Commission, EU General Data Protection Regulation — data subject rights across systems — https://commission.europa.eu/law/law-topic/data-protection_en
• Agencia Tributaria (Spain), NIF format and validation — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), NIF/NIPC information — https://info.portaldasfinancas.gov.pt
• Atypical Tech engagement experience, mid-market CRM and ERP data programmes across Iberia
• Stacksync, real-time integration and sync platform blog — https://www.stacksync.com/blog