Is CVI mandatory for S/4HANA?

Yes. In S/4HANA the Business Partner is the leading object for customers, vendors and contact persons. CVI must be configured and active before customer or vendor data can be created or loaded; it is a prerequisite of a brownfield conversion and of any greenfield load.

What is a BP grouping?

A customizing setting that determines the number range, the mandatory fields and the allowed roles of a Business Partner. Legacy customer and vendor account groups are mapped to BP groupings during migration; every record must land in a valid grouping and satisfy its required fields.

What happens when one company is both a customer and a vendor?

In S/4HANA it becomes one Business Partner with two roles (FLCU01 and FLVN01). The migration has to detect the duplicates across KNA1 and LFA1 — deterministic and fuzzy matching on name, VAT ID, address, bank account — consolidate them, and produce a cross-reference table from legacy KUNNR/LIFNR to the target PARTNER.

Can a migration tool bypass CVI?

It should not. Loading through BAPIs, IDocs (DEBMAS/CREMAS with CVI active) or OData keeps CVI, number ranges, customizing checks and change documents active. Direct table writes bypass all of them and are a red flag for any SAP architect.

S/4HANA Business Partner conversion (CVI) explained

In SAP S/4HANA, customers and vendors are no longer separate master objects: every one of them must be represented as a Business Partner (BP) with roles such as FLCU01 (customer) and FLVN01 (vendor). Customer Vendor Integration (CVI) is the SAP mechanism that creates and synchronises the BP with the underlying customer and vendor records. In a brownfield migration CVI must be active before any record can enter S/4HANA, and converting ~100,000 customer and vendor records by hand typically takes 800–1,000+ hours.

Updated 3 November 2026 · Visehub

What changes with S/4HANA

In SAP ECC, customer master (KNA1/KNB1) and vendor master (LFA1/LFB1) are separate objects. In S/4HANA everything — customers, vendors, contact persons — must exist as a Business Partner (BUT000, BUT020, BUT021), with roles that connect the BP to the old structures: FLCU01 for the customer FI view, FLVN01 for the vendor FI view, UKM000 for credit, and so on.

Customer Vendor Integration (CVI) is the SAP mechanism that maps customer ↔ BP and vendor ↔ BP, synchronises master data in both directions and enforces consistency — change a BP address and it propagates to the customer and vendor views. In a brownfield migration (ECC → S/4HANA) CVI must be switched on before anything can enter the target. It is non-negotiable, and it is where most conversions get hard.

The six scenarios every conversion hits

Customer + vendor merge. The same company is both a customer and a vendor — common in holdings, intercompany and B2B trade. In S/4HANA it must be one BP with two roles. The migration has to find the duplicates across two tables (deterministic and fuzzy matching on name, VAT ID, address, bank account), consolidate them into one BP candidate, flag discrepancies for a business decision, and produce a cross-reference table: legacy KUNNR + LIFNR → target PARTNER.
BP grouping and number ranges. Groupings are customizing; they decide the number range, the mandatory fields and the allowed roles. Legacy account groups must be mapped to groupings, and every record validated against the grouping’s required fields before the load.
BP category. Person, Organisation or Group — explicit in S/4HANA, implicit at best in ECC. Derived from legacy data and checked against the roles each record carries.
Addresses. The BP has a central address; legacy customers and vendors often had several. Primary and additional addresses have to land in BUT020/BUT021 with country-specific format validation.
Tax numbers per country. STCD1–3 and STCEG map to structured tax-number types per country, each with its own format and checksum (NIP, USt-IdNr, GB VAT…).
Bank data. KNBK/LFBK map to the BP bank structure; IBANs are validated per country and bank keys checked against BNKA.

Why “by hand” costs 800–1,000+ hours

For about 100,000 customer and vendor records the manual effort stacks up: profiling (60–120 h), deduplication logic (80–160 h), mapping to the BP structure (120–240 h), validation rules (80–160 h), business validation by e-mail and Excel (100–200 h), load attempts (150–300 h), rework (100–200+ h). The detailed breakdown is in what data preparation really costs when you do it yourself.

How a data workbench prepares records so CVI accepts them

The division of labour is simple: the workbench prepares, SAP executes. vise DMW reads the customer’s customizing (groupings, roles, number ranges), maps and validates every record against it, simulates the load through the real interface and only then posts via BAPI (BAPI_BUPA_CREATE_FROM_DATA, BAPI_BUPA_ROLE_ADD, CVI_FS_BP_BAPI_), IDoc (DEBMAS/CREMAS with CVI generating the BP, or BUPA_) or OData (API_BUSINESS_PARTNER). CVI synchronisation, module validation, BAdI checks, number ranges and change documents all stay active because the write is done by SAP. The cross-reference table and the reconciliation report are produced natively — they are audit deliverables, not extra work after the migration.

vise FieldMap drafts the field mapping to the BP structure with a confidence score per line; vise LoV-MAP harmonises the values (account groups → groupings, payment terms, countries, reconciliation accounts) across operating companies. People approve every line.

Where to go next

The architecture answers — interfaces, simulation, what the AI touches — are on For SAP architects. The service view is on S/4HANA migration.

Frequently asked

Is CVI mandatory for S/4HANA?: Yes. In S/4HANA the Business Partner is the leading object for customers, vendors and contact persons. CVI must be configured and active before customer or vendor data can be created or loaded; it is a prerequisite of a brownfield conversion and of any greenfield load.
What is a BP grouping?: A customizing setting that determines the number range, the mandatory fields and the allowed roles of a Business Partner. Legacy customer and vendor account groups are mapped to BP groupings during migration; every record must land in a valid grouping and satisfy its required fields.
What happens when one company is both a customer and a vendor?: In S/4HANA it becomes one Business Partner with two roles (FLCU01 and FLVN01). The migration has to detect the duplicates across KNA1 and LFA1 — deterministic and fuzzy matching on name, VAT ID, address, bank account — consolidate them, and produce a cross-reference table from legacy KUNNR/LIFNR to the target PARTNER.
Can a migration tool bypass CVI?: It should not. Loading through BAPIs, IDocs (DEBMAS/CREMAS with CVI active) or OData keeps CVI, number ranges, customizing checks and change documents active. Direct table writes bypass all of them and are a red flag for any SAP architect.