Customer Master Data Fundamentals: Structure, Account Groups and Partner Functions

Explanation

Customer master data is the single most reused object in the Order-to-Cash cycle. Every sales order, delivery, billing document, and FI posting reads customer data to determine pricing, tax, shipping, payment terms, and credit exposure. Getting this foundation wrong causes downstream errors that are expensive to fix once thousands of documents reference a customer record. In classic SAP (ECC and still visible conceptually in S/4HANA), customer master data is split into three data levels stored in tables KNA1 (general data, client-independent), KNB1 (company code data, e.g. reconciliation account, payment terms), and KNVV/KNVP (sales area data, e.g. pricing procedure determinant fields, sales district, shipping conditions) plus KNVI (tax classification) and KNVK (contact persons in older releases). The general data is shared across all company codes and sales areas; company code data controls FI-relevant attributes like the reconciliation account and dunning; sales area data (Sales Organization + Distribution Channel + Division) allows the same legal entity to have different pricing, delivery, and billing behavior per sales channel. Account groups (configured in customizing) are the primary control mechanism. Each account group defines: the number range (internal or external), which fields are mandatory, optional, suppressed, or display-only on each screen, whether the customer is a one-time customer (using a generic master with data entered per transaction), and which partner functions are permitted. Typical account groups include Sold-to Party, Ship-to Party, Bill-to Party, and Payer, though organizations may define custom groups aligned to business scenarios (e.g., separate groups for intercompany customers or export customers). Partner functions are the mechanism that allows one business transaction to reference multiple customer roles. The four standard partner functions—Sold-to Party (who places the order), Ship-to Party (delivery address), Bill-to Party (who receives the invoice), and Payer (who pays)—can all point to the same customer master or to different ones. This is configured via a partner determination procedure assigned to the sales document type and customer account group. When a sales order is created, the system reads the sold-to party's partner functions to auto-populate ship-to, bill-to, and payer; users can override at document level, but master data drives the default. Understanding this structure matters for troubleshooting: if a sales order defaults the wrong shipping address, the root cause is usually the ship-to partner function assignment on the sold-to master, not a configuration bug. If tax is calculated incorrectly, check KNVI tax classification per sales area, not just the customer's country. If a customer cannot be selected in a sales document, check whether the account group's sales area data is missing (customer not extended to that sales org/distribution channel/division combination). In S/4HANA, this classic table structure is technically still present at the database level for compatibility, but customer master maintenance is unified into the Business Partner. This lesson establishes the conceptual data model before the next lesson addresses how BP and CVI change the maintenance and governance approach.

Code example

* Example: Reading sales area data for a customer to verify configuration (illustrative selection, not a specific transaction)* Table: KNVV - Customer Master Sales DataSELECT kunnr vkorg vtweg spart kdgrp vsbed lprio  FROM knvv  INTO TABLE @DATA(lt_sales_data)  WHERE kunnr = '0000100234'. * kdgrp  = Customer group (used in pricing condition tables)* vsbed  = Shipping conditions (drives route determination)* lprio  = Delivery priority LOOP AT lt_sales_data INTO DATA(ls_sales).  WRITE: / ls_sales-vkorg, ls_sales-vtweg, ls_sales-spart, ls_sales-kdgrp.ENDLOOP.

Real project scenario

During a retail distribution rollout, a new sales organization was added for a regional subsidiary. Sales orders for existing customers failed with an error that the customer was not defined for the sales area. The root cause was that customer master records existed only at the general and company code level; nobody had extended the sales area data (KNVV) for the new sales organization/distribution channel combination. The functional team had to run a mass extension using a data transfer approach to add sales area segments for over 4,000 customers before go-live, and the project added a checklist step to master data cutover procedures to prevent recurrence in future rollouts.

Common mistakes

• Assuming a customer that exists in one sales area automatically works in another sales org/distribution channel/division combination without extension. • Confusing company code data (FI-relevant, e.g. reconciliation account) with sales area data when troubleshooting billing or pricing issues. • Setting a field as mandatory in the account group without checking whether all business processes creating that customer type can realistically supply it, causing order creation failures. • Overriding partner functions manually at document level as a routine practice instead of fixing the master data default, leading to inconsistent reporting. • Not distinguishing one-time customer account groups from regular ones, resulting in cluttered customer master data for walk-in or ad hoc sales.

Best practices

• Always verify that sales area data exists before assuming a customer is usable in a new sales organization or distribution channel. • Use account groups to enforce mandatory fields aligned with actual business process capability, not aspirational data completeness. • Keep partner function defaults accurate at master data level rather than relying on manual document-level overrides. • Document which account groups are used for one-time customers versus long-term customers to keep reporting clean. • When extending customers to new sales areas, use a controlled mass-maintenance or LSMW/migration approach rather than one-by-one manual entry for volume rollouts.

Interview angle

Interviewers commonly ask candidates to explain the three data levels (general, company code, sales area) and why a customer might exist in FI but fail in an SD transaction. A strong answer connects account group configuration, sales area extension, and partner function determination rather than just naming tables. Be ready to explain a real scenario where missing sales area data caused an order-creation error and how you diagnosed it.