Datanovel know-how

Plan vendor data cleansing around the work that matters

Identify the businesses, define the target and organise the work before committing the team.

A vendor file with thousands of records can conceal a very different number of legal entities and a mixture of straightforward corrections and difficult supplier enquiries. Planning at record level alone can duplicate effort and hide the activities that determine the deadline.

1. Establish the supplier behind the records

Begin by connecting records to legal entities across the systems in scope. Use appropriate registration identifiers, names, addresses and other corroborating information. Retain identifier types and jurisdictions, and separate confirmed matches from cases requiring investigation.

Assign cleansing work around the supplier and its connected records where appropriate. This avoids several people asking the same business for the same information, makes shared evidence reusable and provides a more realistic view of workload.

The mapping also provides a record of where a confirmed change must be reflected. It need not assume that all operational attributes will become identical.

2. Decide what still needs to be retained

Ask procurement which suppliers remain necessary. One-time suppliers, dormant relationships or records superseded by an existing arrangement may not all need the same cleansing effort.

Record deactivation decisions against the affected system records. Before excluding them from migration or remediation, establish how open orders, invoices, balances and other obligations will be handled. A supplier marked as no longer needed may still have transactions that must be completed.

Distinguish a proposal from an approved action. This prevents a planning exercise from unintentionally removing the data needed for operational continuity.

3. Separate necessary and unnecessary duplicates

Multiple records may support locations, currencies, payment arrangements, tax treatments, approval routes or several source systems. Retain the operational reason and define a reliable link to the shared entity.

Unnecessary records may have arisen because an old supplier name could not be found, because several teams can create suppliers, or because an earlier operational need has disappeared.

Where a redundant record still carries open transactions, a temporary link and migration may be required so those transactions can close. Define the exit condition and owner; do not leave a temporary exception to become permanent by default.

4. Segment the work by dependency

Use categories that distinguish the work needed, rather than treating all suppliers as equal-sized tasks. The following segmentation is a starting point to adapt with procurement and finance.

Illustrative work groups; priorities depend on business exposure
GroupWork neededPlanning implication
APayment information needs confirmation or correction.Allow time for the approved verification and review process.
BContacts need attention, without payment-data issues.Establish a reliable route to the supplier before other requests depend on it.
COther information needs supplier clarification.Plan requests, follow-up and specialist review where needed.
DEvidence is available; agreed corrections remain.Prepare controlled transformations, updates and quality checks.

Suppliers in the first three groups may also need the corrections described in Group D. Avoid double counting the shared work when estimating effort.

Prioritise by transaction exposure, criticality, deadline and expected response difficulty. Supplier complexity, access to the right contact and the importance of the relationship may affect elapsed time. Treat these as factors to investigate, rather than relying on a universal response-rate rule.

5. Define the target data map and relationships

The standard supplier profile in an ERP or procurement system is a set of available fields. It is not a specification of how your organisation should use them.

For every required element, define its purpose, supplier applicability, accepted source, quality rule, owner and target field. Map legacy fields to target fields, specify transformations and identify unused fields. Separate supplier-provided facts from internal classifications and approval decisions.

Address local requirements through the intended process. Registration identifiers, payment formats and required addresses vary. Do not apply one country's assumptions to every supplier.

Document links between records for the same entity, necessary duplicates, temporary records retained for open transactions, entities in a supplier group and corresponding records in other systems. Define which fields should synchronise and which must remain different. Use supported structures or an approved mapping with the platform team.

6. Estimate effort and calendar time separately

Break the work into activities: entity investigation, contacting suppliers, chasing responses, checking evidence, updating records, independent review and coordination. Estimate case volumes and handling time for each activity, then allow for the team's actual availability.

Illustrative workload: activity volumes can refer to the same suppliers at different steps
ActivityVolume × minutesHours
Identity investigation600 × 20200
Supplier requests600 × 10100
Follow-up contacts1,200 × 5100
Record updates1,200 × 10200
Record review1,200 × 5100
CoordinationAgreed allowance100
Total800

Illustrative capacity calculation: 800 hours divided by 35 productive hours per person per week over four weeks equals approximately 5.7 full-time equivalents. The result depends on the case mix, time assumptions and actual availability; it is not a general staffing benchmark.

This calculation does not mean that a supplier enquiry taking ten minutes can be completed ten minutes after it is sent. Response delays and approval dependencies consume calendar time. Model them separately from hands-on effort.

Use ranges for uncertain activities and show how the plan changes if responses are slower or complex cases are more frequent. Capacity released from other work must actually be available to this programme.

7. Calibrate the plan with early work

Begin enough long-lead cases early to test contact routes, supplier response and review effort. At the same time, assign a sample of simpler cases to establish realistic update and checking times.

Review the evidence from this first work period. Rebalance the team between supplier-dependent cases and corrections that can proceed from existing evidence. Escalate a resource gap early or agree which exceptions can remain beyond the deadline.

A staged plan makes these decisions visible. It should not rely on a fixed assumed response rate or an identical schedule for every country and supplier group.

8. Prepare the team and the working environment

Assign clear responsibilities for investigation, supplier contact, updates and approval. Train the team on the target data map and the meaning of the quality rules. Where the work needs specialist knowledge of registration or payment processes, arrange access to that expertise.

Use the client's approved workflow and data tools for assignments, evidence, dependencies and status. Supplier information requests should make the required fields clear and apply appropriate input checks. Connect returned information to the relevant supplier case so it does not have to be assembled repeatedly.

Provide a shared working guide, standard communication, access to approved supporting records and a route for difficult cases. Sensitive changes follow the organisation's verification and separation-of-duties arrangements. Platform access and integrations belong in the delivery plan.

9. Stop the leaking tap

Cleansing will struggle to improve the live data if business-as-usual processes continue creating the same problems. Map where incorrect information is entered, transformed or duplicated, and introduce proportionate controls during the programme.

Some corrections can be handled by an agreed transformation during migration. Other issues require a process change because information is being lost, added without evidence or changed without the necessary review.

Illustrative operational case: a payment process requires information the onboarding process does not collect. Staff improvise a workaround to keep transactions moving. The remediation needs two connected actions: review the affected historical records, and establish an approved collection and verification step for future requests.

Fixing the historical records alone leaves the cause active. Changing the future process alone leaves the existing population unresolved. Assign owners to both.

10. Launch with clear decisions and measured progress

Use the kick-off to confirm the target, responsibilities, priorities, quality criteria and escalation route. Invite the people whose processes will change and make sponsorship visible. The team needs to understand how the work supports operations and the implementation deadline.

Track case progress for day-to-day management and reassess the live data at an agreed cadence. Compare improvements with new and recurring issues, retain the underlying case lists and explain changes in the supplier population.

Prepare concise stakeholder updates showing readiness, bottlenecks, dependencies and decisions needed. Forecast completion using observed progress and stated assumptions; keep a forecast separate from a commitment.

Datanovel can scope, plan and lead this work with your team, implementing the required checks, workflow and reporting on the platforms you already have.

← Explore all vendor master data know-how