# Cleaning supplier and material master data with AI, safely.

> In this field note, veridive explains how to clean supplier and material master data with AI without breaking the ERP. AI finds duplicate candidates using tax numbers, IBANs, addresses and name variants, proposes standard descriptions per material class in Turkish and English, and presents merges with evidence; data owners approve, and changes stay logged and reversible.

Duplicate suppliers and inconsistent material descriptions quietly break matching, reporting and every AI workflow built on top. AI can propose merges and standard descriptions with evidence; data owners approve each change, and nothing merges automatically.

## Key takeaways

- Duplicate suppliers and inconsistent material descriptions break matching and reporting, and often look like model errors in AI workflows.
- AI finds duplicates that rules miss, using tax numbers, IBANs, addresses and legal-form variants, and shows the evidence for each.
- Standardize descriptions from a template per material class, with Turkish and English kept in separate fields.
- Data owners approve every merge; changes are logged and reversible, history stays intact, and checks at creation prevent new duplicates.

An invoice fails to match because its supplier exists three times in the ERP, and the purchase order was raised against a different record than the invoice. The spend report shows one supplier as three smaller ones. A planner searches for an M8 bolt and misses the stock filed as “CIVATA M8X20 GALV”. Nobody decided to have messy master data. It built up one hurried record at a time.

Duplicate suppliers and inconsistent material descriptions quietly break matching, reporting and every AI workflow built on top. AI can help clean them, as long as it only proposes: merges and standard descriptions come with evidence, data owners approve each change, and nothing is merged automatically. Here is how, step by step.

## Why does master data matter for AI projects?

Almost every AI workflow in operations joins records: an invoice to a supplier, an order line to an item, a question to the right account. When one supplier has three records, an invoice and its purchase order can point to different ones, and a correct match looks like a failure. Evaluation sets inherit the mess, and reports count the same company three times.

> What looks like a model error is often three records for one supplier.

So cleansing belongs at the start of the first AI workflow that depends on it, sometimes as a small data project of its own. **Done** looks like an agreed list of which master data the workflow touches and a measured duplicate rate for it. **What goes wrong:** a team tunes prompts for weeks to fix errors that live in the data.

## How can AI find duplicates that rules miss?

Rules catch exact matches, such as two records with the same tax number. They miss the rest: a tax number missing from one record, a typo in the name, “Ltd. Şti.”, “LTD. STİ.” and “Limited Şirketi” for the same legal form, “A.Ş.”, “AŞ” and “Anonim Şirketi” for another, “Mah.” against “Mahallesi” in an address, or Turkish characters lost in a record typed in capitals without them.

The method has three layers. First, normalize with plain rules: Turkish-aware casing, so that I and ı, İ and i are handled correctly, legal forms moved to their own field, and abbreviations expanded. Second, compare only records that share something, such as a tax number, an IBAN, a city or a similar name, so the number of pairs stays manageable. Third, let AI assess each candidate pair and write down the evidence: which fields agree, which differ and why they may still be the same company.

Some evidence cuts the other way. The same trade name with “A.Ş.” on one record and “Ltd. Şti.” on another may be two legal entities in one group, and the tax numbers decide. A shared bank account can belong to a group company or a collection agent. Never merge on name alone.

An illustrative example, a fictional supplier recorded three times:

| Record | Name as entered | Evidence |
|---|---|---|
| **1** | Örnek Ambalaj Sanayi ve Ticaret Ltd. Şti. | Complete tax data and open orders: the proposed survivor |
| **2** | ORNEK AMBALAJ SAN. TIC. LTD. STI. | Same tax number and IBAN as record 1 |
| **3** | Örnek Ambalaj San. ve Tic. Limited Şirketi | No tax number; same IBAN and, once normalized, the same address |

The proposal is one merge: records 2 and 3 into record 1, with every piece of evidence listed and no conflicting field. The data owner approves it, or marks the records as different companies so they aren’t proposed again.

## How do you standardize descriptions in Turkish and English?

Descriptions such as “CIVATA M8X20 GALV”, “Cıvata M8 x 20 galvanizli” and “Hex bolt M8x20 zinc plated” may all describe one item. Standardize in two moves. First, extract attributes into fields: type, size, material, finish. Then generate the description from a template for that material class, so every bolt reads the same way and search finds it. Items with identical attributes under different codes surface as candidate duplicates along the way.

Decide the language policy before generating anything. Keep one standard language per field, with Turkish and English in separate fields rather than mixed in one, and make search handle both spellings of the dotted and dotless i. Each material class gets an owner who approves its template, such as maintenance for spare parts or engineering for components.

## Who approves changes?

The people who own the data: usually a master data team in procurement or finance for suppliers, and the owner of each material class for items. The system proposes; the owner approves, rejects or marks a pair as different. High-confidence groups can be reviewed in batches, the rest one by one. Bank details are outside this workflow entirely: any change to them follows your payment-change verification, never a cleansing proposal.

## How do you avoid breaking history and integrations?

- **Block, don’t delete.** The duplicate is blocked for new transactions and points to the surviving record. Past invoices, orders and payments stay where they are, and reports roll up through the mapping.
- **Use the ERP’s own functions** for merging or blocking where they exist, never direct table edits; our note on [ERP integration patterns](https://veridive.com/insights/ai-erp-integration-patterns/) explains why.
- **Check what else stores the old IDs:** warehouse and e-commerce systems, BI models, bank payment files, marketplace listings.
- **Keep it reversible.** Save the record as it was before each change, with who approved it and when, and a tested way to undo it.
- **Sandbox, then small batches.** Run the first merges on a test copy, then in small, reviewed batches.

**Done** looks like a merged supplier whose history reads correctly in every downstream report. **What goes wrong:** a merge that orphans open orders, or a payment file still pointing at a blocked record.

## How do you keep it clean afterwards?

Prevention beats another cleanup. When someone creates a supplier, the form checks the tax number, IBAN and normalized name against existing records and shows likely duplicates before the record is saved. Required fields are enforced, and new material descriptions are generated from the class template at entry. A periodic scan catches what slips through, and a short owner report shows open proposals and new duplicates created. Clean supplier data also makes spend classification possible, as our note on [AI for procurement](https://veridive.com/insights/ai-for-procurement-teams/) describes.

## Start with one workflow’s records

Pick the master data behind one workflow, measure its duplicate rate, and run proposals past its owner. This is [data and AI foundations](https://veridive.com/services/data-ai-foundations/) work, and it is usually the first step toward the matching and drafting described on the [ERP and enterprise workflows](https://veridive.com/solutions/erp-enterprise-workflows/) page.

## Frequently asked questions

### Can AI clean ERP master data automatically?

It shouldn’t merge or change records on its own. AI is good at finding likely duplicates and inconsistent descriptions that rules miss, and at showing the evidence, such as a shared tax number, bank account or address. A data owner approves each change, the old record is blocked rather than deleted, and every change is logged and reversible.

### How do you find duplicate suppliers in an ERP?

Normalize names, legal forms, addresses and Turkish characters first, then compare records on tax numbers, bank account numbers, addresses and name variants. Rules catch exact matches; AI helps with the rest, such as a missing tax number or a legal form spelled three ways, and explains why two records look like the same company. A person confirms each merge.