Customer and Business Partner
SD / O2Cbeginner

SD Customer and Business Partner Part 1: Customer Master Data Structure

Key takeaway

How customer master data is organized for order-to-cash: general data, company code data and sales area data, what each level controls in sales, delivery, billing and accounting, and how account groups and partner functions shape the customer.

What this complete series covers

Learn Customer and Business Partner in a clear, practical sequence — from the basic idea to real project use, troubleshooting, and interview-ready understanding.

Who it is for
Best for SAP consultants, developers, and learners who want a practical understanding of Customer and Business Partner.
Prerequisites
Basic SAP S/4HANA navigation and an understanding of the business process are helpful. Configuration or transaction steps require suitable access to a practice or project system.
Final outcome
By the end, you should be able to explain Customer and Business Partner clearly, follow the main end-to-end flow, apply it in a project scenario, and troubleshoot the most common issues.
  1. Part 1: SD Customer and Business Partner Part 1: Customer Master Data Structure

    Introduces why customer master data is foundational to SD, how it is structured across general, company code, and sales area data, and how account groups and partner functions drive document behavior.

  2. Part 2: SD Customer and Business Partner Part 2: Business Partner Model and CVI Configuration

    Explains how S/4HANA replaces direct customer master maintenance with the Business Partner model, how CVI synchronizes BP with customer and vendor master data, and what this means

  3. Part 3: SD Customer and Business Partner Part 3: Partner Functions and Partner Determination

    Learn how partner functions (Sold-to, Ship-to, Bill-to, Payer) are defined, grouped into partner determination procedures, and assigned to account groups and sales document types s

  4. Part 4: SD Customer and Business Partner Part 5: BP Governance — Migration Strategy, MDG and Multi-System Consolidation

    Architect-level guidance on designing and governing Business Partner as the single master data object across a multi-system, multi-country S/4HANA landscape, covering migration app

  5. Part 5: SD Customer and Business Partner Part 4: CVI Architecture and Synchronization Troubleshooting

    Understand how Customer Vendor Integration synchronizes classic customer and vendor master records with the Business Partner model in S/4HANA, why synchronization can break, and ho

System and release assumptions: Examples focus on SAP S/4HANA. Exact apps, transaction codes, configuration paths, and field names can vary by release and deployment model.

Explanation

📌 KEY POINTS
✅ Customer data lives on three levels: general (KNA1), company code (KNB1) and sales area (KNVV).

✅ Sales area data drives order processing: customer pricing procedure, shipping condition, delivering plant, Incoterms, payment terms, account assignment group, tax classification.

✅ Company code data drives accounting: reconciliation account, payment terms for FI, dunning, payment methods.

✅ Account group (in S/4HANA via the BP grouping mapping) controls number range, field status and which partner functions a customer may have.

⚠️ A customer not extended to the sales area or company code cannot be used there — the most common cause of "customer not defined" errors.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

Part 1: Customer master data structure

Part 2: Business Partner model and CVI configuration in S/4HANA

Part 3: Partner functions and partner determination

Part 4: CVI architecture and synchronization troubleshooting

Part 5: BP governance — migration strategy, MDG and multi-system consolidation

━━━━━━━━━━━━━━━━━━━━
▶ 1. GENERAL DATA

  • Name, address, search terms, communication, tax numbers, industry.
  • Valid for all company codes and sales areas.
  • In S/4HANA maintained on the Business Partner (BUT000 and address tables), synchronized to KNA1.

━━━━━━━━━━━━━━━━━━━━
▶ 2. COMPANY CODE DATA

  • Reconciliation account (link to G/L), sort key, payment terms, payment methods, dunning procedure.
  • Needed before billing can post receivables.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SALES AREA DATA

  • Sales tab: customer pricing procedure, price group, currency, sales office/group.
  • Shipping tab: shipping condition, delivering plant, delivery priority, partial delivery rules.
  • Billing tab: Incoterms, payment terms, account assignment group, tax classification.

━━━━━━━━━━━━━━━━━━━━
▶ 4. PARTNER FUNCTIONS

  • Sold-to (SP/AG), ship-to (SH/WE), bill-to (BP/RE), payer (PY/RG).
  • A sold-to usually carries all four pointing to itself or to other customers.
  • Stored per sales area (KNVP); copied into documents (VBPA).

━━━━━━━━━━━━━━━━━━━━
▶ 5. ACCOUNT GROUP

  • Controls number range (internal/external), field status (required/optional/suppressed) and permitted partner functions.
  • Typical groups: sold-to, ship-to only, payer only, one-time customer.
  • In S/4HANA the BP grouping is mapped to a customer account group via CVI.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. Create the business partner with general data.
  2. Extend it to the company code (FI role).
  3. Extend it to the sales area (sales role) with sales, shipping and billing data.
  4. Maintain partner functions.
  5. Create a test order.

✅ CHECKPOINT: you can say which order field comes from which level of the customer master.

Code example

ABAP Code
===== STEP 1: where each customer field lives =====General data       KNA1   name, address, tax numbers, industryCompany code data  KNB1   reconciliation account (AKONT), payment terms (ZTERM), dunningSales area data    KNVV   customer pricing proc. (KALKS), shipping cond. (VSBED), deliv. plant (VWERK),                          Incoterms (INCO1/2), payment terms (ZTERM), acct assignment group (KTGRD)Tax classification KNVI   per country and tax categoryPartner functions  KNVP   per sales area: SP, SH, BP, PY and others ===== STEP 2: S/4HANA maintenance =====Transaction BP (or Fiori "Manage Customer Master Data")  Role 000000 Business Partner (general)   → general data  Role FLCU00 Customer (FI)                 → company code data  Role FLCU01 Customer (sales)              → sales area data + partner functions ===== STEP 3: display checks =====BP   display customer in role FLCU01, choose sales areaXD03 / VD03 still display (redirect to BP in S/4HANA for maintenance)SE16N KNVV with KUNNR + VKORG/VTWEG/SPART to verify extension

Real project scenario

A distributor's order entry team received "Customer 100345 is not defined for sales area 1000/10/00" dozens of times a day after a new channel was opened. Customers had been created centrally with general and company code data only, and sales area extension was left to local teams who were not told about the new channel. The master data team introduced a creation checklist listing required sales areas per customer type, a mass-extension run for the new channel, and a daily report comparing active sold-to customers against their sales area extensions.

Common mistakes

  • Creating customers without sales area or company code extension.
  • Confusing payment terms in company code data (FI) with payment terms in sales area data (used in billing).
  • Maintaining partner functions only for the sold-to and forgetting additional ship-to parties.
  • Choosing the wrong account group, so required fields or partner functions are missing.
  • Maintaining tax classification incompletely, causing tax determination errors in billing.

Best practices

  • Define required data per customer type (sold-to, ship-to, payer) in a checklist.
  • Extend customers to all needed sales areas and company codes at creation.
  • Keep payment terms consistent between FI and SD data unless deliberately different.
  • Use account groups/BP groupings with clear field status.
  • Monitor incomplete customers with a regular report.

Interview angle

Questions: "What are the levels of the customer master?", "Which customer fields influence pricing, shipping and billing?", "What does the account group control?"
Strong answer: general (KNA1), company code (KNB1) and sales area (KNVV) levels with examples — reconciliation account at company code, pricing procedure/shipping condition/delivering plant/Incoterms/account assignment group at sales area. Account group controls number range, field status and permitted partner functions; in S/4HANA all is maintained via Business Partner roles (FLCU00, FLCU01).

Practice this lesson

Quick check

1. A sales administrator needs to maintain sales-specific fields such as sales district, customer pricing group, and delivery priority for a customer created via the Business Partner transaction. Which type of data segment must be maintained to enter these fields?

2. When a new customer master record is created, the account group assigned during creation primarily controls which of the following?

3. Which of the following is NOT one of the standard data segments typically maintained for a customer master record in Sales and Distribution?

Interview questions

1. What is the purpose of the customer account group in SAP SD, and how does it control customer master data maintenance?

Answer it in your own words first, then compare.

2. A newly onboarded customer's sales order keeps failing with 'sales area data incomplete' even though the customer master appears fully maintained. As the architect, how would you diagnose and resolve a systemic account group misconfiguration causing this?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics