A distributor cannot physically stock everything it sells. To offer a broad assortment without tying up working capital in slow-moving inventory, wholesale distributors route selected orders directly to the supplier, who ships to the end customer. The distributor keeps the commercial relationship, the customer orders from and is invoiced by the distributor, but the goods never pass through the distributor's warehouse. SAP S/4HANA Cloud Public Edition supports this as third-party (drop-ship) order processing.
This article explains the third-party model on Public Edition, the two standard variants, how the sales and purchasing sides connect, and when to use it instead of selling from stock. The general order-to-cash flow is covered in the companion article; this one focuses on the direct-ship variation.
In a third-party scenario, a sales order line is flagged as third-party rather than as a stock item. Instead of creating an outbound delivery from the distributor's warehouse, the order automatically generates a purchase requisition, which becomes a purchase order to the supplier with the end customer's address as the ship-to location. The supplier ships directly to the customer. The distributor then bills the customer, and the supplier bills the distributor, so the margin is the difference between the two.
| Party | Role in a third-party order |
|---|---|
| End customer | Places the order with the distributor; receives the goods directly from the supplier; is invoiced by the distributor |
| Distributor | Owns the sale, the pricing and the billing; raises the purchase order; never handles the goods |
| Supplier | Ships directly to the end customer; invoices the distributor |
The flow links a sales document and a purchasing document around goods that move outside the distributor's four walls. This linkage is what allows the distributor to control margin, customer communication and billing while outsourcing physical fulfillment.
Public Edition provides third-party order processing in two standard variants, distinguished by whether the supplier confirms the shipment back to the distributor. The choice determines what triggers customer billing.
| Aspect | With shipping notification (BD3) | Without shipping notification (BDK) |
|---|---|---|
| Supplier confirms shipment | Yes — statistical goods receipt / ASN | No |
| Basis for customer billing | Confirmed shipped quantity | Supplier invoice |
| Best fit | Bill on confirmed fulfillment | Simpler flow, invoice-driven |
Both are standard scope items, activated and configured rather than built. The right variant depends on how much visibility the distributor has into supplier shipments and on when it wants to invoice the customer.
Third-party processing is where a distributor's Sales and Sourcing and Procurement processes meet on a single order. The sales order line drives a purchase requisition and purchase order automatically, carrying the customer's delivery address and the required quantity and date. Availability for a third-party item is a question about the supplier's ability to deliver rather than about the distributor's stock, so the promised date reflects the procurement lead time.
Because two documents are linked, both sides must stay reconciled: a change to the sales order quantity or date should flow to the purchase order, and the supplier's confirmation or invoice should update the sales side so the customer is billed correctly. Designing this reconciliation, and the exception handling when a supplier ships short, late, or at a different price, is the core of a robust third-party implementation.
Third-party fulfillment is a tool, not a default. It earns its place for products and situations where holding stock is uneconomic or unnecessary, and it costs control in exchange for lower inventory. The decision is usually made per product, supplier or order.
| Situation | Sell from stock | Third-party / drop-ship |
|---|---|---|
| Fast-moving core assortment | Strong fit | Rarely needed |
| Long-tail or bulky, slow-moving items | Ties up capital and space | Strong fit |
| Made-to-order or supplier-configured goods | Not practical | Strong fit |
| Tight control over delivery experience | Full control | Depends on supplier reliability |
| Speed to offer a new product line | Requires stocking first | Can sell immediately |
A distributor commonly runs both models side by side, stocking its core range and drop-shipping the long tail. Because both are standard Public Edition processes, switching a product between them is a configuration and master-data decision rather than a development.
Third-party processing depends on accurate master data and clean integration. Materials must be set up to support third-party procurement, supplier and pricing data must be maintained on both the sales and purchasing sides, and the link between the sales order and the purchase order must be configured for the chosen variant. Where suppliers exchange orders and confirmations electronically, that integration should use released APIs and EDI rather than modifications, in keeping with a clean-core design.
Testing should cover the full cross-document flow and its exceptions: a supplier that confirms a different quantity, a delayed or partial shipment, a price difference between the supplier invoice and the purchase order, and a customer change after the purchase order is placed. Because the goods never pass through the distributor's warehouse, the system record is the only record, so the reconciliation between sales order, purchase order, supplier confirmation or invoice, and customer billing must be verified end to end before go-live.