1.4 Cross-Company and Multi-Plant Sales Enterprise Setup & SD-FI Integration

Cross-Company and Multi-Plant Sales Enterprise Setup & SD-FI Integration

In complex global enterprises, sales and distribution structures must interface seamlessly with Financial Accounting (FI), Management Accounting (CO), and Inventory Management (MM). While simple sales models operate within a single company code, modern supply chains frequently leverage multi-plant logistics and cross-company order processing. Understanding the structural linkages between sales organizations, delivering plants, credit control areas, and general ledger accounts is essential for passing the SAP S/4HANA Sales exam.

---

Multi-Plant Sales vs. Cross-Company Code Sales

When a sales organization receives an order, the goods may be sourced from different manufacturing sites or distribution hubs. The operational and financial complexity depends entirely on whether the delivering plant belongs to the same Company Code or a different Company Code.

Multi-Plant Sales (Intra-Company):
  Company Code 1000 (US)
     ├── Sales Organization 1000 (Ordering Unit)
     ├── Plant 1010 (Dallas Plant)    ── Fulfillment ──> External Customer
     └── Plant 1020 (Atlanta Plant)   ── Fulfillment ──> External Customer
  (Single balance sheet: No intercompany invoices, no internal billing)

Cross-Company Code Sales (Intercompany):
  Company Code 1000 (Ordering CoCode - US Sales)
     └── Sales Organization 1000
  Company Code 2000 (Supplying CoCode - German Manufacturing)
     └── Plant 2000 ── Dispatches Goods ──> External Customer
  (Dual balance sheets: Requires External Invoice F2 + Intercompany Invoice IV)

Intra-Company Multi-Plant Sales

In an intra-company multi-plant scenario:

• Sales Organization 1000 belongs to Company Code 1000.
• Plant 1010 (Dallas) and Plant 1020 (Atlanta) both belong to Company Code 1000.
• An order taken by Sales Organization 1000 can deliver items from either plant, provided each plant is assigned to Sales Organization 1000 + Distribution Channel 10 in customizing.
• Accounting Impact: At Goods Issue, inventory is reduced in Plant 1020, debiting Cost of Goods Sold (GBB-VAX) and crediting Finished Goods Inventory (BSX) within Company Code 1000. When the customer invoice (F2) is created, revenue is recognized within Company Code 1000. The entire process remains within a single balance sheet.

Cross-Company Code Sales (Intercompany Sales)

In a cross-company code sales scenario:

• The customer places an order with Ordering Company Code 1000 (Sales Organization 1000).
• The order is fulfilled by Supplying Company Code 2000 (Delivering Plant 2000).
• Because the delivering plant belongs to a different legal entity than the selling sales organization, two legal transactions occur simultaneously:
  1. The external sale from Company Code 1000 to the end customer.
  2. The internal corporate sale from Company Code 2000 to Company Code 1000.

---

End-to-End Document Flow and Accounting Postings in Cross-Company Sales

The cross-company order-to-cash process follows five distinct steps across both company codes:

Step 1: Sales Order Creation (VA01)

• The sales representative enters an order in Sales Organization 1000 (Ordering CoCode 1000).
• In the line item, Delivering Plant 2000 (Supplying CoCode 2000) is entered.
• Customizing Prerequisite: Plant 2000 must be assigned to Sales Organization 1000 and Distribution Channel 10 in customizing, even though Plant 2000 belongs to Company Code 2000.

Step 2: Outbound Delivery and Post Goods Issue (PGI) (VL01N)

• The delivery is processed by Shipping Point 2000 attached to Plant 2000.
• When the warehouse confirms picking and posts goods issue (PGI), stock is deducted from Plant 2000.
• Critical Accounting Posting: The accounting entry is posted strictly in Supplying Company Code 2000:
  • Debit: Intercompany Cost of Goods Sold (or internal inventory clearing account) in CoCode 2000.
  • Credit: Finished Goods Inventory (BSX) in CoCode 2000.

Step 3: External Customer Billing Document (F2 via VF01)

• Ordering Sales Organization 1000 creates the commercial customer invoice (Billing Type F2).
• Accounting Posting in Ordering Company Code 1000:
  • Debit: Customer Accounts Receivable (External Customer Subledger / G/L Reconciliation Account in CoCode 1000).
  • Credit: Sales Revenue Account (ERL via VKOA in CoCode 1000).

Step 4: Intercompany Billing Document (IV via VF01)

• Supplying Sales Organization 2000 generates an Intercompany Billing Document (Billing Type IV) billing Ordering Sales Organization 1000.
• Mandatory Master Data Setup: An Internal Customer Master must be created in Supplying Company Code 2000 and Sales Organization 2000 to represent the ordering sales organization. In customizing (SPRO $\rightarrow$ Sales and Distribution $\rightarrow$ Billing $\rightarrow$ Intercompany Billing $\rightarrow$ Define Internal Customer Number by Sales Organization), this internal customer number is assigned to Sales Org 1000.
• Accounting Posting in Supplying Company Code 2000:
  • Debit: Intercompany Customer Receivables (Internal Customer Subledger in CoCode 2000).
  • Credit: Intercompany Sales Revenue (Condition type PI01 fixed price or PI02 percentage).

Step 5: Inbound Vendor Invoice Posting in Ordering Company Code

• Ordering Company Code 1000 must post an Accounts Payable liability to Supplying Company Code 2000.
• In automated setups, when Intercompany Invoice IV is saved, an EDI output sends an IDoc (message type INVOIC) to Ordering Company Code 1000, which posts an incoming supplier invoice automatically. In classic NAST output this was output type RD04; in SAP S/4HANA Output Management, the IDoc channel is reserved for exactly this internal billing case:
  • Debit: Intercompany Merchandise Expense / COGS in CoCode 1000.
  • Credit: Intercompany Accounts Payable (Vendor Master representing CoCode 2000).

---

Credit Control Area Architecture in SAP S/4HANA

The Credit Control Area is the organizational unit responsible for defining, specifying, and monitoring customer credit limits. It can encompass one or multiple company codes.

Structural Attributes

• Credit Control Area Currency: Maintains its own base currency. If assigned company codes or sales organizations operate in different currencies, transaction amounts are dynamically converted to the Credit Control Area currency using specified exchange rate types (M).
• Fiscal Year Variant: Must be compatible with the assigned company codes.

Assignment Models

1. Decentralized (1:1 Model): Exactly one Credit Control Area is assigned to one Company Code. Useful when regional operating units maintain autonomous credit departments with independent credit risk policies.
2. Centralized (1:N Model): A single Credit Control Area governs multiple Company Codes. This is standard for multinational corporations, allowing global credit limits across all subsidiaries.
3. Sales Area Override: In customizing, a Credit Control Area can be assigned directly to a Sales Area. This allows overriding the default company code credit control area for specific distribution channels (e.g., separating retail from wholesale credit management).

SAP S/4HANA Credit Management Transformation (FSCM)

In SAP ERP (ECC 6.0), credit management was managed in Financial Accounting (FI-AR) via transaction FD32 and tables KNKK/KNKA.

• In SAP S/4HANA, classical credit management is completely replaced by SAP Credit Management (part of Financial Supply Chain Management - FSCM).
• Credit master data is maintained directly within the Business Partner (BP) under role UKM000 (SAP Credit Management).
• The customer's credit limit is structured into Credit Segments. In customizing, each Credit Segment is mapped to an SD Credit Control Area. When a sales order is entered, the credit check evaluates the customer's credit exposure in the credit segment mapped to the credit control area. SAP Credit Management is not one of the courses in the C_TS462 learning journey, so treat this paragraph as background for the credit blocks you will meet in sales documents.

---

General Ledger Integration: Reconciliation Accounts and Account Determination (VKOA)

The integration between Sales and Financial Accounting culminates when billing documents release to accounting, generating real-time postings in the Universal Journal table ACDOCA.

Customer Reconciliation Accounts

Every customer invoice debits the customer subledger. The offsetting General Ledger account is determined by the Reconciliation Account (KNB1-AKONT) defined in the Business Partner customer company code data (role FLCU00). Subledger entries automatically post to this reconciliation account; direct manual postings to reconciliation accounts are blocked in FI.

Automatic Revenue Account Determination (Transaction VKOA)

When an invoice is generated, the system determines the G/L revenue, discount, and tax accounts automatically using the Condition Technique (Application V for Sales):

• Account Keys: Embedded in the SD Pricing Procedure (e.g., ERL for gross revenue, ERS for sales deductions/discounts, MWS for output tax).
• Determination Tables: Transaction VKOA evaluates a sequence of criteria:
  1. Application (V)
  2. Condition Type (KOFI for account determination without a CO account assignment, KOFK for account determination with a CO account assignment)
  3. Chart of Accounts (from Company Code)
  4. Sales Organization
  5. Customer Account Assignment Group (KTGRD from BP Sales Area data)
  6. Material Account Assignment Group (KTGRM from Material Master Sales: Sales Org 2 view)
  7. Account Key (ERL, ERS, etc.)

Pricing Condition PR00 ──> Account Key ERL ──> VKOA Lookup ──> Credit: G/L Revenue 400000
Pricing Condition K007 ──> Account Key ERS ──> VKOA Lookup ──> Debit:  G/L Discount 410000

---

Organizational Units for Billing (Course S46150)

The billing course in the C_TS462 learning journey starts with the organizational units that billing needs. Three assignments must be in place before an invoice can post:

In the SAP training system, company code 1010 is assigned to the chart of accounts YCOA. Set up the structure carefully and consistently: an extra sales organization or distribution channel multiplies master data maintenance, while a missing assignment stops billing documents from posting.

High-Frequency Exam Traps and Configuration Gotchas