SAP S/4HANA Business Partner: who prepares customer and supplier data under RISE with SAP

Organisations signing up to RISE with SAP often assume the move to SAP S/4HANA comes as a package. For customer and supplier master data, it does not. SAP’s Roles and Responsibilities document for RISE with SAP, Private Edition (July 2026 version) lists Customer Vendor Integration (CVI) among the tasks excluded from the service, and states that the system conversion service does not cover activities before or after the technical conversion, preparation and clean-up included. Overall responsibility for the conversion project sits with the customer, who has no privileged access to the operating system.

That work therefore needs its own budget line, either in-house or in the contract with the implementation partner. The calendar adds pressure: on 7 October 2026 SAP announced that SAP Business Suite 7 systems running on a database other than SAP HANA can be converted only until the end of 2030. Mainstream maintenance for SAP ERP 6.0 ends in 2027 and extended maintenance in 2030.

What Business Partner requires before conversion

In SAP S/4HANA, customer and supplier are roles of a single Business Partner object. In SAP ERP 6.0 they are separate master records, usually maintained for years by different departments, each with its own number ranges and code lists. CVI synchronises them with the new model.

The Simplification List for SAP S/4HANA 2025 makes Business Partner mandatory; conversion cannot proceed without functioning CVI. The Simplification Item Check stops Software Update Manager on return code 12 at the start of the process, and on code 8 or above just before downtime. Every customer, supplier and contact person in every client of the system has to be converted. SAP recommends running the synchronisation weeks or even months before the conversion, off its critical path.

What the SAP tools leave to the project

CVI and SAP S/4HANA Migration Cockpit apply rules that the project has to define. They cannot tell whether two records describe the same company, whether a customer that is also a supplier should become one Business Partner with two roles, or which records that have been dormant for years should be left behind.

Duplicates held under several numbers arrive as several Business Partner objects. A customer that is also a supplier becomes two objects unless someone takes a design decision. Missing mandatory fields reappear as errors in trial loads and during cutover. Code lists that differ between group companies can be mapped, but only once somebody has defined the mapping.

On the new-implementation path, Migration Cockpit creates records rather than updating existing ones. SAP also warns that migrating personal data which should have been deleted may amount to processing without a legal basis.

Where the effort goes

No public source breaks down the effort of preparing customer and supplier data by stage. Three reference points recur: a Business Partner conversion usually takes four or five runs; one data quality vendor reports duplicate rates of 16-17% in customer and supplier files; and the production conversion itself takes anywhere from a few hours to a full day.

Effort is driven mainly by the number of records that need a human decision and by how long each decision takes. Take 80,000 customer and supplier records, of which 16% need review: that is 12,800 decisions. At two minutes each, the work comes to 427 hours; at five minutes, 1,067 hours. With a spread that wide, the budget for this part of the programme should rest on a measurement of the organisation’s own data.

SNOK expert estimate: 28.5-46.5% less effort

The ranges below are SNOK’s expert estimate of how SNOK MDM changes the effort at each stage. They are derived from how the platform works, not measured on past projects, and we test them in a pilot on the organisation’s own data.

Stage	Estimated change in effort
data profiling	-50 to -70%
matching and merge rules	-40 to -60%
mapping to Business Partner	-10 to -20%
validation rules	-20 to -40%
business sign-off	-30 to -50%
trial loads	-20 to -40%
fixes	-40 to -60%

Applied to an illustrative split of effort (profiling 10%, matching 15%, mapping 20%, validation 10%, sign-off 15%, trial loads 15%, fixes 15%), the estimate gives a reduction of 28.5-46.5% in total effort. Matching and fixes contribute most, 6-9 percentage points each: rules resolve unambiguous matches, so only the ambiguous ones reach a data steward, and fewer errors survive into the trial loads. Mapping contributes least, because the project team still has to design the Business Partner structure. The estimate does not include any gain from AI assistance.

How SNOK MDM fits into the programme

SNOK MDM is our master data management platform. It builds an agreed record for each customer or supplier, the golden record, from data held in SAP ERP 6.0, SAP S/4HANA and non-SAP systems, without replacing the ERP.

Standardisation. Legal form embedded in the name or held in its own field, addresses in different layouts, VAT numbers with or without the country prefix: standardisation rules and the code lists in the miniRDM module reduce these to a single form. The value mappings CVI needs are maintained in the same place and apply on every run.

Matching with a person in the loop. Deterministic rules agreed with the domain owner resolve unambiguous matches. Ambiguous ones go to a data steward, because merging two different companies by mistake can have serious operational consequences. The audit trail records the author, date and reason for every change made in the platform.

Checks against Polish registers. During implementation we configure the agreed checks against the Polish VAT taxpayer whitelist, VIES, the KRS company register and the REGON business register. Each result is stored against the record with its date. Business Partner data also feeds invoices issued through KSeF, Poland’s national e-invoicing system, so an incorrect tax number is repeated on every invoice.

Hand-over to SAP S/4HANA. In a system conversion, we clean up the data in SAP ERP 6.0 before CVI is configured. In a new implementation, the golden record is the source for loading. Depending on how the RISE contract and the implementation partner’s contract divide responsibility, we either supply the data in SAP S/4HANA Migration Cockpit format or carry out the load ourselves.

After go-live. New customers and suppliers pass through the same rules, register checks and steward decisions that applied during migration. Keeping the data in good order still takes rule maintenance and steady exception handling by data stewards; the platform gives them the same tools they used in the migration.

Current and planned AI capabilities in SNOK MDM

Today, an AI assistant in SNOK MDM helps write validation rules and, for customer and supplier data, maps the headers of source files to the data model. Record matching remains deterministic. Planned capabilities include explaining where a value in a record came from, grouping exceptions after each run, and pointing a data steward to additional records worth comparing when a match is ambiguous.

A rule proposed by the assistant takes effect only once a person has approved it. Whether two records refer to the same organisation is decided by deterministic rules or by a data steward, not by a language model. The quality of migrated data also matters for any AI application that later uses it: assistants and agents working on SAP S/4HANA can only answer from the records that came across in the migration.

Decisions to take before the first trial conversion

A business owner for the data. Someone in the organisation needs the authority to decide whether two records should be merged, blocked or left out of the migration. Without that person, the decisions fall back on a project team that does not know the trading history.

A baseline before the path is chosen. Completeness of critical fields, the scale of duplication and consistency with public registers all bear on the choice between system conversion, new implementation and a selective transition, so they are worth knowing before the contract with an implementation partner is signed.

Responsibilities written into the contract. Under RISE with SAP, the contract with the implementation partner should refer to SAP’s Roles and Responsibilities document and state who runs CVI, who cleans up the data and who analyses the errors after each run.

Rules approved before the first run. Matching and merge rules, the mapping of account groups to Business Partner groupings and completeness rules for each role should be signed off by the domain owner before the first synchronisation.

Register checks. Customers and suppliers are best checked against the Polish VAT whitelist, VIES, KRS and REGON before loading, with a decision on which system takes over those checks after go-live.

A change process from day one after go-live. Its absence is one of the ten risks on the report’s risk map: it surfaces in the first months of operation and takes the data back to where it was before the migration.

The full report

These questions are covered in depth in our report “Business Partner as a prerequisite for SAP S/4HANA”: 50 pages and 16 figures. It sets out the CVI sequence with the relevant SAP transactions and the common categories of synchronisation errors, and covers materials, financial data and employees as Business Partners. It also includes a master data governance model with roles and quality measures, the effort model with a worked example, a map of ten risks, questions for the board, a 90-day plan and a readiness checklist.

The report is free; we send it by email once you have completed a short form: download the report.

Starting with a measurement

Profiling in SNOK MDM does not depend on having chosen a transition path or an implementation partner. We agree the scope of the diagnostic workshop before it starts: which group companies, which critical fields, the duplicate analysis and the register checks available. A pilot typically runs for four to eight weeks once the agreed data is available, with deliverables defined at the outset, and its results let us test our estimate against the organisation’s own data.

The platform is described on the SNOK MDM page and the service on our Master Data Management page; the technical side of the move is covered on our SAP S/4HANA conversion services page. We have also written about the limits of SAP Readiness Check and securing an SAP S/4HANA conversion under RISE.

To discuss your customer and supplier data, contact us.

This article and the report were prepared by Michał Korzeń, CTO of SNOK, with the SNOK team, using large language models. The authors checked and approved all facts, figures and conclusions. The cover image was generated with AI.