Business Partner Conversion and CVI Explained

Business Partner is the central master object for persons, organizations and groups in S/4HANA, while classic customer and supplier views/tables still exist because SD, FI, purchasing and many applications consume those application-specific roles. Customer/Vendor Integration (CVI) is the synchronization and mapping framework that keeps the BP identity/roles aligned with customer and supplier master representations. It manages number/grouping/account-group mapping, field mapping, partner links and synchronization processes. The important architectural point is that BP is the leading master concept in S/4HANA, but the synchronization framework itself is not accurately described as a permanently one-way pipe. Conversion and supported operational scenarios can synchronize from existing customer/supplier data into BP and can propagate BP/customer/supplier changes according to the configured process.

CVI is mandatory preparation for an ECC-to-S/4HANA system conversion because existing customers and suppliers must have corresponding Business Partners and consistent links before conversion. It is also central to migrations, mergers, master-data replication and troubleshooting cases where the BP exists but a required customer/supplier role or organizational segment is missing. In live S/4HANA, master-data governance should be BP-centric and use supported BP/customer/supplier APIs and transactions; CVI reconciliation tools then prove the linked representations remain consistent. Direct updates to KNA1/LFA1/BUT* tables bypass the framework and are never a supported synchronization strategy.

At the persistence level, BUT000 and related BP tables hold Business Partner data, while KNA1/KNB1/KNVV and LFA1/LFB1/LFM1 represent customer and supplier application views. CVI link tables associate the identities and synchronization customizing maps BP groupings to customer/supplier account groups, number ranges and fields. BP transaction/apps and released migration/API tools sit above this model. During conversion, existing customer/supplier masters can be synchronized into BP; after go-live, BP is the leading entry/master concept, while application-specific customer/supplier views continue to be maintained through the supported synchronization framework.

A brownfield conversion has 60,000 customers and suppliers with no complete BP linkage. The project configures grouping/account-group and number-range mappings, runs CVI consistency checks, cleans invalid addresses and mandatory-field gaps, and then synchronizes existing customer/supplier records to create or link the required BPs. Reconciliation confirms one-to-one/mapped identity before the S/4HANA conversion. After go-live, new master maintenance is performed through BP/released APIs, while CVI keeps the corresponding customer/supplier application views synchronized. If a legacy interface still changes a customer-side representation through a supported process, the team validates how that change is synchronized rather than assuming the framework is permanently one-directional.

For S/4HANA, Business Partner is the mandatory central master approach for customer and supplier integration and the conversion checks require consistent BP/customer/supplier relationships. CVI remains the synchronization framework beneath that model. Existing customer/supplier application structures continue to be relevant, but new clean-core master-data integrations should use released BP/customer/supplier APIs and supported synchronization rather than direct classic-table maintenance. Always validate synchronization behavior against the actual target release and application scenario instead of assuming one universal direction.

The functional master data lead owns account group design, BP role assignment, and number range strategy. The architect owns the synchronization direction decision and the reconciliation approach across the landscape. The developer builds any custom field mapping and mass load logic. Handover should include the number range assignment table, the audited list of custom fields with their BP mapping decision, and the reconciliation report from the last synchronization run.

Read the simplification items page for context on how business partner conversion is presented and checked during a readiness assessment, since it is one of the most consistently flagged items in that process. Read the migration path comparison to understand how the timing and mechanics of the conversion differ between a brownfield system conversion, a greenfield rebuild, and a selective data transition, since each path treats CVI configuration and mass loading differently.