SAP Financial Supply Chain Management & Treasury

作者：Sajiv Francis 约 35 分钟阅读更新日期：2026-07-22 标签：AI, 人工智能, 大模型, SAP, FI, CO, 财务

Central Payments, Advanced Payment Management, Bank Communication Management, Multi-Bank Connectivity, House Banks & External Bank Communications

July 2026

Executive Summary

Treasury in SAP S/4HANA is not a single module — it is an integrated platform spanning liquidity visibility, payment execution, bank communication, risk management, and cash operations. The six components examined here — Central Payments, Advanced Payment Management (APM), Bank Communication Management (BCM), SAP Multi-Bank Connectivity (MBC), House Banks & Bank Account Management, and External Bank Communications — form the operational payment backbone of any mature SAP finance transformation.

The organizing principle is straightforward: cash flows originate in the Transaction Manager or from Accounts Payable, are routed through a payment engine, pass through approval and format controls, and exit the system via a standardized bank channel. Each component occupies a defined position in that chain. Understanding the chain as a whole — and the strict configuration sequencing it demands — is what separates implementations that go live cleanly from those that produce duplicate payments, suspense account overflows, and bank format rejections on day one.

This white paper covers the architecture, process flows, configuration steps, key tables, and integration touchpoints for each component, and concludes with a sequenced implementation blueprint and a catalogue of the most common pitfalls.

Context

The Problem with Distributed Payment Architectures

In a multi-ERP SAP landscape — the default state of any Fortune 500 that has grown through acquisition — payment execution is fragmented. Each source system runs its own F110 payment proposal, maintains its own house bank configuration, manages its own bank reconciliation, and holds its own liquidity buffer. The result: duplicated bank relationships, no enterprise-level payment visibility, and a treasury team flying partially blind on actual cash position.

SAP’s answer is a layered consolidation. Central Finance (CFIN) centralizes the accounting spine. Central Payments shifts payment execution into CFIN. APM and BCM provide a single validation, routing, and approval layer. MBC abstracts the bank channel complexity into a managed cloud service. The Universal Journal (ACDOCA) becomes the single ledger of record for every cleared payment.

Architectural Layers

The payment platform has three distinct layers:

Origination — where payment obligations are created. Either the Transaction Manager (treasury deals generating cash flows via F111), Accounts Payable (vendor invoices cleared via F110), or a Central Finance instance executing payments on behalf of source systems.

Processing and Control — where payments are validated, batched, approved, and formatted. APM handles routing and validation; BCM handles approval workflows and batch management; the Payment Medium Workbench (PMW) handles format generation.

Communication — where formatted payment files leave the SAP system and bank confirmations return. MBC is the managed cloud service that abstracts the technical bank channel. House Banks are the master data anchor that ties company codes to physical bank accounts.

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

TRM["Transaction Manager<br/>(TRM)"]:::source
AP["Accounts Payable<br/>(F110)"]:::source
CFIN["Central Finance<br/>(CFIN)"]:::source

APM["Advanced Payment<br/>Management (APM)"]:::integration
BCM["Bank Communication<br/>Management (BCM)"]:::integration
PMW["Payment Medium<br/>Workbench (PMW)"]:::integration

MBC["SAP Multi-Bank<br/>Connectivity (MBC)"]:::target
HB["House Banks &<br/>Bank Accounts"]:::target
BANK["External Banks"]:::target

GL["Universal Journal<br/>(ACDOCA)"]:::reporting
CASH["Cash Operations &<br/>Liquidity Management"]:::reporting

TRM -->|"F111 / FRFT"| APM
AP -->|"F110"| APM
CFIN -->|"Central Payment Run"| APM
APM --> BCM
BCM --> PMW
PMW --> MBC
MBC -->|"H2H / EBICS / SWIFT"| BANK
BANK -->|"Bank Statements"| MBC
MBC -->|"MT940 / camt.053"| HB
HB --> GL
GL --> CASH

Analysis

Central Payments

Concept and Motivation

Central Payments shifts the execution of vendor and intercompany payments from distributed source systems into the Central Finance instance. Prior to Central Payments, each source system ran its own F110 payment proposal, maintained its own house bank configuration, and managed its own bank reconciliation. In a multi-ERP landscape this produces fragmented bank relationships, duplicated liquidity buffers, and no enterprise-level payment visibility.

Central Payments solves this by technically clearing open items in the source system at the point of replication to CFIN — the open item can no longer be paid in the source — and reconstituting the payable exclusively in the CFIN instance. Once Central Payments is live, aging, open item analysis, and vendor correspondence all originate from CFIN only. Bank reconciliation is centralized. Cash operations and the liquidity forecast gain an enterprise-wide view across all source company codes. Payment factories for scanning, approval, and disbursement can be operated from the CFIN shared service center.

Process Flow

sequenceDiagram
    participant SRC as "Source System"
    participant SLT as "SLT Replication"
    participant AIF as "AIF Interface"
    participant CFIN as "Central Finance"
    participant BCM as "Bank Comm. Mgmt"
    participant BANK as "External Bank"

    SRC->>SRC: Invoice posted (FB60)<br/>GR/IR + Payable created
    SRC->>SLT: CFIN_ACCHD trigger fires
    SLT->>AIF: AC_DOC interface message
    AIF->>CFIN: Document posted to ACDOCA
    CFIN->>SRC: Open item technically cleared<br/>(cannot be paid twice)
    Note over CFIN: Actual open item lives<br/>only in CFIN
    CFIN->>CFIN: F110 Payment Proposal<br/>created in CFIN
    CFIN->>BCM: Payment batch submitted<br/>for approval
    BCM->>CFIN: Approved and released
    CFIN->>BANK: Payment instructions sent
    BANK->>CFIN: Bank statement received
    CFIN->>CFIN: Bank reconciliation<br/>completed in CFIN

Central Payments as a Standard Process Flow

The Central Payments cycle — source invoice, SLT/AIF replication, technical clearing, and the central payment run with BCM approval — as a BPMN 2.0 process:

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Central Payments — source invoice replicated to CFIN, technically cleared, paid centrally via BCM (FSCM & Treasury).
  Canonical BPMN 2.0 (Plan 01): standard namespaces, stable ids, DI included
  so the file imports cleanly into Camunda / Signavio / ARIS / Bizagi.
-->
<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="Defs_TreasuryCentralPayments"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_TreasuryCentralPayments" name="Central Payments — Source Invoice to Central Settlement" isExecutable="false">
    <bpmn:startEvent id="Start_Invoice" name="Vendor invoice posted in source system (FB60)">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_Slt" name="SLT captures document (CFIN_ACCHD trigger)">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Aif" name="AIF posts document to CFIN ACDOCA">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_TechClear" name="Technically clear open item in source (blocks double payment)">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_F110" name="Run central payment proposal in CFIN (F110)">
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:incoming>Flow_8</bpmn:incoming>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Approve" name="BCM batch approved?">
      <bpmn:incoming>Flow_5</bpmn:incoming>
      <bpmn:outgoing>Flow_6</bpmn:outgoing>
      <bpmn:outgoing>Flow_7</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_Rework" name="Rework and re-submit payment batch">
      <bpmn:incoming>Flow_7</bpmn:incoming>
      <bpmn:outgoing>Flow_8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Send" name="Transmit payment instructions to bank">
      <bpmn:incoming>Flow_6</bpmn:incoming>
      <bpmn:outgoing>Flow_9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Statement" name="Receive bank statement; reconcile in CFIN">
      <bpmn:incoming>Flow_9</bpmn:incoming>
      <bpmn:outgoing>Flow_10</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Settled" name="Payment settled — ACDOCA is ledger of record">
      <bpmn:incoming>Flow_10</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="Start_Invoice" targetRef="Task_Slt" />
    <bpmn:sequenceFlow id="Flow_2" sourceRef="Task_Slt" targetRef="Task_Aif" />
    <bpmn:sequenceFlow id="Flow_3" sourceRef="Task_Aif" targetRef="Task_TechClear" />
    <bpmn:sequenceFlow id="Flow_4" sourceRef="Task_TechClear" targetRef="Task_F110" />
    <bpmn:sequenceFlow id="Flow_5" sourceRef="Task_F110" targetRef="Gw_Approve" />
    <bpmn:sequenceFlow id="Flow_6" name="Approved" sourceRef="Gw_Approve" targetRef="Task_Send" />
    <bpmn:sequenceFlow id="Flow_7" name="Rejected" sourceRef="Gw_Approve" targetRef="Task_Rework" />
    <bpmn:sequenceFlow id="Flow_8" sourceRef="Task_Rework" targetRef="Task_F110" />
    <bpmn:sequenceFlow id="Flow_9" sourceRef="Task_Send" targetRef="Task_Statement" />
    <bpmn:sequenceFlow id="Flow_10" sourceRef="Task_Statement" targetRef="End_Settled" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_Process_TreasuryCentralPayments">
    <bpmndi:BPMNPlane id="Plane_Process_TreasuryCentralPayments" bpmnElement="Process_TreasuryCentralPayments">
      <bpmndi:BPMNShape id="Shape_Start_Invoice" bpmnElement="Start_Invoice">
        <dc:Bounds x="202" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Slt" bpmnElement="Task_Slt">
        <dc:Bounds x="330" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Aif" bpmnElement="Task_Aif">
        <dc:Bounds x="500" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_TechClear" bpmnElement="Task_TechClear">
        <dc:Bounds x="670" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_F110" bpmnElement="Task_F110">
        <dc:Bounds x="840" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Approve" bpmnElement="Gw_Approve" isMarkerVisible="true">
        <dc:Bounds x="1045" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Rework" bpmnElement="Task_Rework">
        <dc:Bounds x="1180" y="360" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Send" bpmnElement="Task_Send">
        <dc:Bounds x="1180" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Statement" bpmnElement="Task_Statement">
        <dc:Bounds x="1350" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Settled" bpmnElement="End_Settled">
        <dc:Bounds x="1562" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_Flow_1" bpmnElement="Flow_1">
        <di:waypoint x="238" y="260" />
        <di:waypoint x="330" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_2" bpmnElement="Flow_2">
        <di:waypoint x="450" y="260" />
        <di:waypoint x="500" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_3" bpmnElement="Flow_3">
        <di:waypoint x="620" y="260" />
        <di:waypoint x="670" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_4" bpmnElement="Flow_4">
        <di:waypoint x="790" y="260" />
        <di:waypoint x="840" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_5" bpmnElement="Flow_5">
        <di:waypoint x="960" y="260" />
        <di:waypoint x="1045" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_6" bpmnElement="Flow_6">
        <di:waypoint x="1095" y="260" />
        <di:waypoint x="1180" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_7" bpmnElement="Flow_7">
        <di:waypoint x="1070" y="285" />
        <di:waypoint x="1070" y="400" />
        <di:waypoint x="1180" y="400" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_8" bpmnElement="Flow_8">
        <di:waypoint x="1240" y="440" />
        <di:waypoint x="1240" y="500" />
        <di:waypoint x="900" y="500" />
        <di:waypoint x="900" y="300" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_9" bpmnElement="Flow_9">
        <di:waypoint x="1300" y="260" />
        <di:waypoint x="1350" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_10" bpmnElement="Flow_10">
        <di:waypoint x="1470" y="260" />
        <di:waypoint x="1562" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Configuration Steps

Step	Transaction / Path	Action
1	`FBZP`	Create House Bank and Bank Account for the CFIN company code
2	`SPRO → CFINIMG → Settings for Accounting Document Replication → Activate Tax Consistency Check`	Mandatory prerequisite — loads reference tables to CFIN via SLT
3	`SPRO → CFINIMG → Central Finance: Target System Settings → Central Payment → Activate Central Payment for Company Codes`	Specify source system company codes for which central payment is activated

Tax Reference Tables Required

When the Tax Consistency Check is activated, the following tables must be replicated from source to CFIN via SAP LT Replication Server:

Table	Content
`FINS_CFIN_T000F`	Client settings
`FINS_CFIN_T001`	Company codes
`FINS_CFIN_T005`	Countries
`FINS_CFIN_T007A`	Tax codes
`FINS_CFIN_T007B`	Tax processing keys
`FINS_CFIN_TAXD`	Tax jurisdictions

Advanced Payment Management (APM)

Concept and Motivation

Advanced Payment Management is the S/4HANA-native payment hub that supersedes the classical payment program for high-volume, multi-format treasury and AP payments. Its key architectural shift: payment format generation is centralized in the S/4HANA system, removing the need for each connected system to maintain its own format library.

APM operates on an internal ISO 20022 data model. All incoming payment requests — regardless of original format — are mapped into this model, validated, enriched, routed, and then re-emitted in the target bank format.

APM Processing Architecture

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

IN["Payment Import<br/>(ISO 20022 / MT101 / PEXR2003)"]:::source
VAL["Validation Engine<br/>Content checks · Duplicate checks"]:::integration
FRAUD["Fraud and Sanctions Screening<br/>(SAP or 3rd party — sync/async)"]:::integration
BAM["Bank Account Management<br/>Enrichment (BAM ID)"]:::integration
ROUTE["Payment Routing<br/>GL Accounts / In-House Cash / External Bank"]:::integration
CASH_UPD["Cash Management Update<br/>Amount + Value Date"]:::integration
APPROVE["Approval Workflow<br/>Full / Partial / Reject"]:::integration
DMEEX["Payment Medium Generation<br/>(DMEEX — centralized formats)"]:::target
BANK["External Bank"]:::target
CONFIRM["Confirmation Messages<br/>(file or MBC connector)"]:::reporting

IN --> VAL
VAL --> FRAUD
FRAUD --> BAM
BAM --> ROUTE
ROUTE --> CASH_UPD
CASH_UPD --> APPROVE
APPROVE --> DMEEX
DMEEX --> BANK
BANK --> CONFIRM

APM Processing as a Standard Process Flow

The APM pipeline — import, validation, screening, BAM enrichment, routing, approval, and DMEEX output — as a BPMN 2.0 process:

<?xml version="1.0" encoding="UTF-8"?>
<!--
  APM payment processing — import, validation, screening, BAM enrichment, routing, approval, DMEEX output (FSCM & Treasury).
  Canonical BPMN 2.0 (Plan 01): standard namespaces, stable ids, DI included
  so the file imports cleanly into Camunda / Signavio / ARIS / Bizagi.
-->
<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="Defs_ApmPaymentPipeline"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_ApmPaymentPipeline" name="Advanced Payment Management — Processing Pipeline" isExecutable="false">
    <bpmn:startEvent id="Start_Import" name="Payment order imported (ISO 20022 / MT101 / PEXR2003)">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_Validate" name="Validate content; run duplicate checks">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Screen" name="Fraud and sanctions screening (sync / async)">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Clean" name="Screening passed?">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_Reject" name="Reject or hold payment; notify originator">
      <bpmn:incoming>Flow_5</bpmn:incoming>
      <bpmn:incoming>Flow_11</bpmn:incoming>
      <bpmn:outgoing>Flow_6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Rejected" name="Payment rejected">
      <bpmn:incoming>Flow_6</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:task id="Task_Enrich" name="Enrich with Bank Account Management ID (BAM)">
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:outgoing>Flow_7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Route" name="Route: GL account / In-House Cash / external bank">
      <bpmn:incoming>Flow_7</bpmn:incoming>
      <bpmn:outgoing>Flow_8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Cash" name="Update Cash Management (amount + value date)">
      <bpmn:incoming>Flow_8</bpmn:incoming>
      <bpmn:outgoing>Flow_9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Approve" name="Approval workflow outcome?">
      <bpmn:incoming>Flow_9</bpmn:incoming>
      <bpmn:outgoing>Flow_10</bpmn:outgoing>
      <bpmn:outgoing>Flow_11</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_Dmeex" name="Generate payment medium (DMEEX central format library)">
      <bpmn:incoming>Flow_10</bpmn:incoming>
      <bpmn:outgoing>Flow_12</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Transmit" name="Transmit to bank; receive confirmation (MBC)">
      <bpmn:incoming>Flow_12</bpmn:incoming>
      <bpmn:outgoing>Flow_13</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Confirmed" name="Payment confirmed to originating system">
      <bpmn:incoming>Flow_13</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="Start_Import" targetRef="Task_Validate" />
    <bpmn:sequenceFlow id="Flow_2" sourceRef="Task_Validate" targetRef="Task_Screen" />
    <bpmn:sequenceFlow id="Flow_3" sourceRef="Task_Screen" targetRef="Gw_Clean" />
    <bpmn:sequenceFlow id="Flow_4" name="Pass" sourceRef="Gw_Clean" targetRef="Task_Enrich" />
    <bpmn:sequenceFlow id="Flow_5" name="Hit" sourceRef="Gw_Clean" targetRef="Task_Reject" />
    <bpmn:sequenceFlow id="Flow_6" sourceRef="Task_Reject" targetRef="End_Rejected" />
    <bpmn:sequenceFlow id="Flow_7" sourceRef="Task_Enrich" targetRef="Task_Route" />
    <bpmn:sequenceFlow id="Flow_8" sourceRef="Task_Route" targetRef="Task_Cash" />
    <bpmn:sequenceFlow id="Flow_9" sourceRef="Task_Cash" targetRef="Gw_Approve" />
    <bpmn:sequenceFlow id="Flow_10" name="Approved" sourceRef="Gw_Approve" targetRef="Task_Dmeex" />
    <bpmn:sequenceFlow id="Flow_11" name="Rejected" sourceRef="Gw_Approve" targetRef="Task_Reject" />
    <bpmn:sequenceFlow id="Flow_12" sourceRef="Task_Dmeex" targetRef="Task_Transmit" />
    <bpmn:sequenceFlow id="Flow_13" sourceRef="Task_Transmit" targetRef="End_Confirmed" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_Process_ApmPaymentPipeline">
    <bpmndi:BPMNPlane id="Plane_Process_ApmPaymentPipeline" bpmnElement="Process_ApmPaymentPipeline">
      <bpmndi:BPMNShape id="Shape_Start_Import" bpmnElement="Start_Import">
        <dc:Bounds x="202" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Validate" bpmnElement="Task_Validate">
        <dc:Bounds x="330" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Screen" bpmnElement="Task_Screen">
        <dc:Bounds x="500" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Clean" bpmnElement="Gw_Clean" isMarkerVisible="true">
        <dc:Bounds x="705" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Reject" bpmnElement="Task_Reject">
        <dc:Bounds x="840" y="360" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Rejected" bpmnElement="End_Rejected">
        <dc:Bounds x="1052" y="382" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Enrich" bpmnElement="Task_Enrich">
        <dc:Bounds x="840" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Route" bpmnElement="Task_Route">
        <dc:Bounds x="1010" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Cash" bpmnElement="Task_Cash">
        <dc:Bounds x="1180" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Approve" bpmnElement="Gw_Approve" isMarkerVisible="true">
        <dc:Bounds x="1385" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Dmeex" bpmnElement="Task_Dmeex">
        <dc:Bounds x="1520" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Transmit" bpmnElement="Task_Transmit">
        <dc:Bounds x="1690" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Confirmed" bpmnElement="End_Confirmed">
        <dc:Bounds x="1902" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_Flow_1" bpmnElement="Flow_1">
        <di:waypoint x="238" y="260" />
        <di:waypoint x="330" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_2" bpmnElement="Flow_2">
        <di:waypoint x="450" y="260" />
        <di:waypoint x="500" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_3" bpmnElement="Flow_3">
        <di:waypoint x="620" y="260" />
        <di:waypoint x="705" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_4" bpmnElement="Flow_4">
        <di:waypoint x="755" y="260" />
        <di:waypoint x="840" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_5" bpmnElement="Flow_5">
        <di:waypoint x="730" y="285" />
        <di:waypoint x="730" y="400" />
        <di:waypoint x="840" y="400" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_6" bpmnElement="Flow_6">
        <di:waypoint x="960" y="400" />
        <di:waypoint x="1052" y="400" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_7" bpmnElement="Flow_7">
        <di:waypoint x="960" y="260" />
        <di:waypoint x="1010" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_8" bpmnElement="Flow_8">
        <di:waypoint x="1130" y="260" />
        <di:waypoint x="1180" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_9" bpmnElement="Flow_9">
        <di:waypoint x="1300" y="260" />
        <di:waypoint x="1385" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_10" bpmnElement="Flow_10">
        <di:waypoint x="1435" y="260" />
        <di:waypoint x="1520" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_11" bpmnElement="Flow_11">
        <di:waypoint x="1410" y="285" />
        <di:waypoint x="1410" y="500" />
        <di:waypoint x="900" y="500" />
        <di:waypoint x="900" y="440" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_12" bpmnElement="Flow_12">
        <di:waypoint x="1640" y="260" />
        <di:waypoint x="1690" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_13" bpmnElement="Flow_13">
        <di:waypoint x="1810" y="260" />
        <di:waypoint x="1902" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Key APM Capabilities

Capability	Detail
ISO 20022 Internal Model	All payments normalized to ISO 20022 transfer structure on ingest; built-in mapping from external formats
Duplicate Detection	Configurable duplicate check rules applied at validation stage before any routing
Fraud / Sanctions Screening	Pluggable — SAP-native or third-party; supports synchronous (blocking) and asynchronous (advisory) modes
BAM Enrichment	Payment enriched with BAM ID of the bank account to be used — enforces central bank account governance
Routing Logic	Rules-based routing to internal GL accounts, in-house cash accounts, or external banks
Centralized Format Library	Payment formats maintained once in DMEEX; no per-system format maintenance required
Approval Workflow	Full, partial, or complete rejection; integrates with BCM for multi-level approval
Status Confirmations	Confirmation messages returned to payment-initiating systems via file or MBC connector

Payment Format Support

Format	Use Case
NACHA	US ACH payments
Fedwire	US high-value wire transfers
SWIFT MT	International correspondent banking (MT101, MT103, MT202)
ISO 20022 (pain.001 etc.)	SEPA and global XML-based payments
EBICS	European bank communication standard

Payment Medium Workbench (PMW)

For bank-specific or country-specific format variants, the Payment Medium Workbench provides a graphical editor for creating and testing custom formats. PMW’s test mode allows practitioners to preview the exact output file before submitting to the bank for approval — eliminating iterative format negotiation during onboarding. This capability alone justifies using PMW over classical payment medium programs for any implementation involving more than two banking relationships.

Bank Communication Management (BCM)

Concept and Motivation

BCM sits between the payment proposal and the payment file generation step. Its primary function is batch management and approval workflow — ensuring that payment files are reviewed and approved according to configurable threshold rules before they are formatted and sent to the bank. BCM is the SAP-native control point for segregation of duties on outbound payments: the initiator cannot approve, and approval limits enforce authorization levels.

The Treasury Payment Cycle

The four-step treasury payment cycle integrates BCM at step two:

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

S1["Step 1<br/>Create Payment Request<br/>in TRM"]:::source
S2["Step 2<br/>BCM<br/>Batch · Approve · Release"]:::integration
S3["Step 3<br/>Send via Middleware<br/>to SWIFT / Networks"]:::target
S4["Step 4<br/>External Bank Processing<br/>Clear · Confirm · EBS"]:::reporting

S1 --> S2 --> S3 --> S4

BCM Capabilities

Capability	Detail
Batch Cross-Payment Media Runs	Groups payments across multiple payment media (checks, wires, ACH) into a single approval batch
Multi-Level Approval Workflow	Configurable by payment type, amount, and company code; supports delegation and out-of-office substitution
Approval Limit Rules	Threshold-based rules — payments above a defined amount require dual approval; free-form wires require treasury director sign-off
Outbound Payment Monitoring	Dashboard visibility into payment status from proposal through bank confirmation
Inbound Message Monitoring	Bank statement import status, payment acknowledgements, rejection notices
SOX / SoD Controls	Initiator cannot approve; approval limits enforce authorization levels by role

BCM Transaction Codes

Transaction	Purpose
`F110`	AP payment program — invoice-based vendor payments and IHC internal transfers
`F111`	Treasury payment program — external payments from Transaction Manager
`FRFT_B`	Direct bank-to-bank transfers
`FRFT_TR`	Bank-to-business partner transfers
`RVND`	Free-form wire transfers

F110 vs. F111: F110 reads open items from the AP subledger. F111 is for treasury cash flows generated by Transaction Manager deals — these are not invoice-dependent. Both route through BCM but are distinct payment programs with separate configuration.

SAP Multi-Bank Connectivity (MBC)

Concept and Motivation

SAP Multi-Bank Connectivity is a managed cloud service built on SAP Cloud Platform Integration (CPI) that standardizes and automates bank channel integration. Prior to MBC, bank connectivity was a bespoke, project-dominated effort — each bank required custom middleware, format mappings, and ongoing certificate management. MBC abstracts this into a service that SAP actively operates on behalf of customers. The marginal cost of adding a new banking relationship drops dramatically: the bank connector catalog, certificate lifecycle management, and format library are all SAP-maintained.

MBC Architecture

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

S4["SAP S/4HANA<br/>Payment Engine / BCM"]:::source
CPI["SAP CPI<br/>MBC Managed Service"]:::integration
NORM["Format Normalization<br/>pain.001 / MT101 / NACHA"]:::integration
CERT["Certificate and Key<br/>Management"]:::integration
AUDIT["Audit Log and<br/>Non-Repudiation"]:::integration

H2H["Host-to-Host<br/>(SFTP / AS2)"]:::target
EBICS["EBICS<br/>(European Standard)"]:::target
SWIFT["SWIFT L2BA<br/>(via Alliance Lite2)"]:::target
BANK["External Banks"]:::target

EBS_IN["Bank Statements<br/>MT940 / camt.053"]:::reporting
ACK["Payment Acknowledgements<br/>pain.002 / MT199"]:::reporting

S4 -->|"Payment file"| CPI
CPI --> NORM
NORM --> CERT
CERT --> AUDIT
AUDIT --> H2H
AUDIT --> EBICS
AUDIT --> SWIFT
H2H --> BANK
EBICS --> BANK
SWIFT --> BANK
BANK -->|"Inbound"| EBS_IN
BANK -->|"Inbound"| ACK
EBS_IN --> S4
ACK --> S4

MBC Communication Channels

Channel	Protocol	Typical Use
Host-to-Host (H2H)	SFTP / AS2	Direct bilateral file exchange with a single bank; common in North America and for treasury banks with dedicated file portals
EBICS	EBICS 2.x / 3.0	Standard electronic banking protocol in Germany, France, Switzerland, and Austria; supports multi-bank from one endpoint
SWIFT L2BA	SWIFT Alliance Lite2 for Business Applications	Global correspondent banking; required for cross-border and FX payments; accessed via SWIFT’s managed lite connectivity for corporates
SFTP (Custom)	SFTP	Legacy bilateral connectivity where H2H is not formally packaged; MBC manages certificate rotation

MBC Outbound Flow

Step	Actor	Action
1	S/4HANA BCM	Payment batch approved and released; DMEEX generates formatted payment file
2	MBC	Receives file via CPI iFlow; validates structure against expected format schema
3	MBC	Normalizes to internal canonical model; applies format-specific transformations
4	MBC	Signs and encrypts using bank-issued certificates managed in MBC key store
5	MBC	Transmits over configured channel (H2H / EBICS / SWIFT)
6	Bank	Acknowledges receipt (pain.002 / MT199 / proprietary ACK)
7	MBC	Routes acknowledgement back to S/4HANA; updates payment status

MBC Inbound Flow — Bank Statement Import

Step	Actor	Action
1	Bank	Generates end-of-day statement (MT940 or camt.053)
2	MBC	Retrieves statement via configured channel on schedule
3	MBC	Normalizes to camt.053 canonical format regardless of source format
4	MBC	Routes to S/4HANA via CPI
5	S/4HANA	EBS processing: `FF_5` / `FEBP` posts clearing entries
6	S/4HANA	Cash Management updated; open items cleared in FI-AP / FI-AR

MBC vs. Classical Middleware

Dimension	Classical Middleware (PI/PO)	SAP MBC
Bank onboarding	Custom iFlow per bank	SAP-managed; bank connector catalog
Certificate management	Customer-managed	SAP-managed key store and rotation
Format library	Customer-maintained	SAP-maintained and updated
SWIFT access	Requires SWIFT bureau or own BIC	SWIFT L2BA — SAP as service bureau
Monitoring	Custom alerting	Built-in MBC dashboard + CPI monitoring
Regulatory updates	Customer applies patches	SAP delivers format updates as service
TCO	High per-bank project cost	Subscription-based; lower per-bank marginal cost

House Banks & Bank Account Management

House Banks — Concept

A House Bank in SAP is the master data object that represents a physical banking relationship — it ties a company code to a specific bank (identified by bank key / BIC) and its associated accounts. Everything downstream in the payment chain — payment methods, payment medium generation, bank statement import, liquidity management — references the house bank.

In S/4HANA, house bank management has been modernized through Bank Account Management (BAM) in the Fiori launchpad, replacing the classical FBZP / FI12 transaction model with a governed, workflow-driven account lifecycle.

House Bank Data Model

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

CC["Company Code<br/>(e.g. US01)"]:::source
HB["House Bank<br/>(Bank Key + BIC)"]:::integration
ACCT["Bank Account<br/>(Account ID + IBAN)"]:::integration
BAM["BAM ID<br/>(Internal Reference)"]:::integration
PM["Payment Method<br/>(W / T / U etc.)"]:::target
PMSA["Payment Method per<br/>Company Code"]:::target
GL_ACCT["GL Account<br/>(Bank Sub-Account)"]:::reporting
EBS["Electronic Bank Statement<br/>Import Config"]:::reporting

CC --> HB
HB --> ACCT
ACCT --> BAM
BAM --> PM
BAM --> GL_ACCT
PM --> PMSA
ACCT --> EBS
GL_ACCT --> EBS

House Bank Configuration Steps

Step	Transaction	Action
1	`FI12` / BAM Fiori	Create House Bank — assign Bank Key (routing number / BIC), bank name, address
2	`FI12` / BAM Fiori	Create Bank Account under House Bank — assign Account ID, IBAN, currency, GL account
3	`FBZP`	Assign House Bank to Payment Method per Company Code — defines which bank account is used for each payment type
4	`FBZP`	Define Ranking Order — when multiple house banks exist for the same payment method, rank determines selection priority
5	`FBZP`	Define Available Amounts — daily and per-run limits per house bank account
6	`OT83`	Assign GL Account to Bank Account for EBS posting
7	`FF67` / `FEBP`	Configure EBS import: statement format, posting rules, search strings for automatic clearing

Bank Account Management (BAM) — Governance Layer

BAM introduces a governed lifecycle for bank accounts that classical FI12 did not provide:

Lifecycle Stage	BAM Capability
Request	Any authorized user submits a bank account opening or change request via Fiori; dual approval required before activation
Active	Account is live; associated with BAM ID used in APM routing and MBC configuration
Signatory Management	Bank signatories maintained centrally; e-mandate files generated for bank submission
Amendment	IBAN changes, currency changes, and signatory changes all go through approval workflow
Closure	Deactivation workflow ensures no open payments or standing orders reference the account before closure

Why BAM matters for Central Payments: When Central Payments is active, the CFIN instance becomes the single payment executor. BAM ensures that bank account master data in CFIN is authoritative — source systems cannot independently open bank accounts and route payments. BAM is the governance anchor for the entire treasury payment architecture.

Payment Method Configuration

Payment methods bridge business process (what kind of payment?) and technical execution (which format, which bank?). Each method is configured at two levels: country level (FBZP → Payment Methods in Country) defining format class and required bank data, and company code level (FBZP → Payment Methods in Company Code) defining house bank assignment, available amounts, and min/max payment amounts.

Payment Method Code	Description	Typical Format
`T`	Bank Transfer (domestic)	NACHA / local ACH
`W`	Wire Transfer	Fedwire / SWIFT MT103
`U`	ACH Credit	NACHA CCD / PPD
`S`	SEPA Credit Transfer	pain.001.001.03
`B`	SEPA Direct Debit	pain.008
`C`	Check	Check print format

External Bank Communications

The Full Communication Lifecycle

External bank communication is bidirectional. Outbound (payments) is handled by APM, BCM, and MBC. Inbound encompasses bank statements, payment acknowledgements, and debit advices — all of which feed back into S/4HANA’s cash management and reconciliation engine.

sequenceDiagram
    participant TRY as "Treasury / AP"
    participant BCM as "BCM"
    participant MBC as "SAP MBC"
    participant BANK as "External Bank"
    participant EBS as "EBS Processing"
    participant GL as "Universal Journal"

    TRY->>BCM: Payment batch submitted
    BCM->>BCM: Multi-level approval
    BCM->>MBC: Approved payment file
    MBC->>BANK: Transmitted via H2H/EBICS/SWIFT
    BANK->>BANK: Payment processed
    BANK->>MBC: ACK / pain.002 confirmation
    MBC->>BCM: Status updated — Confirmed
    Note over BANK,MBC: End of Day
    BANK->>MBC: Bank statement MT940/camt.053
    MBC->>EBS: Statement delivered to S/4HANA
    EBS->>EBS: FF_5 / FEBP import and matching
    EBS->>GL: Clearing postings to ACDOCA
    GL->>TRY: Liquidity position updated

Electronic Bank Statement (EBS) Configuration

Configuration Object	Transaction	Purpose
Account Symbols	`OT83`	Define symbolic names for GL accounts used in posting rules (e.g., `MAIN_BANK`, `CLEARING`)
Posting Keys	`OT83`	Assign debit/posting keys to each account symbol
Posting Rules	`OT84`	Define how a bank transaction type maps to a GL posting — which accounts to debit/credit
Transaction Type Assignment	`OT85`	Map bank-specific transaction codes to SAP posting rules
Statement Format Assignment	`OT86`	Assign the statement format (MT940, camt.053, BAI2) to the house bank account
Search Strings	`FEBA`	Define string-matching rules for automatic open item clearing

EBS Posting Flow

Step	Action
1	MBC delivers bank statement file to S/4HANA (scheduled or on-demand)
2	`FF_5` imports statement; header matched to house bank / account ID
3	Each statement line evaluated against posting rules (`OT84`)
4	Search strings (`FEBA`) attempt automatic open item matching — payment document, reference, amount
5	Matched items: automatic clearing posted directly to ACDOCA
6	Unmatched items: posted to interim/suspense account; manual review via `FEBP`
7	Cash Management position updated upon posting

EBS Inbound as a Standard Process Flow

The inbound statement cycle — MBC retrieval, FF_5 import, and the auto-clearing versus suspense decision — as a BPMN 2.0 process:

<?xml version="1.0" encoding="UTF-8"?>
<!--
  EBS inbound — bank statement retrieval via MBC, FF_5 import, auto-clearing vs suspense review (FSCM & Treasury).
  Canonical BPMN 2.0 (Plan 01): standard namespaces, stable ids, DI included
  so the file imports cleanly into Camunda / Signavio / ARIS / Bizagi.
-->
<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="Defs_EbsInboundStatement"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_EbsInboundStatement" name="Electronic Bank Statement — Inbound Processing" isExecutable="false">
    <bpmn:startEvent id="Start_Eod" name="Bank generates end-of-day statement (MT940 / camt.053)">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_Retrieve" name="MBC retrieves statement; normalises to camt.053">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Import" name="Import statement into S/4HANA (FF_5)">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Rules" name="Evaluate lines against posting rules (OT84)">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Match" name="Open item matched via search strings?">
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
      <bpmn:outgoing>Flow_6</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_AutoClear" name="Post automatic clearing to ACDOCA">
      <bpmn:incoming>Flow_5</bpmn:incoming>
      <bpmn:outgoing>Flow_7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Suspense" name="Post to suspense; manual review and clearing (FEBP)">
      <bpmn:incoming>Flow_6</bpmn:incoming>
      <bpmn:outgoing>Flow_8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Cash" name="Update cash position (FF7A)">
      <bpmn:incoming>Flow_7</bpmn:incoming>
      <bpmn:incoming>Flow_8</bpmn:incoming>
      <bpmn:outgoing>Flow_9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Recon" name="Statement reconciled — liquidity position current">
      <bpmn:incoming>Flow_9</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="Start_Eod" targetRef="Task_Retrieve" />
    <bpmn:sequenceFlow id="Flow_2" sourceRef="Task_Retrieve" targetRef="Task_Import" />
    <bpmn:sequenceFlow id="Flow_3" sourceRef="Task_Import" targetRef="Task_Rules" />
    <bpmn:sequenceFlow id="Flow_4" sourceRef="Task_Rules" targetRef="Gw_Match" />
    <bpmn:sequenceFlow id="Flow_5" name="Matched" sourceRef="Gw_Match" targetRef="Task_AutoClear" />
    <bpmn:sequenceFlow id="Flow_6" name="Unmatched" sourceRef="Gw_Match" targetRef="Task_Suspense" />
    <bpmn:sequenceFlow id="Flow_7" sourceRef="Task_AutoClear" targetRef="Task_Cash" />
    <bpmn:sequenceFlow id="Flow_8" sourceRef="Task_Suspense" targetRef="Task_Cash" />
    <bpmn:sequenceFlow id="Flow_9" sourceRef="Task_Cash" targetRef="End_Recon" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_Process_EbsInboundStatement">
    <bpmndi:BPMNPlane id="Plane_Process_EbsInboundStatement" bpmnElement="Process_EbsInboundStatement">
      <bpmndi:BPMNShape id="Shape_Start_Eod" bpmnElement="Start_Eod">
        <dc:Bounds x="202" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Retrieve" bpmnElement="Task_Retrieve">
        <dc:Bounds x="330" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Import" bpmnElement="Task_Import">
        <dc:Bounds x="500" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Rules" bpmnElement="Task_Rules">
        <dc:Bounds x="670" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Gw_Match" bpmnElement="Gw_Match" isMarkerVisible="true">
        <dc:Bounds x="875" y="235" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_AutoClear" bpmnElement="Task_AutoClear">
        <dc:Bounds x="1010" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Suspense" bpmnElement="Task_Suspense">
        <dc:Bounds x="1010" y="360" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Cash" bpmnElement="Task_Cash">
        <dc:Bounds x="1180" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Recon" bpmnElement="End_Recon">
        <dc:Bounds x="1392" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_Flow_1" bpmnElement="Flow_1">
        <di:waypoint x="238" y="260" />
        <di:waypoint x="330" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_2" bpmnElement="Flow_2">
        <di:waypoint x="450" y="260" />
        <di:waypoint x="500" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_3" bpmnElement="Flow_3">
        <di:waypoint x="620" y="260" />
        <di:waypoint x="670" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_4" bpmnElement="Flow_4">
        <di:waypoint x="790" y="260" />
        <di:waypoint x="875" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_5" bpmnElement="Flow_5">
        <di:waypoint x="925" y="260" />
        <di:waypoint x="1010" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_6" bpmnElement="Flow_6">
        <di:waypoint x="900" y="285" />
        <di:waypoint x="900" y="400" />
        <di:waypoint x="1010" y="400" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_7" bpmnElement="Flow_7">
        <di:waypoint x="1130" y="260" />
        <di:waypoint x="1180" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_8" bpmnElement="Flow_8">
        <di:waypoint x="1130" y="400" />
        <di:waypoint x="1155" y="400" />
        <di:waypoint x="1155" y="260" />
        <di:waypoint x="1180" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_9" bpmnElement="Flow_9">
        <di:waypoint x="1300" y="260" />
        <di:waypoint x="1392" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

MT940 vs. camt.053

Dimension	MT940 (SWIFT Legacy)	camt.053 (ISO 20022)
Structure	Fixed-length SWIFT tags	XML with rich structured data
Remittance Info	Limited — unstructured tag 86	Rich structured remittance blocks
Transaction Detail	Minimal counterparty data	Full debtor/creditor IBAN, BIC, name
Auto-Matching Rate	Lower — requires search strings	Higher — structured references match directly
Regulatory Direction	Being phased out (SWIFT MX migration)	Strategic format — ISO 20022 global standard
SAP Support	`FF_5` MT940 import	`FF_5` / MBC camt.053 import

Any new bank connectivity project should default to camt.053 for inbound statements. The richer structured data materially improves auto-clearing rates and reduces the manual reconciliation workload in FEBP.

SWIFT MT-to-MX Migration

SWIFT is completing its migration from MT (legacy) to MX (ISO 20022) formats. For S/4HANA customers this means:

Outbound: MT101 → pain.001 / pain.002
Inbound: MT940 → camt.053; MT199 → camt.054

SAP MBC handles the translation layer during the transition period, but the medium-term design target is end-to-end ISO 20022. Any implementation starting today should treat ISO 20022 as the target state and MT support as a temporary accommodation for incumbent banking relationships that have not yet migrated.

Integration with Cash & Liquidity Management

All six components ultimately feed SAP Cash and Liquidity Management — the consolidated view of where cash is, where it will be, and how to optimize it.

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

CP["Central Payments<br/>Consolidated AP"]:::source
APM2["APM<br/>Validated Payment Flows"]:::source
BCM2["BCM<br/>Released Batches"]:::source
MBC2["MBC<br/>Bank Statement Data"]:::source
HB2["House Banks / BAM<br/>Account Balances"]:::source

CLM["Cash and Liquidity<br/>Management"]:::integration

FCST["Liquidity Forecast<br/>(AP/AR expected flows)"]:::target
ACTPOS["Actual Cash Position<br/>(Bank account balances)"]:::target
IHC["In-House Cash<br/>(Intercompany netting)"]:::target
ACDOCA["Universal Journal<br/>ACDOCA"]:::reporting
SAC["SAP Analytics Cloud<br/>(Treasury dashboards)"]:::reporting

CP --> CLM
APM2 --> CLM
BCM2 --> CLM
MBC2 --> CLM
HB2 --> CLM

CLM --> FCST
CLM --> ACTPOS
CLM --> IHC
CLM --> ACDOCA
ACDOCA --> SAC
FCST --> SAC
ACTPOS --> SAC

Cash Position vs. Liquidity Forecast

Dimension	Cash Position	Liquidity Forecast
Source Data	Actual bank statement balances (EBS-cleared)	Open AP / AR items + TRM expected cash flows
Horizon	Same-day / prior-day actual	Rolling forward — typically 13 weeks
Update Trigger	EBS import via MBC → `FEBP` posting	Real-time as invoices are posted / deals are booked
Primary User	Cash Operations — confirms available funds	Treasury — plans borrowing, investment, FX hedges
Key Transaction	`FF7A`	`FF7B`
S/4HANA Fiori App	Cash Position app	Liquidity Forecast app

In-House Cash (IHC) Integration

In-House Cash allows a corporate treasury to act as an internal bank for subsidiaries — centralizing external bank relationships while still processing intercompany settlements. Under a Central Payments architecture, IHC operates entirely within the CFIN instance:

Flow	Description
Subsidiary payment request	Subsidiary posts intercompany payable; CFIN replicates via SLT
IHC netting	IHC engine nets offsetting intercompany positions before external payment
External payment	Only the net cash flow exits to the bank via MBC
Internal settlement	IHC posts intercompany clearing entries directly to ACDOCA
Bank account reduction	Fewer external bank accounts required — subsidiaries operate via IHC accounts

Key Tables Reference

Payment and Bank Account Tables

Table	Description	Key Fields
`BNKA`	Bank master data	`BANKS`, `BANKL`, `BANKA`, `SWIFT`
`T012`	House banks	`BUKRS`, `HBKID`, `BANKL`
`T012K`	House bank accounts	`HBKID`, `HKTID`, `HKONT`, `BANKN`
`T012T`	House bank account texts	Description per account
`PAYR`	Payment medium records	`ZBUKR`, `HBKID`, `HKTID`, `CHECT`
`REGUH`	Payment header (F110 run)	`LAUFD`, `LAUFI`, `ZBUKR`, `LIFNR` / `KUNNR`
`REGUP`	Payment line items	Links `REGUH` to FI document and open item cleared

Electronic Bank Statement Tables

Table	Description
`FEBEP`	EBS line items (imported statement lines)
`FEBRE`	EBS posting records — links statement lines to FI documents
`FEBKO`	EBS statement header
`T028G`	Account symbols
`T028B`	Posting rules for EBS
`T028P`	Transaction type to posting rule mapping

BCM and Payment Order Tables

Table	Description
`FPAYH`	Payment order header
`FPAYHX`	Payment order header extension
`FPAYP`	Payment order line items
`FPAYPX`	Payment order line item extension
`FPAYSP`	Payment order status and approval tracking

Integration Touchpoints with Other SAP Modules

Module	Integration Point	Data Flow
FI-AP	F110 feeds APM/BCM with vendor payment proposals	AP open items → payment proposals → BCM batch → bank
FI-AR	Incoming payments from EBS clear AR open items	Bank statement → EBS → FEBP → AR clearing
TRM	F111 generates treasury cash flow payments	TRM deal → expected cash flow → F111 → BCM → bank
CO-PA / PaPM	Bank charges posted via EBS become cost inputs	Bank fee line items → GL → cost center allocation
CFIN	Central Payments concentrates all payment execution	Source AP open items → SLT → CFIN → payment run
Group Reporting	Cash and bank balances feed intercompany elimination	Bank GL accounts → ACDOCA → ACDOCU consolidation
SAC	Treasury KPI dashboards draw from ACDOCA + CLM	Actual cash + forecast → SAC planning models

Recommendation

Configuration Sequencing — The Non-Negotiable Build Order

The six components do not configure independently. There is a strict sequencing dependency, and violating it produces integration failures that are difficult to diagnose after the fact.

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

P1["Phase 1 — Foundation<br/>Bank Master Data · House Banks<br/>GL Sub-Accounts"]:::source
P2["Phase 2 — Payment Methods<br/>Country Level · Company Code Level<br/>Ranking + Available Amounts"]:::source
P3["Phase 3 — BCM<br/>Approval Workflow · Batch Rules<br/>SoD Limits"]:::integration
P4["Phase 4 — Format Layer<br/>PMW / DMEEX · APM Routing<br/>Fraud / Sanctions Screening"]:::integration
P5["Phase 5 — Bank Channel<br/>MBC CPI iFlows · Certificate Exchange<br/>H2H / EBICS / SWIFT Testing"]:::target
P6["Phase 6 — EBS Inbound<br/>Account Symbols · Posting Rules<br/>Search Strings · Format Assignment"]:::target
P7["Phase 7 — Central Payments<br/>Tax Table Replication · Company Code Activation<br/>BAM Governance Cutover"]:::reporting

P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7

Phase	Component	Hard Prerequisite
1 — Foundation	Bank Master (`FI01`), House Banks (`FI12` / BAM), GL Sub-Accounts	None
2 — Payment Methods	Payment Methods in Country and Company Code (`FBZP`), Ranking, Available Amounts	Phase 1 complete
3 — BCM	Approval Workflow, Batch Rules, SoD Limits	Phase 2 complete
4 — Format Layer	PMW / DMEEX Formats, APM Routing Rules, Fraud/Sanctions Screening	Phase 3 active
5 — Bank Channel	MBC CPI iFlow Config, Certificate Exchange, Channel Testing	Phase 4 formats assigned
6 — EBS Inbound	Account Symbols (`OT83`), Posting Rules (`OT84`), Transaction Types (`OT85`), Search Strings (`FEBA`), Format Assignment (`OT86`)	GL accounts finalized
7 — Central Payments	Tax Consistency Check, Company Code Activation, BAM Cutover	SLT replication running; full stack tested end-to-end

Common Implementation Pitfalls

Pitfall	Root Cause	Mitigation
Duplicate payments after Central Payment activation	Technical clearing not activated before cutover; source system still processes F110	Strictly sequence: activate technical clearing → confirm no open F110 runs in source → activate central payment
Cash Journal migration failures	Cash journal not at zero balance at cutover	Execute `FBCJC0` to close source cash journal; confirm zero balance before activation
EBS non-posting / suspense overflow	Bank transaction codes not mapped in `OT85`; posting rules missing	Map all bank transaction codes from the bank’s MT940/camt.053 spec before go-live; run EBS simulation with test statements
MBC certificate failures	Bank-issued certificates expired or mismatched	Enroll all accounts through MBC; never manage bank certificates outside MBC
BCM approval bottlenecks	Approval limits set too low; single approver for all amounts	Design approval matrix before configuration: amount thresholds, payment types, delegation rules, out-of-office substitutes
Payment format rejection by bank	PMW format variant not tested with bank’s validation tool	Complete a bank format acceptance test (FAT) before go-live; use PMW test mode to generate and validate sample files
House bank GL account mismatch	`T012K HKONT` points to wrong GL; EBS posting rule references different account	Cross-check `T012K HKONT` against `OT83` account symbol and `OT84` posting rule during configuration review
CO-PA mapping gaps in CFIN	CO-PA derivation not configured in CFIN; SAP Note 2645712 applies	Apply SAP Note 2645712 to skip CO-PA in CFIN CO documents where full derivation is not possible

The Design Principle

Build the foundation first — house banks, BAM, GL sub-accounts — then payment methods, then BCM controls, then MBC connectivity, then EBS inbound. Activate Central Payments last, only after the full stack is tested end-to-end with real bank files. The temptation to activate Central Payments early to demonstrate consolidation value is precisely what produces the duplicate payment and cash journal failures that delay go-live by weeks.

The SWIFT MT-to-MX migration adds urgency to format strategy decisions that teams historically deferred. Any implementation starting today should treat ISO 20022 (pain.001, camt.053) as the only target state. MT940 and MT101 support should be treated as temporary accommodations, not as design choices. SAP MBC’s managed translation layer makes this transition operationally feasible without a rip-and-replace of existing bank connections — but the configuration and testing investment is real, and it belongs in the project plan from day one.

来源说明：本文翻译/整理自 docs.sajivfrancis.com，作者 Sajiv Francis。原文链接保留，版权归原作者所有。