SAP Payment Approval Workflow: BCM Rules and Dual Control

An SAP payment approval workflow is not one screen. It is three gates in sequence: dual control on the payee's bank data, a separation between proposing and executing the payment run in F110, and the batch release in Bank Communication Management (BCM), where payments are grouped by rule and released through workflow steps, optionally with a digital signature. Most audit findings on payments come from treating the third gate as the whole control. A perfectly tiered release strategy protects nothing if the person releasing the batch also changed the supplier's IBAN yesterday.

This page covers each gate at configuration level: the objects, the transactions and apps, and where each one can be bypassed. The BCM overview explains what BCM is for. This page is about making its approval logic, and the controls around it, hold up.

Three gates, not one

The gates answer different questions, and they fail independently. That is the reason to design them together.

Gate 1: dual control on bank details

Payment fraud rarely changes the payment. It changes the payee's bank account and lets a normal payment run do the rest (the payment fraud prevention page lists it as standing-data tampering). SAP's control for this is sensitive fields for dual control. You define which vendor or customer master fields are sensitive in Customizing (Define Sensitive Fields for Dual Control). A change to one of them then has to be confirmed by a second person before the account can be paid. Until then, the account is blocked for the automatic payment run. FK08 confirms a single vendor and FK09 works through the list of unconfirmed changes.

The limitation matters for design. The block applies to the automatic payment run, not to postings. SAP's KBA 3404779 explains why invoices, and even manual payments, can still be posted against an account with unconfirmed changes. So a manual outgoing payment is outside this gate, and needs its own control. And the control is only as good as the list of fields you mark: bank details and alternative payee are the obvious ones, and whether a given bank field shows up for confirmation has its own KBAs. Test it with a real bank-detail change before relying on it.

The segregation rule is simple. Whoever confirms sensitive changes must not also approve payment batches. If they can do both, gate 1 and gate 3 are the same person, and the attack just needs that one person.

Gate 2: separating the proposal from the run

F110 has a two-step design that invites segregation: a proposal (which open items will be paid, how, from which bank) and the payment run (post the payment documents, then create the payment medium). The authorization object F_REGU_BUK controls each step by activity code:

The common segregation is a proposal role with 11–15 and a run role with 21–31, so the person who decides what gets paid is not the person who executes it. Watch activity 12 in particular. Editing the proposal means changing which items are paid, the payment method and the bank. That is a strong right, and it often gets bundled into a generic "AP clerk" role without anyone noticing.

Two points people get wrong here:

• FBZP is configuration, not a transaction for daily use. Paying company codes, payment methods, bank determination and ranking are Customizing, which should reach production through a transport. The control question for FBZP is change management on those settings (the decision log and change control discipline), not who runs it on Tuesday.
• The F110 proposal workflow is not an approval workflow. SAP's KBA 2765633 is explicit: the workflow-based release of the payment proposal organizes the clerks who review and edit the proposal. It does not support a multi-level release of payments. For that, SAP points you to BCM.

Gate 3: BCM batches and release strategy

This is the gate most people mean when they say "SAP payment approval workflow". Its configuration has four parts, and the order matters.

1. Merge into batches. After F110 or F111, the merge step (FBPM1, or its report SAPFPAYM_MERGE scheduled as a job) collects eligible payments and groups them into batches. The prerequisite that surprises people is that BCM's merge works on payments whose format runs through the Payment Medium Workbench, so a payment method still on a classic payment-medium program stays outside the batch logic. The DMEE format tree page covers the PMW side.

2. Payment grouping rules. Under Payment Grouping → Rule Maintenance you define rules with selection criteria built from payment fields such as company code, house bank and payment method, and give each rule a priority. When a payment satisfies more than one rule, the priority decides which batch it lands in. Additional grouping criteria can split a rule into finer batches, for example one per payment method. A batch's rule determines its release procedure, so a wrong priority is a wrong approval path.

3. Release strategy. Each rule is assigned a release procedure with its release steps. There are two release objects:

• BNK_INI for the first approval. It is the only step with change capability: the first approver can take individual payments out of the batch.
• BNK_COM for subsequent approvals, which act at batch level (approve or reject). BNK_COM can carry a varying number of steps, made conditional, for example on amount.

SAP delivers standard workflow templates for these steps. SAP's BCM documentation describes approval through standard workflow, with a standard role assigned to each release step so you can plug in your own agent determination.

4. Signature. Under Release Strategy → Digital Signatures, you can require that approval be signed. The signature method can be a user-credential check or a digital signature based on Secure Store and Forward (SSF), and approvers then need SSF data in their user master. The configuration guides agree on the order: enable "signature required" last, after the SSF setup, the approvers' user master data, the signature method and an end-to-end approval test are in place.

"

The most dangerous line in a BCM configuration is a checkbox. A rule marked for automatic payment sends its batches past the approval workflow entirely, and nothing on the approver's screen shows that it happened.

The checkbox is Mark Rules for Automatic Payments (No Approval), in the same Release Strategy node. It has legitimate uses, such as high-volume low-value runs where the control sits elsewhere. But it is an exemption from gate 3, and it should be in the control documentation as one, with an owner and a review date. In a configuration review, check this list before anything else.

Approving and monitoring. Approvers work in BNK_APP or the Fiori app Approve Bank Payments (F0673A). There they can check payments within a batch and approve, reject or defer individual payments or whole batches. Volume changes the approval problem: the app's "Approve in Background" function (KBA 3196261) runs mass approval as a background job, which avoids timeouts on large batches. It also makes it easier to approve without looking, so decide deliberately who gets it. And don't assume the app enforces four eyes on its own: SAP's KBA 2444592 states that Approve Bank Payments has no check on the creator, so a user can approve a payment they created — the separation has to come from roles and the approver assignment, not from the app. After release, BNK_MONI or Monitor Payments tracks the batch to the bank, and the status coming back (pain.002) closes the loop.

S/4HANA Cloud: approval rules instead of IMG

In SAP S/4HANA Cloud Public Edition, the same control is configured differently. SAP's documentation describes the app Manage Payment Approval Rules, where you define how many people (one or two) from which approver groups may approve which payment amount. The rule itself goes through approval: it is created, submitted, approved or rejected, and the user who submitted a rule may not approve it. That is four-eyes on the control itself, not only on the payments it governs.

The Cloud trap is the default. KBA 3731235 describes payment runs from Manage Automatic Payments being posted without an approval step until you enable the workflow, and lists the prerequisites: the Advanced Cash Operations scope item (J78), full cash management scope in the basic settings, and the payment approval settings (SSCUI 102336). If the scoping workshop assumed approval "comes with" payments, check this before go-live.

SAP's newer approval scenarios, starting in the cloud editions, run on the flexible workflow framework, which offers conditional triggering and flexible agent determination through Fiori. The underlying design decisions are the same either way: which payments need approval, from whom, in what sequence, and with what escape hatch.

The segregation matrix to test

Configuration only shows what the system can enforce. Whether it does depends on the roles. These are the combinations I would test in any payment-controls review:

The segregation of duties page covers the treasury-wide version, and access management and user provisioning covers how these combinations creep back in through emergency access and role changes.

Where AI requests land

The question that now comes up in design reviews is what happens when an AI step, not a clerk, creates the payment request. In SAP the answer sits exactly in these three gates. An agent that proposes payments should hit gate 2 under its own identity and meet gate 3 like any other initiator. It must never hold a BCM approval step. Can an AI agent approve its own payment? works through why the release strategy, not the agent framework, has to enforce that. Four-eyes and segregation of duties for AI agents covers what happens to a human approver who only ever sees the agent's summary.

What I couldn't verify, and left out

• Flexible workflow scenario IDs for bank payments. I found SAP documentation for the approval-rule app and for the flexible workflow framework in general, but not a scenario ID I could print with confidence. It is left out.
• Rule-priority numbering. Consultant guides describe which priority number wins when two grouping rules match. I could not confirm the direction in SAP's own documentation, so the page says only that priority decides.
• Agent determination details per release step. How your organization resolves approvers (organizational management, custom rules, BAdIs) is implementation-specific and not something a reference page should invent.

If you configure one thing differently after reading this, make it the first gate. Release strategies get the design workshops and the audit attention, while the bank-detail change that makes a fraudulent payment look routine happens in master data.

See also SAP Advanced Payment Management, BCM, APM and output-management boundaries and SAP Multi-Bank Connectivity.