Third-Party Sales Fundamentals: Business Purpose and Process Flow
Introduces why companies use third-party sales, how it differs from standard and individual purchase order processing, and walks through the end-to-end document flow from sales order to customer invoice.
Explanation
Third-party sales (also called third-party order processing) is a sales scenario where the selling company never physically holds the goods. Instead, when a customer orders an item, the sales order automatically triggers a purchase requisition that is converted into a purchase order sent to an external vendor. The vendor ships goods directly to the end customer, and the selling company invoices the customer separately, often based on the vendor's invoice (statistical goods receipt) rather than a warehouse-confirmed delivery. Business reasons for using this process include: avoiding inventory carrying costs for slow-moving or bulky items, fulfilling orders for products outside the company's core manufacturing scope, supporting drop-ship business models, and enabling trading companies to broker sales without holding stock. This is distinct from standard sales order processing (own warehouse delivers) and from individual purchase order processing (goods are received into company stock first, then delivered). The process is triggered by item category control. When a sales order line item is entered, the system determines the item category based on the combination of sales document type, item category group of the material (or manually overridden), usage, and higher-level item category. A third-party item category (commonly represented in standard SAP as item category TAS in the standard sales document type OR) is billing-relevant based on the purchase order history rather than delivery, and it carries no delivery-relevant schedule line in the classic third-party flow because the vendor delivers directly. At the schedule line level, the system uses a schedule line category that is configured to automatically create a purchase requisition. This is the critical link between SD and MM: the schedule line category has an indicator that tells the system 'this schedule line creates a purchase requisition' and specifies the requisition item category type used by Purchasing. Once the sales order is saved, a purchase requisition is generated in the background, visible in the requisition, and can be converted by a buyer (or automatically, depending on configuration) into a purchase order against the specified vendor. The purchase order in MM references the original sales order and item, establishing an account assignment category that ties the procurement to the specific sales order (a form of sales-order-related account assignment). When the vendor ships and bills, the goods receipt (which may be statistical only, since the goods never enter company-owned stock) and the vendor invoice verification create the basis for billing the end customer. Depending on configuration, the sales order billing quantity can be based on the quantity from the vendor invoice (invoice-receipt-based) or from a statistical goods receipt, so the biller needs to understand which trigger is active before chasing missing billing documents. From a beginner's perspective, the essential mental model is: Sales Order (item category triggers requisition) -> Purchase Requisition -> Purchase Order to vendor -> Vendor delivers to customer directly -> Vendor invoice / goods receipt updates purchasing document -> Customer billing document created referencing the purchase order history. Understanding this flow is foundational before diving into copy control, billing quantity determination, and account assignment configuration covered in later lessons.
Real project scenario
A distribution company sells specialized lab equipment that they do not manufacture or stock. When an order comes in for an item not held in inventory, the SD sales order line uses a third-party item category, which automatically raises a purchase requisition. The procurement team converts this into a PO against the manufacturing partner, who ships directly to the hospital customer. The AR team later bills the hospital once the vendor's invoice is verified in MM, ensuring margin is captured only after cost is confirmed.
Common mistakes
• Assuming third-party items follow the same delivery-based billing as standard items, leading to confusion when no outbound delivery exists to reference for billing. • Manually changing the item category on an order without understanding that this bypasses the automatic purchase requisition creation, breaking the process for that line. • Not recognizing that goods movement for third-party items is typically statistical, so inventory reports may show no stock movement even though goods physically moved. • Overlooking that the vendor for third-party procurement must be maintained correctly in the requisition/PO before conversion, otherwise procurement is delayed and the customer order appears stuck.
Best practices
• Always confirm which item category group and item category combination is intended for third-party materials before mass data loads, since incorrect master data defaults can silently break the requisition trigger. • Document for the business team that third-party items are billing-document-driven from purchasing activity, not delivery activity, to set correct expectations for order-to-cash cycle time. • Coordinate with procurement early so vendors used in third-party flows are approved, have correct incoterms, and support direct-ship logistics to the end customer. • Use test orders in a sandbox to trace the full requisition-to-billing chain before go-live, rather than assuming standard configuration guarantees correct behavior for every material.
Interview angle
Interviewers often ask candidates to explain, without referencing memorized transaction codes, why a third-party sales order does not require an outbound delivery and how billing is triggered instead. A strong answer distinguishes item category and schedule line category roles, explains the SD-MM linkage via automatic requisition creation, and clarifies that billing can be based on invoice receipt or statistical goods receipt depending on configuration, rather than assuming one universal SAP behavior.