SAP S/4HANA Order-to-Cash: White Paper — Part 2

Advanced Scenarios, Specialty Billing, and Operational Excellence

By Sajiv Francis · July 2026

Series context: This is Part 2 of the SAP S/4HANA Order-to-Cash white paper series. Part 1 established the foundational OTC architecture — organizational structure, master data, pricing, ATP, sales order management, and standard delivery and billing. Part 2 extends into specialty billing models, cross-company flows, compliance-driven revenue recognition, and operational analytics. Every section flags explicit cross-references to Part 1 and to anticipated future papers in this series.

Executive Summary

Standard order-to-cash covers the clean arc from sales order to customer invoice. Real-world SAP deployments break from that arc constantly: volume rebates accumulate over quarters before settling as credit memos; vendors ship directly to customers without goods ever touching a warehouse; company codes in different countries transact with each other and need their own billing document; revenue recognition rules require delaying the posting of income until physical delivery is confirmed at the customer site; returned goods need routing decisions — scrap, restock, vendor return — before any credit is issued; and consignment inventory sits at customer premises while ownership remains on the seller’s books.

Each of these scenarios has a distinct document type, item category, movement type, and configuration path in SAP S/4HANA. This paper covers all of them in sequence, with end-to-end process diagrams, configuration reference tables, and explicit integration hooks to Financial Accounting, Materials Management, Warehouse Management, Transportation Management, and Global Trade Services. The paper closes with a full integration map and a context model showing how Parts 1 and 2 connect and where the series goes next.

Context

Part 1 of this series established the OTC skeleton: business partner and material master, the pricing condition technique, availability-to-promise, sales order processing, outbound delivery, proof of delivery, and the standard F2 invoice. That foundation is assumed throughout this document — readers unfamiliar with it should read Part 1 first.

Part 2 moves into the scenarios that sit around the standard flow rather than inside it. Rebates surround the invoice lifecycle as an accrual layer. Drop shipments redirect the physical flow away from the seller’s warehouse entirely. Intercompany billing introduces a second billing document inside the same sales transaction. Revenue recognition compliance adds a mandatory delay between goods issue and income recognition. Returns management introduces a parallel inbound logistics and financial track. Consignment creates a persistent inventory relationship with the customer that can last months or years. Reporting and Fiori analytics tie the operational picture together.

Each section stands alone as a reference but connects deliberately to the others through shared configuration objects — pricing procedures, item categories, schedule lines, partner determination, and account determination — that were introduced in Part 1.

Rebate Management and Condition Contracts

Overview

Rebate management in SAP S/4HANA allows companies to settle volume-based, value-based, or mixed incentive agreements with customers after invoices have already been issued. Unlike standard discounts applied at order entry — covered in Part 1 under the pricing condition technique — rebates are accrued over a period and settled via a credit memo, typically monthly, quarterly, or annually.

The modern S/4HANA implementation uses condition contracts (Transactions MEB0/MEB1) to replace the older rebate agreement approach from SAP ERP. Both mechanisms follow the same commercial logic, but the condition contract approach is Fiori-native and better aligned with S/4HANA’s simplified data model.

Rebate Accrual and Settlement Mechanics

During normal billing — F2 invoice creation via VF01 — the pricing procedure executes condition types flagged as rebate-relevant. These condition types post an accrual: a credit to a provision account and a debit to a rebate accrual expense account, rather than reducing the invoice price directly. The customer sees the full gross invoice; the rebate liability builds silently in the background.

At settlement, either a partial settlement (interim credit memo, billing type B1) or a final settlement (billing type B2) is created. The final settlement clears all accruals and issues the credit to the customer’s account.

Key configuration flags on the billing document type (VOFA):

Rel.for rebate → marks F2 invoices as rebate-relevant
Rebate settlement → marks B1/B2 as settlement documents

The following configuration table captures the full object set:

Object	Transaction	Key Setting
Rebate agreement / condition contract	`MEB1` / `MEB0`	Agreement type, validity, accrual rate
Billing document type — invoice	`VOFA`	`Rel.for rebate` flag active
Billing document type — settlement	`VOFA`	`Rebate settlement` flag; B1/B2
Pricing condition type (accrual)	`V/06`	Condition class = Expense/Revenue
Account key — accrual	`SPRO`	ERB (rebate accruals); ERU (accrual offset)
Rebate basis	Pricing procedure	Subtotal field drives rebate base value

Rebate Settlement Process

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="RebateSettlement"
                  targetNamespace="http://sajivfrancis.com/rebate">
  <bpmn:process id="RebateProcess" isExecutable="false">
    <bpmn:startEvent id="Start" name="Rebate Agreement Active">
      <bpmn:outgoing>flow1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="CreateOrder" name="Create Standard Sales Order - VA01 - OR Type">
      <bpmn:incoming>flow1</bpmn:incoming>
      <bpmn:outgoing>flow2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="CreateInvoice" name="Create F2 Invoice - VF01 - Rebate Relevant">
      <bpmn:incoming>flow2</bpmn:incoming>
      <bpmn:outgoing>flow3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="PostAccrual" name="Post Rebate Accrual - Provision Account">
      <bpmn:incoming>flow3</bpmn:incoming>
      <bpmn:outgoing>flow4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="GW1" name="Settlement Due">
      <bpmn:incoming>flow4</bpmn:incoming>
      <bpmn:outgoing>flow5</bpmn:outgoing>
      <bpmn:outgoing>flow6</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="PartialSettle" name="Partial Settlement - B1 Credit Memo">
      <bpmn:incoming>flow5</bpmn:incoming>
      <bpmn:outgoing>flow7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="FinalSettle" name="Final Settlement - B2 Credit Memo - Clear Accruals">
      <bpmn:incoming>flow6</bpmn:incoming>
      <bpmn:outgoing>flow8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="CustomerCredit" name="Credit Posted to Customer Account - AR">
      <bpmn:incoming>flow7</bpmn:incoming>
      <bpmn:incoming>flow8</bpmn:incoming>
      <bpmn:outgoing>flow9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End" name="Rebate Cycle Complete">
      <bpmn:incoming>flow9</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="flow1" sourceRef="Start" targetRef="CreateOrder"/>
    <bpmn:sequenceFlow id="flow2" sourceRef="CreateOrder" targetRef="CreateInvoice"/>
    <bpmn:sequenceFlow id="flow3" sourceRef="CreateInvoice" targetRef="PostAccrual"/>
    <bpmn:sequenceFlow id="flow4" sourceRef="PostAccrual" targetRef="GW1"/>
    <bpmn:sequenceFlow id="flow5" name="Partial period" sourceRef="GW1" targetRef="PartialSettle"/>
    <bpmn:sequenceFlow id="flow6" name="End of agreement" sourceRef="GW1" targetRef="FinalSettle"/>
    <bpmn:sequenceFlow id="flow7" sourceRef="PartialSettle" targetRef="CustomerCredit"/>
    <bpmn:sequenceFlow id="flow8" sourceRef="FinalSettle" targetRef="CustomerCredit"/>
    <bpmn:sequenceFlow id="flow9" sourceRef="CustomerCredit" targetRef="End"/>
  </bpmn:process>
</bpmn:definitions>

Cross-reference — Part 1: The pricing procedure and condition technique foundation — condition tables, access sequences, condition records — was established in Part 1 §4 (Pricing Architecture). Rebate condition types sit inside the same pricing procedure framework; the only structural difference is the accrual flag on the condition type and the settlement flag on the billing document type.

Future paper flag: Full accrual accounting entries — debit and credit of ERB/ERU account keys, clearing logic, and balance sheet treatment of rebate provisions — belong to the FI-CO Integration paper. Rebate provisions appear on the balance sheet as accrued liabilities, a topic requiring FI posting logic beyond SD scope.

Drop Shipments and Special Orders

Conceptual Distinction

Both drop shipments and special orders are sales order-driven individual procurement scenarios where no pre-stocked inventory is assumed. The distinction is in where the goods physically flow:

Scenario	Goods Flow	Item Category Group	Item Category	Schedule Line Category
Drop Shipment	Vendor ships directly to customer	`CBNA` / `CBOR`	`CB2`	`CT`
Special Order	Vendor ships to your warehouse, then to customer	`CBUK`	`CBAB`	`CB`

The schedule line category difference is the functional pivot: CT suppresses inventory receipt at the seller’s plant and marks the goods receipt as statistical, while CB creates actual unrestricted stock that feeds a standard outbound delivery.

Billing Relevance — The Critical Configuration Choice

The single most consequential configuration decision in drop shipment is the Billing Relevance field on item category CB2 (VOV7):

Code	Meaning	When to Use
`F`	Order-related — status per invoice quantity	Wait for vendor invoice confirmation before billing the customer; default for CBNA
`G`	Order-related — delivery quantity	Bill at statistical goods receipt; common in North American practice

The practical implication: with code F, the customer invoice cannot be created until MIRO is posted, introducing a dependency on vendor invoice processing timelines. With code G, the customer invoice can be issued as soon as the statistical GR confirms the vendor has shipped — decoupling customer billing from accounts payable.

Component Map — Drop Shipment vs. Special Order

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100
  classDef integration fill:#e8f5e9,stroke:#2e7d32
  classDef target fill:#e3f2fd,stroke:#1565c0
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a

  SO["Sales Order<br>OR - CB2 or CBAB"]:::source
  PR["Purchase Requisition<br>Auto on Save"]:::integration
  PO["Purchase Order<br>ME59N - ME21N"]:::integration

  subgraph DropShip["Drop Shipment - CBNA - CBOR"]
    VendorDS["Vendor Ships to<br>Customer Address"]:::target
    StatGR["Statistical GR<br>No Stock Created"]:::integration
    VendInv["Vendor Invoice<br>MIRO"]:::integration
    CustBill1["Customer Invoice F2<br>Order-Related Billing"]:::target
  end

  subgraph SpecialOrder["Special Order - CBUK"]
    VendorSO["Vendor Ships to<br>Your Warehouse"]:::target
    ActualGR["Actual Goods Receipt<br>Stock Created"]:::integration
    Delivery["Outbound Delivery<br>Pick - Pack - PGI"]:::integration
    CustBill2["Customer Invoice F2<br>Delivery-Related Billing"]:::target
  end

  SO --> PR --> PO
  PO --> VendorDS
  PO --> VendorSO
  VendorDS --> StatGR --> VendInv --> CustBill1
  VendorSO --> ActualGR --> Delivery --> CustBill2

Drop Shipment End-to-End Process

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="DropShipment"
                  targetNamespace="http://sajivfrancis.com/dropship">
  <bpmn:process id="DropShipProcess" isExecutable="false">
    <bpmn:startEvent id="Start" name="Customer Places Order">
      <bpmn:outgoing>flow1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="SalesOrder" name="Create Sales Order - VA01 - OR Type - CB2 Item Category">
      <bpmn:incoming>flow1</bpmn:incoming>
      <bpmn:outgoing>flow2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="PurchReq" name="Auto-Create Purchase Requisition on Save - CT Schedule Line">
      <bpmn:incoming>flow2</bpmn:incoming>
      <bpmn:outgoing>flow3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="PurchOrder" name="Convert to Purchase Order - ME59N - Vendor Address is Customer">
      <bpmn:incoming>flow3</bpmn:incoming>
      <bpmn:outgoing>flow4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="VendorShips" name="Vendor Ships to Customer - EDI 850 - EDI 856 ASN">
      <bpmn:incoming>flow4</bpmn:incoming>
      <bpmn:outgoing>flow5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="StatGR" name="Statistical Goods Receipt - No Inventory Created - MIGO">
      <bpmn:incoming>flow5</bpmn:incoming>
      <bpmn:outgoing>flow6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="VendorInv" name="Vendor Invoice Receipt - MIRO">
      <bpmn:incoming>flow6</bpmn:incoming>
      <bpmn:outgoing>flow7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="GW1" name="Billing Trigger">
      <bpmn:incoming>flow7</bpmn:incoming>
      <bpmn:outgoing>flow8</bpmn:outgoing>
      <bpmn:outgoing>flow9</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="BillStatGR" name="Bill on Statistical GR Qty - Billing Relevance G - VF01">
      <bpmn:incoming>flow8</bpmn:incoming>
      <bpmn:outgoing>flow10</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="BillVendorInv" name="Bill on Vendor Invoice Qty - Billing Relevance F - VF01">
      <bpmn:incoming>flow9</bpmn:incoming>
      <bpmn:outgoing>flow10</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="CustomerInvoice" name="F2 Customer Invoice - AR Posting">
      <bpmn:incoming>flow10</bpmn:incoming>
      <bpmn:outgoing>flow11</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End" name="Drop Shipment Complete">
      <bpmn:incoming>flow11</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="flow1" sourceRef="Start" targetRef="SalesOrder"/>
    <bpmn:sequenceFlow id="flow2" sourceRef="SalesOrder" targetRef="PurchReq"/>
    <bpmn:sequenceFlow id="flow3" sourceRef="PurchReq" targetRef="PurchOrder"/>
    <bpmn:sequenceFlow id="flow4" sourceRef="PurchOrder" targetRef="VendorShips"/>
    <bpmn:sequenceFlow id="flow5" sourceRef="VendorShips" targetRef="StatGR"/>
    <bpmn:sequenceFlow id="flow6" sourceRef="StatGR" targetRef="VendorInv"/>
    <bpmn:sequenceFlow id="flow7" sourceRef="VendorInv" targetRef="GW1"/>
    <bpmn:sequenceFlow id="flow8" name="Bill at shipment - CBOR" sourceRef="GW1" targetRef="BillStatGR"/>
    <bpmn:sequenceFlow id="flow9" name="Bill at vendor invoice - CBNA" sourceRef="GW1" targetRef="BillVendorInv"/>
    <bpmn:sequenceFlow id="flow10a" sourceRef="BillStatGR" targetRef="CustomerInvoice"/>
    <bpmn:sequenceFlow id="flow10" sourceRef="BillVendorInv" targetRef="CustomerInvoice"/>
    <bpmn:sequenceFlow id="flow11" sourceRef="CustomerInvoice" targetRef="End"/>
  </bpmn:process>
</bpmn:definitions>

Copy Control for Drop Shipment Billing

The copy control entry (VTFA — Sales Document to Billing Document) governs how the drop shipment sales order becomes an F2 invoice:

Field	Value
Source order type	`OR`
Target billing type	`F2`
Item category	`CB2`
Billing quantity	`F` (vendor invoice) or `G` (statistical GR)

Cross-reference — Part 1: The schedule line category configuration controlling automatic purchase requisition creation — the Create PO Automatic flag and Order Type field — was introduced in Part 1 §6.4.7. Drop shipment extends that framework by assigning the CT schedule line category, which additionally sets the statistical GR flag and suppresses inventory posting.

Future paper flag: Purchase order creation, vendor master, purchasing info records, and MIRO vendor invoice processing belong to the Procurement / MM paper.

Intercompany Billing and Stock Transfer Orders

The Cross-Company Revenue Problem

When a sales order is fulfilled from a plant belonging to a different company code than the selling sales organization, SAP S/4HANA automatically flags the transaction as intercompany. The selling company posts revenue; the fulfilling company posts cost of goods sold at goods issue. Without an intercompany billing document, the fulfilling company shows an inventory reduction with no offsetting revenue — a gap that violates basic accounting integrity and makes intercompany elimination impossible.

The intercompany billing document type IV resolves this. It is created after the customer-facing F2 invoice and prices the intercompany transaction at an agreed transfer price — not the customer’s sales price — using condition types PI01 or PI02.

Intercompany Pricing Condition Types

Condition Type	Approach	Maintenance Burden
`PI01`	Cost-plus — material cost × configured markup percentage	Minimal; recommended for most implementations
`PI02`	Fixed price list — explicit condition records by material/material group	Ongoing; appropriate where legal entities have negotiated fixed transfer prices

A VOFM requirement routine (022) ensures PI01/PI02 are active only on intercompany billing documents and never appear on customer-facing invoices.

Intercompany Sales — End-to-End Process

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="IntercompanyBilling"
                  targetNamespace="http://sajivfrancis.com/intercompany">
  <bpmn:process id="IntercompanyProcess" isExecutable="false">
    <bpmn:startEvent id="Start" name="Sales Order Entered - Cross-Company Plant">
      <bpmn:outgoing>flow1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="SalesOrder" name="Standard Sales Order - OR Type - Cross-Company Plant Assigned">
      <bpmn:incoming>flow1</bpmn:incoming>
      <bpmn:outgoing>flow2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="ATPCheck" name="ATP Check Allocates Stock in Fulfilling Plant">
      <bpmn:incoming>flow2</bpmn:incoming>
      <bpmn:outgoing>flow3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Delivery" name="Outbound Delivery from Fulfilling Plant - VL01N - LF Type">
      <bpmn:incoming>flow3</bpmn:incoming>
      <bpmn:outgoing>flow4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="PickPack" name="Pick - Pack - Post Goods Issue - Fulfilling Company COGS Posted">
      <bpmn:incoming>flow4</bpmn:incoming>
      <bpmn:outgoing>flow5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="CustomerInvoice" name="Customer Invoice F2 - Revenue Posted to Selling Company - VF01">
      <bpmn:incoming>flow5</bpmn:incoming>
      <bpmn:outgoing>flow6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="IVInvoice" name="Intercompany Invoice IV - VF01 - PI01 or PI02 Transfer Price">
      <bpmn:incoming>flow6</bpmn:incoming>
      <bpmn:outgoing>flow7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="APPosting" name="AP Posted in Selling Company - AR Posted in Fulfilling Company">
      <bpmn:incoming>flow7</bpmn:incoming>
      <bpmn:outgoing>flow8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Clearing" name="Automatic Intercompany Clearing">
      <bpmn:incoming>flow8</bpmn:incoming>
      <bpmn:outgoing>flow9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End" name="Intercompany Cycle Closed">
      <bpmn:incoming>flow9</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="flow1" sourceRef="Start" targetRef="SalesOrder"/>
    <bpmn:sequenceFlow id="flow2" sourceRef="SalesOrder" targetRef="ATPCheck"/>
    <bpmn:sequenceFlow id="flow3" sourceRef="ATPCheck" targetRef="Delivery"/>
    <bpmn:sequenceFlow id="flow4" sourceRef="Delivery" targetRef="PickPack"/>
    <bpmn:sequenceFlow id="flow5" sourceRef="PickPack" targetRef="CustomerInvoice"/>
    <bpmn:sequenceFlow id="flow6" sourceRef="CustomerInvoice" targetRef="IVInvoice"/>
    <bpmn:sequenceFlow id="flow7" sourceRef="IVInvoice" targetRef="APPosting"/>
    <bpmn:sequenceFlow id="flow8" sourceRef="APPosting" targetRef="Clearing"/>
    <bpmn:sequenceFlow id="flow9" sourceRef="Clearing" targetRef="End"/>
  </bpmn:process>
</bpmn:definitions>

Stock Transfer Orders

A stock transfer order (STO) is a purchasing document (ME21N) that treats a source plant as a vendor. It triggers the same delivery and goods-issue logic as a sales order but without a customer-facing transaction. Key configuration:

Step	Transaction / Path	Purpose
Shipping data per plant	`SPRO → MM → Purchasing → STO → Shipping Data`	Assigns a customer number and sales area to each plant for delivery creation
Delivery type by plant	`SPRO → MM → Purchasing → STO → Delivery Type`	Maps PO type to delivery doc type (e.g., `NL`)
Copy control — STO to delivery	`VTLA`	Defines how STO fields copy to the delivery document
Intercompany billing (if applicable)	`VF01` / `VF04`	`IV` billing document for cross-company code STOs

Stock Transfer Order — End-to-End Process

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="STOProcess"
                  targetNamespace="http://sajivfrancis.com/sto">
  <bpmn:process id="STOFlow" isExecutable="false">
    <bpmn:startEvent id="Start" name="Stock Deficit Identified at Receiving Plant">
      <bpmn:outgoing>flow1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="EnterSTO" name="Enter Stock Transfer Order - ME21N - Source Plant as Vendor">
      <bpmn:incoming>flow1</bpmn:incoming>
      <bpmn:outgoing>flow2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="OutboundDel" name="Create Outbound Delivery at Source Plant - VL01N">
      <bpmn:incoming>flow2</bpmn:incoming>
      <bpmn:outgoing>flow3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="PGI" name="Pick - Pack - Post Goods Issue - Stock Leaves Source Plant">
      <bpmn:incoming>flow3</bpmn:incoming>
      <bpmn:outgoing>flow4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="GW1" name="Cross Company Code">
      <bpmn:incoming>flow4</bpmn:incoming>
      <bpmn:outgoing>flow5</bpmn:outgoing>
      <bpmn:outgoing>flow6</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="IVBilling" name="Intercompany Invoice IV - Transfer Price PI01 or PI02">
      <bpmn:incoming>flow5</bpmn:incoming>
      <bpmn:outgoing>flow7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="InboundDel" name="Create Inbound Delivery at Receiving Plant">
      <bpmn:incoming>flow6</bpmn:incoming>
      <bpmn:incoming>flow7</bpmn:incoming>
      <bpmn:outgoing>flow8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="GoodsReceipt" name="Post Goods Receipt - Stock Arrives at Receiving Plant">
      <bpmn:incoming>flow8</bpmn:incoming>
      <bpmn:outgoing>flow9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End" name="Stock Transfer Complete">
      <bpmn:incoming>flow9</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="flow1" sourceRef="Start" targetRef="EnterSTO"/>
    <bpmn:sequenceFlow id="flow2" sourceRef="EnterSTO" targetRef="OutboundDel"/>
    <bpmn:sequenceFlow id="flow3" sourceRef="OutboundDel" targetRef="PGI"/>
    <bpmn:sequenceFlow id="flow4" sourceRef="PGI" targetRef="GW1"/>
    <bpmn:sequenceFlow id="flow5" name="Yes - different company codes" sourceRef="GW1" targetRef="IVBilling"/>
    <bpmn:sequenceFlow id="flow6" name="No - same company code" sourceRef="GW1" targetRef="InboundDel"/>
    <bpmn:sequenceFlow id="flow7" sourceRef="IVBilling" targetRef="InboundDel"/>
    <bpmn:sequenceFlow id="flow8" sourceRef="InboundDel" targetRef="GoodsReceipt"/>
    <bpmn:sequenceFlow id="flow9" sourceRef="GoodsReceipt" targetRef="End"/>
  </bpmn:process>
</bpmn:definitions>

Key Intercompany Configuration Objects

Object	Transaction	Setting
Assign org units by plant	`SPRO → SD → Billing → Intercompany → Assign Org Units by Plant`	Maps fulfilling plant to intercompany sales area
Internal customer by sales org	`SPRO → SD → Billing → Intercompany → Define Internal Customer`	Links selling sales org to intercompany customer number
Copy control — delivery to IV	`VFTA`	Header copy requirement `014`; item copy requirement `015`
Intercompany billing type on order	`VOV8` (OR order type)	`Interco.bill.type` field = `IV`

Cross-reference — Part 1: The organizational structure — the sales organization to company code to plant assignment chain — was established in Part 1 §1.1. That assignment is precisely what makes a transaction “intercompany.” Without a cross-company code plant assignment, the IV billing type field on the order type is never invoked, and no intercompany document is created.

Future paper flag: The AP/AR intercompany clearing journal entries, trading partner configuration, and elimination logic in consolidated financial statements belong to the FI-CO Integration paper and the anticipated Group Reporting paper.

Revenue Recognition under IFRS 15 / ASC 606

The Compliance Problem

IFRS 15 (effective January 2018) and its US GAAP equivalent, ASC 606, require revenue to be recognized when — or as — control of goods or services transfers to the customer. For standard product sales, this means at the point of confirmed delivery to the customer’s location, not at the moment goods leave the seller’s warehouse. Under the previous IAS 18 standard, the timing of revenue recognition and the timing of goods issue were often treated as equivalent. Post-IFRS 15, that assumption fails whenever transit time is material.

Recognition Approaches in SAP S/4HANA

SAP S/4HANA offers three main approaches, each with different implementation complexity and compliance depth:

Approach	Mechanism	Best For
Manual reclassification	Month-end journal entry; reverse deferred revenue based on estimated transit days	Simple scenarios; low volume; short and predictable transit times
Valuated Stock-in-Transit (VSIT)	Movement type 687 at PGI; movement type 601 at POD confirmation	Companies with variable or internationally long transit times; native S/4HANA
SAP Revenue Accounting and Reporting (RAR)	Standalone add-on; full performance obligation model per IFRS 15 five-step framework	Complex multi-element contracts; subscription bundling; software and services

Valuated Stock-in-Transit Deep Dive

VSIT is the native S/4HANA solution for physical goods. At Post Goods Issue, instead of posting directly to COGS with movement type 601, the system uses movement type 687, placing inventory into an in-transit special stock category. The asset remains on the balance sheet. No revenue, no COGS — the goods are legally still traveling.

At Proof of Delivery — registered via Transaction VLPOD or via carrier EDI 214 confirmation — the MvT Iss. Val. SIT field on the schedule line category triggers movement type 601, consuming the in-transit stock to COGS and simultaneously releasing the delivery as billable.

Configuration path:

SPRO → SD → Sales → Sales Documents → Schedule Lines → Define Schedule Line Categories
  MvT (PGI):            687
  MvT Iss. Val. SIT:    601
  Spec.Iss.Val.SIT:     3   (consume stock from in-transit)

SAP delivers order type ORNC with pre-configured schedule line categories N1 and N2 as a starting point for VSIT deployments. N1 handles standard delivery from stock; N2 handles backorder scenarios.

VSIT Process Flow

sequenceDiagram
  participant SO as Sales Order
  participant WH as Warehouse
  participant INV as Inventory Ledger
  participant FI as Finance
  participant POD as POD Event

  SO->>WH: Delivery Document Created
  WH->>INV: Post Goods Issue - Movement Type 687
  Note over INV: Stock moves to In-Transit<br>COGS NOT yet posted
  INV->>FI: In-Transit Asset Remains on Balance Sheet
  POD->>INV: Proof of Delivery Confirmed via VLPOD
  INV->>FI: Movement Type 601 - COGS Posted
  FI->>SO: Delivery Status Set to Billable
  SO->>FI: F2 Invoice Created - Revenue Recognized

Revenue Recognition Approach Comparison

The following chart expresses the qualitative trade-offs across the three approaches on four operational dimensions. All scores are relative assessments derived from the source material’s descriptions; they are not published SAP benchmarks.

{
  "data": [
    {
      "type": "bar",
      "name": "Manual Reclassification",
      "x": ["Implementation Cost", "Ongoing Effort", "Compliance Depth", "Automation Level"],
      "y": [1, 3, 2, 1],
      "marker": {"color": "#e65100"}
    },
    {
      "type": "bar",
      "name": "VSIT - Native S4HANA",
      "x": ["Implementation Cost", "Ongoing Effort", "Compliance Depth", "Automation Level"],
      "y": [2, 1, 3, 3],
      "marker": {"color": "#2e7d32"}
    },
    {
      "type": "bar",
      "name": "SAP RAR Add-on",
      "x": ["Implementation Cost", "Ongoing Effort", "Compliance Depth", "Automation Level"],
      "y": [4, 2, 5, 4],
      "marker": {"color": "#1565c0"}
    }
  ],
  "layout": {
    "title": "Revenue Recognition Approach Comparison (1=Low, 5=High) - Author Estimate",
    "barmode": "group",
    "yaxis": {"title": "Score 1-5", "range": [0, 6]},
    "xaxis": {"title": "Dimension"},
    "legend": {"orientation": "h", "y": -0.3}
  }
}

Cross-reference — Part 1: POD relevance is activated on the customer master (shipping tab) and the delivery item category. Part 1 §9.10 introduced POD configuration in the context of standard delivery. VSIT extends that same configuration by adding movement type logic on the schedule line category — the same object introduced in Part 1 §6.4.7.

Future paper flag: Balance sheet treatment of in-transit inventory, deferred revenue journal entries, IFRS 15 performance obligation modeling, and SAP RAR integration belong to the FI-CO Integration paper and the Billing and Revenue (BRIM) paper.

Advanced Returns Management

ARM vs. Lean Returns

SAP S/4HANA offers two returns processing tracks, and the selection has significant implications for logistics execution, financial control, and downstream reporting:

Feature	Advanced Returns Management	Lean Returns
Order type	`CBAR`	`RE`
Follow-up action control	Explicit follow-up codes per line item	Standard delivery processing only
Refund codes	Configurable percentage-based codes	Standard credit memo
Inspection at customer site	Supported	Not supported
Replacement shipment	Integrated — follow-up action `0021`	Requires a separate free-of-charge order
Approval workflow	Built-in — Blocked for Release / Item to be Revised statuses	Manual credit memo request

ARM is the recommended track for any scenario where the disposition of returned goods is not uniform — where some items are restocked, some scrapped, some returned to a vendor, and some remain at the customer site for field disposal. The follow-up action and refund code model gives that flexibility at the line-item level within a single return order.

ARM Follow-Up Action Reference

Code	Action	Logistics Impact
`0001`	Receive into plant	Inbound delivery `LR2`; goods receipt to blocked stock
`0004`	Ship to other plant	Subsequent STO created automatically
`0005`	Ship to vendor	Vendor return purchase order created
`0007`	Direct shipment to vendor	No inbound delivery; customer ships directly to vendor
`0008`	Inspection at customer site	Field inspector dispatched; no goods movement until result
`0009`	Delivery into plant — materials unknown	GR quantity correctable after receipt
`0013`	Material remains at customer	No logistics movement of any kind
`0021`	Send back to customer	Replacement outbound delivery created
`0011` (Next)	Transfer to free available stock	Unrestricted stock after quality inspection
`0012` (Next)	Transfer to scrap	Disposal movement — goods issue to scrap account

ARM End-to-End Process

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="ARM"
                  targetNamespace="http://sajivfrancis.com/arm">
  <bpmn:process id="ARMProcess" isExecutable="false">
    <bpmn:startEvent id="Start" name="Customer Requests Return">
      <bpmn:outgoing>flow1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="CreateRMA" name="Create CBAR Return Order - VA01 - With or Without Reference">
      <bpmn:incoming>flow1</bpmn:incoming>
      <bpmn:outgoing>flow2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="SelectFollowUp" name="Assign Follow-Up Action and Refund Code per Line Item">
      <bpmn:incoming>flow2</bpmn:incoming>
      <bpmn:outgoing>flow3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="GW1" name="Follow-Up Action">
      <bpmn:incoming>flow3</bpmn:incoming>
      <bpmn:outgoing>flow4</bpmn:outgoing>
      <bpmn:outgoing>flow5</bpmn:outgoing>
      <bpmn:outgoing>flow6</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="ReceiveReturn" name="0001 - Inbound Delivery LR2 - Goods Receipt at Plant">
      <bpmn:incoming>flow4</bpmn:incoming>
      <bpmn:outgoing>flow7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="DirectVendor" name="0007 - Direct Shipment to Vendor - No Inbound Delivery">
      <bpmn:incoming>flow5</bpmn:incoming>
      <bpmn:outgoing>flow7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="DisposeInField" name="0013 - Material Remains at Customer Site - No Logistics">
      <bpmn:incoming>flow6</bpmn:incoming>
      <bpmn:outgoing>flow7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="GW2" name="Refund Control">
      <bpmn:incoming>flow7</bpmn:incoming>
      <bpmn:outgoing>flow8</bpmn:outgoing>
      <bpmn:outgoing>flow9</bpmn:outgoing>
      <bpmn:outgoing>flow10</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="ApprovedCredit" name="P - Approved - Auto Credit Memo CBRE">
      <bpmn:incoming>flow8</bpmn:incoming>
      <bpmn:outgoing>flow11</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="CreditRequest" name="R - Credit Memo Request - Finance Approval Required">
      <bpmn:incoming>flow9</bpmn:incoming>
      <bpmn:outgoing>flow11</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="NoRefund" name="N - No Refund - Rejection Reason Documented">
      <bpmn:incoming>flow10</bpmn:incoming>
      <bpmn:outgoing>flow11</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End" name="Return Cycle Closed">
      <bpmn:incoming>flow11</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="flow1" sourceRef="Start" targetRef="CreateRMA"/>
    <bpmn:sequenceFlow id="flow2" sourceRef="CreateRMA" targetRef="SelectFollowUp"/>
    <bpmn:sequenceFlow id="flow3" sourceRef="SelectFollowUp" targetRef="GW1"/>
    <bpmn:sequenceFlow id="flow4" name="Receive at warehouse" sourceRef="GW1" targetRef="ReceiveReturn"/>
    <bpmn:sequenceFlow id="flow5" name="Direct to vendor" sourceRef="GW1" targetRef="DirectVendor"/>
    <bpmn:sequenceFlow id="flow6" name="Dispose in field" sourceRef="GW1" targetRef="DisposeInField"/>
    <bpmn:sequenceFlow id="flow7a" sourceRef="ReceiveReturn" targetRef="GW2"/>
    <bpmn:sequenceFlow id="flow7b" sourceRef="DirectVendor" targetRef="GW2"/>
    <bpmn:sequenceFlow id="flow7" sourceRef="DisposeInField" targetRef="GW2"/>
    <bpmn:sequenceFlow id="flow8" name="Approved" sourceRef="GW2" targetRef="ApprovedCredit"/>
    <bpmn:sequenceFlow id="flow9" name="Needs approval" sourceRef="GW2" targetRef="CreditRequest"/>
    <bpmn:sequenceFlow id="flow10" name="No refund" sourceRef="GW2" targetRef="NoRefund"/>
    <bpmn:sequenceFlow id="flow11a" sourceRef="ApprovedCredit" targetRef="End"/>
    <bpmn:sequenceFlow id="flow11b" sourceRef="CreditRequest" targetRef="End"/>
    <bpmn:sequenceFlow id="flow11" sourceRef="NoRefund" targetRef="End"/>
  </bpmn:process>
</bpmn:definitions>

ARM Configuration Reference

Object	Transaction	Key Setting
Return reasons	`MSR_RETURNS_REASON`	3-character code + description
Refund codes	`MSR_RETURNS_REFUND`	3-character code; maps to refund percentage
CBAR order type	`VOV8`	Order type `CBAR`; default delivery block recommended
Credit memo type	`VOFA`	`CBRE` — returns credit billing document type
Inbound delivery type	`0VLK`	`LR2` for ARM inbound returns

Cross-reference — Part 1: Reason for rejection configuration (Part 1 §6.2.8) feeds the CMR Rej. Reason field on the CBAR line item, documenting why a credit was declined. The incompletion procedure (Part 1 §6.5) can be configured to require return reason and refund code entry before the RMA order is saveable — enforcing process discipline at creation time.

Future paper flag: Warranty cost accounting, cost center assignments for free-of-charge replacement shipments, and GL account determination for returns credit memos belong to the FI-CO Integration paper and the Account Determination paper — the latter being a natural extension of the account determination framework introduced in Part 1 §10.4.

Customer Consignment

Process Logic

Customer consignment places your inventory at the customer’s premises while retaining ownership until consumption is reported. This creates a special stock category — customer consignment stock — tracked by customer number under either the ship-to partner (SH) or a dedicated consignment special stock partner (SB). No revenue or cost of goods sold posts at fill-up time. Both flow only when the customer confirms they have consumed the material.

Order Type Reference

Order Type	Purpose	Billing Triggered	Delivery Type
`CCFU`	Consignment Fill-Up — replenish stock at customer	None at fill-up	`LF`
`CCIS`	Consignment Issue — bill reported consumption	Yes — F2 invoice	`CCLF`
`CCPU`	Consignment Pick-Up — retrieve unsold stock	None	`LR`
`CCRE`	Consignment Return — credit for incorrectly billed consumption	Yes — credit memo	`CCLR`

The CCLF delivery type for consignment issue is notable: it is configured to trigger automatic Post Goods Issue without a physical pick step, because the goods have already been physically at the customer’s site since the fill-up. The issue delivery is a legal and accounting event, not a logistics event.

Consignment Fill-Up and Issue — End-to-End Process

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="Consignment"
                  targetNamespace="http://sajivfrancis.com/consignment">
  <bpmn:process id="ConsignmentProcess" isExecutable="false">
    <bpmn:startEvent id="Start" name="Customer Requests Replenishment">
      <bpmn:outgoing>flow1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="FillUp" name="Consignment Fill-Up Order - CCFU - Free Goods Pricing">
      <bpmn:incoming>flow1</bpmn:incoming>
      <bpmn:outgoing>flow2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="ATPCheck" name="ATP Check - Allocate Stock">
      <bpmn:incoming>flow2</bpmn:incoming>
      <bpmn:outgoing>flow3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Delivery" name="Outbound Delivery - LF Type - Pick - Pack - PGI">
      <bpmn:incoming>flow3</bpmn:incoming>
      <bpmn:outgoing>flow4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="CustomerStock" name="Stock Moves to Customer Special Stock - No Revenue Posted">
      <bpmn:incoming>flow4</bpmn:incoming>
      <bpmn:outgoing>flow5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="CustomerConsumes" name="Customer Consumes Inventory - Notifies Vendor of Qty">
      <bpmn:incoming>flow5</bpmn:incoming>
      <bpmn:outgoing>flow6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="IssueOrder" name="Consignment Issue Order - CCIS - Pricing Active">
      <bpmn:incoming>flow6</bpmn:incoming>
      <bpmn:outgoing>flow7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="IssueDel" name="CCLF Delivery - Automatic PGI - No Physical Pick Required">
      <bpmn:incoming>flow7</bpmn:incoming>
      <bpmn:outgoing>flow8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Invoice" name="F2 Invoice Created - Revenue and COGS Posted Simultaneously">
      <bpmn:incoming>flow8</bpmn:incoming>
      <bpmn:outgoing>flow9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End" name="Consignment Issue Cycle Complete">
      <bpmn:incoming>flow9</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="flow1" sourceRef="Start" targetRef="FillUp"/>
    <bpmn:sequenceFlow id="flow2" sourceRef="FillUp" targetRef="ATPCheck"/>
    <bpmn:sequenceFlow id="flow3" sourceRef="ATPCheck" targetRef="Delivery"/>
    <bpmn:sequenceFlow id="flow4" sourceRef="Delivery" targetRef="CustomerStock"/>
    <bpmn:sequenceFlow id="flow5" sourceRef="CustomerStock" targetRef="CustomerConsumes"/>
    <bpmn:sequenceFlow id="flow6" sourceRef="CustomerConsumes" targetRef="IssueOrder"/>
    <bpmn:sequenceFlow id="flow7" sourceRef="IssueOrder" targetRef="IssueDel"/>
    <bpmn:sequenceFlow id="flow8" sourceRef="IssueDel" targetRef="Invoice"/>
    <bpmn:sequenceFlow id="flow9" sourceRef="Invoice" targetRef="End"/>
  </bpmn:process>
</bpmn:definitions>

Consignment Reversal — Pick-Up and Return

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="ConsignmentReversal"
                  targetNamespace="http://sajivfrancis.com/consignmentreversal">
  <bpmn:process id="ReversalProcess" isExecutable="false">
    <bpmn:startEvent id="Start" name="Reversal or Pick-Up Required">
      <bpmn:outgoing>flow1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:exclusiveGateway id="GW1" name="Reversal Type">
      <bpmn:incoming>flow1</bpmn:incoming>
      <bpmn:outgoing>flow2</bpmn:outgoing>
      <bpmn:outgoing>flow3</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="PickUp" name="CCPU Order - Retrieve Unsold Stock from Customer - Inbound Delivery LR">
      <bpmn:incoming>flow2</bpmn:incoming>
      <bpmn:outgoing>flow4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Return" name="CCRE Order - Credit for Incorrectly Billed Consumption">
      <bpmn:incoming>flow3</bpmn:incoming>
      <bpmn:outgoing>flow5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="PickUpGR" name="Post Goods Receipt - Stock Returns to Your Unrestricted Inventory">
      <bpmn:incoming>flow4</bpmn:incoming>
      <bpmn:outgoing>flow6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="ReturnCredit" name="CCLR Delivery - Post Goods Receipt - CCRE Credit Memo Issued">
      <bpmn:incoming>flow5</bpmn:incoming>
      <bpmn:outgoing>flow6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End" name="Reversal Complete">
      <bpmn:incoming>flow6</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="flow1" sourceRef="Start" targetRef="GW1"/>
    <bpmn:sequenceFlow id="flow2" name="Physical pick-up" sourceRef="GW1" targetRef="PickUp"/>
    <bpmn:sequenceFlow id="flow3" name="Billing correction" sourceRef="GW1" targetRef="Return"/>
    <bpmn:sequenceFlow id="flow4" sourceRef="PickUp" targetRef="PickUpGR"/>
    <bpmn:sequenceFlow id="flow5" sourceRef="Return" targetRef="ReturnCredit"/>
    <bpmn:sequenceFlow id="flow6a" sourceRef="PickUpGR" targetRef="End"/>
    <bpmn:sequenceFlow id="flow6" sourceRef="ReturnCredit" targetRef="End"/>
  </bpmn:process>
</bpmn:definitions>

Key Design Decision — Special Stock Partner

The most consequential consignment master data decision is whether to track inventory at the ship-to level (multiple customer numbers; granular location visibility) or under a single SB special stock partner (one aggregated bucket regardless of physical location).

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100
  classDef integration fill:#e8f5e9,stroke:#2e7d32
  classDef target fill:#e3f2fd,stroke:#1565c0
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a

  Q{"Granular location<br>tracking required?"}:::integration

  ShipTo["Track by Ship-To - SH Partner<br>Separate customer stock per location<br>Supports cycle counts per site"]:::target
  SBPartner["Track by SB Partner<br>Single customer stock bucket<br>Customer moves stock freely"]:::source

  Trade1["Pro: Full traceability per site<br>Con: Customer must notify you<br>of every internal movement"]:::reporting
  Trade2["Pro: No master data sprawl<br>Con: Cannot reconcile by location<br>Contract accountability required"]:::reporting

  Q -- Yes --> ShipTo --> Trade1
  Q -- No --> SBPartner --> Trade2

Cross-reference — Part 1: Customer master partner determination (Part 1 §2.3.5) and the SH/SB partner function configuration are prerequisites for consignment special stock tracking. The Special Stock field on the item category — configured in Part 1 §6.2.10 — must be set to W (customer) on the CCFU/CCIS item categories to activate the customer stock movement type logic.

Future paper flag: MM vendor consignment — the exact mirror of this process, with your company as the buyer — belongs to the Procurement / MM paper. Inventory valuation of customer consignment stock and the balance sheet implications of holding goods at customer sites belong to the FI-CO / Inventory Accounting paper.

OTC Reporting and SAP Fiori Analytics

Reporting Architecture Overview

OTC reporting in SAP S/4HANA operates across three layers — transactional, operational, and analytical — each served by different tools and data paths. The transactional layer provides line-item visibility into individual documents. The operational layer manages work queues: what needs to be billed, what is stuck, what failed. The analytical layer surfaces KPIs and trends across periods.

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100
  classDef integration fill:#e8f5e9,stroke:#2e7d32
  classDef target fill:#e3f2fd,stroke:#1565c0
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a

  subgraph TRANSACT["Transactional Monitoring"]
    VA03["VA03 - Display Sales Order"]:::source
    VF03["VF03 - Display Billing Doc"]:::source
    VL03N["VL03N - Display Delivery"]:::source
    DocFlow["Document Flow - All Transactions"]:::source
  end

  subgraph OPERATIONAL["Operational Due Lists"]
    VF04["VF04 - Billing Due List"]:::integration
    VL10["VL10 - Delivery Due List"]:::integration
    VV2["V-V2 - Backorder Rescheduling"]:::integration
    V21["V.21 - Collective Processing Log"]:::integration
  end

  subgraph FIORI["SAP Fiori Apps"]
    MSO["Manage Sales Orders"]:::reporting
    MBDL["Monitor Billing - Due List"]:::reporting
    BOR["Backorder Reporting"]:::reporting
    PAL["Manage Product Allocation"]:::reporting
  end

  subgraph HANA["HANA Analytics"]
    CDS["CDS Views - Real-Time KPIs"]:::target
    SAC["SAP Analytics Cloud"]:::target
    BW["SAP BW - BW4HANA"]:::target
  end

  TRANSACT --> OPERATIONAL
  OPERATIONAL --> FIORI
  FIORI --> HANA

Core Fiori Apps for OTC Operations

Fiori App	Purpose	Key Fields Monitored
Manage Sales Orders	Real-time order status across the portfolio	Overall status; delivery status; billing status; rejection status
Billing Due List	Identify and process deliveries ready for invoicing (`VF04` equivalent)	Billing date; billing type; sold-to party; billing block
Monitor Backorders	Identify unconfirmed sales order lines; reschedule	Confirmed quantity = 0; material; plant; requested delivery date
Manage Product Allocation	Create and modify allocation objects and buying sequences	Allocation object; period type; characteristic values
Manage Product Allocation Planning Data	Set per-customer quantity limits	Sold-to party; quantity per period; validity
Configure Product Allocation	Define allocation rules and constraints	Allocation rate; validity dates; consumption sequence

Key Operational Transactions

Transaction	Purpose	Typical User
`VF04`	Billing Due List — collective billing run	AR / Billing team
`VL10`	Delivery Due List — create deliveries in bulk	Logistics coordinator
`V_V2`	Backorder rescheduling — re-run ATP for open orders	Customer service
`V.21`	Collective processing log — monitor billing errors	Billing administrator
`CO09`	Availability overview — stock situation per material and plant	Customer service
`MB5SIT`	Stock in transit — query in-transit quantities for VSIT	Inventory controller

Backorder Rescheduling — Sort Priority Logic

When V_V2 runs, it re-executes ATP for all open orders and allocates available stock following a configurable priority sequence. The sequence determines which orders get confirmed first when supply is insufficient to cover all demand:

{
  "data": [
    {
      "type": "funnel",
      "y": [
        "1. Document Category",
        "2. Delivery Priority",
        "3. Date - Creation or Earliest Schedule Line",
        "4. Document Number",
        "5. Document Item"
      ],
      "x": [100, 80, 60, 40, 20],
      "textinfo": "label+percent previous",
      "marker": {
        "color": ["#1565c0", "#1976d2", "#1e88e5", "#42a5f5", "#90caf9"]
      }
    }
  ],
  "layout": {
    "title": "V-V2 Backorder Rescheduling - Sort Priority Sequence",
    "margin": {"l": 280}
  }
}

Delivery priority is set on the sales order header and sourced from the customer master (shipping tab). Organizations that differentiate strategic accounts from standard accounts use this field to ensure premium customers are always confirmed first in shortage scenarios.

Cross-reference — Part 1: The ATP check mechanics, forward/backward scheduling, and scope of check configuration (OVZ9) were established in Part 1 §7. Backorder rescheduling via V_V2 re-executes those same ATP rules across the entire open order book simultaneously, rather than order by order.

Future paper flag: CDS view architecture for OTC, SAP BW/4HANA OTC data flows, and SAP Analytics Cloud dashboard design belong to the Analytics and Reporting paper. The V.21 error log management, billing background job scheduling, and collective processing monitoring belong to an anticipated OTC Operations and Monitoring paper (Part 3 of this series).

Integration Map: OTC and the Broader SAP Knowledge Graph

The following diagram maps the outbound integration surface of the OTC domain — where each Part 2 specialty scenario connects to other SAP functional areas and to the papers that will cover them.

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100
  classDef integration fill:#e8f5e9,stroke:#2e7d32
  classDef target fill:#e3f2fd,stroke:#1565c0
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a

  OTC["OTC Core<br>Parts 1 and 2"]:::integration

  subgraph FI["FI - Financial Accounting"]
    AR["Accounts Receivable<br>Customer Invoice Clearing"]:::target
    AP["Accounts Payable<br>Vendor Invoice - MIRO"]:::target
    DEFER["Deferred Revenue<br>VSIT - IFRS 15 - ASC 606"]:::target
    IC["Intercompany Clearing<br>IV Billing Document"]:::target
  end

  subgraph CO["CO - Controlling"]
    PA["Profitability Analysis<br>CO-PA Margin Reporting"]:::reporting
    CC["Cost Centers<br>Free-of-Charge Orders"]:::reporting
    PC["Profit Centers<br>Derived from Material Master"]:::reporting
  end

  subgraph MM["MM - Materials Management"]
    PO["Purchase Orders<br>Drop Ship - Special Order - STO"]:::source
    GR["Goods Receipt<br>Special Order - STO Inbound"]:::source
    VI["Vendor Invoice<br>MIRO - Rebate Settlement"]:::source
  end

  subgraph EWM["EWM - Extended Warehouse Mgmt"]
    TO["Transfer Orders<br>Pick - Pack - Confirm"]:::integration
    HU["Handling Units<br>Packing Operations"]:::integration
  end

  subgraph TM["TM - Transportation Mgmt"]
    SHP["Shipment Documents<br>Carrier Tendering"]:::integration
    POD2["Proof of Delivery<br>VLPOD - Carrier EDI"]:::integration
  end

  subgraph GTS["GTS - Global Trade Services"]
    EXP["Export Control<br>Proforma Invoices"]:::reporting
    CUST["Customs Compliance<br>Commercial Invoice"]:::reporting
  end

  subgraph PP["PP - Production Planning"]
    MRP["MRP - Transfer of Requirements<br>Make-to-Order and Make-to-Stock"]:::integration
    PROD["Production Orders<br>ATP Scope of Check"]:::integration
  end

  OTC -->|"Revenue - COGS - AR"| FI
  OTC -->|"Margin and Cost Allocation"| CO
  OTC -->|"Procurement Trigger"| MM
  OTC -->|"Delivery Execution"| EWM
  OTC -->|"Shipment Planning"| TM
  OTC -->|"Compliance Documents"| GTS
  OTC -->|"Demand Signal"| PP

Context Model: How Part 2 Connects to Part 1 and Future Papers

Backward Connections to Part 1

Part 2 Topic	Depends on Part 1 Section	Nature of Dependency
Rebate management	§4 Pricing — condition technique	Rebate condition types live inside the Part 1 pricing procedure; same access sequence and condition record framework
Drop shipment billing	§6.4.7 Schedule lines; §8 Delivery	`CT` schedule line category; copy control from OR to F2
Intercompany billing	§1.1 Org structure; §6 Sales orders	Cross-company plant assignment is the trigger for `IV` billing
VSIT and revenue recognition	§9.10 Proof of delivery	POD flag on customer master; movement type field on schedule line category
Advanced returns management	§6.2.8 Rejection reasons; §6.5 Incompletion	Rejection reason feeds CMR Rej. Reason on CBAR line; incompletion enforces RMA data entry
Customer consignment	§6.2.10 Item categories; §2.3.5 Partner determination	`Special Stock` field on item category; SH/SB partner function
OTC reporting and Fiori	§7 ATP; §9 Delivery	`V_V2` re-executes Part 1 ATP rules; Fiori apps read Part 1 document status fields

Forward Connections to Anticipated Papers

Anticipated Paper	Part 2 Scenarios That Feed It
FI-CO Integration	Rebate accrual GL entries; VSIT balance sheet treatment; intercompany AP/AR clearing; COGS/revenue account determination; cost center for free-of-charge replacements
Procurement / MM	Drop shipment PO creation and statistical GR; STO goods receipt; vendor consignment as the mirror of customer consignment; `MIRO` vendor invoice processing
Warehouse Management / EWM	Consignment `CCLF` auto-PGI logic; ARM inbound delivery `LR2` putaway and inspection; decentralized WMS for consignment replenishment scenarios
Transportation Management	Shipment documents for STO lanes; POD carrier EDI 214 integration for VSIT compliance
Analytics and Reporting	Fiori OTC apps; CDS views underlying backorder and billing due list apps; SAP Analytics Cloud OTC dashboards; BW/4HANA data flows
Global Trade Services	Proforma invoices (F5/F8) for export customs; intercompany IV documentation for customs valuation
Billing and Revenue (BRIM)	SAP RAR integration for complex multi-element arrangements; subscription order management connecting to the OTC document flow
Group Reporting	Intercompany elimination; IV billing document as the source record for trading partner reconciliation in consolidated financial statements

Full OTC Architecture — Parts 1 and 2 Combined

flowchart LR
  classDef source fill:#fff3e0,stroke:#e65100
  classDef integration fill:#e8f5e9,stroke:#2e7d32
  classDef target fill:#e3f2fd,stroke:#1565c0
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a

  subgraph P1["Part 1 - Foundation"]
    MD["Master Data<br>BP - Material - Pricing"]:::source
    SO["Sales Order<br>OR - ATP - Incompletion"]:::source
    DEL["Delivery<br>Pick - Pack - PGI"]:::integration
    BILL["Standard Billing<br>F2 Invoice"]:::target
  end

  subgraph P2["Part 2 - Advanced Scenarios"]
    REB["Rebate<br>B1 - B2 Settlement"]:::reporting
    DS["Drop Shipment<br>CB2 - Statistical GR"]:::integration
    IC["Intercompany<br>IV - PI01 - PI02"]:::integration
    REV["Revenue Recognition<br>VSIT - POD - RAR"]:::target
    RET["Returns<br>CBAR - ARM"]:::source
    CON["Consignment<br>CCFU - CCIS - CCPU - CCRE"]:::source
    RPT["Reporting<br>Fiori - V-V2 - VF04"]:::reporting
  end

  MD --> SO --> DEL --> BILL
  BILL --> REB
  SO --> DS --> BILL
  DEL --> IC
  DEL --> REV
  BILL --> RET
  DEL --> CON
  BILL --> RPT
  P1 --> P2

Recommendation and Conclusion

Where Implementations Get Into Trouble

Part 2 scenarios fail for predictable reasons. The root cause is almost always the same: teams treat them as isolated configuration tasks rather than as extensions of the foundational architecture established in Part 1.

Rebate management fails when the billing document type is not flagged as rebate-relevant before go-live. Months of invoices accumulate with no accruals, and the first settlement produces a surprise debit that the business cannot reconcile.

Drop shipment fails when the billing relevance flag is set incorrectly for the operational model. Choosing code F in an environment where vendor invoices arrive weeks late means customer billing is delayed by the AP team’s processing speed — an operational dependency that should be a business decision, not an accidental default.

Intercompany billing fails when the organizational assignments — internal customer by sales org, org units by plant — are incomplete. The IV billing type on the order type is a dead configuration entry without those cross-references. The symptom is that VF04 never shows IV documents in the billing due list.

VSIT fails when the schedule line category configuration is applied to existing order types without regression-testing the movement type impact on existing open orders. Movement type changes are not backward-compatible with posted goods issues.

ARM fails when return reasons and refund codes are not configured before the first CBAR order is created. SAP blocks the RMA from saving if mandatory follow-up action fields are empty, but without the reason codes, customer service cannot complete the order and escalates to IT.

Consignment fails when the special stock partner decision is deferred. The system will default to ship-to, and once consignment stock is posted under multiple ship-to numbers, consolidating it requires manual stock transfers — an operational correction that auditors will notice.

Architectural Principles That Hold Across All Scenarios

Three principles emerged consistently across the Part 2 scenarios:

First, document type is the control point. Every specialty scenario has its own billing document type or order type: IV, CBAR, CCFU, B1/B2, F. Each carries its own copy control rules, billing relevance, account determination, and partner determination. Before any other configuration, the document type must be defined and its control fields set correctly.

Second, the copy control chain is the data pipeline. SAP does not carry fields automatically from one document to the next — the copy control entry, copying requirement, and data transfer routine govern exactly which fields flow and under what conditions. Every specialty scenario — drop shipment, intercompany, consignment issue, returns credit — has a specific copy control requirement that must be verified.

Third, master data is the upstream dependency. The customer master (partner functions, shipping conditions, rebate relevance, POD flag, special stock partner) and the material master (item category group, MRP type, valuation class) are the inputs that determine which document types and item categories SAP selects automatically. If the master data is wrong, the document flow will be wrong, and no downstream configuration can compensate.

The Series Ahead

Part 1 established the mechanics. Part 2 established the advanced scenarios. The papers that follow will take the output of the OTC cycle — the posted revenue, the cleared receivable, the COGS entry, the intercompany balance — and trace it through Financial Accounting, Controlling, and Group Reporting. The integration points documented throughout Parts 1 and 2 — account keys ERB and ERU, movement types 687 and 601, the IV billing document’s AP and AR postings, the credit memo’s account determination — are the exact entry points for those future papers. The OTC series is complete when the full arc from customer inquiry to consolidated financial statement is documented, end to end, with the same standard of process precision applied here.