Business Partner Conversion and CVI Explained

Business partner (BP) is the unified master data object in S/4HANA covering customers, vendors, and any other party role. CVI is the synchronization framework that keeps the BP tables and the classic customer (KNA1, KNB1, KNVV) and vendor (LFA1, LFB1) tables consistent with each other, because they are two separate data models describing the same real-world entity, linked by a mapping table and a shared number range assignment. The structural fact that explains most confusion: those older tables never disappeared. Pricing conditions, sales orders, FI documents, and years of custom Z-programs still read KNA1 and LFA1 directly, so CVI has to keep populating them every time a BP is created or changed, even though the intended direction in S/4HANA is BP-authoritative, customer/vendor-generated. Anything that writes to the old tables outside that framework produces a business partner that is out of step with the record everyone else in the system is reading.

CVI runs constantly in every S/4HANA system whether anyone thinks about it or not; it fires on every BP create or change. It has to be touched deliberately in three situations: converting existing ECC customer and vendor master data into business partners as part of a system conversion (this is a mandatory, checked simplification item), mass-loading business partners from a legacy or third-party source during a migration, and diagnosing a sync failure where a BP exists but the corresponding customer or vendor role never got created, or vice versa. It is the wrong tool to reach for as a workaround: writing directly to KNA1 or LFA1 through a batch job, an old transaction, or a direct table update in an S/4HANA system bypasses the mapping table entirely and produces an orphaned record that reconciliation reports will flag but that ordinary users will not notice until a sales order or invoice run fails.

Below CVI sit the physical tables: BUT000 and related BP tables on one side, KNA1/KNB1/KNVV and LFA1/LFB1/LFM1 on the other. CVI itself is a middleware layer with its own customizing: synchronization direction, field mapping, and the linkage between BP groupings and customer/vendor account groups. Above CVI sits transaction BP for manual maintenance, the migration cockpit for mass loads, and any BAPI-based custom program that creates business partners programmatically. It replaces the old maintenance transactions XD01, XK01, FD01, FK01, VD01, and VK01, which S/4HANA disables by default. It does not replace account group customizing or number range configuration in FI/SD; it depends on both being correctly linked to BP groupings before any synchronization run is attempted.

A system conversion project inherits an ECC system with roughly forty thousand customer records and fifteen thousand vendor records, none of them linked to a business partner. The readiness check flags the business partner approach as a mandatory pre-conversion item. The team configures CVI with synchronization direction set to customer/vendor-to-BP for the initial load, maps each customer and vendor account group to a corresponding BP grouping, and decides whether to reuse the existing customer and vendor number ranges or generate fresh internal BP numbers. The mass synchronization run then walks the customer and vendor tables and creates a matching business partner for each one, assigning the appropriate customer role and vendor role and copying address and communication data. A reconciliation report compares record counts on both sides and turns up around two hundred customers that failed conversion because of missing country codes or blocked deletion flags; those get corrected and reprocessed individually. Once the counts match, the direction flag is switched to BP-to-customer/vendor so that all further maintenance happens through the BP transaction and the old transactions stay disabled.

On ECC, CVI was an optional add-on installed specifically to prepare a customer and vendor master data set for eventual conversion to business partners. On S/4HANA, CVI is mandatory and always active, and the old customer and vendor maintenance transactions are disabled by default; business partner is the only supported entry point for this master data. The business partner conversion is a fixed, checked item in every system conversion readiness assessment. From a clean core standpoint, any custom master data field should be built as a business partner extension through standard extensibility rather than added directly to KNA1 or LFA1, because CVI mapping already forces the architectural question of where that field belongs, and modifying the standard tables directly works against every clean core upgrade path.

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.