Integrating SD Master Data with MM and FI Across the Enterprise Structure
An intermediate lesson on how SD enterprise structure elements and master data fields integrate at runtime with MM (plant, availability) and FI (company code, account determination), including troubleshooting common cross-module data issues.
Explanation
Once the basic enterprise structure and master data objects are understood, the next essential skill is seeing how they interlock with MM and FI at document-creation time, because most real production issues in SD are actually integration issues, not pure SD configuration errors. This lesson focuses on that intersection. The sales organization is assigned to exactly one company code in customizing, and this single assignment is what drives the financial posting behavior of every sales document created under that sales organization - the company code determines the chart of accounts, currency limitations for local reporting, and which FI document is created when billing posts revenue. When a sales order is created, the system also determines a delivering plant, either from the customer-material info record, the customer master sales view, or the material master sales view (in that kind of priority/fallback order, though the exact precedence can be influenced by customizing). The plant, in turn, belongs to a specific company code via its own assignment, and if the plant's company code differs from the sales organization's assigned company code, the system requires additional configuration (such as maintaining valid combinations for cross-company sales) - otherwise document creation fails or postings go to unexpected company codes. This plant-to-company-code versus sales-org-to-company-code relationship is one of the most tested integration points in SD/MM/FI cross-functional design. Availability check and requirements transfer at the schedule line level are also MM-dependent: SD does not own inventory data itself, it reads material availability from the plant/storage location combination maintained in MM, and if plant-level MRP or stock data is inconsistent, SD will show confirmed quantities that don't reflect reality, or vice versa. From a master data perspective, the material master's sales-relevant fields (item category group, delivering plant, availability check group, loading group) all sit on views that are maintained per plant or per sales organization, so a single material can behave completely differently for two different sales areas if these fields are set differently. On the customer side, integration with FI happens through the company code data segment of the customer master (or Business Partner in S/4HANA), which carries the reconciliation account, payment terms, and dunning procedure - fields SD does not maintain but relies on for credit management and billing document release to accounting. If a customer has sales area data but no company code data (or vice versa), certain transactions will fail with account determination or credit check errors that look like SD problems but are actually incomplete master data on the FI side. Account determination itself (which G/L accounts revenue posts to) is driven by a combination of chart of accounts, customer account assignment group, material account assignment group, and condition type, output of pricing procedure determination in SD - meaning a pricing/master data error can directly cause an incorrect FI posting. Troubleshooting this integration in production typically starts by checking: (1) does the sales area data exist and is it complete for the sold-to and payer partners involved, (2) is the delivering plant correctly assigned and does it belong to a company code compatible with the sales organization, (3) are the relevant material sales views maintained for that plant/sales org combination, and (4) is the account assignment group on both customer and material consistent with what the account determination procedure expects. In S/4HANA, because Business Partner is now the single source of customer data and customer/vendor integration synchronizes it with the classic customer/vendor tables in the background, an inconsistency between Business Partner and the synchronized customer master can itself be a root cause of integration failures that did not exist in classic ECC - worth checking specifically on S/4HANA projects.
Real project scenario
During a rollout to a new country, a project team activates a new sales organization assigned to a newly created company code, but billing documents for orders in that sales organization keep failing to release to accounting. Investigation traces the issue to the plant used for deliveries still being assigned to the old, shared company code from the legacy structure, creating a cross-company scenario that was never configured. The fix requires either reassigning the plant's company code (a major logistics decision affecting inventory valuation) or explicitly configuring the cross-company sales scenario, illustrating how an enterprise structure decision made in SD customizing has direct consequences for FI and MM teams.
Common mistakes
• Assuming plant and sales organization company code assignments are automatically kept consistent; they are independent customizing entries • Overlooking that account determination depends on account assignment groups maintained on both customer and material master, not just on pricing • Not checking company code data completeness on the customer master when troubleshooting billing or credit issues that appear to be SD-only • Ignoring Business Partner and customer/vendor integration synchronization checks when troubleshooting master data issues on S/4HANA • Designing new sales organizations or plants without involving FI and MM teams in the impact analysis
Best practices
• Map company code assignments for every sales organization and plant combination before any cross-company sales scenario goes live • Involve FI and MM leads in enterprise structure design reviews, not just SD consultants • Build a master data completeness checklist covering sales area, company code, and plant-specific views before user acceptance testing • On S/4HANA, include Business Partner/customer-vendor integration consistency checks in the cutover and hypercare runbook • Use test orders that specifically exercise cross-company or cross-plant scenarios during integration testing, not just single-company-code happy paths
Interview angle
Interview questions at this level often probe whether a candidate understands that SD does not exist in isolation: expect questions like 'what happens if a plant's company code differs from the sales organization's company code' or 'where does account determination get the G/L account from.' Strong candidates describe the cross-module data flow (sales area -> company code -> account determination; plant -> MM stock -> availability check) rather than reciting configuration node names.