Business Partner in S/4HANA: what changes and where data quality breaks

In SAP S/4HANA, customer and vendor become roles of a single object, the Business Partner (BP), and every customer and vendor master record must be converted to a BP as a prerequisite for the ERP conversion. General data is shared across roles, the BP becomes the entry point, and Customer/Vendor Integration (CVI) keeps the old tables in sync. Data quality breaks on the decisions nobody made before the conversion: what to merge, who owns the shared data, how to number records and what to leave behind.

"Just grab the customers and vendors and move them to S/4."

I heard versions of that sentence many times during the years I implemented SAP. Anyone who has opened transaction BP after a conversion run that way knows the result: the same company shows up twice, once from sales and once from procurement, with different addresses, and nobody can say which one is right. The system did what it was told. The decision was simply postponed.

This article is for teams moving from SAP ECC to SAP S/4HANA, or already live and struggling with BP master data. I will keep three things apart: what SAP documents, my operational reading, and what I recommend deciding upfront. Some examples come from Brazil, where I work, and I will explain the local context when it matters.

What is a Business Partner in SAP S/4HANA?

According to SAP, the Business Partner is the central master data object for all natural and legal persons with whom your company has a business relationship. The definition is in the "Creating Business Partners" lesson of the SAP Learning course on purchasing in SAP S/4HANA. The same lesson states that BP data is maintained with transaction BP or with the corresponding apps in the SAP Fiori launchpad.

SAP is also explicit about the prerequisite: in an SAP ERP to SAP S/4HANA conversion project, all customer and vendor master records in the system have to be converted to Business Partners. That is in the "Working with Business Partners" lesson, also on SAP Learning.

If you want a quick refresher on master data terms first, the 4MDG glossary covers them.

What changes for customer and vendor master data?

The logic of the record changes. In ECC, customers and vendors were separate records, maintained through the old customer and vendor transactions. In S/4HANA, the company is created once as a BP and receives roles. Here are the points SAP documents.

General data is shared

SAP states that the general data of a Business Partner is shared across different roles, such as customer and vendor. Name, address and identification become one record for both sales and procurement.

One BP, several roles

A single BP can hold roles such as Customer, FI Customer and Vendor. On the procurement side, SAP lists the Supplier (FLVN01) and FI Vendor (FLVN00) roles. Supplier data sits on three levels: general data (client level), accounting data (company code) and purchasing data (purchasing organization).

The category defines the fields

The BP category (person, organization or group) determines which fields are available. Loading a record with the wrong category is more than a wrong label: it changes what can be filled in.

Multiple addresses and time dependency

In ERP 6.0 there was one address per master record. For the BP, SAP documents support for multiple addresses and for time dependency of attributes and relationships.

Numbering, groupings and the same number

According to the "Manage Customer/Vendor Integration" lesson, BP groupings determine number ranges. Customer and vendor account groups must be linked to BP groupings. Ranges can be internal or external, and there is a "same number" option to keep the same number on the BP and on the customer or vendor. The assignment is one to one: each customer or vendor maps to one BP, and a customer and a vendor can also be assigned to the same BP.

The BP becomes the entry point and CVI synchronizes

CVI ensures that when a BP is created or changed, the customer and vendor tables are updated automatically. You maintain the BP, and the system populates and synchronizes the required fields in the corresponding customer or vendor record.

External interfaces need a new target

SAP advises external applications to use the RFC module RFC_CVI_EI_INBOUND_MAIN to create and update Business Partners. Any interface that used to write straight into customer or vendor records has to be reviewed.

Where does master data quality break in the BP conversion?

From here on, this is operational reading, not SAP documentation. These are seven points where missing decisions tend to show up after go-live, especially with Brazilian master data.

1. The same company as customer and vendor

Many companies buy from and sell to the same partner. In ECC, that usually meant two records. Since BP general data is shared across roles, the natural outcome would be one BP with two roles. If nobody decides to merge them, you end up with two BPs for the same company, each with its own address and history. In Brazil, the shared key is usually the CNPJ, the national registry number that the Brazilian federal revenue service (Receita Federal) assigns to legal entities.

2. Headquarters and branches

In Brazil, each establishment has its own CNPJ. Headquarters and branches share the root (the first eight characters) and each one has its own sequence number. The question to answer before loading is: one BP per establishment, or another model? The choice affects invoicing, tax receipts and reporting. There is no single right answer, but there has to be a written decision.

3. Who owns the shared general data

If address and tax data are one record, procurement and sales now touch the same thing. Without a defined owner, a buyer fixes a delivery address with the vendor in mind and changes what billing uses for the customer. This point often turns into a dispute between departments.

4. Numbering and groupings versus old account groups

ECC account groups must be linked to BP groupings. If the old groups were created without clear criteria over the years, the mapping inherits the mess. The decision to keep the same number or not affects reports, interfaces and user habits.

5. Inactive and blocked records

SAP requires all customer and vendor records in the system to be converted. That makes it even more important to deal, before the conversion, with records that should not stay alive: vendors with no activity for years, blocked customers, records created by mistake. My recommendation is to handle whatever can be archived in ECC, under documented criteria, and not load it as if it were active.

6. Interfaces that wrote directly to customer and vendor

Supplier portals, CRM, e-commerce, onboarding tools. Anything that created or changed customers and vendors from outside now has to come in through the BP. SAP points to RFC_CVI_EI_INBOUND_MAIN for that. A forgotten interface means records entering without rules.

7. Alphanumeric CNPJ (Brazil only)

This rule applies only in Brazil. The Receita Federal has established that, starting in July 2026, the alphanumeric CNPJ applies exclusively to new registrations, under IN RFB nº 2.229/2024. The CNPJ keeps 14 positions: 8 for the root, 4 for the sequence and 2 check digits. Entities already registered keep their number. The Receita Federal itself tells companies to adapt their systems. For BP master data, my recommendation is to review fields, validations and custom programs that treat the CNPJ as a number before the conversion locks those rules in.

What should be decided before the conversion, and by whom?

The table below is a working summary. The "who decides" column is a suggestion; each company adjusts it to its own structure.

Break point	What happens if nobody decides	What to decide upfront	Who decides
Same company as customer and vendor	Two BPs for one company	Merge rule and which record prevails for general data	Master data team, with sales and procurement
Headquarters and branches	Different models for identical cases	One BP per establishment or another model, in writing	Master data, tax and SAP architecture
Shared general data	One department changes what another relies on	Owner of each field group and the change workflow	Data governance with the business areas
Numbering and groupings	Old groups without criteria become groupings without criteria	Map of account groups to BP groupings and use of "same number"	SAP architecture with master data
Inactive and blocked records	Dead records converted as if active	Inactivity criteria and what to handle first in ECC	Master data, finance and procurement
External interfaces	Records entering outside the BP	Interface inventory and changes to create and update through the BP	IT and integration
Alphanumeric CNPJ (Brazil)	Custom validation rejects or corrupts the identifier	Review of fields, validations and programs that handle the CNPJ	IT, tax and master data

Cleanup checklist

• List the tax IDs that appear as both customer and vendor.
• Group records by CNPJ root and check headquarters and branches.
• Validate legal name, address, state tax registration (a Brazilian state-level tax ID) and registration status against official sources.
• Standardize address, name and tax fields that will be shared across roles.
• Define inactivity criteria and separate what should not stay active.
• Map account groups to BP groupings and decide on keeping the same number.
• Inventory the interfaces that write to customer and vendor records.
• Review custom CNPJ fields and validations.
• Measure quality before and after, using the same indicators.

On that last item, I wrote about building the baseline in how to measure master data quality.

What does this look like in a hypothetical case?

The following example is hypothetical. The company is fictitious and the round numbers are for illustration only.

Example Distribution Co. has 10,000 customers and 4,000 vendors in ECC. When the master data team cross-checks tax IDs, it finds 500 partners on both sides. Some of them have a different address in each record.

Without a decision, the conversion carries both records and each one becomes its own BP. With a decision, the team defines that these 500 become one BP with two roles, picks which address prevails, checks it against the official source and records who owns the general data from now on.

The same cross-check shows 1,000 vendors with no purchases for many years. The team sets the criteria, handles those records in ECC and avoids loading as active what is no longer in use.

None of this is new technology. It is a decision made at the right time.

Where should you start?

1. Take a snapshot of current master data: how many customers, vendors, tax IDs repeated across both sides and records without activity.
2. Write the rules: merge or not, headquarters and branches, owner of general data, inactivity criteria.
3. Cleanse at the source, before loading, validating against official sources.
4. Close the numbering and grouping map with SAP architecture.
5. Review interfaces and CNPJ validations.
6. Test the conversion in load cycles and compare quality before and after.

If your conversion is still being planned, it is worth reading about data migration for SAP projects and about reducing risks and costs in SAP data migration. Our SAP S/4HANA migration page shows how we approach this work.

Frequently asked questions

Does every customer and vendor have to become a Business Partner in the conversion?

Yes. SAP documents that, in an SAP ERP to SAP S/4HANA conversion project, all customer and vendor master records in the system have to be converted to Business Partners. That is why inactive and incorrect records should be handled beforehand.

Should a partner that is both customer and vendor be a single BP?

The BP was designed for that: general data is shared across roles such as customer and vendor. My recommendation is to define the merge rule before the conversion. Without that decision, the same company may end up as two BPs.

Can we keep the same number we had in ECC?

SAP documents a "same number" option that keeps the same number on the BP and on the customer or vendor. This requires specific number range configuration (external numbering and matching intervals), to be validated with SAP architecture.

Should headquarters and branches be separate BPs?

In Brazil, each establishment has its own CNPJ, with the same root and a different sequence number. There is no single answer. What matters is choosing a model, writing down the rule and applying the same rule to every case.

What should we do with inactive records before the conversion?

Define inactivity criteria with finance, procurement and sales, handle those records in ECC and avoid loading them as active. Since all customer and vendor records must be converted, cleanup has to come first.

Does the alphanumeric CNPJ affect BP master data?

It can affect fields, validations and custom programs that treat the CNPJ as a number. This is a Brazilian rule: the Receita Federal adopted the alphanumeric format for new registrations starting in July 2026 (IN RFB nº 2.229/2024), keeping 14 positions, and told companies to adapt their systems. Entities that already have a CNPJ keep their number.

How 4MDG can help

The BP conversion exposes master data as it really is. 4MDG handles data migration to SAP, from legacy systems to SAP and from ECC to S/4HANA. We cleanse and standardize master data at the source, before loading. That includes deduplication, standardization, enrichment and validation of customers and vendors against official sources, such as CNPJ, state tax registration, certificates and registration status, using AI and more than 600 public databases. We work with source to target mapping, mock loads and a controlled cutover, with a methodology integrated with SAP Activate. See our page on data migration to SAP S/4HANA. If you want to start with a real slice of your data, you can request an assessment or get in touch.

Sources

• SAP Learning, "Working with Business Partners", course Functions & Innovations in SAP S/4HANA Sales: https://learning.sap.com/courses/functions-innovations-in-sap-s-4hana-sales/working-with-business-partners_a6b68cce-1d88-41a5-b2c4-513775c98be6, accessed on October 6, 2026.
• SAP Learning, "Creating Business Partners", course Purchasing in SAP S/4HANA: https://learning.sap.com/courses/purchasing-in-sap-s-4hana/creating-business-partners, accessed on October 6, 2026.
• SAP Learning, "Manage Customer/Vendor Integration", course Managing Customer and Vendor Accounts: https://learning.sap.com/courses/managing-customer-and-vendor-accounts/manage-customer-vendor-integration_b3f948ee-b6e4-4f7c-85cd-08dc926ce427, accessed on October 6, 2026.
• Receita Federal (Brazil), "CNPJ Alfanumérico": https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/programas-e-atividades/cnpj-alfanumerico, accessed on October 6, 2026.