Intercompany Sales Fundamentals: Business Purpose and Document Flow
Understand why intercompany sales exists, the roles of the ordering and delivering company codes, and the end-to-end document flow from customer sales order through delivery, customer billing, and intercompany billing.
Explanation
Intercompany sales is used when a multinational or multi-company-code SAP landscape needs one legal entity to sell to an external customer while a different legal entity within the same corporate group actually holds the stock and ships the goods. This is extremely common in organizations with centralized sales offices per country but shared manufacturing or distribution centers located in another country or company code. Rather than the customer dealing with two entities, the process is designed so the customer sees one seller (the ordering company code, tied to the sales organization) while internally the delivering plant's company code invoices the ordering company code for the goods at an internal transfer price. The key organizational actors are: the ordering sales organization (assigned to Company Code A), which owns the customer relationship and issues the standard sales order and customer invoice; and the delivering plant (assigned to Company Code B), which is the plant from which goods are physically shipped. The plant on the sales order line item determines which company code will act as the internal seller. When the plant's company code differs from the sales organization's company code, the system recognizes this as an intercompany scenario, provided intercompany configuration exists linking the sales organization to the delivering plant. The document flow has two parallel billing threads. First, the standard order-to-cash thread: sales order (customer-facing) -> outbound delivery (created at or referencing the delivering plant's shipping point) -> goods issue (which reduces stock at the delivering plant and posts COGS/inventory in the delivering company code) -> customer invoice (billed by the ordering sales organization to the end customer, using standard pricing meant for the external customer). Second, the intercompany thread: once the delivery has posted goods issue, an intercompany billing document is created (often with a distinct billing type) that bills the ordering company code from the delivering company code, using an internal transfer price rather than the customer's price. This intercompany billing document generates an intercompany accounts receivable entry in the delivering company code and, in many configurations, is expected to be settled or offset against a corresponding payable in the ordering company code, sometimes through subsequent FI intercompany reconciliation processes. A critical concept for beginners is that the intercompany billing document is triggered by the delivery (goods issue), not directly by the customer invoice, and it uses its own pricing procedure separate from the customer billing pricing procedure. The transfer price is captured through a dedicated intercompany price condition maintained as a condition record between the sales organization and the delivering plant (or via customer-independent condition tables keyed on sales org, distribution channel, and plant). Without a valid condition record for this internal price, the intercompany billing document will fail to price correctly or will be blocked. From a master data perspective, the delivering plant must be assigned to a company code different from the ordering sales organization's company code for the intercompany logic to activate. The internal customer master record (representing the ordering company code as a 'customer' from the delivering company code's perspective) must also exist and be correctly assigned in configuration, because the intercompany invoice is technically billed to this internal customer number. Understanding this dual-document, dual-company-code structure is foundational before diving into configuration steps, pricing procedures, or FI integration, because every troubleshooting scenario in this topic traces back to whether the sales order, delivery, and billing documents correctly identified the ordering and delivering entities and whether the internal pricing condition record existed.
Real project scenario
A consumer goods company has a sales organization in France (Company Code FR01) that sells finished goods to French retail customers, but all manufacturing and warehousing happens at a plant in Germany (Company Code DE01) shared across multiple country sales organizations. When the French sales team enters a sales order for a French customer with the German plant as the delivering plant, the system must recognize this as intercompany, create a delivery from the German shipping point, and after goods issue, automatically generate an intercompany billing document that invoices Company Code FR01 (as an internal customer) from Company Code DE01, at an internally agreed transfer price, separate from the price charged to the French retail customer.
Common mistakes
โข Assuming any cross-plant sales order is automatically intercompany without checking that the plant's company code actually differs from the sales organization's company code. โข Confusing the customer invoice (external, customer-facing price) with the intercompany billing document (internal, transfer price) and expecting them to use the same pricing procedure. โข Forgetting that the intercompany billing document depends on goods issue having been posted for the delivery; if goods issue is delayed or blocked, the intercompany invoice cannot be created. โข Overlooking the need for an internal customer master record representing the ordering company code within the delivering company code's customer master data. โข Assuming intercompany sales requires a physical cross-border shipment; it can also occur between company codes within the same country if they are legally separate entities.
Best practices
โข Always verify plant-to-company-code assignment in configuration before troubleshooting intercompany billing failures. โข Maintain clear internal customer master records for each company code pairing involved in intercompany flows to avoid billing block errors. โข Document the intended document flow (order type, delivery type, both billing types) for each intercompany corridor as part of solution design, since multiple corridors may need different configurations. โข Educate business users that changes to customer pricing do not affect the intercompany transfer price, since they use separate condition records and pricing procedures. โข Confirm goods issue posting timing expectations with logistics teams since it directly gates intercompany invoice creation.
Interview angle
Interviewers often probe whether a candidate understands that intercompany sales generates two distinct billing documents (customer invoice and intercompany invoice) driven by different triggers and different pricing procedures, and that the differentiator between a normal sale and an intercompany sale is the mismatch between the sales organization's company code and the delivering plant's company code. Be ready to explain the sequence: order, delivery, goods issue, customer billing, intercompany billing, and why goods issue is the technical trigger point for the intercompany invoice.