The SAP S/4HANA Business Partner (BP) model merges customer and vendor master data, which were managed separately in ECC, into a single business partner record. The BP transaction replaces XD01 and VD01; calling the old transactions redirects you to BP. At first glance it looks like a screen change, but because it touches the data model it sits on the critical path of every S/4HANA project.
Why a single business partner?
The same company can be both your customer and your supplier. In ECC, its address, bank and tax details were kept in two separate records and drifted apart over time. In the BP model, general data (name, address, contact details, tax number) is stored once, and customer- or vendor-specific data is added through "roles".
BP roles and CVI
- Roles: adding roles such as "FI customer" (FLCU00) and "customer (sales)" (FLCU01) to the same BP opens the accounting and sales views.
- CVI (Customer/Vendor Integration): keeps BP in sync with the classic customer and vendor tables. SD documents still work with the customer number, so this bridge is mandatory.
- Number ranges: having the same BP and customer number makes reporting and interfaces much simpler, so number ranges must be planned before migration.
The path from ECC
- Data cleansing: duplicate, unused and incomplete records are removed before migration. This is the most labour-intensive part of any data migration.
- Pre-checks: postal code formats, tax numbers, email and phone fields are validated against BP rules; faulty records stop synchronisation.
- Configuration: BP groupings, roles, number ranges and field mappings (for example industry, title) are defined.
- Synchronisation: existing customers and vendors are converted to BPs using the synchronisation cockpit, and error lists are worked through one by one.
- Validation: order, delivery and invoice are tested end to end with sample customers.
What to watch on the SD side
- Sales area data (price group, delivery terms, payment terms) must be migrated completely under the role; missing data directly breaks pricing.
- Partner functions (sold-to, ship-to, bill-to) need to be checked again.
- Credit management data also lives on the BP, so the move to FSCM credit management needs its own plan.
- Custom reports and interfaces that read customer master data must be adapted to the BP structure.
Common problems
The most common problem is data cleansing left to the last weeks of the project: thousands of records stuck in the error list put the go-live date at risk. The second is BP and customer numbers ending up different, breaking interfaces and user habits. The third is authorisations: the BP transaction gives access to both customer and vendor data, so segregation of duties must be reviewed.
A Business Partner migration looks like a technical conversion, but its success depends on data discipline. Projects that start cleansing early experience a much calmer go-live.
