SAP Business Partner Conversion Basics for SAP S/4HANA

Business Partner conversion is a data and process workstream in an SAP S/4HANA conversion project. Existing customer and supplier records become Business Partners, while customer and supplier roles preserve the relevant business-process functions.

The safest approach is to treat the work as a controlled sequence: assess the source data, design the target roles, resolve duplicates, configure synchronization, run conversion cycles, and validate the result with business owners.

01Understand the target Business Partner model

A Business Partner represents a person, organization, or group. The same Business Partner can carry multiple roles, such as a customer role and a supplier role, when the organization has both commercial relationships with that party.

The conversion therefore separates two concerns:

• The central identity of the party, including name, address, communication details, and identification data.
• The role-specific data required for sales, purchasing, accounting, and other processes.

Customer-vendor integration, usually called CVI, connects the legacy customer and supplier objects with Business Partners during the transition. The project must define how source records map to target Business Partners and which values take precedence when records overlap.

The target design should document the required Business Partner categories, grouping, number ranges, role assignments, tax data, bank data, payment data, sales-area data, purchasing data, and company-code data. The design also needs clear ownership for fields that are maintained centrally and fields that remain owned by a business function.

02Assess source data before conversion

Start with an inventory of customers, suppliers, relationships, addresses, tax identifiers, bank details, payment terms, blocking indicators, deletion flags, sales areas, purchasing organizations, and company-code assignments. Include records that appear inactive because they can still affect open items, historical reporting, interfaces, or legal retention requirements.

Create a data-quality worklist with at least these categories:

• Missing mandatory values
• Conflicting names or addresses
• Duplicate tax or registration identifiers
• Inconsistent country and region values
• Invalid or obsolete payment information
• Customers and suppliers that represent the same legal or commercial party
• Records with incompatible account groups or grouping requirements
• Interfaces that depend on customer or supplier numbers

Duplicate analysis should use business evidence rather than name similarity alone. Compare tax identifiers, registration numbers, addresses, bank details, contact information, legal ownership, and transaction history. A proposed match should have a business owner, a reason, and an approved disposition.

Do not merge records solely to reduce the record count. A single legal entity can have multiple operational relationships, and separate records can be justified by company policy, data ownership, or different legal entities.

03Design customer and supplier roles

Map each source customer and supplier to the Business Partner roles required by the target processes. A party that sells to the organization may need a customer role; a party from which the organization buys may need a supplier role. A shared Business Partner can carry both roles when the relationship and master-data governance support that model.

Document role-specific ownership for:

• Sales-area data and partner functions
• Purchasing-organization data and partner functions
• Company-code accounting data
• Reconciliation accounts
• Payment terms and payment methods
• Incoterms and delivery information
• Withholding tax and tax classifications
• Output, integration, and compliance attributes

Number-range and grouping decisions deserve early attention. The project should establish whether Business Partner numbers are aligned with existing customer or supplier numbers, assigned independently, or mapped through a documented cross-reference. Interfaces, forms, reports, authorizations, and custom code must use the selected approach consistently.

04Configure and sequence CVI activities

CVI configuration should be completed in a controlled development path and transported through the project landscape. The sequence normally includes Business Partner customizing, customer and supplier integration settings, role and account-group mapping, number-range alignment, field mapping, synchronization settings, and error handling.

Use a repeatable conversion cycle:

1. Copy or refresh representative data in the project environment.
2. Run the relevant consistency and readiness checks.
3. Execute synchronization or conversion activities.
4. Collect errors by root cause, not only by message count.
5. Correct configuration or source data.
6. Repeat until the remaining exceptions have an approved resolution.
7. Record runtime, volume, throughput, and reconciliation results.

The SAP S/4HANA migration overview provides the wider conversion context, while SAP S/4HANA SUM overview helps place the Business Partner workstream around the technical conversion sequence. Use the SAP S/4HANA simplification item check to track prerequisite findings that can affect the conversion plan. For the broader patterns used to move objects and volumes across data areas, coordinate the change through the same governance approach used for SAP system version checks before and after the conversion window.

05Run conversion rehearsals

A rehearsal should represent production characteristics rather than only a small clean sample. Include high-volume customers and suppliers, international addresses, multiple roles, blocked records, open items, tax variations, bank data, long names, special characters, and records used by interfaces.

Measure both technical and business outcomes:

• Number of source records selected
• Number of Business Partners created or updated
• Number of customer and supplier roles created
• Failed records grouped by cause
• Runtime and processing throughput
• Unresolved duplicates
• Missing or changed mandatory values
• Reconciliation totals by company code, sales area, and purchasing organization
• Interface results and downstream acknowledgements

Keep a conversion ledger for every rehearsal. It should identify the data snapshot, configuration version, execution window, corrections applied, exception owners, and approval status. This makes the final cutover repeatable and gives the team evidence for go or no-go decisions.

06Test business processes after conversion

Business validation must cover the processes that consume customer and supplier master data. Technical creation of Business Partners is not sufficient evidence that the conversion is complete.

Test representative end-to-end scenarios, including:

• Customer creation, change, sales order, delivery, billing, and incoming payment
• Supplier creation, purchase order, goods receipt, invoice, and outgoing payment
• A party with both customer and supplier roles
• Changes to addresses, tax data, bank data, payment terms, and blocking status
• Duplicate prevention and controlled duplicate resolution
• Interfaces, forms, workflow, output, reporting, and analytics
• Authorizations for central and role-specific maintenance
• Reprocessing of failed synchronization records

Reconcile key totals before and after each test cycle. Compare counts and values at the appropriate organizational level, and investigate differences caused by selection criteria, timing, open transactions, or changed master-data rules.

07Plan cutover controls

Freeze the conversion design before the final rehearsal. Define the source-data freeze, open-transaction treatment, interface pause and restart sequence, backup and restore checkpoints, conversion order, validation owners, and rollback decision points.

The cutover runbook should contain executable steps with an owner, start condition, expected result, evidence location, and escalation path. Include a short path for resolving records that fail during the final run and a business decision process for exceptions that cannot be corrected within the cutover window.

After conversion, monitor synchronization errors, failed interfaces, master-data changes, accounting postings, sales and purchasing transactions, and user reports. Maintain heightened support until the error rate and business validation results return to the agreed operating baseline.

08Troubleshoot common conversion failures

Missing mandatory data usually requires a source-data correction or an approved mapping rule. Identify the owning business team, correct the authoritative source, and repeat the affected records through the controlled process.

Number-range conflicts require a decision about grouping and target numbering. Check existing assignments, mapped objects, interfaces, and custom code before changing ranges.

Role or organizational-data errors generally indicate incomplete mapping for company codes, sales areas, purchasing organizations, or account assignments. Compare the failed record with a known-good record from the same organizational scope.

Duplicate proposals need business review. Preserve the evidence used for the decision and record whether records are merged, retained separately, or excluded with a documented reason.

Interface failures should be traced across the complete message path. Confirm the Business Partner key, role availability, mapped identifiers, authorization, payload values, and receiving-system response before reprocessing.

09Define completion criteria

Business Partner conversion is ready for production when the project has approved the target design, completed data cleansing, passed representative rehearsals, reconciled critical totals, tested dependent processes, assigned every remaining exception, and approved the cutover runbook.

A useful completion report contains:

• Scope and source-data snapshot
• Mapping and number-range decisions
• Conversion volumes and runtimes
• Exception totals by root cause
• Duplicate decisions and approvals
• Reconciliation results
• Interface and end-to-end test evidence
• Open risks with owners and due dates
• Cutover and hypercare sign-off

This evidence turns conversion from a one-time technical run into a controlled migration workstream with accountable outcomes.

Sources and further reading

• SAP S/4HANA On-Premise documentation
• SAP NetWeaver documentation