Third-Party Sales: MM Integration, Invoice Verification, and Copy Control for Billing

Explanation

Third-party sales only works end to end because SD and MM/FI are tightly wired together through the purchase requisition generated from the sales order. When a sales order line uses an item category configured for third-party processing, the schedule line category attached to it carries an indicator that tells the system to create a purchase requisition instead of reserving stock. This requisition carries the sold-to customer and sales order/item as an account assignment reference, which is what allows the eventual vendor invoice and goods receipt to trace back to the originating sales document. A purchasing group converts that requisition into a purchase order, typically manually in most implementations, though some organizations automate this with background jobs or workflow approvals for low-risk, high-volume vendors. The purchase order item carries the same account assignment category (item category I is common in ECC/S4 terminology for third-party account assignment) pointing back to the sales order. This is the linchpin: without correct account assignment, the system cannot connect the vendor's goods receipt or invoice back to the customer billing document. Depending on configuration, the business either does not expect a goods receipt at all (invoice receipt based billing, common in drop-ship scenarios where the vendor ships directly to the customer and the company never physically receives goods) or requires goods receipt as a billing-relevant event. This is controlled by the billing-relevance indicator on the sales document item's copy control settings and the item category's billing plan or default relevance flag. Two common configurations exist: billing based on order quantity (billing relevance A, invoice created as soon as the order is entered or ready for billing) and billing based on invoice receipt quantity (billing relevance F or similar, which requires MM invoice verification against the vendor's bill before the customer invoice can be created). The invoice receipt based approach protects the company from billing the customer for quantities never actually invoiced by the vendor, which matters when partial shipments or quantity variances occur. When invoice-receipt-based billing is active, the accounts payable clerk posts the vendor invoice through invoice verification, referencing the purchase order. This posts a debit to a third-party cost of goods sold or clearing account and credns the vendor. The system simultaneously updates the sales document to reflect billable quantity based on what was actually invoiced by the vendor, not just what was ordered. Only then does the sales order item appear in the billing due list with the correct invoiceable quantity. Sales administrators must understand that if the vendor invoice has not been posted, the customer billing document literally cannot be created for invoice-receipt-based items, and this is one of the most common support tickets in third-party processing: "why won't this order bill?" On the revenue and cost side, the vendor invoice amount typically flows into a cost element tied to the sales order as a statistical or real cost object, enabling sales order-level profitability reporting through controlling. This lets finance see, per sales order, the vendor cost against the customer revenue, which is central to why many distribution and non-stocking businesses use third-party sales as their core margin visibility mechanism. S/4HANA on-premise and private cloud retain this architecture largely unchanged from ECC, though Fiori apps for managing sales order fulfillment and purchase requisition monitoring give better visual tracking of the requisition-to-PO-to-invoice chain. Public cloud editions expose this through preconfigured scope items with the same underlying account-assignment logic, but configuration flexibility (for example, custom billing relevance combinations) is more restricted, and organizations should validate exact billing-relevance behavior against their specific release rather than assuming ECC parity.

Code example

* Illustrative only - not a real transaction sequence* Conceptual link between documents (data shown, not executable code) Sales Order 4500001234, Item 10  Item Category: TAS (third-party)  Schedule Line Category: CS -> triggers Purchase Requisition Purchase Requisition 1000005555, Item 10  Account Assignment Category: X (third-party)  Account Assignment: Sales Order 4500001234 / Item 10 Purchase Order 4500009999, Item 10  Created with reference to PR 1000005555  Vendor: 100234 Vendor Invoice (Invoice Verification) posted with reference to PO 4500009999  -> Updates 'invoice receipt quantity' on Sales Order Item 10  -> Sales Order Item becomes billing-relevant (if billing relevance = F) Billing Due List (VF04-style worklist)  -> Sales Order 4500001234 / Item 10 now appears  -> Customer invoice created for invoiced quantity only

Real project scenario

A specialty equipment distributor configured third-party items with invoice-receipt-based billing to avoid overbilling customers when vendors shipped partial quantities. During a period-end crunch, AP fell behind on invoice verification for a batch of vendor invoices, and sales operations could not understand why dozens of orders were stuck out of the billing due list despite goods having shipped per the vendor's tracking confirmation. The support team traced it to the billing relevance indicator requiring MM invoice posting, coordinated with AP to prioritize the backlog, and separately proposed a monitoring report joining open purchase orders without invoice receipt against overdue sales order items so the business could proactively flag AP bottlenecks before they affected the billing cycle and cash collection.

Common mistakes

• Assuming a sales order will bill automatically once goods ship, without checking whether the item category uses invoice-receipt-based billing relevance • Creating the purchase order with an incorrect or missing account assignment reference, breaking the link back to the sales order and orphaning the requisition • Posting the vendor invoice against the wrong purchase order item or with a quantity/value mismatch that does not update the sales order's billable quantity correctly • Not reconciling the third-party cost account regularly, allowing mismatched vendor cost and customer revenue postings to accumulate undetected • Overlooking that goods receipt, if required by the PO's GR-based invoice verification flag, must also be posted before invoice verification is allowed, adding another gating step • Failing to communicate billing-relevance behavior to AP and purchasing teams, who may not realize their document timing directly controls customer billing eligibility

Best practices

• Document and communicate to AP, purchasing, and sales operations exactly which item categories require invoice-receipt-based billing versus order-based billing • Build a monitoring report or worklist that surfaces third-party orders with open purchase requisitions, unconverted POs, or pending invoice verification so bottlenecks are visible before they affect billing cycles • Reconcile third-party cost clearing accounts on a regular schedule as part of period-end close, not only when discrepancies are reported • Ensure account assignment categories and default cost objects are configured consistently so sales order profitability reporting remains reliable • Test the full requisition-to-invoice-to-billing chain in a realistic end-to-end scenario during any S/4HANA migration or configuration change, since partial testing often misses the invoice-verification gating step • Clarify with the business up front which drop-ship scenarios require goods receipt versus invoice-only confirmation, since this materially changes process timing and risk exposure

Interview angle

Interviewers use this scenario to test whether a candidate truly understands cross-module dependency rather than reciting configuration names. Expect questions such as: what determines whether a third-party order bills on order quantity versus invoice receipt quantity, what account assignment category links the PO to the sales order, and how would you troubleshoot an order stuck out of the billing due list. Strong answers walk through the requisition-to-PO-to-invoice-verification chain and explicitly mention the billing relevance indicator as the control point, plus how sales order profitability data flows from the vendor invoice.