What is the difference between BCM and output management in SAP?

Output management (the Payment Medium Workbench and DMEE) generates the payment file — it evaluates the payment data from the payment run and produces the payment medium in the bank's required format. Bank Communication Management sits around that: it batches outgoing payments, drives the approval/release workflow, and monitors the status of the batches as they go to and return from the bank. Put simply, output management makes the file; BCM controls and tracks the file's journey. They're complementary layers, not alternatives — one produces the medium, the other governs and monitors it.

What does SAP Advanced Payment Management (APM) do that BCM doesn't?

APM is a central payment hub: it receives payment requests from across the group (SAP and non-SAP sources), standardises and orchestrates them, and routes them to the right bank channel — a single controlled layer for all outbound payments. BCM, by contrast, is focused on the approval and status-monitoring of payment batches within the payment process. APM operates at the architectural level of 'all payments flow through one hub'; BCM operates at the level of 'this batch is approved and tracked.' Many landscapes use both, and the exact division depends on whether you've adopted an APM-centric hub or a classic payment-run design.

How do PMW, BCM and APM fit together?

Think of the outgoing payment as passing through layers: the payment run produces payment data; the Payment Medium Workbench (with DMEE formats) generates the payment medium in the bank's format; Bank Communication Management approves and monitors the batch; a connectivity layer transmits it to the bank; and status messages come back. Advanced Payment Management can sit above this as a central hub that receives and routes payments across the group. Which components you use, and exactly where format generation and routing happen, depends on your release, edition and whether you run a classic or hub-centric architecture — so map your own stack rather than assuming one universal picture.

SAP Payments: BCM, APM & Output Management Boundaries

"SAP payments" isn't one thing — it's a stack of layers, and most confusion comes from not knowing which layer owns what. Output management, Bank Communication Management, Advanced Payment Management: teams treat these as competing options or interchangeable names, when they're actually distinct responsibilities in the journey of an outgoing payment. Format generation is not approval; approval is not routing; routing is not transmission. Get the boundaries clear and you can design, troubleshoot and explain the payment stack precisely. Blur them and you'll spend every payment incident arguing about which component "should have" handled something it was never responsible for. This is the boundary map.

Architectures differ. The outgoing-payment stack, and exactly where each responsibility sits, depends on your release, edition, and whether you run a classic payment-run design (F110 + PMW + BCM) or an APM-centric hub. This article maps the responsibilities; confirm how they're arranged in your own system against SAP's documentation.

The layers of an outgoing payment

Follow one payment from ledger to bank and the distinct responsibilities separate cleanly:

Layer	Component (typical)	Owns
Payment data	Payment run (e.g. F110)	Deciding what to pay, to whom, from which bank
Medium generation	Payment Medium Workbench + DMEE	Producing the payment file in the bank's format
Approval & monitoring	Bank Communication Management	Batching, approval/release workflow, status monitoring
Central orchestration	Advanced Payment Management	Receiving, standardising and routing group-wide payments
Transmission	Connectivity (host-to-host/SWIFT/MBC)	Actually sending the file and receiving status

Two boundaries cause most of the confusion, so name them precisely.

Boundary 1: output management vs BCM

Output management makes the file. BCM governs its journey.

The Payment Medium Workbench (PMW), using DMEE format trees, evaluates the payment data and generates the payment medium — the DME file — in the format the bank requires. Payment methods can even use different formats per house bank and company code, so the same payment method produces the right file for each bank. That's output management's job: correct medium, correct format.

Bank Communication Management doesn't generate the file — it wraps the process around it: grouping payments into batches, driving the approval and release workflow (who signs off before money moves), and monitoring the status of batches to and from the bank. When a payment is "stuck for approval," that's BCM. When a payment file is "in the wrong format," that's output management. Different layer, different owner, different fix.

Output management answers "is the file right?" BCM answers "is the batch approved, and where is it now?" Confusing the two turns a two-minute triage into a two-team argument.

Boundary 2: BCM vs APM

BCM governs a batch. APM is the hub for all payments.

Advanced Payment Management operates at a different altitude. It's a central payment hub: it receives payment requests from across the group — SAP and non-SAP sources — standardises them, and routes them to the right bank channel, so every outbound payment flows through one controlled, monitored layer. That's the payment factory pattern realised in SAP.

BCM is narrower and process-level: the approval and status-monitoring of payment batches. You can run BCM without APM (classic design) and APM changes where orchestration and routing sit. In an APM-centric architecture, the hub becomes the central point payments pass through; in a classic architecture, the payment run, PMW and BCM carry the flow. Which you have determines where format generation and routing actually happen — so the boundary between BCM and APM is partly an architecture decision, not a fixed line.

Where In-House Cash sits

In-House Cash (IHC) is adjacent, not part of this stack: it's the internal bank that handles intercompany and payments-on-behalf-of (POBO), generating the payment requests that then flow into this outgoing stack. IHC decides the internal leg; the stack above handles the external leg to the bank. Keeping that separation clear stops IHC and APM being conflated — one is internal banking, the other is the outbound payment hub.

What usually goes wrong

Treating the components as alternatives. "Should we use BCM or output management?" is a category error — you need medium generation and approval/monitoring; they're different layers.
Assuming one universal architecture. Designing as if APM, BCM and PMW always divide the same way, when the split depends on release, edition and whether you run a hub.
Troubleshooting at the wrong layer. Chasing a format problem in BCM, or an approval delay in output management, because the boundary was never made explicit.
Conflating IHC with the payment hub. Treating internal banking and outbound orchestration as one thing.

What I would decide

Map your own stack first — for one real payment, name which component owns each layer (data, medium, approval, orchestration, transmission). That single diagram resolves most design and support disputes before they start. Choose an APM-centric hub when you genuinely need one controlled path for all group payments across SAP and non-SAP sources; keep the classic payment-run + PMW + BCM design when a hub would be more machinery than the payment volume justifies. Either way, hold the boundaries explicitly, and verify against your release and edition — because the one thing that's always true is that "SAP payments" is a stack, and every layer has an owner.

Part of the SAP Treasury & Cash Management guide. See also Bank Communication Management (BCM) in SAP and SAP Advanced Payment Management (APM). The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.