SAP SD Third-Party Sales Process in S/4HANA
TAS & CS · the automatic requisition · billing on the vendor invoice · troubleshooting · Last updated September 2026
You take the order. A vendor ships the goods straight to your customer. You never see the material, never post a goods issue, never create a delivery — and still have to invoice the customer correctly.
This guide follows one order through the whole process: the configuration that makes it work, the documents it creates, how billing depends on the vendor’s invoice, and what to check at each point where it breaks. Written for SAP S/4HANA on-premise and Private Edition; the logic is unchanged from ECC.
On this page
What third-party sales means
In third-party sales — drop shipment, in commercial language — the goods flow from your vendor straight to your customer, while the documents flow through you. You own the customer relationship and the margin; the vendor owns the logistics.
It is used when stocking the item makes no sense: bulky goods shipped from the manufacturer, long-tail catalogue items, spare parts, anything drop-shipped in e-commerce. What makes it interesting in SAP is that two modules share one process — SD raises the demand, MM fulfils it, and billing waits on a document MM creates.
Scroll the diagram sideways to see all of it →
SAP SD third-party sales: documents pass through your company, goods go directly from vendor to customer.
The worked example
A Noida distributor sells industrial pumps. One model is heavy, slow-moving and shipped from the manufacturer’s plant in Pune. Stocking it would tie up cash and warehouse space, so it is sold third-party.
The order: the customer orders 10 pumps at ₹80,000 each. The material carries item category group BANS, so the item determines TAS and the schedule line CS. Saving the order creates a purchase requisition for 10 pumps. Purchasing converts it to a purchase order on the Pune manufacturer at ₹62,000 each — the margin is ₹18,000 a pump, fixed at that moment.
The manufacturer ships 6 pumps now and 4 next month, and invoices for the 6. That single fact drives the rest of this guide: with standard TAS, your customer is invoiced for 6 — not 10 — because billing follows the vendor’s invoice. The section on billing explains the alternative and when to choose it.
Configuration checklist
Six things have to line up. The first four are pure SD, the fifth is MM, and the last is the one people forget until the order refuses to bill.
Material master — item category group
MM02 → Sales: Sales Org 2 view
Set the item category group to BANS for materials that are always sold third-party. The material still needs sales views for the sales area, but it needs no stock and no plant stock views, because it never enters your warehouse.
Item category determination
VOV4
OR + BANS + blank + blank → TAS. If the material is only occasionally sold third-party, keep the item category group NORM and make TAS a manual alternative in the same row, so the user can switch the item.
Item category TAS
VOV7
Delivery relevance off (no delivery is ever created), schedule lines allowed, pricing active, billing relevance F, and the purchasing indicators set so the item triggers a requisition. TAS is delivered as standard — copy it rather than changing it.
Schedule line category CS
VOV6 (determination in VOV5)
CS carries no movement type, and holds the three purchasing fields: order type NB (purchase requisition), item category 5 (third-party) and account assignment category 1 (third-party). Those three are what actually create the requisition. Determination: TAS + MRP type → CS.
Purchasing master data
ME11 info record, source list, MM settings
The requisition needs a vendor eventually: a purchasing info record for the vendor and material gives the buyer a price, and a source list can assign the vendor automatically. Purchasing organisation and group must exist for the plant on the item.
Copy control order → billing
VTFA → F2 from OR, item TAS
Third-party items are billed from the order, not a delivery, so the order-to-billing copy control must exist for the TAS item category, with billing quantity F (invoice receipt quantity less already invoiced quantity) and the pricing type your business wants.
The determination itself is ordinary: item category determination gets you TAS, and schedule line category determination gets you CS. Third-party sales is not a special mode in SAP — it is standard determination pointed at two special categories.
Document flow step by step
Sales order
VA01The item determines TAS, the schedule line determines CS. No availability check runs against your stock — you have none. On save, SAP creates a purchase requisition and links it to the order item in the document flow.
Purchase requisition
created automaticallyThe requisition carries the sales order as its account assignment and the ship-to party’s address as the delivery address. Changing the quantity on the order changes the requisition, as long as the requisition has not yet become a purchase order.
Purchase order to the vendor
ME21N / ME57 / ME59NThe buyer converts the requisition, choosing the vendor and the purchase price. This is the moment your margin is fixed: the customer price came from your pricing procedure, the cost comes from the PO.
The vendor ships to your customer
outside SAPGoods never touch your plant. If the purchase order requires a goods receipt, it is posted in MIGO as a non-valuated receipt against the sales order account assignment — it records that the vendor delivered, it does not create stock you own.
Vendor invoice
MIROInvoice verification posts the vendor’s invoice against the purchase order. This is the step that matters to SD: with billing relevance F, the invoiced quantity is what makes the sales order item due for billing.
Customer invoice
VF01 / VF04The customer invoice is created from the sales order with reference to the invoice receipt quantity. Two vendor invoices for half the quantity each produce two customer invoices, unless you wait and bill once.
Variants worth knowing: whether a goods receipt is expected at all is a purchase order setting, and whether invoice verification requires that receipt first is the GR-based invoice verification flag. Billing relevance decides whether SD waits for MIRO. Those three switches explain nearly every “but on my project it worked differently” you will hear.
Billing explained
Third-party items are billed from the sales order, because no delivery exists. What quantity gets billed depends on the billing relevance of the item category.
F — the invoice receipt quantity
The item becomes due for billing only after the vendor invoice is posted, and only for the quantity invoiced. In the example, 6 pumps invoiced by the manufacturer means 6 pumps invoiced to the customer. You never bill for goods the vendor has not charged you for — the margin is protected by design.
B — the order quantity
The item is due for billing straight away, for the ordered quantity, without waiting for the vendor. Cash arrives sooner, and the risk is billing for goods that were never shipped or that the vendor later invoices differently. Businesses choose this deliberately, not by accident.
Partial quantities follow the same rule. With F, each vendor invoice makes that quantity billable, so a part-shipped order can produce several customer invoices. If the business prefers one invoice, wait until the vendor has invoiced everything before running billing — the copy control setting billing quantity F bills what has been invoiced and not yet billed, so nothing is lost or duplicated.
The goods receipt is often called “statistical” in third-party discussions. What it means in practice: the purchase order is account-assigned to the sales order, so any goods receipt is non-valuated — it records that the vendor shipped, without creating stock you own or a value in your inventory. Whether it is posted at all is a purchase order setting, and with billing relevance F it is the invoice receipt, not the goods receipt, that releases billing.
Troubleshooting
No purchase requisition is created when the order is saved
- ·The schedule line category is not CS — check what VOV5 determined for the item category and MRP type
- ·CS has no order type, item category or account assignment category maintained
- ·The item determined TAN instead of TAS, so no purchasing is involved at all
- ·The order was saved with an incompletion that stops the requisition, or the item is rejected
Fix: Open the item’s schedule line and read the schedule line category first. It tells you immediately whether this is a determination problem (wrong category) or a configuration problem (right category, missing purchasing fields).
The item category is TAN, not TAS
- ·The material master has item category group NORM, not BANS
- ·No VOV4 entry for the order type + item category group combination
- ·The order type is a custom one that was never added to VOV4
Fix: Fix the material master for materials that are always third-party. For occasional third-party sales, add TAS as a manual alternative in the VOV4 row so users can change the item category on the order.
The order never appears in the billing due list
- ·The vendor invoice has not been posted in MIRO, and billing relevance F waits for it
- ·A billing block is set on the order header or item
- ·Copy control from the order type to F2 is missing for item category TAS
- ·The item was billed already, or is fully rejected
Fix: Check MIRO first — this is the single most common third-party question. If the business wants to bill before the vendor invoice arrives, switch the item category to billing relevance B (order quantity) with the finance team’s agreement.
The customer invoice quantity is not what you expected
- ·The vendor invoiced a partial quantity, and F bills exactly what was invoiced
- ·The vendor invoiced more than the customer ordered, or a second invoice arrived
- ·Billing relevance is B, so the full order quantity was billed regardless of the vendor invoice
Fix: Compare the invoice receipt quantity on the purchase order history with the billed quantity on the order item. With F they should match; a difference is a purchasing question, not an SD one.
Third-party vs individual PO vs intercompany
All three bring in goods your plant did not have, which is exactly why interviewers ask you to separate them.
| Third-party | Individual purchase order | Intercompany | |
|---|---|---|---|
| Who ships | An external vendor, straight to your customer | An external vendor, into your plant, then you deliver | A plant belonging to another company code in your group |
| Item category | TAS | TAB | Standard (TAN) |
| Schedule line | CS — no movement type | CB | CP |
| Stock in your books | None at any point | Yes — sales order stock, then goods issue to the customer | In the supplying company code |
| Delivery created | No | Yes | Yes |
| Billing basis | Invoice receipt quantity (relevance F) or order quantity (B) | Delivery-related, after goods issue | Delivery-related to the customer, plus an intercompany invoice (IV) |
The individual purchase order is the near miss: it also creates a requisition from the order, but the goods arrive in your plant as sales order stock and you deliver them. If a candidate says “TAB is third-party too”, that is the gap. Intercompany sales is different again: the supplier is a plant inside your own group, and a second invoice flows between the two company codes.
Interview questions
Walk me through the third-party sales process.
A sales order with item category TAS and schedule line CS creates a purchase requisition automatically. Purchasing converts it into a purchase order to the vendor, and the vendor ships directly to the customer. A goods receipt may be posted, non-valuated, if the purchase order requires one. The vendor invoice is posted in MIRO, and that invoice receipt quantity is what makes the sales order item due for billing. The customer invoice is then created from the sales order — there is never a delivery.
Which settings actually create the purchase requisition?
The three purchasing fields on the schedule line category CS: the requisition document type (NB), the purchasing item category (5, third-party) and the account assignment category (1, third-party). The item category TAS gets you to CS; CS creates the requisition.
What is the billing relevance of TAS, and why does it matter?
Standard TAS is F — order-related billing based on the invoice receipt quantity, so the customer is billed only for what the vendor actually invoiced. B is the alternative: it bills the order quantity without waiting. F protects the margin; B protects cash flow. Knowing both, and the trade-off, is what the question is really testing.
Is the goods receipt in third-party sales mandatory?
No. Whether a goods receipt is expected is controlled on the purchase order item. When one is posted it is non-valuated, because the goods are account-assigned to the sales order and never become your stock. Billing with relevance F depends on the invoice receipt, not the goods receipt.
How is third-party sales different from an individual purchase order?
Third-party (TAS, CS) means the vendor ships straight to the customer and you never hold the goods — no delivery is created. An individual purchase order (TAB, CB) procures the material specifically for the sales order, but it comes into your plant as sales order stock and you deliver it to the customer yourself, with goods issue and delivery-related billing.
Where this sits in the SD landscape
Third-party sales is the Order-to-Cash process with the delivery removed and a purchase order put in its place. Everything else is familiar: item category and schedule line determination choose the behaviour, copy control lets the order be billed, and revenue account determination posts the invoice.
Frequently Asked Questions
What is third-party sales in SAP SD?
Third-party sales is when your company takes the customer order but an external vendor ships the goods directly to the customer. SAP creates a purchase requisition from the sales order, purchasing turns it into a purchase order, and the customer is invoiced from the sales order — no delivery and no stock movement in your plant.
What is item category TAS?
TAS is the standard third-party item category. It has no delivery relevance, allows schedule lines, is relevant for purchasing and billing, and carries billing relevance F so the customer is billed the vendor invoice receipt quantity.
What is schedule line category CS?
CS is the third-party schedule line category. It has no movement type and holds the purchasing data used to create the requisition: order type NB, purchasing item category 5 and account assignment category 1.
How is the purchase requisition created from a sales order?
Automatically, when the order is saved, from the schedule line category CS. The requisition is account-assigned to the sales order item and carries the ship-to party’s address as the delivery address, so the vendor ships to the customer.
Why is my third-party order not in the billing due list?
With billing relevance F the item becomes due for billing only after the vendor invoice is posted in MIRO. The other usual causes are a billing block or missing order-to-billing copy control for item category TAS.
Is a goods receipt needed in third-party sales?
Only if the purchase order item requires one. When posted it is non-valuated: the goods are account-assigned to the sales order and never become your inventory. Billing on relevance F depends on the invoice receipt, not the goods receipt.
What is the difference between BANS and NORM?
BANS is the item category group for materials that are always sold third-party — it determines item category TAS. NORM determines TAN, the standard item delivered from your own stock. For materials sold both ways, keep NORM and make TAS a manual alternative in VOV4.
Which tables hold the link between the sales order and the purchase requisition?
The requisition is in EBAN, with the sales order and item in its account assignment; the purchase order is in EKKO and EKPO, and the whole chain is visible in the sales order document flow.
Written by
Rahul Narain Saxena
SAP SD Solution Architect with 17+ years of hands-on implementation experience across SAP ECC and S/4HANA. Every guide on The SD Vault is written from live project experience, not summarised from documentation.
“The third-party order will not bill. Why?”
Cross-module questions separate consultants who have run the process from those who have read about it. The SD Vault has 230+ depth-graded questions and 38 real configuration scenarios — including a full third-party scenario with IMG paths and test steps.
Get Lifetime Access →Or start free with the sample pack, Item Category guide, and Intercompany Sales guide.