The same customer exists three times, and every system knows a different version.
Customer, supplier, and item data live in three worlds at once: in the ERP, in the CRM, and in a handful of Excel files nobody wants to touch. None of the three systems is wrong on purpose. They simply drifted apart over the years.
Changes arrive by email. A supplier reports new bank details, a customer a new billing address, a contact person leaves. Whoever reads the email updates the system they happen to be working in, and moves on. The other two keep the old value. Six months later nobody can say which version is right.
Duplicates appear the same way, because a company gets created a second time with a slightly different spelling. And the consequences do not stay inside the data: dunning runs go to addresses where nobody sits anymore, deliveries go to a closed warehouse, and every report silently counts one company as two.
We decide who owns which field first, then we build the software.
Master data projects fail when they start with a sync. Two systems pointing at each other, without a decision about who owns which field, simply overwrite each other in turns. And the team’s conditions become the specification: bank details never run automatically, every proposal shows its source, and the team maintains the rules itself.
- Define the leading system per field: For every data type and every field it gets decided which system leads. Usually the ERP for commercial fields like payment terms and tax number, the CRM for contacts and roles. Fields without an owner are exactly the ones that drift.
- Deliberately small start: The first scope is one data type and one pair of systems, for example suppliers between ERP and CRM. Narrow enough that the team can check every proposal in the first weeks.
- Clean up the existing data once: The AI employee lists duplicates with both records side by side and deviations field by field. The team works through the list. That is exactly where the real rules become visible.
- Go-live only after the team’s okay: After that the AI employee watches new and changed records continuously. The system goes live once the clerks say: the proposals are right, and I can see where they come from.
80 percent is done by the AI employee. The human decides at two points.
Two things trigger the AI employee. The first is the data itself: it walks through one data type across systems, recognizes the same customer or supplier through a bundle of signals, and reports two kinds of finding, namely duplicates within one system and deviations between systems. The second is the inbox: emails and attached documents are read for reported changes and matched to the right record before anyone types anything.
Every finding becomes a proposal with its source. You can see which email, which document, and which field in which system said what. The clerk releases the change and confirms the duplicate merge. Only then does the AI employee write back, into the system that owns the field, with a log entry that keeps the source. Bank details always go through four eyes.
A supplier writes that the company was renamed after a merger and that invoices go to a new account from the first of next month. A signed change notice is attached as a PDF.
One field is flagged for review: bank details are the field payment fraud targets. Two people check it against the change notice before a single character is written.
That was before, this is today.
This is how master data maintenance ran before, and this is how it runs today with the AI employee. Conservatively calculated, that saves about 80 percent of the maintenance effort per change.
| Before | Today | |
|---|---|---|
| Reported change | Typed into one system by whoever read the email | One evidenced proposal for every affected system |
| Duplicates | Found by accident, usually after an error | Detected through a signal bundle, merged after confirmation |
| Deviating fields | Nobody knows which system is right | Leading system per field, deviations are listed |
| Changing bank details | A matter of convention, sometimes by one person alone | Never automatic, always through four eyes |
| Traceability | No trace of who changed what and why | Every change logged with its source document |
* Savings conservatively calculated: a reported change took 10 to 15 minutes before, because several systems get opened, searched, and typed into, and takes about 1 minute of release on a finished proposal today. Calculated with the lower bound of 10 minutes. At 400 to 800 changes per year that is 60 to 120 hours, so two to three work weeks, and at about 40 euros full cost per clerk hour a mid four-figure amount. The rework for misrouted dunning letters and deliveries is not included, because it honestly cannot be quantified.
How do you build an AI employee like this, technically?
The knowledge from this use case to take away, whether you build with us or on your own:
Reading changes from emails and documents
Reported changes arrive as running text, as a PDF attachment, or as a scan. Language models like GPT from OpenAI or Claude from Anthropic read both and pull out the individual fields: new name, new address, new contact, new bank details. Every field gets its location in the document, so the proposal can be evidenced later.
Finding duplicates through a signal bundle
Exact text matching finds almost nothing in grown data. Müller GmbH, Mueller G.m.b.H., and Müller Gesellschaft mbH are three records for one company. Fuzzy matching therefore compares a bundle: normalized name, address, VAT ID, register number, bank details, contacts, order history. Each signal alone is weak, together they carry a merge proposal.
Rules instead of AI where ownership is at stake
Which system leads for which field is a decision, not a probability. That belongs in a fixed rule, not in a model. The same holds for which fields may be written automatically. Bank details are never on that list.
Integration: the existing systems stay
The AI employee connects to the ERP through the SAP and Microsoft Dynamics interfaces, to sales through the CRM interface, and to Outlook and the Excel files through Microsoft Graph. There is no new master data platform and no migration.
UX: the interface decides adoption
A review screen shows the proposed change and the source side by side, the email or document on the left, the field with old and new value on the right. Critical fields have their own four-eyes release. And the rules have their own view where the team changes them itself. Exactly these three things turned skepticism into approval.
What does it cost in comparison?
Superkind charges per use case. The price grows with data volume, not with headcount. Here is the honest comparison:
| Manual maintenance | MDM software | Superkind AI employee | |
|---|---|---|---|
| Cost | 55,000 to 75,000 € per year for one clerk | Often 50,000 € and more for the rollout, plus license and data stewards | Price per use case, a fraction of a full-time position |
| What is included | The whole comparison, by hand | Governance and rules, but no reading of emails | Reading, comparing, duplicates, proposal with source, write-back |
| Scales with | More staff | License tiers and maintenance effort | Data volume, without new positions |
| Exceptions | Human does everything | Left unhandled | Flagged and sent to a human |
| Rollout | Recruiting and onboarding | A project of several months | 2 to 3 weeks to the first productive version |
The honest comparison is the full cost of data drifting apart: the maintenance itself, the follow-up errors in dunning and logistics, and the report that silently counts one company as two.
What we learned from these projects.
Master data is the most underestimated building block in the whole AI discussion. Companies plan an invoice assistant, a dunning assistant, and a reporting assistant, and then all three trip over the same duplicate suppliers. Nobody gets budget approved for data maintenance, everybody gets it for the use case that fails without it. Our honest advice: do the boring layer first.
The second thing: the fear is never about capability, it is about write access. Nobody doubts that a model can find a duplicate. Teams doubt that in six months they will still know what happened to their data. That is why the source on the proposal is not an extra, it is the entry ticket.
What it is not suited for: If all master data sits in a single system and one person maintains it with discipline, there is nothing to compare. If nobody is allowed to decide which system leads for which field, all you get is a longer conflict list. And a legacy system without an interface and without an export is a wall that should be cleared up beforehand.
