Order-to-Cash in SAP S/4HANA — White Paper, Part 1

Executive Summary

The Order-to-Cash (OTC) process is the revenue spine of any SAP S/4HANA implementation. It connects commercial intent — a customer placing an order — to financial reality: cash received, revenue recognized, and the general ledger updated. In SAP S/4HANA, OTC is not a single module but a tightly coupled system spanning Sales & Distribution (SD), Logistics Execution (LE), and Financial Accounting/Controlling (FI/CO), all underpinned by the Universal Journal (ACDOCA) as the single source of truth.

This white paper, Part 1, establishes the architectural foundation: organizational structures, master data, the condition technique, the end-to-end business process flow, finance integration touchpoints, and — critically — how PGI and billing release to accounting can be fully automated to eliminate period-end revenue distortion risk. Part 2 will cover advanced scenarios including rebate management, intercompany billing, revenue recognition under IFRS 15, and analytics.

The central argument: OTC in S/4HANA is only as strong as the configuration decisions made before go-live and the automation posture adopted for the two financial posting events that matter most — Post Goods Issue and billing release to accounting. Getting both right produces a self-running revenue cycle. Getting either wrong produces month-end chaos.

1. Organizational Architecture

Before a single sales order can be entered, SAP S/4HANA requires a fully defined organizational hierarchy. This is not bureaucratic overhead — it is the structural key that routes every transaction to the correct legal entity, financial account, and reporting dimension. These decisions are permanent: changing organizational structure after go-live, once master data and transactions exist in the system, is too disruptive to be a viable option.

1.1 The Hierarchy

The OTC organizational model nests within the broader SAP enterprise structure. At its core, the Sales Area — the combination of Sales Organization, Distribution Channel, and Division — is the atomic unit of every sales transaction. Every sales order, every delivery, every billing document carries a Sales Area. Everything else resolves from it.

flowchart TD
    classDef finance fill:#fff3b0,stroke:#cc9a06
    classDef sales fill:#b8d4f0,stroke:#1565c0
    classDef logistics fill:#c5e8c5,stroke:#2e7d32
    classDef shared fill:#f3e5f5,stroke:#6a1b9a

    CC["Company Code<br>(Legal Entity)"]
    SO["Sales Organization"]
    DC["Distribution Channel"]
    DV["Division"]
    SA["Sales Area<br>(SOrg + DCh + Div)"]
    PL["Plant"]
    SP["Shipping Point"]
    CCA["Credit Control Area"]

    CC --> SO
    SO --> DC
    SO --> DV
    DC --> SA
    DV --> SA
    SA --> PL
    PL --> SP
    CC --> CCA
    SA --> CCA

    class CC finance
    class SO,DC,DV,SA sales
    class PL,SP logistics
    class CCA shared

1.2 AAPM Reference Model

Throughout this white paper, the American Automotive Parts Manufacturer (AAPM) example grounds configurations in a real-world context. AAPM operates two legal entities (US01, CA01) across three distribution channels — Original Equipment (OE), Aftermarket (AM), and Intercompany (IC) — yielding seven distinct sales areas.

Sales Org	Distribution Channel	Division	Sales Area ID	Business Purpose
US01	OE	00	US01-OE-00	OEM Sales USA
US01	AM	00	US01-AM-00	Aftermarket USA
US01	AM	PP	US01-AM-PP	Performance Parts USA
US01	IC	00	US01-IC-00	Intercompany USA
CA01	OE	00	CA01-OE-00	OEM Sales Canada
CA01	AM	00	CA01-AM-00	Aftermarket Canada
CA01	IC	00	CA01-IC-00	Intercompany Canada

The IC distribution channel in both entities is the seed for intercompany billing — a topic addressed fully in Part 2.

2. Master Data Architecture

OTC master data is the foundation every transaction resolves against. There are three pillars: the Business Partner, the Material Master, and transactional master data — customer-material info records and condition records.

2.1 Master Data Relationship Model

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

    BP["Business Partner<br>(Transaction BP)"]
    MM["Material Master<br>(MM01/02/03)"]
    CMIR["Customer-Material<br>Info Record<br>(VD51)"]
    CR["Condition Records<br>(VK11 — Pricing)"]
    SA["Sales Area Data<br>(Shipping / Billing / Orders tabs)"]
    SO["Sales Order<br>(VA01)"]
    FI["FI Customer<br>(Reconciliation Account)"]

    BP --> SA
    BP --> FI
    MM --> CR
    BP --> CMIR
    MM --> CMIR
    CMIR --> SO
    SA --> SO
    CR --> SO
    FI --> SO

    class BP,MM source
    class CMIR,CR integration
    class SO target
    class FI reporting

2.2 Business Partner: The Unified Customer Record

SAP S/4HANA replaces the legacy customer master (XD01) with the unified Business Partner (Transaction BP). A single physical location is one business partner record — the BP Role qualifies whether that entity acts as sold-to party, ship-to, payer, or bill-to. The four partner functions that govern every sales order:

Partner Function	Code	Role
Sold-to Party	SP	Sends the purchase order
Ship-to Party	SH	Receives the goods
Bill-to Party	BP	Receives the invoice
Payer	PY	Makes the payment

These are resolved at order entry from the partner determination procedure (Transaction VOPAN). A single sold-to can have multiple ship-to and payer combinations — the partner determination procedure handles the resolution logic without manual override at order entry.

2.3 Material Master: Sales-Relevant Views

The material master organizes data by view. For OTC, four views carry the load:

View	Key Fields	OTC Impact
Sales: Sales Org 1	Delivering Plant, Material Status, Tax Data, Min Order Qty	Default sourcing, blocks, tax
Sales: Sales Org 2	Item Category Group, Product Hierarchy, Price Group, Account Assignment Group	Item category, pricing, revenue account
Sales: General/Plant	Availability Check, Loading Group, Trans. Group	ATP and shipping point determination
Intl Trade: Export	Control Code (HTS), Country of Origin	Customs compliance, pro-forma invoices

The Item Category Group on Sales Org 2 is particularly critical — it feeds the item category determination on the sales order, which in turn controls whether a line is relevant for billing, delivery, or costing. This single field, set at material master configuration time, determines behavior across the entire downstream document chain.

3. The Condition Technique: OTC’s Pricing Engine

The condition technique is the most powerful and most misunderstood feature in OTC. It governs not just pricing, but free goods, material determination, output determination, listing and exclusion, and cross-selling — all using the same architectural pattern. Understanding it once means understanding six OTC capabilities simultaneously.

3.1 Condition Technique Architecture

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 Entry<br>(VA01)"]
    PP["Pricing Procedure<br>(e.g. A17J02)"]
    CT["Condition Type<br>(e.g. PPR0, ZST1)"]
    AS["Access Sequence<br>(Table priority order)"]
    CTBL["Condition Table<br>(e.g. A304 — Material)"]
    CR["Condition Record<br>(VK11 Master Data)"]
    CV["Condition Value<br>(calculated result)"]

    SO --> PP
    PP --> CT
    CT --> AS
    AS --> CTBL
    CTBL --> CR
    CR --> CV
    CV --> SO

    class SO target
    class PP,CT integration
    class AS,CTBL source
    class CR,CV reporting

3.2 Condition Technique Applications

Functionality	Master Data Tx	Config Tx	Key Condition Type
Pricing	VK11	VOK0 / V/03	PPR0 (base price), ZST1 (discount)
Free Goods	VBN1	—	YA00
Material Determination	VB11	OV16	Y001
Cross-Selling	VB41	OV48	ZST1 (custom)
Listing / Exclusion	VB01	OV05	ZSTL / ZSTE
Output Determination	VV11	V/56	BA00 (order acknowledgment)

3.3 Pricing Procedure Determination

Pricing procedure determination resolves at order entry from three inputs simultaneously. All three must resolve to a configured entry or the system throws a hard error at order entry — there is no fallback.

flowchart LR
    classDef source fill:#fff3e0,stroke:#e65100
    classDef target fill:#e3f2fd,stroke:#1565c0

    SA["Sales Area<br>(SOrg + DCh + Div)"]
    DPP["Document Pricing Procedure<br>(on Sales Order Type)"]
    CPP["Customer Pricing Procedure<br>(on Business Partner)"]
    PROC["Pricing Procedure<br>Assigned"]

    SA --> PROC
    DPP --> PROC
    CPP --> PROC

    class SA,DPP,CPP source
    class PROC target

4. The Order-to-Cash Business Process

Every OTC step produces a document; every document feeds the next. The BPMN below captures the full end-to-end flow from customer purchase order receipt to cash cleared, including the credit check branch and the proof-of-delivery gate before billing.

<?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="OTC_Process"
                  targetNamespace="http://sajivfrancis.com/otc">
  <bpmn:process id="OTC_Main" isExecutable="false" name="Order-to-Cash: SAP S/4HANA">

    <bpmn:startEvent id="Start" name="Customer Purchase Order Received">
      <bpmn:outgoing>flow_start_to_inquiry</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:task id="Inquiry" name="Create Sales Inquiry / Quotation (VA11/VA21)">
      <bpmn:incoming>flow_start_to_inquiry</bpmn:incoming>
      <bpmn:outgoing>flow_inquiry_to_order</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="SalesOrder" name="Create Sales Order VA01 - ATP and Pricing Check">
      <bpmn:incoming>flow_inquiry_to_order</bpmn:incoming>
      <bpmn:outgoing>flow_order_to_credit</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="CreditCheck" name="Credit Check Passed?">
      <bpmn:incoming>flow_order_to_credit</bpmn:incoming>
      <bpmn:outgoing>flow_credit_pass</bpmn:outgoing>
      <bpmn:outgoing>flow_credit_fail</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="CreditBlock" name="Credit Block - Review by Credit Department">
      <bpmn:incoming>flow_credit_fail</bpmn:incoming>
      <bpmn:outgoing>flow_creditblock_to_release</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="CreditRelease" name="Release Credit Block (VKM3)">
      <bpmn:incoming>flow_creditblock_to_release</bpmn:incoming>
      <bpmn:outgoing>flow_credit_pass_from_release</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Delivery" name="Create Outbound Delivery (VL01N)">
      <bpmn:incoming>flow_credit_pass</bpmn:incoming>
      <bpmn:incoming>flow_credit_pass_from_release</bpmn:incoming>
      <bpmn:outgoing>flow_delivery_to_pick</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Picking" name="Pick and Transfer Order (LT0A) - Warehouse Execution">
      <bpmn:incoming>flow_delivery_to_pick</bpmn:incoming>
      <bpmn:outgoing>flow_pick_to_pack</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Packing" name="Pack Goods - Handling Units">
      <bpmn:incoming>flow_pick_to_pack</bpmn:incoming>
      <bpmn:outgoing>flow_pack_to_transport</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Transport" name="Transportation Planning (VT01N) - Shipment Document">
      <bpmn:incoming>flow_pack_to_transport</bpmn:incoming>
      <bpmn:outgoing>flow_transport_to_pgi</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="PostGoodsIssue" name="Post Goods Issue (VL02N) - FI Document Generated">
      <bpmn:incoming>flow_transport_to_pgi</bpmn:incoming>
      <bpmn:outgoing>flow_pgi_to_pod</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="PODRequired" name="Proof of Delivery Required?">
      <bpmn:incoming>flow_pgi_to_pod</bpmn:incoming>
      <bpmn:outgoing>flow_pod_yes</bpmn:outgoing>
      <bpmn:outgoing>flow_pod_no</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="POD" name="Confirm Proof of Delivery (VL02N)">
      <bpmn:incoming>flow_pod_yes</bpmn:incoming>
      <bpmn:outgoing>flow_pod_to_billing</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Billing" name="Create Billing Document (VF01/VF04) - Account Determination">
      <bpmn:incoming>flow_pod_no</bpmn:incoming>
      <bpmn:incoming>flow_pod_to_billing</bpmn:incoming>
      <bpmn:outgoing>flow_billing_to_revrecog</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="RevRecog" name="Revenue Recognition - IFRS 15 Compliance">
      <bpmn:incoming>flow_billing_to_revrecog</bpmn:incoming>
      <bpmn:outgoing>flow_revrecog_to_ar</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="AR" name="Accounts Receivable - Open Item (FI-AR)">
      <bpmn:incoming>flow_revrecog_to_ar</bpmn:incoming>
      <bpmn:outgoing>flow_ar_to_payment</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="Payment" name="Incoming Payment - Clear Open Item (F-28 / F-32)">
      <bpmn:incoming>flow_ar_to_payment</bpmn:incoming>
      <bpmn:outgoing>flow_payment_to_end</bpmn:outgoing>
    </bpmn:task>

    <bpmn:endEvent id="End" name="Cash Received - OTC Cycle Complete">
      <bpmn:incoming>flow_payment_to_end</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:sequenceFlow id="flow_start_to_inquiry" sourceRef="Start" targetRef="Inquiry"/>
    <bpmn:sequenceFlow id="flow_inquiry_to_order" sourceRef="Inquiry" targetRef="SalesOrder"/>
    <bpmn:sequenceFlow id="flow_order_to_credit" sourceRef="SalesOrder" targetRef="CreditCheck"/>
    <bpmn:sequenceFlow id="flow_credit_pass" name="Yes" sourceRef="CreditCheck" targetRef="Delivery"/>
    <bpmn:sequenceFlow id="flow_credit_fail" name="No - Block Applied" sourceRef="CreditCheck" targetRef="CreditBlock"/>
    <bpmn:sequenceFlow id="flow_creditblock_to_release" sourceRef="CreditBlock" targetRef="CreditRelease"/>
    <bpmn:sequenceFlow id="flow_credit_pass_from_release" name="Released" sourceRef="CreditRelease" targetRef="Delivery"/>
    <bpmn:sequenceFlow id="flow_delivery_to_pick" sourceRef="Delivery" targetRef="Picking"/>
    <bpmn:sequenceFlow id="flow_pick_to_pack" sourceRef="Picking" targetRef="Packing"/>
    <bpmn:sequenceFlow id="flow_pack_to_transport" sourceRef="Packing" targetRef="Transport"/>
    <bpmn:sequenceFlow id="flow_transport_to_pgi" sourceRef="Transport" targetRef="PostGoodsIssue"/>
    <bpmn:sequenceFlow id="flow_pgi_to_pod" sourceRef="PostGoodsIssue" targetRef="PODRequired"/>
    <bpmn:sequenceFlow id="flow_pod_yes" name="Yes - POD Configured" sourceRef="PODRequired" targetRef="POD"/>
    <bpmn:sequenceFlow id="flow_pod_no" name="No" sourceRef="PODRequired" targetRef="Billing"/>
    <bpmn:sequenceFlow id="flow_pod_to_billing" sourceRef="POD" targetRef="Billing"/>
    <bpmn:sequenceFlow id="flow_billing_to_revrecog" sourceRef="Billing" targetRef="RevRecog"/>
    <bpmn:sequenceFlow id="flow_revrecog_to_ar" sourceRef="RevRecog" targetRef="AR"/>
    <bpmn:sequenceFlow id="flow_ar_to_payment" sourceRef="AR" targetRef="Payment"/>
    <bpmn:sequenceFlow id="flow_payment_to_end" sourceRef="Payment" targetRef="End"/>

  </bpmn:process>
</bpmn:definitions>

5. OTC Document Chain and Finance Integration

Every OTC document generates downstream financial postings. This is where SD and FI/CO converge — and where the most consequential design decisions live.

5.1 Document Flow Architecture

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

    QT["Quotation<br>(VA21)"]
    OR["Sales Order<br>(VA01)"]
    DL["Outbound Delivery<br>(VL01N)"]
    PGI["Post Goods Issue<br>(VL02N)"]
    BD["Billing Document<br>(VF01)"]
    FI_DOC["FI Document<br>(ACDOCA — Universal Journal)"]
    AR_OI["AR Open Item<br>(FI-AR)"]
    CO_DOC["CO Document<br>(Profitability Analysis)"]
    PMT["Incoming Payment<br>(F-28)"]

    QT -->|"reference"| OR
    OR -->|"copy control"| DL
    DL -->|"goods movement"| PGI
    PGI -->|"COGS posting<br>Dr: COGS / Cr: Inventory"| FI_DOC
    OR -->|"copy control"| BD
    DL -->|"billing due list"| BD
    BD -->|"revenue posting<br>Dr: AR / Cr: Revenue"| FI_DOC
    BD -->|"account determination<br>(VKOA)"| AR_OI
    BD -->|"PA transfer<br>(CO-PA)"| CO_DOC
    PMT -->|"clears"| AR_OI

    class QT,OR source
    class DL,PGI integration
    class BD target
    class FI_DOC,AR_OI,CO_DOC,PMT reporting

5.2 The Two Critical FI Postings

Both write to ACDOCA — the Universal Journal — and both must land in the correct period. Period-end integrity depends entirely on these two postings being timely and automated.

Posting 1: Post Goods Issue (PGI)

Triggered at VL02N → Post Goods Issue. Reduces inventory and books cost of goods sold. Driven by movement type 601 and the material valuation (standard cost or moving average price). No pricing condition records are involved — this is a pure logistics and CO posting.

Dr/Cr	Account Type	Account	Amount
Dr	Expense	Cost of Goods Sold	Inventory value (MAP / standard cost)
Cr	Asset	Inventory — Finished Goods	Same amount

Posting 2: Billing Document Release to Accounting

Triggered at VF02 → Release to Accounting. Books revenue and creates the AR open item.

Dr/Cr	Account Type	Account	Determination
Dr	Asset	Accounts Receivable	Reconciliation account on BP master
Cr	Revenue	Revenue Account	VKOA — account determination (KOFI/KOFK)
Cr/Dr	Tax	Output Tax	Tax procedure (TAXUS / TAXEUR)

Account determination (Transaction VKOA) resolves from: Application + Condition Type + Chart of Accounts + Sales Org + Account Assignment Group (Customer) + Account Assignment Group (Material) + Account Key.

5.3 Integration Scenarios: OTC to FI/CO

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 SD["SD — Sales and Distribution"]
        SO["Sales Order"]
        BD["Billing Document"]
        PGI_S["Post Goods Issue"]
    end

    subgraph FI["FI — Financial Accounting"]
        AR["FI-AR<br>Accounts Receivable"]
        GL["FI-GL<br>General Ledger<br>(ACDOCA)"]
        CRED["FI-AR Credit Mgmt<br>(Credit Control Area)"]
    end

    subgraph CO["CO — Controlling"]
        COPA["CO-PA<br>Profitability Analysis"]
        CCA["Cost Center Accounting"]
        PC["Product Costing"]
    end

    SO -->|"credit check"| CRED
    PGI_S -->|"COGS + Inventory"| GL
    PGI_S -->|"actual cost"| CCA
    BD -->|"revenue + AR"| AR
    BD -->|"revenue posting"| GL
    BD -->|"PA transfer"| COPA
    PC -->|"standard cost"| PGI_S

    class SO,BD,PGI_S source
    class AR,GL,CRED integration
    class COPA,CCA,PC target

5.4 Account Keys and Revenue Account Mapping

Standard account keys used in VKOA:

Account Key	Posting	Example G/L
ERL	Revenue	400000 — Revenue
ERS	Sales Deductions	400100 — Discounts
ERF	Freight Revenue	400200 — Freight
VST	Output Tax	175000 — VAT Output

6. Key Configurations

6.1 Sales Order Type (Transaction VOV8)

The sales order type is the control center for a sales document:

Field	Controls
SD Document Category	Order, contract, returns, etc.
Item Category Determination	Which item categories are valid
Document Pricing Procedure	Input to pricing procedure determination
Delivery Type	Default delivery document type (e.g., LF)
Billing Type	Default billing document type (e.g., F2)
Credit Check	Whether and when credit is checked
Incompletion Procedure	Which fields must be complete before processing

6.2 Item Category Determination

Item category determination uses a four-key combination:

Sales Document Type + Item Category Group (MM) + Item Usage + Item Category of Higher-Level Item
→ Default Item Category

The item category is the most granular control point in the sales order — it determines billing relevance, delivery relevance, pricing relevance, and costing relevance at the line level.

6.3 Copy Control (VTAA / VTLA / VTFA)

Copy control governs how data flows from one document to the next. It operates at header, item, and schedule line levels using transfer routines (VOFM).

Copy Route	Transaction	Key Routine Area
Order → Order	VTAA	Data transfer, pricing type
Order → Delivery	VTLA	Quantities, dates, shipping data
Delivery → Billing	VTFL	Billing quantity, pricing
Order → Billing	VTFA	Direct billing (service orders)

6.4 Shipping Point Determination

Shipping point determination resolves automatically from three inputs — all three must resolve to a configured entry in the determination table (Transaction OVZB) or the delivery cannot be created:

Shipping Condition — from customer master, Shipping tab
Loading Group — from material master, Sales: General/Plant
Delivering Plant — from material master or customer master

6.5 ATP and Transfer of Requirements

The Available-to-Promise (ATP) check runs at sales order entry and determines the confirmed delivery date — the commitment made to the customer. It can be configured for simple availability check (stock only), ATP with replenishment lead time (forward scheduling), product allocation (constrained supply), or rule-based ATP (multi-plant substitution).

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

    OE["Order Entry<br>(VA01)"]
    SC["Schedule Line<br>Category"]
    RC["Requirement Class<br>(Transfer to MRP?)"]
    ATP["ATP Check<br>(Availability Overview)"]

    subgraph ATP_SCOPE["Scope of ATP Check"]
        STOCK["Current Stock"]
        PLANNED["Planned Receipts<br>(Production / POs)"]
        SAFETYSTOCK["Safety Stock"]
        ALLOC["Product Allocation"]
    end

    SCHED["Confirmed Schedule Line<br>(Delivery Date + Qty)"]
    MRP["MRP — Individual<br>Requirements Transfer"]

    OE --> SC
    SC --> RC
    RC --> ATP
    ATP --> ATP_SCOPE
    ATP --> SCHED
    RC -->|"if IndReq = Yes"| MRP

    class OE,SC source
    class ATP,RC integration
    class SCHED target
    class MRP,ATP_SCOPE reporting

7. Automating PGI and Billing Release to Accounting

The two FI postings from Section 5.2 are only as timely as the processes that trigger them. In non-automated environments, a time gap opens between physical reality and system record — inventory positions distort, billing runs miss deliveries, and COGS postings land in the wrong period. At scale, hundreds of deliveries per day make this gap catastrophic at period-end.

There are four automation paths for PGI and four for billing release. They are not mutually exclusive — the right answer for most implementations combines two or three, matched to the operational context.

7.1 PGI Automation Architecture

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

    DL["Outbound Delivery<br>(VL01N / VL10)"]

    subgraph AUTO["PGI Automation Paths"]
        WS["1. Shipment Activity Profile<br>(VT02N — Shipment Start)"]
        BATCH["2. Background Batch Job<br>(VL06G — Goods Issue Monitor)"]
        EDI["3. EDI / IDoc Trigger<br>(SHPCON / DESADV Inbound)"]
        EWM["4. EWM Transfer Order<br>Confirmation - Auto PGI"]
    end

    PGI["Post Goods Issue<br>(Movement Type 601)"]
    FI1["FI Posting:<br>Dr COGS / Cr Inventory"]
    BD_ELIG["Delivery becomes<br>Billing-Eligible"]

    DL --> WS
    DL --> BATCH
    DL --> EDI
    DL --> EWM
    WS --> PGI
    BATCH --> PGI
    EDI --> PGI
    EWM --> PGI
    PGI --> FI1
    PGI --> BD_ELIG

    class DL source
    class WS,BATCH,EDI,EWM integration
    class PGI target
    class FI1,BD_ELIG reporting

Path 1: Shipment Activity Profile (VT02N)

When transportation management is active and shipment documents are in use, the activity profile maps shipment status events to system actions. When a dispatcher updates the shipment start time in VT02N, the system fires PGI across all deliveries in that shipment simultaneously.

Configuration path: SPRO → Logistics Execution → Transportation → Shipments → Activity Profiles → Define and Assign Activity Profiles

Shipment Status Event	System Action Triggered
Shipment Start (actual)	PGI on all assigned deliveries
Shipment End	Proof of Delivery update (optional)
Check-in	Output trigger (optional)

Constraint: Only available when shipment documents are active. Many implementations skip shipment documents for simple outbound flows, making this path unavailable without activating transportation planning as a parallel effort.

Path 2: Background Batch Job — VL06G

The most universally applicable path. VL06G (Outbound Delivery Monitor — Goods Issue) scheduled as a periodic background job selects all deliveries ready for PGI and posts them without user interaction.

Steps:

Define a variant in VL06G with: Shipping Point(s), Planned Goods Issue Date (today or past-due), picking confirmed, no GI block
Schedule the variant in SM36:

Program:   SDRQCR21
Variant:   ZPGI_AUTO_DAILY
Frequency: Every 30–60 minutes depending on SLA

The delivery must be fully picked (picking quantity equals delivery quantity) and carry no active GI block (LIFSP blank on delivery header). If either condition is not met, the job skips that delivery and logs it — it does not fail the entire run.

Path 3: EDI / IDoc-Triggered PGI

For 3PLs or external WMS systems that send an Advance Shipment Notice upon physical dispatch, the inbound IDoc (message type SHPCON) triggers PGI automatically. This pattern is standard in 3PL-operated warehouses where SAP does not manage physical warehouse operations — the 3PL’s WMS is the system of record; SAP mirrors those movements via IDoc.

sequenceDiagram
    participant WMS as "3PL / WMS"
    participant EDI as "EDI Layer<br>(ALE / CPI)"
    participant SAP as "SAP S/4HANA"
    participant FI as "FI-GL<br>(ACDOCA)"

    WMS->>EDI: ASN / Shipment Confirmation sent
    EDI->>SAP: Inbound IDoc (SHPCON / DESADV)
    SAP->>SAP: IDoc processing - update delivery<br>picking qty and status
    SAP->>SAP: Auto-trigger PGI<br>(movement type 601)
    SAP->>FI: FI Document posted<br>Dr COGS / Cr Inventory
    SAP->>EDI: Acknowledgment IDoc (optional)
    EDI->>WMS: Confirmation returned

Path 4: EWM Transfer Order Confirmation → Auto PGI

When Embedded EWM is active, confirming the transfer order in the EWM mobile or Fiori interface can automatically trigger PGI on the linked outbound delivery. The warehouse worker loading the truck triggers the financial posting in real time — the most operationally clean path when EWM is in scope.

Configuration: SPRO → Extended Warehouse Management → Goods Issue Process → Activate Post Goods Issue

The warehouse process type configuration includes the Automatic Goods Movement flag. When set, transfer order confirmation cascades to PGI with no SD user action required.

7.2 Billing Release Automation Architecture

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

    PGI_DONE["PGI Complete<br>Delivery Billing-Eligible"]

    subgraph BILL_AUTO["Billing Creation Paths"]
        VF04B["1. VF04 Background Job<br>(Collective Billing Run)"]
        SCHED["2. Invoice Calendar<br>(Billing Date Control)"]
        IMMEDIATE["3. Immediate Release<br>(Billing Type Config — VOFA)"]
        FIORI["4. SAP Fiori<br>Schedule Billing Release App"]
    end

    BD["Billing Document Created<br>(F2 / Invoice)"]

    subgraph REL_AUTO["Release to Accounting"]
        AUTO_REL["Auto-Release on Save<br>(No Posting Block on VOFA)"]
        BLOCK_REV["Billing Block - Manual Review<br>then VFX3 Mass Release"]
        BATCH_REL["VF06 Background<br>Billing Release Job"]
    end

    FI_POST["FI Posting:<br>Dr AR / Cr Revenue<br>(ACDOCA updated)"]
    COPA_POST["CO-PA Posting:<br>Revenue + COGS<br>to Profitability Segment"]
    AR_OI["AR Open Item Created<br>(Customer Sub-ledger)"]

    PGI_DONE --> VF04B
    PGI_DONE --> SCHED
    PGI_DONE --> IMMEDIATE
    PGI_DONE --> FIORI
    VF04B --> BD
    SCHED --> BD
    IMMEDIATE --> BD
    FIORI --> BD
    BD --> AUTO_REL
    BD --> BLOCK_REV
    BD --> BATCH_REL
    AUTO_REL --> FI_POST
    BLOCK_REV --> FI_POST
    BATCH_REL --> FI_POST
    FI_POST --> COPA_POST
    FI_POST --> AR_OI

    class PGI_DONE source
    class VF04B,SCHED,IMMEDIATE,FIORI integration
    class BD,AUTO_REL,BLOCK_REV,BATCH_REL target
    class FI_POST,COPA_POST,AR_OI reporting

Path 1: VF04 Background Job (Collective Billing Run)

VF04 scheduled as a background job with a saved variant is the workhorse automation for high-volume billing. It selects all delivery items with PGI posted (billing relevance status = A), no billing block, billing date on or before today, and copy control conditions met.

The collective billing run also consolidates multiple deliveries into a single billing document when consolidation criteria match — same sold-to, payer, payment terms, and incoterms — reducing invoice volume for high-frequency customers.

Program:   RV60SBAT
Variant:   ZBILL_DAILY_RUN
Frequency: Nightly or multiple intraday runs

Path 2: Invoice Calendar

For customers with contractual billing schedules (monthly invoicing, milestone billing, subscription), the Invoice Date Calendar on the customer master (Billing tab, field ZINDT) controls when billing documents can be created. Combined with a background job, this enforces billing on agreed dates only — and is the mechanism for milestone billing on project-based orders and periodic billing on contracts where the billing plan drives the schedule independently of delivery.

Path 3: Immediate Release — Billing Type Configuration (VOFA)

The most aggressive automation: the billing document type is configured so it releases to accounting immediately upon save, with no intermediate “not yet posted” state.

In billing type configuration (VOFA): Posting Block field left blank — no block.

When blank, saving the billing document in VF01 or VF04 simultaneously creates the billing document, posts the FI document, creates the AR open item, and transfers to CO-PA. This is the default behavior for standard billing type F2 — the manual two-step only arises when a posting block is explicitly set.

When not to use immediate release:

Revenue recognition scenarios where revenue is deferred (IFRS 15 — Part 2)
Intercompany billing requiring review before FI impact
High-dispute customers where invoice review is contractually required

Path 4: SAP Fiori — Schedule Billing Release App

The Schedule Billing Release Fiori app allows a billing manager to define recurring job schedules in the UI (no SM36 access required), set selection parameters, monitor execution results with status tiles, and drill into error logs for failed billing documents. This is the recommended path for S/4HANA Cloud and for organizations moving billing operations to non-technical business users.

7.3 What Happens When Billing Releases to Accounting

sequenceDiagram
    participant BD as "Billing Document<br>(SD)"
    participant VKOA as "Account Determination<br>(VKOA)"
    participant FI as "FI-GL<br>(ACDOCA)"
    participant AR as "FI-AR<br>Sub-ledger"
    participant COPA as "CO-PA<br>Profitability Analysis"
    participant TAX as "Tax Engine<br>(TAXUS / TAXEUR)"

    BD->>VKOA: Revenue account key (ERL/ERS/ERF)
    VKOA->>VKOA: Resolve: App + Cond Type + CoA +<br>Sales Org + Cust AAG + Mat AAG
    VKOA->>FI: G/L Account determined
    BD->>TAX: Tax condition type (MWS/VST)
    TAX->>FI: Tax account posted
    BD->>FI: Post FI Document<br>Dr: Customer Recon Account<br>Cr: Revenue G/L / Cr: Tax G/L
    FI->>AR: Open item created<br>(linked to customer BP)
    BD->>COPA: PA transfer structure<br>Revenue, COGS, conditions to Profitability Segment
    FI-->>BD: Accounting document number<br>stored on billing document

The reconciliation account on the Business Partner master is what creates the AR sub-ledger entry. The system never posts directly to the reconciliation account — it posts to the customer, and the reconciliation account mapping ensures the GL balance reflects it. This is the mechanism that keeps the AR sub-ledger and the GL in permanent sync without manual reconciliation.

7.4 Mass Error Recovery: VFX3

When billing documents fail to release to accounting — pricing errors, missing account determination, locked GL periods — they accumulate in Transaction VFX3, the billing error monitor. VFX3 provides a list of all blocked documents with the error message per document and a mass release capability once errors are corrected.

The count of documents sitting in VFX3 should be treated as a daily operational KPI. A non-zero count at period-end represents revenue recognized in the wrong period — a direct SOX and audit exposure. The target is zero at any period close.

7.5 End-to-End Automated Flow

sequenceDiagram
    participant WH as "Warehouse / EWM"
    participant SD as "SAP SD"
    participant BATCH as "Background Jobs<br>(SM36)"
    participant FI as "FI-GL (ACDOCA)"
    participant AR as "FI-AR"
    participant COPA as "CO-PA"

    WH->>SD: Transfer Order confirmed<br>(goods loaded)
    SD->>SD: Auto PGI triggered<br>(EWM config / Activity Profile)
    SD->>FI: FI Doc 1 posted<br>Dr COGS / Cr Inventory (601)
    SD->>SD: Delivery status = Billing-relevant
    Note over BATCH: VF04 background job<br>runs every N hours
    BATCH->>SD: Collective billing run<br>selects all PGI-complete deliveries
    SD->>SD: Billing document created<br>(F2 - no posting block)
    SD->>FI: FI Doc 2 posted immediately<br>Dr AR Recon / Cr Revenue / Cr Tax
    FI->>AR: Open item created
    SD->>COPA: PA transfer<br>Revenue + COGS + conditions
    Note over AR: Customer receives invoice<br>Payment due per terms
    AR->>FI: Incoming payment cleared<br>(F-28 / F-32)
    FI->>AR: Open item cleared - zero balance

7.6 Configuration Checklist: Enabling Full Automation

Configuration Object	Transaction	Setting Required	Notes
Billing Type — Posting Block	VOFA	Leave blank	Enables immediate accounting release
Customer Master — Subs. Invoice Processing	BP	Leave unchecked	Prevents manual billing hold
Delivery Type — Auto GI	OVLK	Check Auto GI flag	For specific delivery types only
Activity Profile (Shipment)	SPRO / TM	Map shipment start to PGI	Requires shipment documents active
VF04 Background Variant	SM36 / VF04	Create and schedule	Define selection criteria precisely
EWM — Auto Goods Movement	SPRO / EWM	Activate on warehouse process type	Requires embedded EWM
Billing Block default on Order Type	VOV8	Leave blank unless review required	Order-type-level default
Output Type BA00 — Dispatch	VV11	Date/Time = 4 (Immediate) or 1 (Batch)	Controls invoice output timing
VFX3 Monitoring	VFX3	Daily alert on count greater than 0	Operational control, not config

8. Customer Complaint Management — The Reverse OTC

Returns and credit/debit processing are the reverse side of OTC. They use the same document architecture but flow in opposite directions, with dedicated document types for each scenario.

<?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="Returns_Process"
                  targetNamespace="http://sajivfrancis.com/returns">
  <bpmn:process id="Returns_Main" isExecutable="false" name="Customer Returns and Complaint Management">

    <bpmn:startEvent id="RetStart" name="Customer Complaint Received">
      <bpmn:outgoing>flow_ret_start</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:exclusiveGateway id="ComplaintType" name="Complaint Type?">
      <bpmn:incoming>flow_ret_start</bpmn:incoming>
      <bpmn:outgoing>flow_physical_return</bpmn:outgoing>
      <bpmn:outgoing>flow_credit_debit</bpmn:outgoing>
      <bpmn:outgoing>flow_free_of_charge</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="ReturnOrder" name="Create Return Order (VA01 - RE) - Advanced Returns Management">
      <bpmn:incoming>flow_physical_return</bpmn:incoming>
      <bpmn:outgoing>flow_ret_to_inbound</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="InboundDelivery" name="Inbound Delivery - Post Goods Receipt">
      <bpmn:incoming>flow_ret_to_inbound</bpmn:incoming>
      <bpmn:outgoing>flow_inbound_to_credit</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="CreditMemoRequest" name="Credit Memo Request (VA01 - CR)">
      <bpmn:incoming>flow_inbound_to_credit</bpmn:incoming>
      <bpmn:incoming>flow_credit_debit</bpmn:incoming>
      <bpmn:outgoing>flow_credit_to_billing</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="FreeOfCharge" name="Free of Charge Order (VA01 - FD)">
      <bpmn:incoming>flow_free_of_charge</bpmn:incoming>
      <bpmn:outgoing>flow_foc_to_end</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="CreditBilling" name="Credit Memo Billing (VF01) - Negative AR Posting">
      <bpmn:incoming>flow_credit_to_billing</bpmn:incoming>
      <bpmn:outgoing>flow_credit_billing_to_end</bpmn:outgoing>
    </bpmn:task>

    <bpmn:endEvent id="RetEnd" name="Complaint Resolved - Credit and Goods Processed">
      <bpmn:incoming>flow_credit_billing_to_end</bpmn:incoming>
      <bpmn:incoming>flow_foc_to_end</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:sequenceFlow id="flow_ret_start" sourceRef="RetStart" targetRef="ComplaintType"/>
    <bpmn:sequenceFlow id="flow_physical_return" name="Physical Return" sourceRef="ComplaintType" targetRef="ReturnOrder"/>
    <bpmn:sequenceFlow id="flow_credit_debit" name="Credit or Debit Adjustment" sourceRef="ComplaintType" targetRef="CreditMemoRequest"/>
    <bpmn:sequenceFlow id="flow_free_of_charge" name="Free of Charge" sourceRef="ComplaintType" targetRef="FreeOfCharge"/>
    <bpmn:sequenceFlow id="flow_ret_to_inbound" sourceRef="ReturnOrder" targetRef="InboundDelivery"/>
    <bpmn:sequenceFlow id="flow_inbound_to_credit" sourceRef="InboundDelivery" targetRef="CreditMemoRequest"/>
    <bpmn:sequenceFlow id="flow_credit_to_billing" sourceRef="CreditMemoRequest" targetRef="CreditBilling"/>
    <bpmn:sequenceFlow id="flow_foc_to_end" sourceRef="FreeOfCharge" targetRef="RetEnd"/>
    <bpmn:sequenceFlow id="flow_credit_billing_to_end" sourceRef="CreditBilling" targetRef="RetEnd"/>

  </bpmn:process>
</bpmn:definitions>

9. OTC Process Metrics

The following metrics represent reference benchmarks for an SAP S/4HANA OTC implementation. Actuals vary by industry and configuration maturity. Improvement figures are modeled estimates based on typical observed outcomes in S/4HANA deployments.

{
  "data": [
    {
      "type": "bar",
      "name": "Baseline (Pre-Automation)",
      "x": ["Order to Delivery<br>(days)", "Delivery to Billing<br>(days)", "Billing to Cash<br>(days)", "Credit Block Rate<br>(%)", "Return Rate<br>(%)"],
      "y": [3.2, 1.1, 32.0, 8.5, 4.2],
      "marker": {"color": "#c62828"},
      "text": ["3.2", "1.1", "32", "8.5%", "4.2%"],
      "textposition": "outside"
    },
    {
      "type": "bar",
      "name": "SAP S/4HANA Automated",
      "x": ["Order to Delivery<br>(days)", "Delivery to Billing<br>(days)", "Billing to Cash<br>(days)", "Credit Block Rate<br>(%)", "Return Rate<br>(%)"],
      "y": [1.8, 0.5, 24.0, 4.1, 2.8],
      "marker": {"color": "#2e7d32"},
      "text": ["1.8", "0.5", "24", "4.1%", "2.8%"],
      "textposition": "outside"
    }
  ],
  "layout": {
    "title": "OTC Process KPIs: Baseline vs Automated S/4HANA",
    "barmode": "group",
    "yaxis": {"title": "Value (days or %)"},
    "xaxis": {"title": "KPI"},
    "legend": {"orientation": "h", "y": -0.25},
    "height": 480,
    "margin": {"t": 60, "b": 130}
  }
}

The period-end billing distribution illustrates the structural risk of manual processes. The month-end spike in a non-automated environment means revenue that belongs in period N is posted in period N+1 — a direct SOX and audit exposure.

{
  "data": [
    {
      "type": "bar",
      "name": "Manual Process",
      "x": ["Day 28", "Day 29", "Day 30<br>(Month End)", "Day 1<br>(New Period)", "Day 2"],
      "y": [12, 18, 67, 45, 8],
      "marker": {"color": "#c62828"},
      "text": ["12", "18", "67", "45", "8"],
      "textposition": "outside"
    },
    {
      "type": "bar",
      "name": "Automated Process",
      "x": ["Day 28", "Day 29", "Day 30<br>(Month End)", "Day 1<br>(New Period)", "Day 2"],
      "y": [14, 15, 16, 13, 14],
      "marker": {"color": "#2e7d32"},
      "text": ["14", "15", "16", "13", "14"],
      "textposition": "outside"
    }
  ],
  "layout": {
    "title": "Billing Documents Released to Accounting — Manual vs Automated<br>Month-End Pattern",
    "barmode": "group",
    "yaxis": {"title": "Billing Documents Released"},
    "xaxis": {"title": "Business Day"},
    "legend": {"orientation": "h", "y": -0.28},
    "height": 460,
    "margin": {"t": 70, "b": 130},
    "annotations": [
      {
        "x": "Day 30<br>(Month End)",
        "y": 73,
        "text": "Period-end rush — revenue distortion risk",
        "showarrow": true,
        "arrowhead": 2,
        "ax": 80,
        "ay": -30,
        "font": {"color": "#c62828"}
      }
    ]
  }
}

{
  "data": [
    {
      "type": "pie",
      "labels": ["Pricing Config", "Master Data", "Copy Control", "Account Determination", "Output Determination", "ATP Config", "Credit Management"],
      "values": [22, 18, 15, 14, 12, 11, 8],
      "hole": 0.4,
      "marker": {
        "colors": ["#1565c0", "#2e7d32", "#6a1b9a", "#c62828", "#e65100", "#00838f", "#f57f17"]
      },
      "textinfo": "label+percent"
    }
  ],
  "layout": {
    "title": "OTC Configuration Effort Distribution<br>Typical S/4HANA Implementation",
    "height": 440,
    "margin": {"t": 70, "b": 40}
  }
}

10. SAP Fiori in OTC

SAP S/4HANA delivers OTC functionality through both the SAP GUI and the SAP Fiori launchpad. Key Fiori apps for OTC operations:

App Name	Semantic Object	Role
Manage Sales Orders	SalesOrder / manage	Sales Order Manager
Manage Billing Documents	BillingDocument / manage	Billing Clerk
Schedule Billing Release	BillingDocument / schedule	Billing Manager
Product Allocation Overview	—	Supply Chain Planner
Sales Order Items — Backorders	SalesOrder / displayFactSheet	Sales Order Manager
Display Business Volume — Condition Contracts	—	Sales Manager
Manage Business Partner Master Data	BusinessPartner / manage	Master Data Specialist

The implementation note that matters: SAP Fiori requires explicit activation of business roles and app assignments. A user without a configured role sees nothing — not an error, simply a blank launchpad. Fiori setup effort should be scoped as a parallel workstream to functional configuration, not a phase 2 afterthought. This is consistently underestimated and consistently causes post-go-live disruption.

11. OTC in the SAP Context Model

Every white paper in this series is a node in an interconnected SAP knowledge graph. The diagram below establishes how OTC Part 1 connects to adjacent domains — each arrow represents a real document flow, financial posting, or system integration, not a conceptual relationship.

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 — Order to Cash<br>(This Paper, Part 1)"]
    FI["FI — Financial Accounting<br>(ACDOCA, AR, Revenue)"]
    CO["CO — Controlling<br>(CO-PA, Cost Centers)"]
    MM["MM — Materials Management<br>(Procurement, Inventory)"]
    PP["PP — Production Planning<br>(MRP, Individual Requirements)"]
    EWM["EWM — Extended Warehouse<br>Management"]
    TM["TM — Transportation<br>Management"]
    GTS["GTS — Global Trade Services<br>(Export Compliance)"]
    REV["Revenue Accounting<br>IFRS 15 (Part 2)"]
    REBATE["Rebate Management<br>(Part 2)"]
    IC["Intercompany Billing<br>(Part 2)"]

    OTC -->|"billing - FI postings"| FI
    OTC -->|"revenue - CO-PA"| CO
    OTC -->|"ATP, COGS"| MM
    OTC -->|"individual requirements"| PP
    OTC -->|"warehouse execution"| EWM
    OTC -->|"shipment planning"| TM
    OTC -->|"export compliance"| GTS
    OTC -->|"deferred revenue"| REV
    OTC -->|"settlement"| REBATE
    OTC -->|"cross-company flows"| IC

    class OTC source
    class FI,CO integration
    class MM,PP,EWM,TM target
    class GTS,REV,REBATE,IC reporting

Integration Reference Table

Integration	Document	Trigger	FI/CO Impact
OTC → FI-AR	Billing Document	VF02 Release	Creates open item, updates reconciliation account
OTC → FI-GL	PGI + Billing	Movement type 601, billing release	COGS + Revenue to ACDOCA
OTC → CO-PA	Billing release	Account determination (PA transfer)	Revenue, COGS, conditions to profitability segment
OTC → MM	PGI	Goods movement	Inventory reduced at standard or MAP cost
OTC → PP	Sales Order	Requirement transfer (IndReq)	Planned independent requirements created
OTC → Credit Mgmt	Sales Order entry	Credit check (automatic)	Exposure tracked in credit control area
OTC → EWM	Outbound Delivery	Transfer order creation	Warehouse execution driven by delivery
OTC → TM	Delivery / Shipment	Shipment document creation	Carrier assignment, freight cost settlement

12. Conclusion and Part 2 Preview

Part 1 has established the complete architectural foundation for OTC in SAP S/4HANA:

The organizational hierarchy — seven elements from Company Code to Transportation Planning Point — is permanent by design. The decisions made here constrain every configuration choice that follows, and changing them post-go-live is not a realistic option.

The master data architecture — unified Business Partner, Material Master sales views, and condition records — is the three-pillar foundation every transaction resolves against. Quality here determines the accuracy of every downstream posting.

The condition technique is the single most leveraged pattern in OTC. Pricing, free goods, material determination, output determination, and listing/exclusion all run on it. Understanding it once means understanding six capabilities simultaneously, and the configuration investment compounds across every application.

The two critical FI postings — PGI (movement type 601) and billing release to accounting — are where SD hands off to Finance. Both write to ACDOCA. Both must land in the correct accounting period. And both can be fully automated: EWM transfer order confirmation or shipment activity profiles for PGI; VF04 background jobs with no posting block on the billing type for billing release. A fully automated OTC financial chain distributes postings evenly across the period, eliminates the month-end billing spike, and removes SOX exposure from timing differences between physical shipment and system record.

VFX3 — the billing error monitor — is the residual control. Its count should be zero at period close. Treating it as a daily operational KPI, rather than an exception report, is the operational posture that keeps the automated chain clean.

Part 2 will cover:

Customer rebate agreements and condition contracts — the condition technique at its most commercially complex
Intercompany billing — stock transfer orders, cross-company document chains, and the IC distribution channels seeded in Section 1.2
Revenue recognition under IFRS 15 — deferred revenue, performance obligations, event-based recognition, and the interaction with the billing automation paths described in Section 7
Advanced returns management and dispute resolution
Drop shipments and third-party order processing
Embedded S/4HANA reporting and analytics for OTC