ERPClimb logoERPClimb

SAP SD / O2C Customer and Business Partner Interview Questions

In SAP SD / O2C rounds, customer and business partner questions are where configuration knowledge meets day-to-day behaviour — what a setting does, and what breaks in a live system when it is wrong.

Covers the customer master and Business Partner (BP) model in SAP SD, including data structure, the ECC-to-S/4HANA transition from XD/VD transactions to the BP-centric approach, account groups, partner functions, integration with FI (customer account) and CRM/cloud scenarios, and troubleshooting master data issues that affect order-to-cash processing.

This page carries 26 reviewed SAP SD / O2C customer and business partner interview questions, each with a complete written answer and no sign-in required. The set breaks down into 4 foundational, 14 mid-level and 8 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

Rehearse these out loud rather than reading them. If you can explain each answer in your own words, including one realistic way it goes wrong on a project, you are covering what a normal SAP SD / O2C round on customer and business partner expects.

26 Customer and Business Partner questions with answers

easyCustomer and Business Partner

1. What is sales area data on the customer master, and why is it maintained separately from the general and company code data?

Sales area data is the customer master segment maintained per sales organization, distribution channel and division combination. It holds sales-relevant attributes like pricing procedure determination fields, delivery/shipping conditions, order probability, and account assignment groups. It is separated because the same customer can transact through multiple sales areas with different pricing, terms, or output requirements, while general data (name, address) and company code data (payment terms, reconciliation account) remain common across all sales areas.
easyCustomer and Business Partner

2. What is the purpose of a customer account group in SAP SD, and how does it influence credit management setup for a customer master record?

The account group controls the field status (mandatory, optional, suppressed fields), number range assignment, partner determination procedure, and whether the customer can be a one-time or sold-to party. For credit management, it determines whether the credit control area/credit segment fields appear during master creation and whether the customer is eligible for credit limit assignment via FD32/BP credit views.
easyCustomer and Business Partner

3. What is a customer hierarchy in SD, and what business purpose does it serve?

A customer hierarchy links customer master records in a tree structure (table KNVH, maintained via VDH1N) to reflect organizational relationships, such as a corporate HQ with regional buying offices. It is used to roll up sales statistics, determine pricing/rebate condition records from a higher node, and route output or credit checks up the chain. Nodes must share compatible sales areas for determination to work correctly.
easyCustomer and Business Partner

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

The account group controls which fields are mandatory, optional, suppressed, or display-only on the customer master, determines the number range (internal/external) for the partner/customer number, and restricts which partner functions (sold-to, ship-to, bill-to, payer) can be created. It also drives one-time customer logic and controls whether the customer master requires a sales area or is FI-only.
mediumCustomer and Business Partner

5. A customer complains that invoices are being sent to the wrong bill-to party after a partner function change was made at the customer master level. The change was intended to apply only to new orders. What is likely happening, and how should partner function changes be managed?

Partner function changes at the customer master (general or sales-area level) typically apply going forward to new sales documents by default, since partners are copied into the document at creation time; however, if the change was made incorrectly at general data level instead of sales-area level, or if open orders were reprocessed/copied after the change, existing document partners could be affected. You should check whether the change was scoped to the correct level, review partner determination procedure logic, and confirm whether any automated jobs recreated invoices referencing updated master data instead of the original order partners.
mediumCustomer and Business Partner

6. During a merger, two legacy companies each maintain the same customer under different account groups in different sales areas, and now both need to be consolidated into one BP with a shared sales area structure. What is your approach to resolving the account group conflict and consolidating the sales areas?

First determine which account group's field control and partner determination procedure is the target standard, since a BP/customer can only belong to one account group in the merged system. Map the legacy customer numbers to a single BP via a data migration/reconciliation tool, retaining historical sales area data as extended sales areas under the surviving account group where the field status permits. Where account groups differ materially in mandatory fields (for example, credit-relevant fields), remediate missing data before extension, and involve the business partner governance team to approve the consolidated master.
mediumCustomer and Business Partner

7. In a Business Partner-centric S/4HANA landscape, how should number ranges for customer account groups be designed to avoid conflicts between internal and external numbering, and what happens if the BP number range overlaps with an existing account group range?

Number ranges must be defined once at the BP grouping level (via BP number range configuration) and mapped consistently to each customer account group so KNA1/BUT000 numbers stay synchronized. Internal and external ranges must not overlap across groups; SAP checks this during BP-customer synchronization. An overlap causes duplicate number errors or blocks BP creation, since the same interval cannot serve two purposes simultaneously.
mediumCustomer and Business Partner

8. Multiple regional teams independently maintain customer master records, resulting in duplicate customers and inconsistent sales area data. What governance approach would you recommend using MDG or Business Partner controls?

Recommend centralizing customer creation through MDG-C or a governed Business Partner creation process with mandatory duplicate/fuzzy-search checks before record creation, combined with workflow-based approval for new customers and changes to key sales fields. Restrict regional teams' authorization to maintain only sales-area-specific fields (KNVV) relevant to their region via authorization objects, while general and company code data remain centrally controlled, reducing duplicate creation and inconsistent extensions.
mediumCustomer and Business Partner

9. A regional sales manager wants to view all customers assigned to their sales area in a Fiori app, but the app shows fewer customers than expected. What sales area assignment issues would you check first?

Verify the customer's KNVV records actually include the specific sales organization, distribution channel, and division combination the manager expects, since customers not explicitly extended to that exact sales area will not appear even if they exist in other combinations. Check the Fiori app's OData service filter logic for authorization restrictions tied to sales organization or sales area in the user's role, and confirm common distribution channels/divisions setup (VOR1/VOR2) isn't causing unintended exclusions. Also validate that the customer isn't blocked at the sales area level (deletion flag or sales block).
mediumCustomer and Business Partner

10. A business unit wants to onboard a new customer that will order under two different sales areas sharing the same account group. What master data governance considerations must you address?

Since account group controls number ranges, field status, and partner functions, using the same account group across sales areas is fine as long as the general data is shared correctly via one central customer/BP record, with sales area data extended per sales area using account group settings that permit multiple sales views. You must verify partner determination procedures per sales area, ensure pricing and output data are extended correctly, and confirm the account group's field status doesn't force redundant mandatory fields conflicting between the two sales areas.
mediumCustomer and Business Partner

11. In an S/4HANA Business Partner landscape, how does the customer account group configuration interact with material sales view data to determine which fields are mandatory or relevant when creating a sales order?

The customer account group (via BP grouping and field status group) governs which customer-sales-area fields—like pricing group, delivery priority, or shipping conditions—are mandatory, optional, or hidden during BP creation. These same fields often act as defaults or checks against material sales view data (e.g., delivery plant, item category group) at order entry. Misaligned field status settings on the account group can suppress fields the material logic expects to be populated, causing incomplete sales area data errors or wrong item category determination downstream.
mediumCustomer and Business Partner

12. Your organization is migrating from classic customer master maintenance to Business Partner-based customer creation. A consultant proposes reusing the existing account group directly as the BP grouping. What issues should you anticipate and how should the design be validated?

Account groups and BP groupings are linked via customizing (BP grouping to account group mapping) but are not automatically identical; number ranges must be synchronized to avoid conflicts, and the account group's field status must be mirrored in BP role configuration (e.g., FLCU00, FLCU01). You should validate that number range intervals don't overlap, that partner determination and field status groups behave consistently for both BP creation (BP transaction) and downstream sales views, and test integration with FI customer account groups (KNB1) to prevent inconsistent master data.
mediumCustomer and Business Partner

13. A Fiori-based mass update adds a new sales area to a group of customers under existing MDG governance, but ship-to partner functions default incorrectly for orders created in the new sales area while the sold-to and bill-to remain correct. How would you diagnose the root cause?

First confirm the partner determination procedure assigned to the new sales area's document type matches the one used where defaults work correctly, since procedures can differ by sales area. Check whether the mass Fiori update populated the ship-to partner function record at the customer-sales area level (KNVP) for the new sales area, or only copied general/company data. Also verify customer hierarchy assignments weren't reset for the new sales area, since hierarchy-driven ship-to defaults are sales-area-specific and easily missed in mass extension jobs.
mediumCustomer and Business Partner

14. During a Business Partner migration, material sales views for a set of materials are not appearing correctly on sales orders for certain customer account groups, though the materials exist in the Sales Org/Distribution Channel combination. How would you investigate the integration between Material Sales Views and Customer Account Group settings?

First confirm the material's Sales Org 1/2 views exist for the exact Sales Org/Distribution Channel combination used by the order, since missing extension causes the item to fail entirely, not just display incorrectly. Then check whether the customer account group's field status/partner determination setup restricts certain material groups via listing/exclusion (VB01/VB02) rather than the material master itself. Also verify Business Partner grouping (BP role FLCU00) didn't break the Sales Area segment link during migration, which is a common post-cutover BP conversion issue.
mediumCustomer and Business Partner

15. A regional finance team reports that a newly created customer via Fiori Manage Customer Master Data app cannot be used in a sales order because the required sales area is missing. Walk through how you would diagnose and resolve this.

First confirm whether the Fiori app created only the general/company code data (BP roles FLCU00/FLCU01) without the sales area view (BP role FLVN00/customer sales role). Check if the sales area extension step was skipped in the app's guided activity or governance workflow. Resolve by extending the customer to the required sales organization/distribution channel/division combination via the sales data BP role, ensuring account group and partner functions are correctly maintained, then retest order entry.
mediumCustomer and Business Partner

16. A customer complains that invoices are being sent to the wrong company entity even though the sold-to party is correct. How would you investigate and resolve this using partner function configuration?

Check the partner determination procedure assigned to the customer's account group and sales document type to see if the bill-to party (BP) partner function is correctly determined and defaulted from the customer master partner functions in the sold-to's KNVP/BP relationships. Verify the sold-to customer master has the correct bill-to partner assigned in its partner function tab; if missing, the system defaults sold-to as bill-to. Correct by maintaining or updating the partner function relationship, and check for existing open orders that copied a wrong bill-to from an outdated master record.
mediumCustomer and Business Partner

17. Your organization uses SAP MDG to govern customer master creation, but sales teams complain that newly approved customers cannot be used in sales orders for two days after MDG approval. How would you investigate and resolve this?

Check whether MDG replication to the SD system is delayed due to batch job scheduling, IDoc/CIF processing errors, or missing sales area data not captured in the MDG business object model. Review IDoc status (WE02/WE05) or the replication monitor for failed segments, and confirm the MDG data model includes sales-area-specific fields required by SD, not just general/company code data. Also verify that text and output determination master data (partner-specific texts, print parameters) is included in replication scope, since incomplete replication commonly causes usability gaps.
mediumCustomer and Business Partner

18. During a Business Partner customer creation, procurement teams complain that vendor-relevant texts are missing when the BP is extended to a vendor role after being created as a customer with SD-specific texts. How would you address this text governance gap?

In the BP model, text objects are role-specific and text IDs configured for the customer role (e.g., sales texts) are not automatically visible or relevant to the vendor role since text determination procedures differ by application area (SD vs MM). You need to review text ID configuration in both customer and vendor roles, ensure the BP's central data texts are set up correctly if shared, and clarify with business which texts are truly cross-role versus role-specific before assuming a defect.
hardCustomer and Business Partner

19. After a merger, a customer hierarchy spans nodes assigned to different credit control areas and company codes. Once hierarchy-based rebate accrual postings go live, finance reports rebate accruals hitting incorrect reconciliation accounts for certain subsidiary nodes. As the architect, how would you diagnose whether the customer hierarchy structure itself is driving this FI account determination issue?

Start by reviewing the hierarchy in VDH1N to confirm which nodes cross company code or credit control area boundaries, since hierarchy nodes are not inherently constrained to a single company code. Check whether rebate condition records reference the hierarchy customer versus the payer/sold-to, and validate account determination (VKOA) access sequences for that condition type. Confirm the sales area of each node matches the intended company code for FI posting, and check BSEG/ACDOCA postings against the expected reconciliation account per node to isolate whether it's a hierarchy assignment gap or a condition record misconfiguration.
hardCustomer and Business Partner

20. Sales orders in a specific sales office are inconsistently picking the wrong ship-to partner despite correct customer master partner determination. How would you diagnose and resolve this in an MDG-integrated landscape?

First check whether the partner determination procedure assigned to the sales document type includes the sales office as a source field or if it's overridden by order-level manual entry. Then verify MDG replication logs to confirm the ship-to partner function was correctly synced to ECC/S4 partner tables (KNVP) without truncation or timing issues. Check if sales office-specific partner assignment tables were maintained, and review whether change pointers or IDocs from MDG introduced duplicate or outdated partner records causing incorrect defaulting.
hardCustomer and Business Partner

21. A global rollout project reports that partner determination on customer-sales area data is inconsistent across regions, causing wrong ship-to or bill-to defaults on sales orders created via an MDG-driven mass upload. How would you troubleshoot this?

First check whether the partner determination procedure assigned to the sales document type and customer account group is consistent across regions, since MDG mass uploads may bypass manual defaulting logic embedded in transaction screens. Verify that MDG replication correctly populates KNVP (or BP relationship tables in S/4HANA) with the intended partner roles, and check for missing or duplicate partner assignments at customer-sales area level versus general data level. Also confirm MDG business rules replicate region-specific partner functions rather than applying a single global template.
hardCustomer and Business Partner

22. When extending a customer to a new sales area in a global rollout governed by MDG, what enterprise structure and partner determination considerations must be validated before the extension is approved?

Validate that the target sales organization, distribution channel and division combination is a valid, released sales area in customizing, and that the customer's account group permits the partner functions required (sold-to, ship-to, payer, bill-to) for that sales area's partner determination procedure. MDG workflow should trigger a check against existing partner roles to prevent duplicate ship-to creation and confirm pricing procedure, credit control area and output determination consistency across the extended sales area.
hardCustomer and Business Partner

23. 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?

Check the customer's account group field status settings; sales area data (KNVV) fields may be marked mandatory in the account group config but were skipped during creation via a different transaction/BAPI that bypassed screen validation. Also verify whether the account group's number range overlaps with another group causing the record to be internally created against the wrong number range, resulting in inconsistent sales area extension. Fix by correcting field status group settings and running a mass sales-area extension (VD02/XD99) for affected records.
hardCustomer and Business Partner

24. In a sales organization design project governed by MDG, what process would you follow to create and maintain Customer-Material Info Records (CMIR) across multiple sales organizations while ensuring partner determination remains consistent?

Define CMIR governance rules within MDG's change request process so CMIR creation is triggered only after the customer-sales area and material sales view combination is approved and active. Use a central data model to map which sales organizations share CMIR data versus which need distinct records per legacy structure. Validate that partner determination procedures assigned to the sales area produce consistent ship-to/bill-to results before mass CMIR upload, since CMIR overrides (delivery priority, substitution) can mask partner-function-driven defaults if sequencing is wrong.
hardCustomer and Business Partner

25. For a global rollout, you must extend an existing customer master to new sales areas across multiple sales organizations while keeping general and company code data shared, and without creating duplicate credit exposure. How would you architect this?

Use the sales area extension approach (copy with reference from an existing sales area via VD01/VD02 extend function) to reuse general and company code data while creating new KNVV records per sales area. For credit management, ensure the credit control area assignment or, in S/4HANA, the credit segment mapping is consistent so the same customer isn't evaluated under multiple independent credit exposures; align risk category and credit limit assignment centrally rather than per sales area to prevent double-counting exposure across regions.
hardCustomer and Business Partner

26. In a global rollout with thousands of customer-material combinations, how would you design the use of Customer-Material Info Records (CMIR) to avoid performance and data governance issues while still supporting customer-specific overrides on pricing, delivery tolerances and material substitution?

Use CMIR selectively only where genuine customer-specific overrides are needed (customer material number, delivery tolerances, minimum delivery quantity, or material substitution), not as a blanket mapping for every combination, since CMIR volume grows multiplicatively and complicates maintenance. Centralize governance through mass maintenance tools or migration objects rather than manual VD51 entry, use condition records (VK11/VK12) for pricing overrides where possible instead of CMIR, and periodically archive obsolete CMIR entries tied to inactive materials or customers to control table growth and lookup performance.

Related lesson

Business Partner Model and Customer Vendor Integration (CVI) in S/4HANA

Related topics

Advanced SD Scenarios, Integration and Production SupportS/4HANA SD Transformation, Migration, Public Cloud and ArchitecturePricingEnterprise StructureBillingOutput ManagementSchedule Line CategoriesItem CategoriesCopy ControlCredit ManagementSales DocumentsAvailability Check

Next practice step

Practice with Interview AITake a mock test