Third-Party Sales: Customer Order Shipped Directly by the Vendor

Business scenario

Demo Retail Pvt. Ltd. orders 40 EA of RM-1000. Demo Manufacturing does not stock it for this customer and has Demo Supplier Ltd. deliver directly. The goods never touch your warehouse, but both the cost and the revenue land in your books.

All companies, numbers and documents are fictional demo data.

Step-by-step flow

1. 01

   Customer orders an item you do not stock open in twin

   Sales order 10000456 is created. The item gets category TAS — third party.

   The item category is the whole trick. TAS tells SAP that this item will be procured and shipped by a vendor, not picked from your stock.

2. 02

   Purchase requisition appears by itself open in twin

   Saving the order automatically creates purchase requisition 10000987, account-assigned to the sales order.

   This is the hand-off from SD to MM. The requisition carries the sales order as its account assignment, so the cost will follow the sale rather than landing in stock.

3. 03

   Purchasing orders from the vendor open in twin

   PO 4500002200 goes to Demo Supplier Ltd. — with your customer's address as the delivery address.

   That address is what makes the goods bypass your warehouse completely.

4. 04

   Vendor ships directly to your customer open in twin

   The goods travel from the vendor straight to Demo Retail. Your warehouse never sees them.

   This is the commercial point of third-party sales: you sell and invoice without holding, handling or financing the stock.

5. 05

   Statistical goods receipt (optional) open in twin

   If configured, a goods receipt is posted for confirmation only — it records the quantity but moves no stock.

   Because the PO item is account-assigned to the sales order and flagged as a non-valuated goods receipt, this receipt updates the PO history and the order's confirmed quantity without touching stock or value.

6. 06

   Vendor invoices you open in twin

   MIRO posts the supplier invoice for ₹40,000 — the cost is charged to the sales order, not to stock.

   This is where the cost of the sale enters your books. In a stocked sale the cost comes from a goods issue; here it comes from the vendor's invoice.

7. 07

   You invoice the customer open in twin

   Invoice 90001234 is billed from the sales order — there is no delivery to bill from.

   Delivery-related billing is impossible — no delivery and no goods issue ever existed. The item category's billing relevance makes the order itself billable.

8. 08

   Third-party sale complete open in twin

   Order → requisition → PO → direct shipment → vendor invoice → customer invoice. Margin ₹40,000, stock untouched.

   The entire process is a document flow spanning SD and MM. It is the cleanest demonstration that SAP tracks value and obligation independently of physical stock.

SAP documents

Stock impact

This part of the process does not change stock.

Accounting impact

Movement type

• 101GR for a third-party PO — statistical and non-valuated where configured, so no stock is updated

Sells goods you do not stock by having the vendor ship directly to the customer. You keep the customer relationship and the margin without holding inventory or handling the goods.

Transactions & Fiori apps

Configuration

• Item category group on the material master

  Configuration dependent

  BANS typically drives third-party item category determination. A material can also be sold as third party case by case by changing the item category manually.

• Schedule line category CS

  Configuration dependent

  Controls that a purchase requisition is created, with which item category and account assignment, and whether an availability check runs.

• Non-valuated goods receipt on the PO item

  Configuration dependent

  Decides whether cost hits consumption at goods receipt or waits for the supplier invoice. The non-valuated setting is typical for third party.

• Billing relevance of the item category

  Configuration dependent

  'F' bills by invoice receipt quantity, so the vendor invoice must come first. Other settings allow billing on the goods receipt quantity or the order quantity.

• Individual purchase order vs third party

  Typical

  An individual purchase order (item category TAB) routes the goods through your plant for the specific customer; third party (TAS) ships direct. Same idea, different physical flow.

Prerequisites

• Item category determination set up so the item becomes TAS (often driven by the material's item category group BANS)
• Schedule line category CS assigned, so saving the order creates a requisition
• Material purchasing data and a source of supply for the vendor
• Account assignment from the requisition to the sales order enabled
• Billing relevance on the item category decided (typically 'F', billing per invoice receipt quantity)

Master data

Material master

Item category group drives TAS determination; purchasing views allow the requisition and PO.

Customer / business partner

Ship-to address is copied into the purchase order as the delivery address.

Supplier / business partner

Source of supply for the requisition and the party you pay.

Purchasing info record

Supplies the purchase price, so the margin is known when the order is taken.

Organizational structure

• Company code 1000
• Sales organization 1000, distribution channel 10, division 00
• Purchasing organization 1000 and purchasing group 001 (demo)
• Plant 1000 — present on the documents for organizational reasons, though no stock moves there

Tables

Integration

• MMThe requisition, purchase order and supplier invoice are all MM documents created inside an SD process.
• FITwo postings: the supplier invoice posts cost and a payable, the customer invoice posts revenue and a receivable.
• COBoth land on the sales order, so profitability analysis shows the true margin of a sale that never touched stock.

Common errors

• “No purchase requisition is created when the sales order is saved”

  Likely causes: Schedule line category is not CS; Item category is TAN, not TAS; Material has no purchasing data

  Where to look: Sales order schedule line category · Item category determination · Material master purchasing views

• “Cannot bill the customer although the vendor has delivered”

  Likely causes: Billing relevance 'F' and no supplier invoice posted yet; Goods receipt expected but not posted; Billing block on the order

  Where to look: PO history (EKBE) · Item category billing relevance · Order billing block

• “Cost ended up in inventory instead of on the sales order”

  Likely causes: PO item not account-assigned to the sales order; Valuated goods receipt instead of non-valuated

  Where to look: PO item account assignment tab · Goods receipt indicator and non-valuated flag

• “Vendor shipped to your plant instead of the customer”

  Likely causes: Delivery address not copied from the ship-to party; PO created manually without the requisition

  Where to look: PO item delivery address · Requisition to PO conversion

Troubleshooting

Something went wrong? Work through these checks in order. They are diagnostic questions, not configuration instructions — confirm changes with your system owner.

1. CHECK 1

   Requisition not created

   • Is the item category TAS?
   • Is the schedule line category CS?
   • Does the material have purchasing views?

2. CHECK 2

   Wrong costs

   • Is the PO item account-assigned to the sales order?
   • Is the goods receipt flagged non-valuated?
   • Does the purchasing info record carry the right price?

3. CHECK 3

   Cannot invoice the customer

   • What is the item category's billing relevance?
   • Has the supplier invoice been posted?
   • Is there a billing block?

4. CHECK 4

   Wrong delivery address

   • Does the PO item show the customer's address?
   • Was the PO created from the requisition rather than manually?

Interview questions

• What makes a sales order item a third-party item, and what happens as a result?

  The item category — typically TAS, usually determined from the material's item category group BANS — together with schedule line category CS. Saving the order then creates a purchase requisition account-assigned to the sales order. Purchasing converts it to a PO with the customer's address, the vendor ships direct, the supplier invoice posts the cost and billing is order-related because no delivery exists.

• In third-party sales, where does the cost of sales come from?

  From the supplier invoice, not from a goods issue. With a non-valuated goods receipt and the PO account-assigned to the sales order, invoice verification posts the cost straight to consumption against that order. There is no goods issue because there is no stock.

• Why is billing order-related rather than delivery-related here?

  Because no delivery is ever created — your company never ships anything. The item category's billing relevance makes the sales order itself billable. With the common setting 'F', the billable quantity comes from the supplier invoice receipt quantity, so the vendor invoice has to be posted first.

• What is the difference between third-party sales and an individual purchase order?

  Both procure specially for one customer order. Third party (TAS) has the vendor ship directly to the customer, so no stock movement happens in your plant. An individual purchase order (TAB) has the goods delivered to your plant as sales-order stock, which you then pick, deliver and goods-issue to the customer normally.

• Does any stock movement show up in your system for a third-party sale?

  Normally none that changes stock. A goods receipt may be posted for confirmation and PO history, but with the non-valuated setting it updates no stock quantity and no value. If you see inventory moving, the PO was probably not set up as third party.

Quiz

Related processes

• 101101 Goods Receipt
• 101Procure-to-Pay
• 601Order to Cash

References

• SAP SE — SAP Help Portal: Third-Party Order Processing (source)
• SAP SE — SAP Help Portal: Item Categories in Sales Documents (source)
• SAP SE — SAP Help Portal: Account Assignment for Sales Orders (source)

Explanations are original. They summarize standard behaviour; always validate against your system's release and configuration.

Version history