Master data management software keeps the records your business runs on, customers, suppliers, materials and products, consistent across every system that holds a copy. At Lleverage we think the deciding question for a mid-sized manufacturer is not which product has the better data model, but whether you have the data stewards to feed it, because traditional MDM assumes a team that most SMEs simply do not employ.
The failure everybody recognises looks like this. A customer changes its VAT number. Finance updates it in the ERP. Sales never hears, so the CRM still carries the old one. Six weeks later an invoice is rejected by the customer's own compliance check, and somebody spends an afternoon working out which of the three records is the real one. Nothing was broken. There was just no mechanism to keep three copies of the same truth in agreement.
This piece compares the two ways of solving that in 2026, the classic MDM suite and the AI agent, and sets out where each one earns its place. We build these agents for manufacturers, processors and wholesalers, usually starting from the pain of one specific record type rather than from a data model, and the master data management work below reflects that. If you want it applied to your own systems, book a demo.
What is master data management software?
Master data management software is the layer that defines one authoritative version of each core business record and keeps every connected system aligned to it. It covers four things: a model for what a customer or material record must contain, matching and deduplication, validation rules, and a distribution mechanism that pushes the agreed version out to the ERP, the CRM and everything else.
Master data is the stable, shared data your processes reference, as distinct from the transactional data your processes generate. A sales order is transactional. The customer it belongs to, with its delivery addresses, payment terms, VAT registration and credit limit, is master data. A production run is transactional. The material specification it consumes is master data.
The reason this matters more in manufacturing and process industries than in most sectors is the volume of attributes attached to a single material. A chemical or food ingredient carries composition, allergen declarations, hazard classifications, shelf life, storage conditions, packaging variants and customer-specific specifications. Those attributes appear in the ERP, the quality system, the label printer and the customer portal, and every one of them is a place the copies can drift apart.
Poor data quality carries a cost that is widely quoted and worth quoting accurately. In its 2020 Magic Quadrant for Data Quality Solutions, Gartner asked 154 reference customers what poor data quality cost their organisation, and the average answer was 12.9 million dollars a year. That figure is self-reported by large enterprises rather than measured, so treat it as an order of magnitude rather than a benchmark, but it tells you which direction the arrow points.
What does traditional master data management software do?
Traditional MDM software builds a golden record. You define the data model, connect the source systems, set the survivorship rules that decide which system wins on each field, and the suite maintains a central master that is then syndicated outward. Around that sit workflow screens for data stewards, who review matches, resolve conflicts and approve new records.
The engineering is mature and the products are good at what they do. Informatica, Stibo, Semarchy, SAP and Oracle all ship capable multidomain suites, and if you have several million customer records across a dozen acquired systems, a golden-record architecture is the correct answer. The design assumes scale, and at scale it repays the effort.
The problem for a company of 200 to 2,000 people is not the licence. It is the operating model that comes with it. A golden-record programme needs somebody to define the model before it can start, which is a project measured in months, and it needs stewards to run the exception queue afterwards, which is a permanent headcount. The software does not remove the manual work. It organises it, and then it hands it to a person to do.
That is the trade we see companies walk into without pricing properly. The implementation gets budgeted. The steward who ends up spending half a week clearing a match queue does not, because that cost lands quietly inside an existing team.
How do AI agents handle master data differently?
An AI agent does not start by building a central master. It reads the records in the systems you already have, compares them, works out which one is right by checking against source evidence, corrects the divergence and writes the correction back to every system that holds a copy. The reconciliation becomes continuous work done by a system, rather than periodic work done by a steward.
The mechanism is the same one that makes agents useful on documents. When a customer record differs between Salesforce and SAP, the agent can check the VAT number against the official register, read the last signed contract for the payment terms, and resolve the conflict with evidence rather than by applying a survivorship rule that says "CRM always wins". Survivorship rules are a proxy for knowing which is correct. The agent can often simply find out.
On the master data figures we publish ourselves, data sync runs at an 80 percent reduction in manual effort. The same page puts the freed capacity at 8 FTE a week, redirected out of manual data entry into work that needs judgement. Those are our own numbers on our own product page rather than an independent benchmark, and we say so.
Xpol, a Dutch fresh flower wholesaler, is the case we point at when someone asks what this looks like in a company of 25 to 150 people. Their agent codifies 25 customer-specific rulesets, unit conversions, weekday-specific label text and multi-depot splits, that previously lived in the head of a specialist about to retire. Xpol's published story records roughly 20 minutes of manual work saved on each large order, across 150 orders a week. That is master data work in everything but name, and it was solved without a data model or a steward team.
"It's a matter of building trust in the organisation with these kinds of initiatives. You can't just throw something like this over the fence."
Cees Maaskant, General Manager at Xpol. The full account is in the Xpol customer story.
AI agents vs traditional MDM software: how do they compare?
The two approaches solve overlapping problems from opposite ends. Traditional MDM fixes the architecture and then asks people to maintain it. Agents fix the maintenance and leave the architecture where it is. Neither is universally right, and the table below is the comparison we actually walk customers through.
| Traditional MDM suite | AI agents | |
|---|---|---|
| Starting point | Define the data model and survivorship rules | Read the records that exist today |
| Central master | Yes, a golden record is created | No, the existing systems stay authoritative |
| Conflict resolution | Rules decide which source wins | Evidence is checked, then the record is corrected |
| Ongoing effort | Data stewards clear a match queue | Corrections teach the agent, queue shrinks |
| Time to first value | Months, after the model is agreed | Weeks, one record type at a time |
| Handles unstructured input | No, structured feeds only | Yes, contracts, emails, certificates, specifications |
| Audit trail | Strong, built into the workflow | Strong, every change logged with its reasoning |
| Best fit | Millions of records, many acquired systems | 2 to 10 systems, no steward team, high attribute complexity |
| Weakness | Cost and permanent headcount | Needs supervision before it earns autonomy |
The row that decides most SME cases is the fourth one. In a traditional programme, the exception queue is the steady state, and its size is roughly proportional to how much your data changes. With an agent, each correction a person makes is retained and applied to the next record of the same shape, so the queue is designed to shrink. Whether it shrinks fast enough is a fair question to put to any vendor, including us, and the answer should be a measured correction rate over time rather than a claim.
Our position is that for a company running a handful of systems, the agent approach wins on economics rather than on capability. A golden-record suite can do things an agent cannot, particularly hierarchy management across a large acquired estate. Most SMEs do not need those things and cannot staff them.
Where does bad master data actually cost you money?
Bad master data costs money in four places: duplicate purchasing from duplicate supplier records that a procurement agent would otherwise catch, rejected invoices and shipments from wrong registration or address data, production and labelling errors from stale specifications, and the compliance work of proving your records were correct at a point in time.
Duplicate purchasing is the one finance notices first, because the same material is bought twice under two part numbers at two different prices and the variance shows up in margin. Rejected documents are the one that reaches the customer, since an invoice carrying a stale VAT registration fails the recipient's own validation and comes straight back.
The third is the expensive one in process industries. A specification that is current in the quality system but stale in the ERP produces a label or a certificate that does not match what is in the drum, and in food and chemicals that is a recall conversation rather than a data conversation. This is why we treat master data in those sectors as an operational control rather than a governance exercise.
The fourth is becoming harder to avoid on a schedule that is already published. Under the EU's VAT in the Digital Age package, adopted by the Council on 11 March 2025, electronic invoicing to the European standard becomes mandatory for intra-Community business-to-business transactions from 1 July 2030. Structured invoices are validated by machines rather than read by people, which means a registration number or an address that is merely nearly right stops being a minor annoyance and starts being a rejected document. Companies with clean master data will not notice that transition. Companies without it will.
Which approach does an SME actually need?
If you run between two and ten connected systems, have no dedicated data stewards, and your pain is records drifting apart rather than records not existing, agents are the better fit. If you carry millions of customer records across systems inherited from acquisitions, and you already employ people whose job title contains the words "data governance", a traditional MDM suite is doing work an agent will not replace.
The honest middle case is a company that needs both, in sequence. Getting the day-to-day divergence under control with agents first is cheaper and faster, and it produces something a later governance programme would otherwise have to buy separately: a record of where your data actually goes wrong, by system and by field, gathered from real corrections rather than from a discovery workshop.
Three questions usually settle it in a first conversation:
- Who clears the exception queue today, and what else is that person responsible for? If the answer is "nobody, we notice when it breaks", a steward-based product will not be staffed and will not be maintained.
- How much of your master data arrives as unstructured input, in supplier specification sheets, certificates, contracts and emails? The more it does, the worse a structured-feed architecture performs.
- What has a data error actually cost you in the last year? If the answer is a recall, a rejected shipment or a customs delay, this is an operations problem with a data cause, and it should be scoped as one.
The same reading-and-deciding layer that keeps records in agreement also runs the document data extraction that feeds them, which is why teams that start with one usually end up with both. Both write into the systems you already run, through the same ERP and CRM integrations.
How do you start without an eighteen-month programme?
Pick one record type and two systems, and fix the divergence between them before touching anything else. Customer records between the ERP and the CRM is the usual starting pair, because the divergence is measurable on day one and the business impact of a fix is quick to demonstrate.
The sequence we use:
- Run a comparison across the two systems and count the disagreements. This is a read-only exercise and it is often the first time anyone has seen the number.
- Classify what you find. Genuine conflicts, stale copies and formatting differences need different handling, and the proportions tell you what kind of problem you have.
- Let the agent propose corrections while a person approves each one. The approval rate over the first weeks is your evidence, and the corrections are its training.
- Move the confident categories to the background, where the agent corrects and syncs without asking. Formatting and stale copies usually go first, genuine conflicts stay supervised longest.
- Add the next record type. Suppliers and materials tend to follow customers.
The thing not to do is agree the enterprise data model first. It is the step that makes an MDM programme feel rigorous and it is also the step where eight months disappear, because agreeing what a customer record should contain turns out to require the whole company in a room. Start with the records you have and the disagreements between them, and the model that emerges is the one your business actually uses.
Frequently Asked Questions
What is the difference between master data management and data governance?
Master data management is the practice and the systems that keep core records consistent across your estate. Data governance is the wider set of policies, ownership and accountability around all data, including who may change what and how it is classified. MDM is one of the mechanisms governance uses, not a substitute for it.
Do we need master data management software if we only run one ERP?
Usually less of it than a multi-system company, but rarely none. Single-ERP businesses still hold master data in a CRM, a quality system, a webshop and spreadsheets on a shared drive. The divergence moves rather than disappears. What changes is the scope: you are reconciling satellite systems against the ERP rather than arbitrating between peers.
Can AI agents replace data stewards entirely?
No, and we would be careful with any vendor claiming otherwise. Agents remove the volume work of comparing, correcting and syncing, and they escalate genuine conflicts that need a business decision. Somebody still owns the decision about which payment terms a customer gets. The steward's job shifts from clearing a queue to resolving the residue.
How does master data management affect e-invoicing compliance?
Structured e-invoices are validated automatically, so registration numbers, addresses and tax identifiers must be exactly correct rather than approximately correct. Under the EU's ViDA package, e-invoicing to the European standard becomes mandatory for intra-Community B2B transactions from 1 July 2030. Clean master data is what makes that transition uneventful.
How long does master data management software take to implement?
A traditional MDM suite is typically a multi-month programme, because the data model has to be agreed before the build starts. An agent-based approach on one record type and two systems is a matter of weeks, since it works from the records that already exist. Scope, not technology, sets the difference.
Get your records to agree with each other
Master data problems rarely announce themselves. They arrive as a rejected invoice, a duplicate purchase order, or a label that does not match the drum, and the data cause is found afterwards. If your teams are reconciling the same records by hand every week, the constraint is not discipline, it is that nothing is doing the comparing.
That is the work we automate, one record type at a time. To see it against your own systems, book a demo.