Moving data does not make it reliable
Master data is the relatively stable information your organisation uses: customers, suppliers, products and their attributes. Transactions such as orders and invoices use these records. If an item code refers to the wrong packaging unit, a technically successful transfer may still cause an incorrect delivery.
This guide concerns meaning and quality. For transfer methods, see connecting CRM and ERP through integration or RPA. Process mining instead examines recorded events and what they reveal about a process.
Agree an authoritative source for each field
For necessary fields, define their meaning, authoritative source and the person allowed to approve changes. One system need not own everything. Sales may maintain contact details, finance payment terms, and operations item codes and units. Avoid two systems overwriting each other without an agreed conflict rule.
A blank value is not always an error: a delivery address may be absent because collection was agreed. Distinguish unknown, not applicable and required but missing. Do not fill gaps with plausible AI-generated information. Check the source or ask the responsible person to confirm.
The Government Data Quality Framework starts from fitness for the intended purpose. A fully populated file is not necessarily accurate. This is a framework, not a Dutch legal standard.
Detection, correction and merging are separate decisions
A check can flag a possible duplicate. It does not authorise merging records. Two customers sharing a name may be different organisations; branches may deliberately have separate billing arrangements. A different spelling does not prove that customers are different either.
On a narrow screen, scroll the table sideways. With a keyboard, focus the table and use the arrow keys.
| Signal | Investigate first | Possible next step |
|---|---|---|
| Two customers sharing a name | Identity, branch and arrangements | Keep separate or prepare a reviewed merge proposal |
| An item code with a different unit | Meaning of item, box and conversion | Correct mapping after confirmation from the item-data owner |
| A required field is missing | Source, meaning and processing impact | Hold the record and request missing information |
Separate permission to detect, correct and merge. Show which values would survive and which relationships a proposal affects. Check orders, invoices, contacts and history. Establish recovery with the application administrator; a backup does not guarantee that one incorrectly merged record is easy to restore.
Check existing software first
Required fields, permitted values, import validation and existing detection may be enough. Examine every input route: screens, imports and integrations may behave differently. A warning during manual entry does not prove that a background process performs the same check.
For example, Microsoft documents potential-duplicate detection rules in Power Platform. Concurrently created records may escape detection, and not every processing route displays a detection dialog. This is not a product recommendation or a guarantee that your software offers identical features. Verify configuration and permissions.
Fictional trial: checking a customer and an item
A fictional wholesaler has two CRM records named Northhaven. Its ERP defines item A-17 as a box, whereas an order file expects individual items. Use only fictional records in a separate test environment. The trial does not change production data.
- Have the data owner identify deliberate differences and seeded errors in advance.
- Test a missing required field, customers sharing a name, a valid exception and an incorrect unit. Start with existing validation rules.
- Produce signals and proposed corrections only. A person compares them with the documented expected outcome.
- With the application specialist, examine downstream effects on orders, reports and integrations. Test recovery separately before considering automatic corrections.
Measure missed errors, false alerts and total review and recovery time. Proceed when important errors are recognisable, valid differences remain intact, and responsibility and recovery are clear. Adjust rules that reject many correct records. Stop automatic-change plans if identity or consequences cannot be established reliably. The trial does not demonstrate a general savings percentage.
Keep the improvement manageable
A one-off clean-up does not prevent new errors. Agree who follows up exceptions and retests rules when fields or applications change. Limit access and recording to what the check needs. Keep the reason, old and new values and responsible person traceable under the applicable data arrangements; do not record complete customer files unnecessarily.
Include configuration, any required licences, staff time, review effort and maintenance. Less retyping releases capacity but does not automatically reduce expenditure. Use the automation business-case guide to compare costs and effects over the same period.
Frequently asked questions
Does every record need to be perfect first?
No. Establish the quality the selected process needs and which errors could cause harm. Keep uncertain records out of automatic processing until someone reviews them.
Can AI merge customers automatically?
AI may help propose similar records, but similarity is not proof of identity. Start with rules and human review. Do not give a trial merge permissions just because its suggestions look convincing.
Who needs to be involved?
The data owner, someone familiar with the downstream process and the application administrator. Financial or sensitive data may require additional expertise. Advice, any implementation through Korper, costs and ongoing management are agreed separately.
Where does your data disagree?
Describe one type of data, the systems and the work affected. Do not share real customer records or confidential files.
Discuss your question