C

1
T

Mary Loughran
Praveen Gupta

Bank Communication
Management in SAP® S/4HANA

2
C /I

Mary Loughran, Praveen Gupta

Bank Communication Management in SAP® S/4HANA

ISBN:
978-3-9601-2357-6 (E-Book)
Editor:
Karen Schoch

Cover Design:
Philip Esch
Cover Photo:
istockphoto.com | roman_klevets No. 675896144
Interior Book Design (E-Book):
Johann-Christian Hanke

All rights reserved.

1st Edition 2020, Gleichen

© 2020 by Espresso Tutorials GmbH

URL: www.espresso-tutorials.com

All rights reserved. Neither this publication nor any part of it may be
copied or reproduced in any form or by any means or translated into
another language without the prior consent of Espresso Tutorials
GmbH, Bahnhofstr. 2, 37130 Gleichen, Germany.

Espresso Tutorials makes no warranties or representations with

respect to the content hereof and expressly disclaims any implied
warranties of merchantability or fitness for any particular purpose.

3
C /I

Espresso Tutorials assumes no responsibility for any errors that may

appear in this publication.
Feedback
We greatly appreciate any feedback you may have concerning this
book. Please send your feedback via email to: info@espresso-
tutorials.com.

4
T C

Table of Contents
Cover
Title
Copyright / Imprint
Introduction
1 The basics
1.1 What is SAP S/4HANA?
1.2 What is BCM?
1.3 Why use BCM?
1.4 Who would be interested in using BCM?
1.5 Prerequisites to using BCM
1.6 Where does BCM fit in the SAP landscape?
1.7 Licensing of the BCM module
1.8 Key advantages of using SAP BCM
1.9 Summary
2 Process overview
2.1 Process steps
2.2 Process steps in SAP
2.3 Bank statement monitor
2.4 Scheduled jobs
2.5 BAM versus BCM payment approvals
2.6 Summary
3 BCM configuration
3.1 Activating the Enterprise Business Function for BCM
3.2 BCM specific configuration
3.3 Additional configuration
3.4 Summary
4 Advanced topics
4.1 Triggering alerts

5
T C

4.2 Automatic reversal of rejected payments

4.3 BCM Connector
4.4 Summary
5 Resolving implementation issues
5.1 Workflow settings
5.2 Errors in the batching process
5.3 Resetting the merging of a batch
5.4 Payment file generation
5.5 Summary
6 SAP Multi-Bank Connectivity
6.1 Overview of SAP Multi-Bank Connectivity
6.2 Advantages of using SAP Multi-Bank Connectivity
6.3 Summary
7 Advanced Payment Management
7.1 Advanced Payment Management overview
7.2 Functionality included in Advanced Payment Management
7.3 BCM Connector versus Advanced Payment Management
7.4 Key benefits of Advanced Payment Management
7.5 Summary
8 Other useful information
8.1 Cutover to production
8.2 Definition of terms
8.3 BCM Fiori apps and transaction codes
8.4 Authorizations
8.5 BCM tables
8.6 Relevant SAP Notes
A The Authors
B Disclaimer

6
T C

Thank you for purchasing this book from Espresso Tutorials!

Like a cup of espresso coffee, Espresso Tutorials SAP books are
concise and effective. We know that your time is valuable and we
deliver information in a succinct and straightforward manner. It only
takes our readers a short amount of time to consume SAP concepts.
Our books are well recognized in the industry for leveraging tutorial-
style instruction and videos to show you step by step how to
successfully work with SAP.

Check out our YouTube channel to watch our videos at

https://www.youtube.com/user/EspressoTutorials.

If you are interested in SAP Finance and Controlling, join us at

http://www.fico-forum.com/forum2/ to get your SAP questions
answered and contribute to discussions.

Related titles from Espresso Tutorials:

Mary Loughran, Lennart Ullmann:

Guide to SAP® In-House Cash (ICH)
Mary Loughran, Praveen Gupta:
Cash Management in SAP® S/4HANA
Oona Flanagan:
A Practical Guide to SAP® S/4HANA Financial Accounting
Oona Flanagan:
Delta from SAP ERP Financials to SAP® S/4HANA Finance
Kees van Westerop:
New Fixed Asset Accounting in SAP® S/4HANA
Maddie Allenspach:
First Steps in SAP® S/4HANA Financial Accounting

7
T C

8
T C

9
I

Introduction
This book is intended to give business users, SAP support
staff, and SAP consultants an overview of the functionality
included in SAP’s Bank Communication Management (BCM)
module. As the BCM module is tightly integrated with the other
payment-related modules in SAP, this guide also includes an
introduction to these other modules.

Chapter 1 provides a brief introduction to SAP S/4HANA and the

great transformation SAP has made. A high-level overview of BCM
is also covered.

In Chapter 2, we cover the end-to-end process of using BCM. This

chapter shows the application-side process of executing payment
runs, batching payments, approving payments, and rejecting
payments. By the end of this chapter, readers should have a very
solid understanding of the BCM business processes.

After reviewing the business processes, Chapter 3 covers the

configuration required for BCM. Readers should find the
configuration to be fairly straight-forward.

Chapter 4 covers the more technical aspects of using BCM, such as:
implementing alerts, automated payment reversals in the case of a
rejected payment or batch, and using the BCM Connector to import
and process a payment file generated from an external system.

In Chapter 5, we look at implementation-specific issues that users

might encounter, and their resolutions.

A guide to payment processing in SAP would not be complete

without reviewing the newest payment-related modules: SAP Multi-

10
I

Bank Connectivity and Advanced Payment Management. These are

covered in Chapters 6 and 7.

We finish with Chapter 8, which provides further useful information.

It provides a glossary of terms, and looks at the apps included in the
Bank Communication Module, all of which are helpful resources for
readers.

A special thank you goes to everyone at Espresso Tutorials who

made this book possible.

We sincerely hope you find this book useful.

We have added a few icons to highlight important information. These

include:

Tip

Tips highlight information concerning more details

about the subject being described and/or additional
background information.

Warning

Warnings draw attention to information that you

should be aware of when you go through the
examples from this book on your own.

Finally, a note concerning the copyright: All screenshots printed in

this book are the copyright of SAP AG. All rights are reserved by

11
I

SAP AG. Copyright pertains to all SAP images in this publication.

For simplification, we will not mention this specifically underneath
every screenshot.

12
1T

1 The basics
As the title implies, this chapter covers the basics of the SAP
Bank Communication Management (BCM) module. In this
chapter, we discuss what the BCM module does, how it works,
its landscape, why companies would be interested in it, and the
key advantages of using it. We also provide a short
introduction to what SAP S/4HANA is. This chapter prepares
readers for subsequent chapters which provide more detailed
information.

1.1 What is SAP S/4HANA?

SAP S/4HANA is SAP’s next generation business suite designed to
help its customers “run simple” in a digital and connected world. This
new suite is built on an in-memory data platform, SAP HANA, and
offers a personalized user experience with SAP Fiori. The SAP
S/4HANA business suite is built natively and optimally to run only on
an SAP HANA platform. A brand-new user experience, SAP Fiori
has been delivered to improve the productivity and satisfaction of
business users and it brings the interface standard up to a current-
generation experience optimized for any device (e.g., laptop,
smartphone and tablet).

It is truly monumental that a 48-year-old software company, with a

customer base the size of SAP’s, can make the significant
generational changes to its product that SAP is making at this time.

SAP S/4HANA is SAP’s way of leveraging advancements in

technology, such as powerful multicore processors, huge memories,
optimized caches, and cloud computing etc., to re-write and design
their business application software and bring it to the next

13
1T

generation of technology, thereby making it mobile, efficient, and

powerful. In addition, with these changes, SAP can offer several
different deployment options to its current and future customer base,
such as SAP S/4HANA on-premise, SAP S/4HANA Cloud
Essentials, S/4HANA Cloud Extended, and hybrid environments.

With the move to SAP S/4HANA, SAP has completely changed the
user interface, and has upgraded functionality in many areas.

The BCM functionality offered in SAP S/4HANA is virtually the same

as in SAP ECC (ERP Central Component). Apart from Fiori tiles that
are used in place of transaction codes in ECC, the functionality is
the same. Because SAP S/4HANA is the future, we often use Fiori
apps in screenshots throughout this book, but always mention the
associated transaction code for the functionality being covered.

1.2 What is BCM?

BCM is a component within SAP’s Treasury and Cash Management
solution offering, which is part of SAP Financial Supply Chain
Management (FSCM). SAP’s Treasury and Cash Management
solution offering is broadly composed of the following areas:

Payments and bank communications

Cash and liquidity management
Debt and investment management
Financial risk management

BCM is included under payments and bank communications.

SAP Bank Communication Management is used to efficiently

manage outbound and inbound communications with banking
partners. This includes batching of payments, approval of payments,
exception handling, status tracking, and centralized reporting.

14
1T

The BCM module impacts the payment processes applicable to

most organizations. More broadly, it covers the processes relating to
Accounts Payable (AP), Accounts Receivable (AR), Treasury, and
payroll. BCM can be used as the centralized reporting hub within
SAP. Without using BCM, there is no SAP standard functionality to
track the status of payments. With BCM, there is a status monitor
that can be used by AP, Treasury, and payroll personnel to check the
latest status of their payments.

BCM also has a bank statement monitor that gives a high-level view
of the bank statements imported into SAP. It is an important first step
for Treasury departments to check the status of imported bank
statements before looking at their cash position report.

Below is a list of inbound and outbound files that a company

typically transfers to, or receives from, their banking partners daily:

Outbound messages/files to bank:

Accounts Payable payments
Accounts Receivable payments
Treasury payments
Employee/payroll payments
Payment files from third-party systems
Inbound messages/files from the bank:
Delivery notification from payment network
File and transaction level acknowledgements
Current day reporting
Prior day reporting

For outbound flows to banks, BCM can be used to manage the flow
of information to the bank and to determine the latest status based

15
1T

on delivery notification from the payment network and

acknowledgments from the bank. From an outbound payment
standpoint, BCM provides the following capabilities:

Merging of payments
Flexible payment approval routing (with or without digital
signature)
Payment file generation
Payment status (acknowledgement) tracking and notifications

For inbound flows from banks, BCM can be used to determine the
following statutes related to reconciliation of the prior day’s reports
along with balance-related information:

Processing status
Difference status
Serial number status
Reconciliation status

Prior to the release of the SAP BCM, SAP did not provide users with
the ability to merge payments from various payment runs using pre-
configured rules and route them for approval to appropriate users
before the payment file was created. SAP system users also could
not process and track file and transaction-level acknowledgments
that were provided by the banks. With the addition of BCM, SAP
now provides these additional capabilities along with payment and
bank statement status monitoring tools.

Transferring files to and from banks

There is often a misunderstanding regarding the functionality

included within BCM, in that BCM does not communicate with

16
1T

the banks. It supports the files going to and coming

from the banks within SAP. For information
regarding transferring files to, and receiving from,
banks, please see Chapter 6 on SAP Multi-Bank
Connectivity.

1.3 Why use BCM?

We will now look at payment process flow, both with and without
BCM, to further explain how BCM works and where it fits into
payment processing in SAP.

1.3.1 Payment process without BCM

In the payment process flow shown in Figure 1.1, we have used the
term payment program to mean either the Schedule Automatic
Payments app (transaction code F110), which is used to process AP
(Accounts Payable) invoices, or the Automatic Payment
Transactions for Payment Requests app (transaction code F111),
which is used to process payment requests.

Note that approval on the banking portal (see the fourth step in
Figure 1.1) might be not required in all payment scenarios after the
payment file is created and transferred to the bank. However, in the
process flow shown here, we are assuming that approval at the
bank is required after the payment run is competed and before the
bank can begin payment processing.

17
1T

Figure 1.1: Payment process flow without BCM

The process flow starts with the payment program run 1, which
processes payment requests and creates a payment file in XML
format. The XML file is delivered to the bank; in this example via
SWIFT. Once the file is received by the bank, it is approved by the
business user in the banking portal, which then triggers the actual
payment processing of the file by the bank. The same process is
repeated for payment program runs 2 and 3. Every payment run
creates an XML file which is individually delivered to the bank via
SWIFT and goes through the approval process before the bank
begins payment processing.

Payment formats

SAP has the ability to generate payment files in

many different formats. Because XML
(pain.001.001.03) is used globally, we are using the
XML payment format as an example here.

Payment status tracking is not possible in SAP if BCM is not used,

even though most banks do have the capability to provide payment
status reports (PSRs) for XML payments. Users have to rely on
external banking portals, current day bank statements (CDRs), or
possibly email notifications by the bank, assuming email notifications
are available.

Without BCM, it is not possible to track expected bank statements

against received bank statements, which are received on a daily
basis in SAP. Users must go to either bank statement processing
(Reprocess Bank Statement Items app /transaction code FEBAN) or
display the electronic bank statement (Display Bank Statements app

18
1T

/transaction code FF.5) to confirm if the bank statement was

received.

1.3.2 Payment process with BCM

The process flow shown in Figure 1.2 starts with payment program
runs 1, 2, and 3, where payment requests are processed.

Figure 1.2: Payment process flow with BCM

However, with BCM, instead of creating an XML file immediately

upon completion of the payment run, payments are queued for
batching and approval before the payment file is created. In this
example, BCM combines the payments into one file before they are
transferred to the bank.

Payment file creation

When BCM is used, the payment files are not

created until either the merge program has been
executed (if there are no payment approvals
required) or after payment approvals have been
executed. This is important because it is better not to have the
payment files sitting on a file server where they can be
manipulated before being sent to the bank. With BCM, the
payment files are created at the last possible moment.

19
1T

Payments from multiple payment runs can be merged together

(transaction code FBPM1) to create one or more payment batches
which are then routed for approval, if required. In the process flow
shown above, payments from payment run 1, 2, and 3 are merged
together to create one payment batch which is routed for approval
as per the setup. After payment batch approval (Approve Bank
Payments app /transaction code BNK_APP), the XML payment file
is created, which is delivered to the bank via SWIFT. In this case,
approval has already taken place in SAP, so the bank can
immediately process the payment file upon receipt.

The requirement to approve a file before it is processed by the bank

can be accommodated using BCM. When using BCM, this approval
process at the bank may no longer be necessary. This is because
the approval can be made in SAP before the payment file is
transferred to the bank.

For XML payments, most banks have the capability to provide

payment status reports that can be imported into SAP and which
update the status of the payment batch, if BCM is used. Users can
use the Monitor Payments app (transaction code BNK_MONI) to
look up the status of a given payment and/or a batch.

With BCM, users also have access to the Bank Statement Monitor
app (transaction code FTE_BSM) that can be used to obtain the
status and balance-related information for the prior day’s reports, for
bank accounts that are set up for bank statement monitoring.

The use of BCM can increase the efficiency of payment processing

and reconciliation. It can also help with internal controls and
payment fraud prevention.

1.4 Who would be interested in using BCM?

20
1T

The diagram in Figure 1.3 shows the core functions of SAP BCM.
SAP BCM works with ISO 20022 XML payments, which is a global
standard that is supported by most banks worldwide.

Figure 1.3: BCM at a glance

From our perspective, most SAP customers process their Accounts

Payable, Accounts Receivable, and Treasury payments in SAP and
can benefit from a company-wide adoption of XML payments.

Using the ISO 20022 XML format

Using one payment file format within the

organization and across all banks makes the system
more scalable and maintainable moving forward.

SAP BCM can be useful for companies that require a final approval
after the completion of payment runs, and before the payment file is
created and sent to the bank. SAP BCM can be used for payment
approvals, and the entire workflow is completed within SAP with
proper audit trails. In addition, BCM can be used as a centralized
payment hub for the organization.

21
1T

SAP BCM payment and bank statement monitoring tools help SAP
customers proactively monitor payments and bank statements using
a centralized tool within SAP.

Finally, as SAP rolls out new SAP S/4HANA functionality, BCM is

becoming a key component for this functionality. Figure 1.4
illustrates a current SAP landscape showing SAP Multi-Bank
Connectivity and Advanced Payment Management. SAP Multi-Bank
Connectivity is SAP’s bank communication software. Advanced
Payment Management is a module used for payment centralization,
format validation, and exception processing. We have devoted a
chapter to each of these new areas, so readers can understand the
direction SAP is heading with payment processing.

Figure 1.4: SAP S/4HANA payment processing architecture

1.5 Prerequisites to using BCM

The following are prerequisites to using BCM:

22
1T

Enable the enterprise business function set FIN_FSCM_BNK.

This is not reversible.
Use of Payment Medium Workbench for media creation for
payments is required.
Release level ERP 6.0, Enhancement Package 4 or higher
If BCM is not universally used for all payments, then companies
will need to ensure that there is a clear distinction between
BCM and non-BCM payments based on reservation for cross-
payment run media and payment methods. This might lead to
some process restructuring.

1.6 Where does BCM fit in the SAP landscape?

The BCM component is available with SAP ECC as well as in SAP
S/4HANA. As per the latest version, there is fundamentally no
difference between the functionality offered between SAP ECC and
SAP S/4HANA. However, users get the Fiori app experience when
using SAP S/4HANA, which is not the case with SAP ECC.

BCM fills a space between the SAP back-end modules and the
banks, as shown in Figure 1.5.

23
1T

Figure 1.5: SAP landscape with BCM

SAP BCM can be used as a standalone component without any

additional SAP software such Advanced Payment Management or
SAP Multi-Bank Connectivity. If companies are not using SAP
software for bank connectivity, they can still use BCM while using
other connectivity mechanisms such as host-to-host connections,
SWIFT Alliance Lite, direct connectivity with SWIFT via SAP PI, etc.

Transferring payment files to the bank

24
1T

SAP BCM is a component that sits within SAP ECC or SAP

S/4HANA and is independent of the method used to
transmit files to and from the various banking
partners.

1.7 Licensing of the BCM module

Although licensing may vary based on customer-specific situations,
and can change at any time, the current licensing for the BCM
module is as follows:

For SAP customers in ECC, BCM is a separate license.

For SAP customers in SAP S/4HANA, BCM is included with a
license to SAP S/4HANA Cash Management (also known as
Advanced Cash Management). For customers who have not
purchased SAP S/4HANA Cash Management, BCM can be
purchased separately.

1.8 Key advantages of using SAP BCM

The BCM module provides important improvements for companies.
Some of the key advantages of BCM are:

It gives the ability to merge payments from various payment

runs using predefined rules and to create payment batches that
can be routed for approvals through workflow. There are many
payment attributes such as amount, payment origin, company
code, payment methods, currency, house bank, and value date
that can be used to batch payments together.
It offers the optional ability to approve payments before the
payment file is created and is delivered to the bank. A payment
batch can still be sent to the bank without approval, if approvals
after the payment runs are not necessary.

25
1T

It enables users to digitally sign the payment file in the approval

step as an additional optional security feature. If used, it can
provide two factors of identification.
It provides the ability to import delivery notifications from the
payment network and payment acknowledgements from the
bank. In SAP, this can be viewed in the Monitor Payments app
(transaction code BNK_MONI), which shows all payments and
their associated statuses. Business users can validate that their
payments were sent successfully, without having to log on to the
banking portals.
BCM’s bank statement monitor gives Treasury and bank
reconciliation users a detailed view of the status of bank
statements expected versus bank statements imported daily. In
addition, users can view a reconciliation of the balance in SAP
by account against the balance at the bank, as delivered in the
bank statements. This report can also be used to notify users of
any bank statements missing for the day.

1.9 Summary
In this chapter, we have set the stage for the following chapters,
which provide progressively more detailed information. Readers
should now understand the basics of SAP BCM—what it is, how it
works, its landscape, why companies would be interested in it, and
the key advantages of using it.

26
2P

2 Process overview
In this chapter, we discuss the steps involved when using the
BCM module and walk through these steps in SAP. From the
process perspective, we start with the payment programs. The
steps prior to the execution of the payment programs are not
discussed here.

The use case scenario we use throughout this book adopts the
following:

Payments under $10,000 are batched together and do not

require approval.
Payments from $10,000 and under $10,000,000 are batched
together and require one approval.
Payments of $10,000,000 and over are batched together and
require two approvals.

We assume both the AP and Treasury payment programs are in-

scope and all payments are routed through the BCM module. At
payment approval, a digital signature is required.

The advantages of routing all payments through BCM are:

There is no risk that a payment file will be generated without the

required approvals.
BCM can be used as a centralized reporting hub for the
company.
There is a consistent process across all payments.

2.1 Process steps

27
2P

Before viewing the process steps using SAP screenshots, we will

first walk through the end-to-end process flow for a vendor payment
scenario in which two approvals are required before a payment file
is sent to the bank. This process is outlined in Table 2.1.

The payment file format in this case is pain.001.001.03 and the bank
sends back both file and transaction level acknowledgements in
pain.002.001.03 format.

28
2P

29
2P

Table 2.1: Process flow with two payment approvals

2.2 Process steps in SAP

In this section, we walk through the process flow described above,
using screenshots from SAP.

2.2.1 Payment programs

If BCM is not used, or the payment run ID pattern is not maintained
in the R C -P R P M
program (transaction code OBPM5), then the execution of the
payment run (either Schedule Automatic Payments App (transaction
code F110) or Automatic Payment Transactions for Payment
Requests app (transaction code F111)) results in an accounting

30
2P

posting and the creation of the payment run media (i.e., the payment
file). However, when BCM is used, the execution of the payment
program does not result in the creation of a payment file. Instead,
users see the message shown in Figure 2.1, at the bottom of the
payment log. This is an informational message and does not
indicate an error.

Figure 2.1: Message—payment routed to BCM

The message P 04/06/2020 PG001

- means that this payment run
will go through BCM and is now queued for batching.

2.2.2 Merging payments

Users can view the payments that are queued for batching using the
P report (transaction code
BNK_MONIP). There are many selection option fields that can be
used to determine what specific payments to display, as shown in
Figure 2.2. By pressing the A S button (not shown
here), users can see all input fields.

31
2P

32
2P

Figure 2.2: Selection options for Payment status (batching) process report

Payments that are queued for batching but are not yet processed by
the Creation of Cross-Payment Run Payment Media program
(transaction code FBPM1) have the status P ,
as shown in Figure 2.3.

33
2P

Figure 2.3: Payment status for batching process report (BNK_MONIP) output

The Creation of Cross-Payment Run Payment Media program

(transaction code FBPM1) can be scheduled to run frequently
throughout the day (e.g. every five minutes), although this is an
implementation-specific decision. The inputs when running the
program are static and can therefore be easily scheduled.

We ran this program manually so readers can have a better

understanding of the selection options available in this transaction.
In our example, we have used payment R D ,I ,
and P to merge payments from one payment
run, as shown in Figure 2.4.

34
2P

Figure 2.4: Creation of Cross-Payment Run Payment Media program (FBPM1) inputs

Figure 2.5 shows the screen that appears after executing this
transaction. It displays the number of payments selected for
batching and a message indicating that the collector “was created or
updated”, meaning that the batching process has been started.

35
2P

Figure 2.5: Creation of Cross-Payment Run Payment Media program (FBPM1) output

Table 2.2 lists the six payments executed in the payment run shown
above, and also indicates the associated batch numbers.

Batch Payment amount Batching rule used

46 $6,500 Vendor Payment Less 10K
46 $7,000 Vendor Payment Less 10K
47 $500,000 Vendor Payment Between GTE 10K and LT10M
47 $450,000 Vendor Payment Between GTE 10K and LT10M
45 $21,000,000 Vendor Payment Greater than or equal to 10M
45 $17,000,000 Vendor Payment Greater than or equal to 10M
Table 2.2: Example payments

Although it is not required from the process standpoint, users can

run the P report
(transaction code BNK_MONIP) to display the updated status of
payments that were queued for batching, as shown in Figure 2.6.

36
2P

Figure 2.6: Payment status for batching process report (BNK_MONIP)

SAP has three different statuses relating to batching in the P

program (transaction code
BNK_MONIP):

P —payment is queued for batching but

not batched yet
P —batch is created but payment medium is
not created
P —payment medium created

Note that payments where the amount is less than 10,000 USD are
in P status because payments under this amount do
not require approvals. For payments greater than 10,000 USD, the
status is P because they still need to go through
the approval process before the payment file can be generated.

37
2P

Running Creation of Cross-Payment Run Payment Media and

approvals

If the Creation of Cross-Payment Run Payment

Media program (transaction code FBPM1)—also
known as the payment merging program—is
executed manually, the person running it can be a
payment approver. This applies to executing the payment
programs as well. The person who executes the payment
program can also approve the payments.

2.2.3 Payment approvals

Approvals can be required on payments before the payment
medium is created. The Approve Bank Payments app (transaction
code BNK_APP) is used to approve payments. Keep in mind,
however, it is not required to have approvals in BCM.

In BCM, there are two types of approvers:

Verifier—can approve or reject individual payments

Approver—can only approve or reject entire batch

The Verifier is always the first approver, and to avoid confusion, we

refer to this as “first releaser”. Any approvals after the first are done
by the Approver. This is an important distinction to make because
only the Verifier has the ability to approve or reject individual
payments.

Approvers can see batches that are in different approval stages and
require their approvals using the Approve Bank Payments app
(transaction code BNK_APP).

38
2P

In our scenarios, both batches that require approval are in the first
approval stage and can be seen on the C R tab,
as shown in Figure 2.7.

Figure 2.7: Approve Bank Payments app (BNK_APP)

The A R S tab lets users approve batches

that have gone through the first approval, but which require
additional approvals. Because both of our batches are still in the first
approval stage, we do not see any batch on the A
R S tab, as shown in Figure 2.8.

Figure 2.8: Approve Bank Payments app (BNK_APP)—additional approvals

First approval
We will now approve batch 47. This requires only one approval, as
indicated by the F (see highlighted text) in the

39
2P

F A column, as shown in Figure 2.9.

Figure 2.9: Approve Bank Payments (BNK_APP) final approval

We select the batch and click on the payments icon , or double

click on the row of the batch (Figure 2.10), to display all payments in
the batch.

Figure 2.10: Click for batch detail

Payment-level information is displayed in the next screen, as shown

in Figure 2.11.

40
2P

Figure 2.11: View batch detail

At this point, we have the following options:

Approve all payments

Reject all payments
Resubmit the entire batch at a later date
Resubmit individual payments at a later date
Approve individual payments
Reject individual payments

For our example, we approve both payments in batch 47 by

selecting the payment batch and clicking on the approve icon , as
shown in Figure 2.12.

41
2P

Figure 2.12: Approve batch

By clicking on the approve icon , the batch disappears from the

list, as shown in Figure 2.13.

Figure 2.13: Approved batch disappears from approval screen

We then click on the S icon to complete the first approval

process and the screen shown in Figure 2.14 then appears.

42
2P

Figure 2.14: Batch approval message

By clicking on the continue icon , as shown in Figure 2.14, we

are taken to the screen shown in Figure 2.15, where we have to
enter our SAP system password to approve the batch.

Figure 2.15: Enter digital signature

After entering the SAP password, we click on the continue icon

one more time to complete the approval process. A message is then
displayed at the bottom left of the screen indicating that the approval
was successfully executed (see Figure 2.16).

43
2P

Figure 2.16: Message—approval successful

SAP GUI versus Fiori

The digital signature/password functionality is not

available for the Fiori Approve Bank Payment app.
As a workaround, users can use the Approve Bank
Payments (BNK_APP) SAP GUI application.

As of version 1809, it is possible to use SMS authorization

instead of a digital signature.

Users are able to see the updated status of a payment batch in the
Monitor Payments app (transaction code BNK_MONI). For our
example, we have also approved batch 45 in the exact same way,
so we will not walk you through the entire process again. The status
of both batches is displayed in Figure 2.17.

44
2P

Figure 2.17: Batch status after the first approval

Batch 47 required only one approval, so it has a status of P

M C , and the payment file has been created. Because
batch 45 required two approvals and only one approval is completed
so far, it is in I A status.

Second approval
We will now walk through the second and final approval of batch 45.
As mentioned earlier, the Approve Bank Payments app (transaction
code BNK_APP) is used to approve payments.

We will look at the A R S tab, which lets

users approve batches that have gone through the first approval, but
which require additional approvals.

45
2P

We select the batch and click on the payments icon , as shown in

Figure 2.18, to display the payment details included in the batch.

Figure 2.18: Second approval

Drilling down on the batch to see the payment details, we can see
from the screenshot in Figure 2.19 that there is no option to approve
or reject individual payments, unlike what appeared in the first
approval payment details screen.

Figure 2.19: Payment details on second approval

At this step, we have the following options:

46
2P

Approve all payments in the batch

Return all payments in the batch

To approve the payment batch, ensure that the batch is selected and
click on the approve icon , as shown in Figure 2.20.

Figure 2.20: Second approval step

After the payment is approved, it disappears from the list, as shown

in Figure 2.21.

Figure 2.21: Approve payments screen after approval

We then need to click on the S button, after which an approval

message screen appears, as shown in Figure 2.22. Click on the
continue icon to move to the next step.

47
2P

Figure 2.22: Approval message

As with the first approval, a new screen prompts us to enter our SAP

password, as shown in Figure 2.23. Click on the continue icon

(not shown here) to finish this step.

Figure 2.23: Second approval digital signature

We are then presented with a message on the bottom left of the

screen indicating that the approval was completed successfully (see
Figure 2.24). The approval process is now compete.

48
2P

Figure 2.24: Approval complete message

The updated status of the payment batch is shown in the Monitor

Payments app (transaction code BNK_MONI). Both batches used in
our example have been completely approved, so they are now listed
on the A tab, as shown in Figure 2.25.

Figure 2.25: Batch and payment monitor after approvals

The diagram in Figure 2.26 shows a summary of the end-to-end

BCM payment process steps for payments with two approvals, and
indicates how the batch is reflected in the Monitor Payments app
(transaction code BNK_MONI).

49
2P

Figure 2.26: Summary of BCM process step and the Monitor Payments app

Advantages of BCM without approvals

If a company does not need or use the payment

approval functionality in BCM, the following benefits
of using BCM still apply:

Payment batching—BCM creates a payment file generated

from multiple payment runs, based on the batching
configuration.
Payment status tracking—BCM reports on the status of
payments.
Centralized payment reporting—if a company uses both the
AP and Treasury payment programs, for example, BCM will
provide centralized reporting across these payments. If
payment files created in non-SAP systems are imported into

50
2P

BCM using the BCM Connector, then BCM provides

centralized reporting across all these payments.
Payment alerts— alerts are sent via email in the case of
rejected payments.

2.2.4 Rejecting payments

The process flow outlined above is one where all payment batches
were approved. Let’s now look at the process flow when payments
are rejected.

From a payment rejection standpoint, users have several options,

depending on the approval level.

At the first approval level, users can:

reject all payments in the batch, or

reject individual payments in the batch.

At the second, and subsequent, approval levels, users can:

return all payments.

In other words, at the first approval, individual payments can be

rejected, or the entire batch can be rejected. At the second approval,
it is not possible to reject individual payments. Either the entire batch
must be approved or returned to the first releaser.

We will now walk through the rejection use case scenarios.

Reject individual payment

In this section, we reject an individual payment and approve two
payments in a batch of three payments, at the first approval level.

51
2P

First, we run the Approve Bank Payments app (transaction code

BNK_APP) and enter the batch number to display the batch that we
want to work on, as shown in Figure 2.27.

Figure 2.27: Approve Bank Payments app—rejecting payment

Next, we select the payment batch by clicking on the checkbox to

the left, as highlighted in Figure 2.28, and then click on that payment
batch to display the payment details.

52
2P

Figure 2.28: Select batch to display batch payment details

The individual payments included in the batch are then listed on the
screen, as shown in Figure 2.29. Click on the E button,

53
2P

Figure 2.29: Display batch payment details

Figure 2.30 shows the screen that then appears, where we are now
able to select a specific action for a specific payment, such as
A ,R ,D , etc.

Figure 2.30: Edit batch payment details

We now click on the relevant checkbox to select the payment that

needs to be rejected and then click on the S R button, as
shown in Figure 2.31.

54
2P

Figure 2.31: Reject one payment in batch

The payment status changes to R , as shown in Figure 2.32.

Figure 2.32: Rejected payment

At this point, we can select the payments that should be approved

and then click on the A button, as shown in Figure 2.33.

55
2P

Figure 2.33: Approve two of three payments

In the next screen, shown in Figure 2.34, we are given the option to
add a note, if desired. Note that SAP summarizes the status of the
payments in the batch, e.g. 2 P are approved and 1
P is rejected. Click on OK to proceed.

56
2P

Figure 2.34: Confirm approval settings

We are then presented with the screen shown in Figure 2.35. To

continue approving the batch, click on the S R
B button to proceed further.

57
2P

Figure 2.35: Continue approving the batch

In the prompt that now appears, we click on the S button, as

shown in Figure 2.36.

Figure 2.36: Final approval step to approve a batch

The batch status is now updated, and the latest status can be seen
in the Monitor Payments app (transaction code BNK_MONI), as
shown in Figure 2.37.

58
2P

Figure 2.37: Latest batch status displayed

Note that the rejected payment has not shown up on the

E tab. Click on the > icon to display the payment level
details (see Figure 2.38).

Figure 2.38: Payment level details

59
2P

Return the entire batch

In this rejection scenario, we have a batch that has already gone
through the first approval and now has I A status in the
Monitor Payments app (BNK_MONI), as shown in Figure 2.39.

Figure 2.39: Batch in “In Approval” status

To fully reject the batch, the following process steps are required:

The second approver rejects the batch, and it is returned to first

approver.
The first approver rejects the batch again, and the BCM status
changes to ‘Automatic Rejection’.

We process the batch using the Approve Bank Payments app

(transaction code BNK_APP). Enter the batch number to display the
batch, as shown in Figure 2.40.

60
2P

Figure 2.40: Display batch in Approve Bank Payments app

We select the checkbox to the left of the batch line, as shown in

Figure 2.41, and click anywhere on the line.

61
2P

Figure 2.41: Select batch in “In Approval’ status

The batch and payment details are then displayed, as shown in

Figure 2.42. Note that we do not have the ability to select individual
payments as was shown in the first approval scenario. We have to
either approve or reject the entire batch, so click on R .

62
2P

Figure 2.42: Return entire batch to first approver

We then receive a prompt on the screen shown in Figure 2.43. Click

on OK to proceed further.

63
2P

Figure 2.43: Confirm return batch message

An informational message is then displayed, as shown in Figure

2.44.

64
2P

Figure 2.44: Informational message

At this stage, the rejection (or approval) process is not yet complete.
We need to press the S R B button to
complete this step. This is shown in Figure 2.45.

Figure 2.45: Submit reviewed batches step

We then see the confirmation message shown in Figure 2.46. To

continue with the updates made, press the S button to
complete the rejection process.

65
2P

Figure 2.46: Confirm reviewed batches final message

Returning the batch changes the batch status from I A to

P B C in the Monitor Payments app (transaction
code BNK_MONI), as shown in Figure 2.47.

Figure 2.47: Return batch in the Monitor Payments app (BNK_MONI)

To fully reject the batch, the first approver has to reject it by selecting
that batch and clicking on R in the Approve Bank Payment
app (transaction code BNK_APP), as displayed in Figure 2.48.

66
2P

Figure 2.48: First approver rejects returned batch

On the screen prompt shown in Figure 2.49, we have the possibility

to enter a note about the rejection reason, and then click the OK
button.

67
2P

Figure 2.49: First approver confirms the rejection of the batch

Next, we click on S R B , as shown in Figure

2.50.

Figure 2.50: First approver submits reviewed batches

68
2P

We then click on the S button to complete the rejection

process, as shown in Figure 2.51.

Figure 2.51: First approver submits the rejection of the batch

The information message shown in Figure 2.52 is displayed. This

means that rejection of the batch is now complete.

Figure 2.52: Message—rejection of the batch is complete

If a payment batch is rejected, the batch moves to the E

tab and is listed with a status of A R in the
Monitor Payments app (transaction code BNK_MONI), as shown in
Figure 2.53.

69
2P

Figure 2.53: Rejected batch with Automatic Rejection status

The diagram in Figure 2.54 shows the process flow step for
rejections and indicates how the batch is reflected in the Monitor
Payments app (transaction code BNK_MONI).

70
2P

Figure 2.54: Summary of BCM rejection process step and the Monitor Payments app

2.2.5 Importing acknowledgements

There are two types of acknowledgement files: file and payment.
Acknowledgements, also known as payment status reports (PSR),
are imported using the program
RBNK_IMPORT_PAYM_STATUS_REPORT.

The program that imports acknowledgement files reads from a file

server directory and is typically scheduled to run on an automated
basis. Upon successfully processing the confirmation file, it is moved
into an archive directory. Any confirmation files that are not
successfully processed are moved into an error directory.

Keep in mind that if you send the bank a pain.001.001.03 payment

file, then you will receive a pain.002.001.03 acknowledgement file. If

71
2P

you send the bank a SWIFT MT101 payment message from SAP,
you will receive a SWIFT ack or nack file.

Acknowledgement file formats

SAP supports only the XML pain.002.001.03 format

for acknowledgement files. If SWIFT MT101
payment files are sent from SAP, the
acknowledgement files need to be converted to
pain.002.001.03 format before being imported into SAP.

SAP delivers a standard XSL transformation

PAIN002_V3_TO_CPON that can be used to import pain.002.001.02
files. This XSL transformation uses the pain.002 file data content
and status codes to distinguish between a level 0 (file level)
pain.002 file and a level 1 (transaction level) pain.002 file.

It is important to note that not all banks provide level 0 and level 1
pain.002 files. Some banks, although very few, have the ability to
provide more than two levels. Implementation teams need to work
with individual banks to understand the available options and how
they would like to utilize the available payment status reports.

Information SAP uses in transaction level acknowledgement

files

The only data in the transaction level

acknowledgement files used by SAP when the
acknowledgement files are imported are: the
message ID, the end-to-end ID, and the status
code.

72
2P

In our examples, we have used a level 0 pain.002 file to indicate that

a payment file has been received by the bank and a level 1 pain.002
file to indicate that a payment file has been accepted by the bank.

A successful file-level acknowledgment import should change the

status of the batch to R , as shown in Figure 2.55.
The payment batch also moves from the A tab to the S
B tab.

Figure 2.55: Batch with Received by Bank status

A successful transaction-level acknowledgment import should

change the status of the batch to A B , as shown in
Figure 2.56. However, the payment batch remains on the S
B tab.

73
2P

Figure 2.56: Batch with Accepted by Bank status

2.2.6 Bank statement integration

The prior day’s bank reports (PDR) are tightly integrated with BCM
via the Bank Statement Monitor app (transaction code FTE_BSM)
and the Monitor Payments app (transaction code BNK_MONI). If set
up correctly, importing the prior day’s report will update the payment
batch status to S R and move it from the S
B tab to the C tab. An example of a batch after the
bank statement has been uploaded is shown in Figure 2.57.

74
2P

Figure 2.57: Payment monitor—Statement Received status

The status history of a batch is displayed in Figure 2.58.

Figure 2.58: Batch status history log

This completes the payment lifecycle and payment processing.

2.2.7 Payment status reporting review

All payment batches can be viewed using the Monitor Payments app
(BNK_MONI). The following tabs are found in the report’s output:

A B

75
2P

N
I A
A
S B
C
E

The A B tab shows all batches regardless of their actual

status. An example of this is shown in Figure 2.59.

Figure 2.59: Payment monitor—All Batches tab

The NEW tab shows all batches that are waiting for the first
approval. These are the batches where payment approval is
required before the payment medium can be created. An example of
this is shown in Figure 2.60.

76
2P

Figure 2.60: Payment monitor—New tab

The I A tab shows batches that required more than one

approval, after their first approval. An example of this is shown in
Figure 2.61.

Figure 2.61: Payment monitor—In Approval tab

77
2P

The A tab lists batches that are fully approved and shows
a status of P M C (payment file created). An
example of this is shown in Figure 2.62.

Figure 2.62: Payment monitor—Approved tab

The S B tab has batches for which acknowledgement

(file and transaction level) has been received and successfully
uploaded into SAP. An example of this is shown in Figure 2.63.

78
2P

Figure 2.63: Payment monitor—Sent to Bank tab

The C tab shows batches that have been confirmed by

the prior day’s bank statement. An example of this is shown in
Figure 2.64.

Figure 2.64: Payment monitor—Completed tab

The E tab shows all other batches; for example,

something may have gone wrong with the batches and they might
need special attention. The batches that have been rejected by the

79
2P

approvers show up here as well. An example of this is shown in

Figure 2.65.

Figure 2.65: Payment monitor—Exceptions tab

Note that if one payment is rejected from a batch that consists of

multiple payments, the rejected payment will not show up in the
E tab.

Although the Monitor Payments app provides the same information

as in the corresponding GUI Batch and payment monitor program
(transaction code BNK_MONI), users can see the detailed batch
status history in transaction code BNK_MONI, which is not possible
via the Monitor Payments Fiori app.

Figure 2.66 shows the batch history in the Monitor Payments app

Figure 2.66: Batch history in the Monitor Payments app (Fiori)

80
2P

Figure 2.67 shows the batch history via the Batch and payment
monitor (transaction code BNK_MONI).

Figure 2.67: Batch history via the Batch and payment monitor

From our experience, the Monitor Payments app provides a better

user experience, while transaction code BNK_MONI provides more
detailed information.

2.3 Bank statement monitor

The bank statement monitor (transaction code FTE_BSM) gives
Treasury and bank reconciliation users a high-level view of the
status of bank statements expected versus bank statements
imported each day. In addition, it provides a reconciliation of the
balance in SAP by account versus the balance at the bank
(delivered in the bank statements). This report can also be used to
notify users of any bank statements missing for the day. The report
provides multiple selection options that can be used to filter
accounts, as per requirements. To appear in this report, the
accounts to be displayed in the bank statement monitor report must
be entered in configuration.

The selection options for the bank statement monitor report is shown
in Figure 2.68. In our example, we have used C C ,
H and S D as input values.

81
2P

Figure 2.68: Bank statement monitor input screen

After executing the report, the output is displayed, as shown in

Figure 2.69.

Figure 2.69: Output of bank statement monitor report

Note that the data in the first line of the report, under P
S , indicates that the bank statement has not been imported for
this bank account; this needs to be investigated to determine the
reason.

The C B. G/L column displays the balance in the cash G/L for
the bank account, and the E B .A column shows the

82
2P

balance determined from the bank statement. D A

shows the difference between the cash general ledger balance and
the actual bank account balance. Ideally, the difference between
cash general ledger balance and actual bank balance should always
be zero. This indicates whether the bank account balance in SAP is
the same as the balance at the bank.

In addition to the balance details, the following statuses can also be

set up to appear in the report output:

P S
D S
S N S
R S

The process status is the processing status of the bank statement

and is similar to the status displayed in the Reprocess Bank
Statement Items app (transaction code FEBAN). There are three
processing statuses:

Red—the bank statement is not imported but should have been

based on interval setting.
Yellow—the bank statement is imported but some of the items
could not be posted.
Green—the bank statement has been posted correctly.

The D S is a tolerance amount calculated as the

difference between the bank statement balance and the general
ledger balance for the bank account. If the bank statement account
balance matches the general ledger account balance within
tolerance, the difference status is green. Otherwise, the status is
red.

83
2P

The S N S indicates if the sequence of the last

five bank statements is complete.

The R S is green if, for this bank statement, all

bank statement items are processed completely. This status is red if
there are reconciliation items still to be processed after posting is
complete.

From the bank statement monitor, users can display the bank
statement by clicking on any of the dropdown options shown in
Figure 2.70.

Figure 2.70: Click to drill down and view bank statement

The bank statement is then displayed, as shown in Figure 2.71.

84
2P

Figure 2.71: Drilldown to bank statement from the bank statement monitor

2.4 Scheduled jobs

This chapter has demonstrated that the end-to-end payment
process, including Bank Communication Management, bank
statement import, and monitoring, involves multiple steps. The good
news is that many of these steps can be scheduled, so users do not
need to perform them manually.

Below are the process steps that we recommend scheduling:

Treasury payment program

Merge payments
Workflow approval email notification delivery
Status update email notification delivery

85
2P

Payment file delivery to bank (renaming the file and pushing it

to the bank)
Payment acknowledgment import
Timeout alert trigger program
Bank statement import

The end-to-end process flow must be evaluated to ensure the

proper segregation of duties is followed.

2.5 BAM versus BCM payment approvals

The payment signatories defined in Bank Account Management
(BAM) can be used for payment approval instead of using the BCM
settings. One key difference between these two methodologies is
the way in which the approvers are defined. In the case of BAM, it is
a business user master data setting. In the case of BCM, it is an IT
task. The BAM payment approval settings can be used for basic
payment release strategies.

See Section 5.1 for information on how to control whether payment

approval messages are triggered by BAM or BCM settings.

Note that if the BAM payment approval process is used, it is still

possible to use the BCM Monitor Payments app (transaction code
BNK_MONI) for payment and its status reporting.

2.6 Summary
In this chapter, we walked through the entire BCM process, from
batching payments, which is the starting point for Bank
Communication Management, to batch status update via the bank
statement, which completes the payment life cycle. We also
explained how the bank statement monitor tool can be used to
streamline the reconciliation process and ensure efficiency. Readers

86
2P

should now have a complete understanding of how the BCM

process works for payments and bank statement monitoring, and
how to use the monitoring tools in BCM to their advantage.

87
3 BCM

3 BCM configuration
In this chapter, we cover the configuration required for Bank
Communication Management. Readers should be happy to
know that the configuration of BCM is relatively
straightforward. The use case scenario discussed in Chapter 2
is used in this chapter as well.

Before starting BCM configuration, users need to ensure that the

payment program configuration is already in place. It is also
important to understand a few aspects of the payment program
configuration that are relevant to BCM, which are covered in this
chapter.

3.1 Activating the Enterprise Business Function for BCM

As mentioned in Section 1.5, before getting started with BCM, the
Enterprise Business Function for the BCM (FIN_FSCM_BNK)
module must be activated. This is done through transaction code
SFW5. This activation, shown in Figure 3.1, is not reversible.

Figure 3.1: Activate the Enterprise Business Function for the BCM module

3.2 BCM specific configuration

In this section, we outline the BCM configuration, which is shown in
Figure 3.2. The configuration falls under five groupings, each of

88
3 BCM

which are covered here. There is a further configuration node that

may be relevant to some BCM implementations which are
associated with processing payment files from external systems—
the BCM Connector configuration node, which is covered in Section
4.3.

Figure 3.2: BCM configuration

3.2.1 Basic Settings node

Under the B S node, is the B S
A configuration, where users specify the default currency
for the total batch amount, the resubmission days from the current
date, and whether a digital signature is required with payment
approval when using the SAP GUI.

To complete this step, follow menu path: F S C

M • B C M • B
S • B S A . Click the N
E button and then populate the fields, as shown Figure 3.3.

89
3 BCM

Figure 3.3: Basic Settings configuration

In the R C field, the default currency specifies the

currency in which the total batch amount is displayed for approvals.
Setting this to USD means that for all batch approvals, the total
amount of the batch is displayed in USD, regardless of the currency
of the individual payments.

The value entered in the E field (M in our

example) is the exchange rate type used to convert payments into
the R C entered; in our example, into USD.

In the D R field, enter the default number of days

to be used when batches are resubmitted. During the approval
process, if a payment or batch is resubmitted, the system adds the
number of days entered in this field to the current date to compute
the proposed resubmission date. In our example, the D
R is set to 1, so the default resubmission date is the
next day.

The BCM module has the ability to put digital signatures on

payments. If you select the S checkbox, a
signature box appears during the batch approval process when
using the SAP GUI. Transaction code BNK_LG_SGN (Digital
Signature Logs) can be used to view this digital signature
information at a later point.

Digital signature in Fiori

90
3 BCM

As mentioned earlier, when looking at the payment

approval process (Section 2.2.3), digital signatures
are available in the SAP GUI but not in the Fiori
Approve Bank Payments app.

3.2.2 Payment Grouping node

Under the P G configuration node, we define how
payments are to be batched. The rules defined here are applied to
group payments that result in a batch (or batches). Keep in mind
that if you have approvals, the approvals will be by batch. In
addition, the files are sent to the bank by batch, and the
acknowledgements from the bank are at the batch level as well. It is
therefore important to understand how the payment batching should
be done.

Based on our use case scenario presented in Chapter 2, the

batching criteria are as follows:

Company code
House bank ID
Account ID
Payment method
Amount

Rule Maintenance node

This configuration defines the rules for batching payments. A rule ID
is defined for each unique combination of batching criteria. Within
the definition of the rule ID, the attributes of the rule ID are specified.
Based on our use case scenario the attributes we are using for

91
3 BCM

batching criteria in the rule ID are: C , H

ID, A ID, P , and A .

For our use case scenario, we have created the rule IDs shown in
Table 3.1.

Rule ID Rule description

VPAYLT10K Vendor payments less than 10K
VPGTB10KM Vendor payments greater than/equal to 10K and less than 10M
VPAYGTE10M Vendor payments greater than or equal to 10M
Table 3.1: Rule IDs

For example, if you require approvals for all payments over a million
dollars, you define a rule ID for all payments greater than that
amount and another rule ID for all payments less than a million
dollars. In addition, these batches need to be separated by bank
because, as mentioned previously, batching is how the payments
are grouped when they are sent to the bank; and you do not want to
send JPM Chase payments to Citibank. To make a rule ID by bank,
the house bank ID is included as an attribute of the rule ID. It is not
necessary to create separate rule IDs for each house bank;
however, we recommend creating a separate batching rule by
payment method.

In our use case scenario, the payment approvals are based on

payment amounts, but this may not the case for every company. For
example, if you do not want any approvals in BCM, but instead want
the payments to flow through BCM, then the batching rules do not
need the amount attribute. SAP has provided numerous attributes,
which should be sufficient to meet your batching and approval
needs.

One further aspect to consider is that a rule ID can be given a

priority. Priorities are given to rules where a payment falls into more
than one rule. In this case, the payment is included in the rule with

92
3 BCM

the highest priority (the highest priority has the lowest number, so
priority 0 is higher than priority 1).

Priority of batching rules

Ideally, there should be a clear distinction among

the batching rules so there is no overlap. This is a
cleaner design.

To complete this step, follow menu path: F S C

M • B C M • P
G •R M .

When carrying out this configuration, first define the rules and then
press the S button (see Figure 3.4). The S button appears on
the lower right of the screen (not shown here).

Figure 3.4: Define batching rule

Next, press the button under R . (rule maintenance), as

shown in Figure 3.5, to enter the actual criteria for the batching rule.

Figure 3.5: Rule maintenance button

93
3 BCM

Press the N E button (not shown here) and enter the

validity period of the rule. Specify the details of the rule by double
clicking on the fields in the left panel and then populate the fields
accordingly, as shown in Figure 3.6.

Figure 3.6: Specify details of payment batching rule

Business Add-In (BAdI) for additional grouping criteria

If the available fields are not sufficient to meet the

requirements, the BNK_BADI_BATCH_GROUPING
BAdI is available for customer-specific grouping.

Figure 3.7 shows the definition of the batching rule for payments
between an amount of USD $10,000 and USD $9,999,999.99. Any
payment with parameters meeting the attributes of the rules will be
included in the batch.

94
3 BCM

Figure 3.7: Definition of rule VPGTB10KM

As a comparison, Figure 3.8 shows the definition of the batching rule

for payments over an equivalent of USD $10,000.

Figure 3.8: Definition of rule VPAYLT10K

Note that, when making the configuration entries, there are many
different fields which can be used in the batching rules. For example,
batching rules can incorporate the O of the payment. The
O of the payment is used by SAP to indicate the submodule
where the payment originated, which indicates the type of payment:

Accounts Payable (FI-AP)

Accounts Receivable (FI-AR)
Bank Accounting (for a freeform payment) (FI-BL)
Treasury Management (TR-TM)
Bank-to-bank transfers (TR-CM-BT)
In-House Cash payment (TR-IHC)

This configuration is very flexible and robust and should cover all
customer requirements relating to batching.

Additional Criteria for Payment Grouping node

95
3 BCM

Additional criteria for grouping payments can be specified in the

A C P G configuration node.

Typically, this configuration is used for house bank and house bank
account ID, assuming the house bank and house bank account ID
were not included in the Rule Maintenance node and a separate file
by house bank account is needed.

Another example of the use of this configuration is when companies

send SWIFT messages and want to have the payment files created
per payment; the payment document number can be added as a
batching criterion. Doing this creates an individual file per payment.
In this case, the company is taking advantage of the BCM approvals
and payment reporting and is batching by individual payment.

Figure 3.9 shows the configuration screen for this step. Here,
additional criteria for payment grouping is specified; for example, by
using the value date field (VALUT) as the additional batching
criteria, which facilitates separation of payment files by value date.
For our use case scenario, we have used house bank and account
ID as the additional criteria.

To complete this step, follow menu path: F S C

M • B C M • P
G •A C G .

Figure 3.9: Additional grouping criteria

Payment Medium: Create/Assign Selection Variants node

96
3 BCM

When you use the Payment Medium Workbench (PMW), the

SAPFPAYM_SCHEDULE program is used to create all payment
media. The AP and Treasury payment programs trigger the
SAPFPAYM_SCHEDULE program to run in the create payment
medium step, which creates the payment media (payment file). This
program can be accessed using transaction code FBPM.

When defining P configuration

(transaction code FZBP), there are two ways to define a payment
method’s payment medium:

Use the Payment Medium Workbench

Use classic payment medium programs (RFFO*)

SAP Bank Communication Management is intended to be used with

PMW payment methods only. In order for payments to be routed to
BCM, they must be PMW payment methods with a Data Medium
Exchange (DME) tree assigned. The DME tree defines the format of
the payment file. In our example, we have used the SAP standard
DME tree US_CGI_XML_CT and have assigned it to payment
method A, as shown in Figure 3.10.

97
3 BCM

Figure 3.10: Payment medium workbench payment methods

After the configuration of the payment method is complete, the

variant using the DME tree can be created using transaction code
FBPM, as shown in Figure 3.11.

Figure 3.11: Defining the PMW payment method variant

In addition to the payment medium format, the variant contains

information relating to the file name, and the location where the file
is to be created.

After the payment medium variant has been created, the last step is
to assign the payment medium variant to the given combination of

98
3 BCM

company code, house bank, and payment method, as shown in

Figure 3.12. The figure shows the configuration node to
create/assign the selection variants (transaction code OBPM4).

Figure 3.12: Assign payment medium format variants

To assign the variant, follow menu path: F S C

M • B C M • P
G • P M : C /A S
V (OBPM4). The variant assignment can be put into a
transport or this step can be done as a cutover step in each SAP
client.

Creating variant and assigning payment medium format

Creating payment medium variants is a cutover step

that needs to be performed when moving to a new
SAP environment. Configuring the payment method
and assigning the payment medium format to the
payment method are configuration steps, while creating a
payment medium variant and assigning the variant to the
company code, house bank, and payment method are cutover
activities.

99
3 BCM

3.2.3 Release Strategy node

Revisiting our use case scenario, Table 3.2 shows the batching rule
and approval requirements.

Rule ID Rule description Approvals

VPAYLT10K Vendor payments less than 10K Automatic
VPGTB10KM Vendor payments greater than/equal to 10K and less than One
10M approval
VPAYGTE10M Vendor payments greater than or equal to 10M Two
approvals
Table 3.2: Rule ID approval requirements

To summarize, payments that fall under rule ID VPAYLT10K do not

require approval (i.e. approval is automatic). Payments that fall
under rule ID VPGTB10KM require one approval, and payments that
fall under rule ID VPAYGTE10M require two approvals.

The workflow approval settings are made under the R

S configuration node (see Figure 3.13) using the batching
rule ID which determines the approvals required and the responsible
approvers.

100
3 BCM

Figure 3.13: Release Strategy configuration node

If there is a requirement for a digital signature while approving

payments, that is also specified under the R S
configuration node.

Once the payments are batched, the approval mechanism specified

for the R ID determines whether approval is required for the
batch. If approvals are required for the batch, the payment file is not
created until the required approvals are complete.

Mark Rules for Automatic Payments (No Approval) node

Payments where no approvals are required are referred to as
automatic payments, meaning the payment file is created once the
batching step is complete. To complete this step, follow menu path:
F S C M •B C

101
3 BCM

M • R S • M R
A P (N A ).

In this configuration step, the following settings are made for each
rule ID:

1. A —selecting this checkbox marks the batching rule ID for

automatic payment.

2. D D —selecting this checkbox means that users

approving payments must drill down from the batch level to see
all the payments included in the batch before they can approve
the batch.

Figure 3.14 shows that for batching rule ID VPAYLT10K, the A

indicator selected. Because the other two rule IDs require approval,
the A indicator should not be selected.

Figure 3.14: Mark rule IDs for automatic payment and drilldown

When approving a batch with the D D checkbox selected, if

the user tries to approve a batch without drilling down to view the
payments in the batch first, a message appears indicating that they
must first view the payment details before they will be allowed to
approve the batch (see Figure 3.15).

102
3 BCM

Figure 3.15 : Message indicating batch has not been reviewed

Drilldown indicator

For batches that require approval, we recommend

selecting the drilldown indicator to ensure that users
are unable to approve a batch without reviewing the
payments included in it.

Assign Role to Release Steps node

As mentioned in Section 2.2.3, the Verifier (first releaser) has the
ability to change batches by approving or rejecting individual
payments, which is not the case for the approvers.

The two types of workflow approvers, and their corresponding

release objects, are as follows:

Verifier—can approve or reject individual payments (BNK_INI)

Approver—can only approve or reject entire batches
(BNK_COM)

103
3 BCM

This configuration assigns users for the workflow approval process.

To complete this step, follow menu path: F S C
M • B C M • R
S • C R • A R R
S .

Looking at the configuration nodes under R S , there

are two A R R S configuration nodes (see
Figure 3.16). The first is for the Verifier release object (BNK_INI) and
the second is for the Approver release object (BNK_COM).

Figure 3.16: Configuration under Release Strategy

In the first A R R S configuration node, a

rule for the release object BNK_INI is created and assigned, as
shown in Figure 3.17.

104
3 BCM

Figure 3.17: Create workflow rule for BNK_INI

Initially the R field does not have any value populated, as shown
in Figure 3.17. By pressing the C R button, a screen
appears where the workflow rule parameters can be selected (see
Figure 3.18). For our use case scenario, the rule ID is the only
parameter required.

105
3 BCM

Figure 3.18: Selection of rule parameters

After the rule ID parameters are specified and the rule is created,
the next screen appears, as shown in Figure 3.19.

Figure 3.19: Assign Role to Release Steps with rule generated

Once we have created the rule and assigned it to the release object,
the next step is to assign approvers to the rule.

To do this, select the checkbox to the left of the entry and click the
D R button, as shown in Figure 3.20. From here, users

106
3 BCM

are assigned to the workflow rule.

Figure 3.20: Display Rule to assign approvers

Workflow agents and rule

SAP uses the term agent to mean recipients of the

workflow messages. In our case, the agents are the
BCM workflow approvers. The rule being referred to
here is a workflow rule, which is a term used to
define or determine the agents, or recipients of the workflow
approval messages.

After selecting the indicator to the left of the release object and
pressing the D R button, a screen appears, similar to the
one shown in Figure 3.21, which should look familiar to readers who
have worked with SAP workflow. This is the standard workflow agent
assignment screen used for all SAP standard workflows.

107
3 BCM

Figure 3.21: Initial workflow settings screen

To complete this step, the following two actions are performed:

Specify the parameters to determine the workflow object that

needs to be set.
Assign the approvers who can approve the workflow object.

Click on the C icon (the first icon on

the left), and a popup message appears, as shown in Figure 3.22.
Depending on the implementation, the name of the workflow object
can be changed. These settings are not visible to business users.

Figure 3.22: Create responsibility popup window

108
3 BCM

Next, click C to move forward. The parameters relevant to

the workflow are displayed on the screen. For our use case
scenario, the batching rule ID determines the approvers allowed.
Therefore, only the rule ID is needed to determine the workflow
approvers, as shown in Figure 3.23.

Figure 3.23: Specify workflow parameters

Users can now be assigned as approvers using the standard

workflow settings. The process of assigning users to the different
release objects is exactly the same as for all standard workflow
objects in SAP. Start by pressing the insert agent assignment icon
, as shown in Figure 3.24.

109
3 BCM

Figure 3.24 : Assign agents (payment approvers)

Users can be assigned by work center, job, or position, as shown in

Figure 3.25. In our example, we want to assign users by user ID, so
we select U on this screen.

Figure 3.25: Agent assignment

Next, enter the user ID for the approver, as shown in Figure 3.26.

110
3 BCM

Figure 3.26: Specify user

As with all SAP standard workflows, assignment to the role is date

dependent, so the time period is adjusted for the approver, as shown
in Figure 3.27. Next, press the C button at the bottom of the
popup window.

Figure 3.27: Date range for approver

In this step, any number of users can be assigned as a Verifier.

Figure 3.28 shows the screen after users have been added. The
workflow configuration must be specifically put into a transport by
clicking the transport icon .

111
3 BCM

Figure 3.28: Review of workflow agent assignment

Although the workflow settings can be put into a transport, because

the user assignments are different based on the type of system (e.g.
development versus production), the workflow agent assignments
are typically done as a cutover task in each system.

At this point, we have completed the workflow settings for the first
approval (i.e. the Verifier) for both of our batching rules that require
approvals. The next step is to complete the workflow settings for the
second approval (i.e. the Approver), which is required for the
batching rule ID for payments of $10,000,000 or more.

Define Release Procedure node

This step is not required for the first approval release object
BNK_INI, but it is required for the second approval release object
BNK_COM. In the D step, we specify
whether a workflow release is always required or only conditionally
required. The release object in this configuration step is always
BNK_COM (Approver), who can only approve or reject entire
batches. Figure 3.29 shows the location of this configuration under
B C M .

112
3 BCM

Figure 3.29: Additional Release Steps configuration nodes

To complete this step, follow menu path: IMG • F S

C M • B C M •
R S • A R S • D
R P . This leads to the A R
P R O screen, as shown in Figure 3.30.

113
3 BCM

Figure 3.30: Assign release procedure to release object—BNK_COM

Select the C radio button, where second-level approval

is required for certain conditions. In our use case scenario, the
second approval step is conditional based on the payment amount.
In other words, if the batch is composed of payments of $10,000,000
or more, only then is a second approval required.

The only time the N radio button should be selected is when

there is no second-level approval in the design. Selecting the N
radio button sets the value in the R R S field to
00. When changing the radio button back from N to A , it
is important to make sure that the R R S field
contains a value other than 00. Click the S button in the lower
right of the screen to save the values.

The Never radio button

Note that if the N radio button is selected, all

entries for the conditional release workflow are
deleted. Therefore, be careful when working with
this IMG node after you have entered the
conditional release workflow configuration.

114
3 BCM

Assign Roles to Release Steps node

In this step, agents are assigned for the Approver step(s); i.e., the
BNK_COM release object. This step is like the Change and Release
step in the BCM configuration, which was set up for the BNK_INI
release object. In this step, a standard role is assigned to the
release step, that applies to the Approver release object
(BNK_COM). This configuration is relevant to all subsequent
approvals after the first approval.

Figure 3.31 shows the location of this configuration under B

C M , which can be found by following
menu path: F S C M • B
C M • R S •
A R S •A R R S .

115
3 BCM

Figure 3.31: Assign Role to Release Steps configuration node

The R R S (steps) setting determines how many

approvals are required for the associated batch. Where this is set to
01, one approver is required at the BNK_COM level. A setting of 02
will require two approvers at the BNK_COM level.

The first entry in Figure 3.32 is relevant to the first approval step. In
our use case scenario, only batches with payments of $10,000,000
or more require this release step.

For illustration purposes, the screenshot shows a second entry that

would apply to a second Approver step, but which does not apply to
our use case scenario. Note that this second Approver step would
only be necessary if there was a requirement for three different
approval steps in a payment process.

Figure 3.32: Approver release steps

As we did with the BNK_INI release object, select the checkbox to

the left of the R O (see Figure 3.32) and press the
D R button to get to the agent assignment screen (see

116
3 BCM

Figure 3.33). Because the steps are the same, we have not shown
the subsequent screenshots again here.

Figure 3.33: Agent assignment for BNK_COM release object

Different user groups can be assigned to approve different release

procedures. For example, the approvers in the first approval step
can be one group of users, and the approvers in the second
approval step can be a completely different set of users. SAP does
not put any restriction on the users assigned as agents to the
different approval steps.

Keep in mind that the person performing the first approval is not able
to do the second approval, even if they are assigned as an approver
to both objects. This feature is a built-in dual control principle.

Activating digital signatures

Digital signatures are an optional security feature that SAP has
provided to prevent potential fraud or unauthorized approvals. This
feature also has the functionality to incorporate third-party
authentication software. Without this software, SAP can still provide
two-factor authentication using an SAP user ID password or a code
from the SAP Authentication app (see Figure 3.34).

117
3 BCM

Figure 3.34: SAP Authenticator app

As an example, with the SAP user ID password feature, even if an

approver leaves their laptop unlocked, it is not possible for a
different person to approve the payment. This is because there is a
requirement to reenter the password at the time the payment is
approved.

To use this functionality, we must ensure that when configuring the

B S for approval, the S indicator is
set (see Figure 3.3).

Figure 3.35: Digital Signatures configuration

118
3 BCM

Under the D B configuration node (see Figure

3.35), users are taken to the user master record definition
(transaction code SU01). For all BCM approvers, the full name of
the user and his/her time zone must be specified. If there is not a full
name in User Maintenance (transaction code SU01), the user will
get an error message—SIG237: E
—when approving a payment.
When a signature is entered, the system copies the signatory name
and the local time for that person according to the signatory’s time
zone into the signed payment document.

The next step is to specify further settings relating to digital

signatures in the S S M A
U S S node, as shown in Figure 3.36.

Figure 3.36: Configuration settings for digital signatures

This completes the setup required for digital signatures using the
SAP user ID and password.

3.2.4 Payment Status Management node

XML payment acknowledgements (pain.002.001.03) are imported
into SAP to update the status of the batches. The batch status
update is supported by the configuration settings shown in Figure
3.37.

119
3 BCM

Figure 3.37: Payment Status Management configuration node

In M E S I S configuration, (see
Figure 3.38), external status codes are mapped to an SAP internal
status code by following menu path: F S C
M • B C M • P
S M • M E S I
S .

Figure 3.38: Map external status to internal status

The external status codes are the codes in the acknowledgment files
sent from the banks. All the external status codes need to be
mapped to internal status codes. In Figure 3.38, the external status

120
3 BCM

codes are shown on the left, and the SAP internal status codes are
displayed on the right. In our example, we have mapped the bank
status code PAIN_RCVD to internal status code BRB (R
B ).

PAIN_ABCD status code

Status code PAIN_ABCD must be configured, and

needs to be assigned to internal code BSP (Batch
Partially Processed). If this is not done, error
messages will appear when importing the payment
acknowledgement files.

Because there is a status by payment and by batch, when the

multiple transactions in the batch are sent from the bank one by one,
the batch status is P B until all the items
in the batch are received, at which time the batch status is changed
to A B .

In this configuration, it is also possible to assign an alert to a status

code, as shown in Figure 3.39. This triggers an email notification
when the batch status changes to that status code.

Figure 3.39: Assignment of alert to status codes

For example, if the bank rejects a payment, an alert message is

triggered with information about the rejected payment. Payment
alerts are discussed further in Chapter 4.

121
3 BCM

Payment status messages

There are a number of different terms that are used

when referring to payment acknowledgement
messages: payment status messages, payment
status reports (PSR) or payment
acknowledgements. These terms all mean the same thing. With
ISO 20022 pain.001 payment files, the acknowledgement
messages are referred to as pain.002 files.

Payment status sequence

As we have seen, SAP tracks the different payment statuses
through the payment life cycle. Viewing and/or controlling how SAP
moves from one status to the next can be important in certain
situations. For example, the order in which the acknowledgement
files are imported might not always be the order in which the
acknowledgement files are received from the banks. This could be
the case for various reasons; for example, the way that the
acknowledgement files are queued up to be imported into SAP.
Regardless of how the acknowledgement files are processed in
SAP, there are certain sequences that should never take place; for
example, A should not occur before R
.

The different statuses in SAP are displayed using transaction code

BS23 (Display System Status). This is shown in Figure 3.40, on the
S S : D screen. The payment-related status
codes are the S S codes that start with IBC*.

122
3 BCM

Figure 3.40: BCM status codes

By double clicking on a status code, the statuses that are

subsequently allowed and forbidden are then displayed. This is
shown in Figure 3.41 for the R status. In this
example, going from R to A is
an allowable sequence, but going from R to S
or P is forbidden.

123
3 BCM

Figure 3.41: Sequencing of status changes

Below is an approximate sequence of the statuses that should take

place over the payment life cycle, assuming the payment is
approved and accepted at the bank:

P
P B C
I A
P M C
S B

124
3 BCM

R B
A B
S

Timeout for Batch Status Update node

In this configuration, we can set up optional alerts that are triggered
when a specified amount of time has elapsed between particular
statuses. The configuration can be specified by batching rule ID, or,
if the R ID field is left blank, the configuration applies to all batch
rule IDs. This alert allows for proactive payment monitoring.

This configuration is entered by following menu path: F

S C M • B C
M • P S M • T
B S U . The duration can be specified in minutes,
hours, days, or weeks, as shown in Figure 3.42.

Figure 3.42: Timeouts between two statuses

For more information on triggering BCM alerts, see Section 4.1.

3.2.5 Bank Statement Monitor configuration

In this step, the house bank accounts that you want to view in the
Bank Statement Monitor (transaction code FTE_BSM) are specified
(see Figure 3.43). To specify the house bank account, enter the
company code, house bank ID, and account ID. For each account,

125
3 BCM

indicate the type of monitoring desired by selecting the relevant

checkboxes: P S (processing status), D
S (difference status), S N . S (serial number status), and
R . S (reconciliation status). In addition, and most
importantly, indicate how frequently the bank statements are to be
imported into SAP.

To complete this configuration step, follow menu path: F

S C M • B C
M •B S M •S B
S M .

Figure 3.43: Bank Statement Monitor configuration

As mentioned previously, the Bank Statement Monitor report

provides information about the bank statements received versus the
bank statements expected, as well as other important information;
for example, any difference in the bank account balance between
SAP and at the bank.

3.3 Additional configuration

In this section, we outline the required configuration that does not
fall specifically under the BCM configuration node.

As stated earlier, the payment method must be defined as a

Payment Medium Workbench (PMW) payment method to be routed
through BCM. This is a requirement of the BCM module.

The configuration node to create payment medium formats through

the PMW is under the following menu path: F A

126
3 BCM

(N ) • A R A P •
B T • O P • A
O P • P M • M S
P M F P M W .
Under this node, the configuration steps to create and configure
PMW formats can be found. These configuration nodes are shown
in Figure 3.44.

Figure 3.44: PMW format—configuration nodes

Using the above configuration nodes, users are able to create the
PMW payment medium format and the associated variant which will
be assigned to the payment method and bank account respectively.

3.3.1 Reservation for Cross-Payment Run Payment Media

node
This configuration determines which payment runs are routed
through BCM. SAP uses the payment I field, within
the A P T program (transaction code
F110), for this determination, as shown in Figure 3.45.

127
3 BCM

Figure 3.45: Payment run identification field

If a company is using both PMW and classic payment medium

program (RFFO*) payment methods, this configuration step will be
tricky. Users need to ensure that for payment runs which include
IDoc payment methods, the run identification is not included in this
configuration step. There should be a clear distinction between the
run IDs used for PMW and those for IDoc payment method payment
runs. This is achieved through process control or custom coding.

To complete this step, follow menu path: F A

(N ) • A R A P •
B T • O P • A
O P • P M • D I
C -P R P M (transaction code
OBPM5).

In this configuration, specify the AP/AR (transaction code F110),

Treasury (transaction code F111), and HR payment runs that need

128
3 BCM

to be routed through BCM for batching of payments and approvals.

In the initial screen, there are four buttons, as shown in Figure 3.46.
These are for:

AP payment runs,
Treasury payment runs,
HR payment runs, and
bill of exchange payment runs.

Figure 3.46: Route payments through BCM

Click on the FI AP/AR P

button to specify how payments generated by the
Automatic Payment Transactions program (transaction code F110)
should be routed through BCM. The R I field is set
based on the button clicked (see Figure 3.47). Do not change it.
Enter payment-run identifiers in the fields in the I column,
and select the BRM (BCM) checkbox. Click the S icon (not
shown here).

The most secure approach is to enter an asterisk * in this

configuration for all types of payment runs (AP, Treasury and HR),
as shown in the screenshot. Doing this routes all payment runs

129
3 BCM

through BCM. This is more secure because all payments follow the
same path through SAP. In addition, when an asterisk is entered in
this configuration setting, there is no risk of a payment file being
created that does not have the required approvals.

Figure 3.47: Route all AP payments through BCM

It is possible to set the configuration so that payment runs can be

excluded from going through BCM. As an example, if you only want
payment identification runs that start with numbers to go to BCM,
then set the configuration as shown in Figure 3.48. In this example,
all payment runs where the I field does not start with
a number will not be routed through BCM. (Note that we do not
recommend this approach; it is given only as an example of an
alternative approach.)

Figure 3.48: Route only certain payment runs through BCM

130
3 BCM

Next, to create the setting for the Automatic Payment Transactions

for the Payment Request program (transaction code F111), press
the FI-BL P button.
Figure 3.49 shows the setting to route all Treasury payment program
payments through BCM.

Figure 3.49: Route all Treasury payments through BCM

The same principle of entering an asterisk, as outlined above,

applies to this configuration as well. Enter payment run identifiers in
the field under the I column and select the BRM (BCM)
indicator. Click the S button when done.

BRM column header

The column header BRM should be BCM. This is a

translation issue. When viewing this configuration
node when logged into SAP in German, the column
header is BCM.

The process for the remaining two buttons—for HR and bill of

exchange payments—is the same, so we will not repeat the steps
again here.

3.3.2 Creating file paths and file directories

131
3 BCM

The RBNK_IMPORT_PAYM_STATUS_REPORT program

(transaction code S_EBJ_98000208) is used to import payment
acknowledgement files and requires the directories from which files
are imported to be defined as logical file paths, as shown in Figure
3.50.

Figure 3.50: Program to import payment acknowledgement files

Using the Logical File Path Definition program (transaction code

FILE), the following logical file paths must be defined and mapped to
physical directories:

Import files
Archive files
Error files

132
3 BCM

When assigning the physical path to the logical file path, a

parameter for the system can be incorporated into the physical path,
as shown in Figure 3.51. The SYS parameter is substituted with the
actual system. This then allows the logical file path definitions to be
moved between systems in a transport.

Figure 3.51: Assignment of physical path to logical path

3.3.3 Cutover activities

In this section, we list the steps that must be performed in each SAP
client; for example, the steps that must be carried out when moving
from development to the Quality Assurance (QA) system, and when
moving from the QA system to production:

1. Creation of PMW variants (transaction code FBPM)

2. Assignment of PMW variants to bank accounts (transaction code

OBPM4)

3. Assign approvers in the workflow agent settings

4. User master record update for digital signatures, if required

5. Validate physical and logical paths used (transaction codes FILE

and AL11)

3.4 Summary

133
3 BCM

In this chapter, we walked through the steps to configure the BCM

module. We also covered the non-BCM configuration that is required
when implementing the BCM module. We discussed the
configuration that routes payments to BCM, how to create batching
rules, and how to carry out the payment approval using SAP
workflow settings.

In addition, we reviewed the setup required to import and process

acknowledgments, and we discussed the process changes that
might be required when implementing BCM. Readers should now be
able to do the required configuration to get BCM up and running for
their organization and fully utilize BCM’s capabilities.

134
4A

4 Advanced topics
In Chapter 3, we covered the configuration required for the
Bank Communication Management module. In this chapter, we
discuss some additional setups that, although not necessary
for BCM to work, can be useful in making payment processing
more efficient and reliable. The topics covered in this chapter
are somewhat more technical in nature.

4.1 Triggering alerts

SAP payments are critical to standard business operations, so
timing and monitoring of these payments are vital in order to notify
key users of issues that may arise. With the use of alerts, email
notifications are sent to key users when there are issues relating to
payment processing.

Some examples of alerts that can be implemented are when:

a payment is rejected by the bank, or

a file level acknowledgement is not received after a specific
amount of time after sending the payment file to the bank.

With SAP standard functionality in BCM, there are three possible

alerts available, which are triggered at specific events. These alerts
are outlined in Table 4.1. If companies want to enhance the
functionality, they can copy the SAP-delivered content and modify
the created program.

Alert Description
File This alert is triggered if the payment file creation fails.
creation

135
4A

error
alert
Timeout This alert is triggered if, for a payment file, a specified amount of time has
alert elapsed between two steps in the communication process with the bank. When
this alert is triggered, users need to find out if the bank did not receive the
payment file or if the bank failed to acknowledge it.
Payment This alert is triggered if, in communication with the bank (after the file was
status created and submitted through the external payment network), a failed status
alert message appears indicating a rejected payment.
Table 4.1: BCM Alerts

It is important to understand the extent of the functionality available

in the delivered content. Companies can then decide if they want to
use that delivered content or copy it and enhance it.

Table 4.2 shows the steps of an end-to-end SAP Bank

Communication Management process flow for a scenario in which
no approvals are necessary. The alerts are noted to show where
along the process flow they are triggered.

136
4A

137
4A

Table 4.2: BCM Alerts in the process flow

The following steps are required when implementing BCM alerts:

1. Create the alert.

2. Verify the corresponding BAdI is active.

3. Enter the configuration to trigger the alert.

4. Test the alert.

Let’s now walk through each of these steps.

4.1.1 Creating alerts

Before the alerts can be fully configured, they must first be defined.
The three BCM alerts are all defined in a similar way. The definition
of each of the alerts includes the short and long messages to be
sent, and also identifies the key users who should receive the alerts.

138
4A

In the Editing Alert Categories program, alerts must be defined with

the appropriate alert category corresponding to the BAdI being used.
This is because the alert category acts as a filter value for the BAdI
to perform the respective alert logic assigned to it. Table 4.3 shows
the corresponding alert information that should be used in the
definition of the alert for each SAP Bank Communication
Management BAdI.

Alert Alert Category Container

File creation error alert PAYALRT BNK_STR_PAY_STAT
Timeout alert TIMEOUT BNK_STR_TIMEOUT_ALERT_CONT
Rejected payment status alert PAYALRT BNK_STR_PAY_STAT
Table 4.3: BCM alerts and container values

The BCM alerts are defined using the Editing Alert Categories
program (transaction code ALRTCATDEF), which can also be found
by following the application-side menu path: A •
F S C M •B C
M • E • C S • D
A . To create a new alert using the Editing Alert Categories
program, first press the D /C button, then press the
create icon , as shown in Figure 4.1.

Figure 4.1: Create alert

139
4A

A new row appears, where users enter the A C and a

description of the alert (see Figure 4.2).

Figure 4.2: Create new alert

When using the standard alerts delivered in SAP, the alert

categories must be the ones specified in Table 4.3.

Alert Category PAYALRT

The file creation error alert and the timeout alert

both use category PAYALRT with container
BNK_STR_PAY_STAT. The file creation error alert
has an empty external status (structure field
STSCD) and the internal status (SYS_STAT) is hard-coded
‘BFE’. For the timeout alert, both fields are populated according
to the entries in Map External Reason Codes to Internal Reason
Codes configuration.

140
4A

On the P tab (see Figure 4.3) enter the information

relating to the alert—D , P , etc. The
A P (package) should be set to FIN_BNK_COM for all
BCM alerts.

Figure 4.3: Specify properties for alert

On the C tab, specify the data structure that contains

information relating to the specific alert. This data structure drives
the default information that is used in the alert triggered; for
example, the amount of the batch or payment, the batch number, the
paying company code, etc. Figure 4.4 shows the container assigned
to the timeout alert. Refer to Table 4.3 to identify which structure
(container) should be used for each alert.

141
4A

Figure 4.4: Container assigned to the timeout alert

On the L S T tab, enter the alert subject and the

text for the short and long messages that are to be sent when the
alert is triggered.

Note that you can populate any of the fields in the

BNK_STR_PAY_STAT structure (the container used in the example)
as data to be inserted into the email message. This is shown in the

142
4A

L T (E-M , F ) tab in Figure 4.5. The format to add fields

to the BNK_STR_PAY_STAT structure is &BNK_STR_PAY_STAT.
<field_name>&. As shown in the example, to add the batch number
to the alert message, we used
BNK_STR_PAY_STAT.BATCH_NO . To view the fields available
in the BNK_STR_PAY_STAT structure, use transaction code SE11
and put the structure in the D T field (not shown here).

Figure 4.5: Alert message subject and text

The next step is to define the recipients of the newly-created alert.

This is done by selecting the indicator to the left of the alert and

143
4A

pressing the F R button, as shown in Figure 4.6.

Figure 4.6: Specify email recipients to the alert

In the screen that appears, enter the users who you want to receive
the alert messages, as shown in Figure 4.7.

Figure 4.7: Alert recipients specified

Alternatively, alert recipients can be specified by user roles by

pressing the R U R button, as shown in
Figure 4.6. The alert should be saved when complete.

This concludes the creation of the timeout alert. The steps to create
the rejected payment alert are, for the most part, the same, so they
have not been added here.

144
4A

4.1.2 SAP-delivered BAdIs for the alerts

For each alert, SAP has provided a BAdI. SAP customers may
choose to use the SAP-delivered BAdIs for the alerts or they may
choose to add to them.

It is important to note that for the alerts to be used, the

corresponding BAdI must be active. These are outlined in Table 4.4.

Alert Business Add-in (BAdI)

File creation error alert BNK_BADI_FILE_ERROR_ALRT
Timeout alert BNK_BADI_PAYM_ALRT
Payment status alert BNK_BADI_PAYM_ALRT
Table 4.4: BCM alerts and corresponding BAdI

To validate that the BAdIs are active, use transaction code SE18 or
follow menu path: T • ABAP W • U •
B A -I •D , and enter the BAdI name into the
BA I N field, as shown in Figure 4.8.

Figure 4.8: View defined BAdI

Press the D button to verify that the BAdI has been activated,
as shown in Figure 4.9.

145
4A

Figure 4.9: Verify BAdI is active

Business Add-ins (BAdIs)

A BAdI is an enhancement that provides a

mechanism to change the functionality of a well-
defined business function without making changes
to the SAP-delivered source code. Future upgrades
of the original business function can be applied without losing
customer-specific enhancements.

4.1.3 Triggering the alerts

In this section, we outline how each of the alerts can be triggered.

File creation error alert

With this default implementation, note the following when defining
the alert:

The alert category key must be PAYALRT.

The container name must be BNK_STR_PAY_STAT and it must
be built with DDIC structure BNK_STR_PAY_STAT.

The file creation error alert can be activated by following menu path:
B C M • P S
M • A E P F
C , as shown in Figure 4.10.

146
4A

Figure 4.10: Activate error with payment file creation alert

The batch release is handled in the following function modules,

which calls the SAPFPAYM_MERGE file creation program:

BNK_API_CLOSE_BATCH—for batches without approvals

BNK_API_BATCH_INI_REL_RFC—final release in BNK_INI
process
BNK_API_BATCH_RELEASE—final release in BNK_COM
process

If this program does not receive a success message when the file is
created, the BAdI mentioned above is called and the alert is
triggered.

Timeout alert
Keep in mind that there is a status code associated with each step in
the BCM process. For more on this, see Section 3.2.4 (subsection
“Payment status sequence”). The timeout alert is triggered if a
specified time has elapsed between two steps in the process flow
with the bank, relating to a payment file.

To configure the timeout alert, follow menu path: F S

C M • B C M •
P S M • T B S
U .

147
4A

In this configuration, the maximum time allowed between two status

updates is specified. If this amount of time passes between status
updates, an alert is triggered. The configuration can be specified by
batching rule ID or by leaving the R ID field blank; the
configuration applies to all batch rule IDs, as shown in Figure 4.11.

Figure 4.11: Specify trigger time for timeout alerts

This alert could be used, for example, to notify users if too much
time has passed between a payment file being created and the bank
receiving the payment file. In this case, a timeout alert is set
between the statuses of payment file creation (P
– IBC15) and receipt of the payment file by the bank
(R – IBC06). If the amount of time between these
two statuses exceeds the amount of time entered in this
configuration, a timeout status alert is triggered, and an email is sent
to the specified key users, who then need to check if the bank did
not receive the payment file or if the bank failed to acknowledge it.

Another example of this alert is to notify users of a missing or

delayed payment acknowledgment file. There are numerous other
situations where this alert can be used.

When using the timeout alerts, a periodic job must be scheduled to

call program RBNK_BATCH_TIMEOUT_MONITOR, as shown in
Figure 4.12.

148
4A

Figure 4.12: Inputs to program RBNK_BATCH_TIMEOUT_MONITOR

Every time the program runs, it reads the entries in table

BNK_BTCH_TIMEOUT that do not yet have the RESPONDED flag
set. If the time passed exceeds the time specified in this
configuration, the BAdI method SEND_TIMEOUT_ALERT raises the
alert and an email is sent to the specified key users.

Payment status alert

The payment status alert is triggered from the M E
S I S configuration, which was covered in
Section 3.2.4. In this configuration, it is possible to assign an alert to
a status code, as shown in Figure 4.13.

Figure 4.13: Failed payment alert assignment

As an example, if the bank rejects a payment, an alert message is

triggered with information about the rejected payment, and the key
users receive an alert message.

4.1.4 Alert emails generated

In this section, we show the triggering steps for timeout and rejected
payment alerts.

149
4A

Timeout alert
Figure 4.14 shows an example of a timeout alert email that was
triggered for batch number 62. The alert was triggered when the
RBNK_BATCH_TIMEOUT_MONITOR program was executed.

Figure 4.14: Sample email alert triggered

It was triggered because there was no response from the bank

indicating acceptance or receipt of the payment file. The configured
duration had elapsed.

The email is displayed from SAPconnect: Send Requests

(transaction code SOST) because this is not a productive system.

Rejected payment alert

An alert is triggered if, in communication with the bank, specifically
in the level 1 acknowledgement file from the bank, there is a failed
status message indicating a rejected payment. The steps to trigger
this alert are shown in the following section.

150
4A

After the level 0 file acknowledgement is received from the bank,

and before the level 1 acknowledgement is received, the status of
the batch in the Monitor Payments app (transaction code
BNK_MONI) is set to R B , as shown in Figure 4.15.

Figure 4.15: Monitor Payments app before level 1 acknowledgement

In Figure 4.16, the level 1 acknowledgement message is displayed.

Note that the status is RJCT (rejected).

151
4A

Figure 4.16: Level 1 acknowledgement file

The acknowledgement files from the bank are placed in the physical
directory tied to the logical directory for BNK_IMPORT. The
RBNK_IMPORT_PAYM_STATUS_REPORT program, shown in
Figure 4.17, is typically scheduled to run frequently throughout the
day.

Figure 4.17: Acknowledgement import program

When this program is executed, the acknowledgement files are

imported into SAP. The RBNK_IMPORT_PAYM_STATUS_REPORT
output screen shows the information indicating that the status of
batch 62 has been updated (see Figure 4.18).

152
4A

Figure 4.18: Log file after import of acknowledgement file

Recipients of the alert immediately receive a message to notify them

of the failed payment (see Figure 4.19).

Figure 4.19: Urgent message to business user regarding rejected payment

Figure 4.20 shows the urgent email message which is sent to the
alert recipients.

Figure 4.20: Alert email message

153
4A

As a final step for this rejected payment alert, the status of the batch
in the Monitor Payments app (transaction code BNK_MONI) is
updated, and is now set to R B , as shown in Figure
4.21.

Figure 4.21: Rejected payment status on the All tab

Note that the payments rejected by the bank show on both the A
tab and the E tab (see Figure 4.22) in the Monitor
Payments app (transaction code BNK_MONI).

Figure 4.22: Rejected payment status on the Exceptions tab

Delivered alert functionality

SAP delivers basic alert functionality that might not

meet all customers’ requirements. However, this
basic functionality can be used as a foundation to
build the desired functionality via custom coding.

4.2 Automatic reversal of rejected payments

154
4A

Whenever a payment or batch is rejected in BCM, users need to

ensure that payment documents posted by the AP or Treasury
payment programs have been reversed. SAP provides sample code
to assist with the automatic reversal of payment documents that are
rejected during the payment approval process, because some SAP
customers might want this functionality.

Figure 4.23 shows the two methods in this SAP-delivered BAdI.

There is one method for resubmitting a payment and one method for
rejecting a payment.

Figure 4.23: Payment reversal BAdI

The SAP-delivered sample code does the following:

On resubmission, it changes the value date in the bank clearing

line item of the original document and adjusts the corresponding
cash management data for cash position. The new value date is
the resubmission date.
On rejection, the value date is changed to the last day of year
9999 to indicate that this payment will never leave the company.

The code of the note only contains logic for FI (Financial

Accounting) payments (payment program F110). If you have

155
4A

activated BCM for Treasury (payment program F111), Travel, or

Payroll you have to enhance the logic accordingly.

If you require different functionality, such as automatic reversal of

the payment document in the case of rejection, you can create an
enhancement implementation for enhancement spot
BNK_BADI_ORIG_PAYMT_CHG (using transaction code SE19).

Automatic reversal OSS note

Readers can find further information on this topic in

SAP Note 1333640—"Exit: Automatic Reset
Cleared Items on Batch Rejection”.

4.3 BCM Connector

The BCM Connector is a tool within the BCM module that enables
companies to centralize their payment approvals and reporting. The
BCM Connector can be used to route payment files generated by
other systems; for example, Concur T&E payment files, through the
central instance of SAP, before the payments are sent to the bank.
Users should check with their SAP account executives for the
licensing of the BCM Connector.

The non-SAP system payment files are created in their respective

systems, then placed in an incoming BCM Connector directory on
the on-premise system. The SAP system reads the non-SAP
payment files, goes through any necessary approvals, and then
sends the payments to the bank using the same transmission as the
SAP payment files. This enables SAP customers to have centralized
reporting across all payments.

156
4A

What is BCON?

When you see the acronym BCON in SAP

materials, this refers to the BCM Connector.

Figure 4.24 shows the SAP architecture when using the BCM
Connector to import payment files from either non-SAP systems or
other SAP instances.

Figure 4.24: Overview of BCM Connector

The process flow when using the BCM Connector is as follows:

157
4A

1. The payment file is created in the source system, which can be

an SAP or non-SAP system.

2. The BCM Connector inbound interface is called either through

an RFC call, a batch job, or a manual transaction call. Within
BCM, an “external batch” is created for the imported payment
file. If a company wants to use other file transfer tools to move
the file from the source system to the target system, SAP
supports that as well.

3. If payment approvals are being used, the imported payment file

is either approved or rejected using the same apps and
programs that any other payment file would use in BCM. Note,
however, that the imported payment file starts at the second
level release. This is the Verifier approval step. It is not possible
to approve or reject individual payments within the imported
payment file.

4. The payment file is transferred to the outbound directory, from

which it is sent to the bank.

5. The payment file is sent to the bank following the same process
as payment files created in SAP; for example, through SAP
Multi-Bank Connectivity. In addition, the acknowledgement files
are received from the bank and imported into BCM.

6. Reporting is available on the payments/batches in the imported

file, the same as if the imported payment file was generated in
SAP.

One unique characteristic of BCON batches that we would like to

highlight is the status of BCON batches after approval. Payment
batches originated from the current system have the status
P M C after they are approved, while BCM

158
4A

Connector payment batches have the status S I -

H after approval, as shown in Figure 4.25.

Figure 4.25: BCON batch status after approval

All other statuses for the BCON batches are the same.

4.3.1 BCM Connector configuration

We will now walk through some of the configuration associated with
BCM Connector.

Figure 4.26 shows the configuration nodes relevant to BCM

Connector.

Figure 4.26: BCM Connector configuration nodes

Define Formats for Payment Data Mediums node

One of the first steps is to define the format of the payment files that
are to be imported into BCM Connector, as well as the parameters
that are used to read the imported payment file. Figure 4.27 shows
the function modules SAP provides to read the imported files.

159
4A

Figure 4.27: Function modules to read imported payment file

The above function modules are used in the configuration that

specifies how to read the imported file. Note that the function
module is different, based on the format of the imported file.

160
4A

In this configuration step, we specify information relevant to

importing the payment file, such as (as entered) the desired
payment format of the output file, the function module to read the
input file, the message ID as the reference number, the end-to-end
ID as the payment document number, and payment method (see
Figure 4.28). A number of these fields are used to display the
payment batches in the Monitor Payments app (transaction code
BNK_MONI).

Figure 4.28: Configuration to read the imported payment file

Define Direct Release for Payment Medium Files node

In this configuration, the release requirements for the imported
payment file are defined.

Before doing this, we have to define the batching rule ID we want to

use, as shown in Figure 4.29.

Figure 4.29: Define BCM Connector Rule ID

Just as the BCM batching rule was created for native payments,
BCON payments can have either automated approval or multiple
approval levels. As shown in Figure 4.30, we have used BCM Rule

161
4A

DIREKT to process the input file from an external Concur system

with automated approval.

Figure 4.30: BCON batch automated approval

The rule ID is then assigned to a company code, house bank, and

account ID in SAP, as shown in Figure 4.31. These parameters are
used for routing.

Figure 4.31: Direct release customizing

Define debit account as house bank account ID

For successful processing, the debit account in the

imported payment file must be defined in SAP as a
house bank account ID.

Define Outbound Directories node

The final step for our BCON setup is to define the logical directories
where the imported payment file is moved to upon approval and
rejection. These are as follows:

F P O directory—where the payment file is

moved to after payment approval.

162
4A

F P R directory—where the payment file is moved

to in the case of rejection.

This configuration is shown in Figure 4.32.

Figure 4.32: Specify BCON outbound directories

The directory setup for BCON is similar to that for importing

acknowledgement files where the physical directories are specified
using logical directory names with the transaction code FILE.

4.4 Summary

163
4A

In this chapter, we walked through the optional BCM configuration,

that, if implemented, can make the payment process more efficient.
Alerts can be very helpful from a proactive monitoring point of view,
and automated reversals can help resolve cash position and
reconciliation-related issues. We also discussed BCM Connector,
which is used to process files from external systems and which
makes the central SAP system a true payment processing, approval,
and reporting hub.

164
5R

5 Resolving implementation
issues
In this chapter, we walk through the typical issues that can
arise during implementation, and in ongoing support, and how
to resolve them. You might not encounter these issues, but it is
useful to be aware of them. We cover detailed steps to validate
and verify workflow settings, where to look if encountering
batching errors when executing the Creation of Cross-Payment
Run Payment Media program, and how to reset a batch.

5.1 Workflow settings

As mentioned previously, BCM approval is based on SAP standard
workflow, which can be tricky. In this section, we outline the
validations that should be performed after completion of the
workflow setup and how to execute these validations.

5.1.1 Sending workflow verification message

After completing the basic workflow settings in your SAP system,
verify that you are able to trigger a test workflow message using
Automatic Workflow Customizing (transaction code SWU3). Press
the S V W button, as shown in Figure
5.1.

165
5R

Figure 5.1: Send workflow test message

An informational message is then displayed (see Figure 5.2). Press

the C button.

Figure 5.2: Workflow verification message sent

The person executing this step then receives a workflow message in

their inbox. To view the message from an SAP GUI login, press the
SAP B W button, as shown in Figure 5.3.

Figure 5.3: Getting to SAP Business Workplace

From there, the user sees their Business Workplace with a panel on
the left, as shown in Figure 5.4.

166
5R

Figure 5.4: User’s Business Workplace screen

Open the W inbox folder, as shown in Figure 5.5.

167
5R

Figure 5.5: User’s Workflow inbox

The workflow verification message should be the topmost message

in the W folder, as shown in Figure 5.6.

168
5R

Figure 5.6: Workflow verification message

With this test, you confirm that the basic RFC connection workflow
settings are properly set up on your SAP system.

5.1.2 Verifying release procedures

In this step, we verify the release procedure for release object
BNK_INI. It should be set to A . Use the M :
A R P R O program
(transaction code BNK_BNK_INI_REL01), as shown in Figure 5.7.

Figure 5.7: Release procedure for release object BNK_INI

The release procedure for release object BNK_COM should be

verified as well. This is done by using the M : A

169
5R

R P R O program (transaction
code BNK_BNK_COM_REL01), as shown in Figure 5.8.

Figure 5.8: Release procedure for release object BNK_COM

The settings here depend on the business requirement for the

Approver release. In our use case scenario, the Approver release is
conditional, based on the batching rule assigned.

5.1.3 Verifying release procedure settings

Validate the release procedure settings by displaying the contents of
the V_TBCA_RTW_LINK view using the ABAP (Advanced Business
Application Programmin) dictionary (transaction code SE11). Do this
by entering the view name in the V field, as shown in Figure 5.9.

170
5R

Figure 5.9: ABAP Dictionary screen

Click the D button, then click on M and C (not

shown here). The entries appear as shown in Figure 5.10.

Figure 5.10: BCM release procedure settings

171
5R

There must be an entry for BNK_INI, which is for the first release
level, and there might also be entries for BNK_COM, depending on
the approval requirements after the first release.

5.1.4 Event type linkage

Using the C V “E T L ”: O
program (transaction code SWETYPV), users should search for
O T BUSISB001, as shown in Figure 5.11.

Figure 5.11: Event Type Linkages program

Double click on the top entry (not shown here), and a details screen
appears, as shown in Figure 5.12.

172
5R

Figure 5.12: BUSISB001 settings—linkage activated

Verify that for object type BUSISB001 the T A

checkbox is selected.

5.1.5 Payment signatories

The payment signatories defined in Bank Account Management
(BAM) can be used for payment approval instead of using the BCM
settings for payment approval. The BAM payment approval settings
can be used for more basic payment release strategies. The setting
to determine whether a BAM signatory or BCM configuration is
used, is made via menu path: F S C
M • C L M • B
A M •E P A (see Figure

173
5R

5.13). In this example, BAM payment approval is set instead of BCM

payment approval.

Figure 5.13: Enable BAM payment signatory approvals

When using the BCM configuration for payment approvals, the

setting shown above should not be used. In our system, we use the
configuration shown in Figure 5.14 because we want to use BCM
approvals, instead of BAM approvals.

Figure 5.14: Enable BCM payment approvals

5.1.6 Verifying BCM workflow tasks

Using the T :M program (transaction code PFTC_CHG)
ensure that each BCM standard task is defined as a G T .
To do this, set the T T to S and enter the task
number, as shown in Figure 5.15. Then press the Enter key.

174
5R

Figure 5.15: Task: Maintain program

Press the C button (from Figure 5.15) and an informational

message is displayed, as shown in Figure 5.16.

Figure 5.16: Informational message

Next, press the C button to move past the informational

message and you are taken to the screen shown in Figure 5.17.

175
5R

Figure 5.17: Change workflow task

From this screen, follow the menu path shown in Figure 5.18.

Figure 5.18: Maintain agent assignment menu path

From there, select the A button and verify the task is

defined as a G T , as shown in Figure 5.19.

176
5R

Figure 5.19: Verify workflow task is defined as a General Task

These settings should be confirmed for all the BCM standard tasks
listed below:

50100025
50100026
50100066
50100075

After the above verifications have been made, enter the business
process steps to create a new batch that requires workflow. If you
encounter issues such as no workflow agents assigned, use the
D W I C E program, which
is explained in the next section.

177
5R

5.1.7 Diagnosing workflow errors

The D W I C E program
(transaction code SWI2_DIAG), shown in Figure 5.20, can be used
to display any workflow items with errors.

Figure 5.20: Diagnosis of workflow errors

After executing the program, a screen similar to the one shown in

Figure 5.21 is displayed.

178
5R

Figure 5.21: Diagnosing workflow errors

Double click on the relevant entry to view more information relating

to that error (see Figure 5.22).

Figure 5.22: Workflow error details

The details of the error should provide information to help resolve it.

5.1.8 Check approvers

After a batch has been created, you can verify the approvers or
agents of the batch using the S
program (RBNK_COM_SHOW_BTCH_APPR_LST), as
shown in Figure 5.23

179
5R

Figure 5.23: Show approvers program

A screen is displayed showing the possible approvers (see Figure

5.24).

Figure 5.24: List of possible approvers

Be aware that SAP does not show the list of approvers after a batch
has been approved. When executing this program for a batch that
has been approved, a screen similar to the one in Figure 5.25 is
displayed.

180
5R

Figure 5.25: List of approvers for approved batch

As we can see, the message N is displayed for

batches that have been approved.

To view the approver that approved the batch, go to the batch

S display, in the Monitor Payments app (transaction
code BNK_MONI), as shown in Figure 5.26.

181
5R

Figure 5.26: Batch status history screen

Keep in mind that there are other workflow programs that may assist
in resolving issues, such as the Selection Report for Work Items
program (transaction code SWI1) and the Process Work Item as
Administrator program (transaction code SWIA).

5.2 Errors in the batching process

Payments that have errored in the batching process can be found in
the P program (transaction
code BNK_MONIP), as shown in Figure 5.27. For these errors, the
payments show a status of P , which is the
same status as payments which have not yet been batched. The
difference is that with batching process errors, the M and
M ID fields are populated; these fields are blank for payments
not yet sent through the batching process.

Figure 5.27: Errored payments in batching process

In the example shown, the payment made on 01/09/2020 errored,

whereas the payments run on 12/07/2019 have not yet been run
through the batching process.

5.3 Resetting the merging of a batch

One potentially important process step that we have not yet covered
is resetting the merging of a batch. If a batch is merged in error, it
can be corrected with the R M R B
program (transaction code BNK_MERGE_RESET). This reverses
the merge step.

182
5R

If a payment file is not created on the file server after approval of the
batch, it may be necessary to reset a batch in BCM. After resolving
the issue, the steps to reset a batch are below. This is not part of the
normal process; you should only need to do this as an exception.

The steps to reset a batch are:

1. Determine the batch number to be reset. The batch number is

displayed in both the P
report (transaction code BNK_MONIP) or in the Monitor
Payments app (transaction code BNK_MONI). In our example,
the batch number to be reset is 38, as shown in Figure 5.28.

Figure 5.28: Batch to be reset

2. Execute the R M R B app

(transaction code BNK_MERGE_RESET). Enter the batch
number and deselect the T R and S C
checkboxes, as shown in Figure 5.29. Note the ability to reset a
merge run in test run mode.

183
5R

Figure 5.29 : Reset a batch

3. Press E and an output screen appears, as shown in

Figure 5.30.

Figure 5.30: Merge reset output screen

4. Back out once and a message is displayed, as shown in Figure

5.31.

184
5R

Figure 5.31: Merge reset success message

At this point, the batch has been reset. It now follows the normal
process to be re-batched, starting with the C C -
P R P M app (transaction code FBPM1).

New batch number

A new batch number is given to this payment. The

old batch number no longer exists but is visible
when executing the P
report (transaction code
BNK_MONIP), as shown in Figure 5.32.

Figure 5.32: Reset batch in Payment status for batching process report

185
5R

Remember that the execution of the C C -P

R P M program (transaction code FBPM1) is most
likely to be a scheduled job in production and the frequency is
determined by the company’s needs.

5.4 Payment file generation

If you run into the issue that a payment file has not been created
and the message F (BNK_GENERAL223) is
displayed in the monitoring reports, it may be necessary to review
the jobs triggered to create the payment file in order to diagnose the
issue. These jobs are triggered automatically after payment approval
(where there is a payment approval), otherwise they are triggered
after payment batching (where there are no approvals).

To view the status of the jobs triggered to create the payment files,
run transaction code SM37 (Overview of job selection) and search
for the jobs that start with PAYM*, as shown in Figure 5.33.

186
5R

Figure 5.33: View payment file creation jobs

The subsequent output screen is similar to the one shown in Figure

5.34.

Figure 5.34: Payment file creation output

187
5R

Batches with no file do not show a F status.

5.4.1 Identification for Reservation for Cross-Payment Run

Payment Media (OBPM5) configuration
Based on how transaction OBPM5 is configured, there is a risk that
a user can mistakenly enter an incorrect payment run identification
to route the payment through BCM.

For example, if an asterisk is entered in this configuration, all

payments are routed through BCM. If the configuration does not
enable users to enter an asterisk in this configuration, there is a risk
that a payment file might be created without the necessary
approvals.

SAP Note 1447399

For this scenario, it may be helpful to refer to SAP

Note 1447399—"Prevent payment media creation if
batching was bypassed”.

Users that are not able to enter an asterisk in the OBPM5

configuration must have a process in place to avoid the above-
mentioned issue.

5.5 Summary
In this chapter, we covered some of the typical issues that might
arise during implementation and in ongoing support. The information
in this chapter should provide consultants and support users with
useful information to resolve BCM-related issues in an efficient and
timely manner.

188
6 SAP M -B C

6 SAP Multi-Bank Connectivity

To give readers a full picture of SAP’s payment processing
solution, a book on Bank Communication Management would
not be complete without a chapter on SAP Multi-Bank
Connectivity. SAP Multi-Bank Connectivity is an SAP Cloud
Platform (SCP) solution that provides connectivity to and from
banks. In this chapter, we outline what SAP Multi-Bank
Connectivity is, how it works, and how companies can benefit
from it.

6.1 Overview of SAP Multi-Bank Connectivity

Electronic communication with banks is something most SAP
customers need to do on a daily basis. This includes, for example,
retrieving bank statement files, sending payment files to banks,
verifying the status of payments sent to the banks, etc. For
companies that have banking relationships with multiple banks,
supporting the connections with all of them can be a significant task.
Where electronic connections do not exist, these daily tasks must be
performed manually, which is time-consuming and prone to error.

Companies using SAP can connect to their banking partners in a

number of ways:

Direct connection (host-to-host)

SWIFT network
EBICS (Electronic Banking Internet Communication Standard)
Third-party bank communication software
Manually through the banking portal

189
6 SAP M -B C

Companies now have another option—SAP's Multi-Bank

Connectivity (MBC).

It is possible to connect to SAP Multi-Bank Connectivity from ECC,

SAP S/4HANA Cloud editions, and SAP S/4HANA on-premise
environments. In the next section, we explain how this is
accomplished.

As mentioned earlier, SAP Multi-Bank Connectivity is an SCP app.

This is a cloud application run and managed by SAP.

Other examples of SCP apps in the SAP Finance, Treasury and

Risk Management areas are:

SAP Cash Application —this automates cash application using

machine learning.
Trading Platform Integration app— this connects SAP’s
Treasury and Risk Management module with third-party front-
office trading systems such as 360T and FXAll.
Digital Payments app—this securely handles digital payments
(e.g. credit card payments or PayPal payments).

Each of these SCP apps are run and managed by SAP. Information
can be passed, from various release levels, from the SAP
environment to the SCP app.

SAP Cloud Platform app

SAP Cloud Platform (SCP) apps are a type of

product that was introduced with SAP S/4HANA.
One of the key benefits of SCP apps is that
companies do not need to be on SAP S/4HANA to
use the SCP app functionality; users are able to take advantage

190
6 SAP M -B C

of the new functionality offered by SAP on S/4HANA while still

being on an ECC environment.

6.1.1 System landscape of SAP Multi-Bank Connectivity

To ensure our readers understand the system landscape when using
SAP Multi-Bank Connectivity, we will review it in this section.

The diagram in Figure 6.1 shows the landscape when using SAP
Multi-Bank Connectivity.

Figure 6.1: Landscape using SAP Multi-Bank Connectivity

With SAP Multi-Bank Connectivity, SAP provides users with a new

connectivity service, which was not available previously. This
enables SAP to offer an end-to-end payment solution to their
customers.

191
6 SAP M -B C

SAP provides multiple options to connect with banks through SAP

Multi-Bank Connectivity:

Direct connections
Member banks
Use of third-party communication software
SWIFT network
EBICS

SAP supports most of the options currently utilized by companies for

bank connectivity.

In theory, SAP users should not be overly concerned with how SAP
Multi-Bank Connectivity connects to their banks. This can be
decided between the SAP customer, the bank, and the SAP Multi-
Bank Connectivity team at the time of on-boarding.

There are a number of advantages of using the SWIFT network and

standards for interfacing with banks. SWIFT is a member-owned
cooperative that provides safe and secure bank communication for
its nearly 11,000 members. The SWIFT network guarantees the
secure transfer of files and messages to and from the banks. It is a
way to standardize communication, giving banks less leverage over
companies. With SAP Multi-Bank Connectivity, SAP offers its
customers a seamless connection to the SWIFT network. It is no
longer necessary for companies to maintain SWIFT hardware and
software on their own, or to use a service bureau.

Note that for most SCP app products, there is a connector on the
company’s SAP environment that connects their system to the SCP
app. In some cases, this connector is referred to as the ECC
Connector; however, in the case of SAP Multi-Bank Connectivity,
this component is referred to as the MBC Connector. All messages

192
6 SAP M -B C

passed to and from the SAP customer’s system to SAP Multi-Bank

Connectivity go through the MBC Connector.

MBC Connector

The MBC Connector program is included with all

SAP S/4HANA systems, but is an add-on for ECC
systems.

6.1.2 Implementing SAP Multi-Bank Connectivity

After a company signs on to use SAP Multi-Bank Connectivity, the
company and the SAP Multi-Bank Connectivity team determine the
scope of the project, the number of banks included in the
implementation, the timeline, etc.

Implementing SAP Multi-Bank Connectivity can be a stand-alone

project, with a timeline dependent on a number of factors; one of the
main factors being the company’s readiness to rollout the
functionality.

For example, a company not yet making electronic payments from

SAP has to do more system setup than a company that is currently
making electronic payments from SAP. The difference is that, in the
latter scenario, the SAP system is most likely ready, with all the
proper master data (e.g. bank master data) and payment processes
in place to start sending electronic payments from SAP to additional
banks.

The effort required to implement SAP Multi-Bank Connectivity is

independent of the setup required in SAP to make changes to allow
for straight-through processing of payments. The amount of

193
6 SAP M -B C

payment file testing with the banks contributes significantly to the

implementation time.

The readiness of the banks to accept payments electronically is

another significant contributing factor to the implementation timeline.

Bank connectivity

It is important to point out that SAP Multi-Bank

Connectivity provides communication to and from
the banks. It does not change or adjust the payload
of the messages during processing. The formatting
of the message payload is done by the SAP back-end systems.

When sending outbound payments from SAP, the bulk of the

implementation time is taken up in defining the payment formats and
testing with all the banks, and from the bank accounts in scope.

Implementing SAP Multi-Bank Connectivity is similar to

implementing a host-to-host connection with a bank, but in the case
of SAP Multi-Bank Connectivity, SAP supports the bank
communication. In both cases, there is a test environment where
sufficient testing takes place before moving the connection to
production. From a customer’s perspective, when implementing SAP
Multi-Bank Connectivity, the connection to SAP Multi-Bank
Connectivity happens once, whereas when implementing host-to-
host connections, connectivity needs to be established for each
bank.

With SAP Multi-Bank Connectivity, each network participant has a

unique tenant (or area) for processing, and a unique partition (with
unique encryption) for data storage within the SAP Multi-Bank
Connectivity SCP app.

194
6 SAP M -B C

On the SAP system, there is either a program, the Connector

Monitor, or an app—the Manage Bank Messages app, which is used
to view and process all messages that go to or from SAP Multi-Bank
Connectivity (see Figure 6.2).

Figure 6.2: Manage Bank Messages app

The company’s SAP release level determines the programs that can
be used to view messages via the MBC Connector:

Up to release 1909 FP00, use the Connector Monitor. This

includes ECC releases.
Starting at SAP S/4HANA 1909 FP01, use the Manage Bank
Messages app.

The actual configuration required for the MBC Connector in the SAP
system is minimal.

6.1.3 File types supported by SAP Multi-Bank Connectivity

At the time of writing this book, the different types of files supported
by SAP Multi-Bank Connectivity are:

195
6 SAP M -B C

Outgoing payment files

Incoming payment acknowledgement files
Incoming bank statements (account statements)
Incoming lockbox files
Bank fee analysis reports
Outgoing and incoming Treasury trade confirmations (MT300
and MT320)
Payment advice files

Keep in mind, however, that this is a continuously growing list.

For any file types not yet supported, it is possible to create a

message at the MBC Connector, and send it to SAP Multi-Bank
Connectivity, then to the bank.

6.1.4 Integration of SAP Multi-Bank Connectivity

SAP Multi-Bank Connectivity is tightly integrated with the SAP back-
end modules that generate or consume the messages. No other
software vendor can integrate better with SAP.

Let’s consider a few examples of the seamless integration available

with SAP Multi-Bank Connectivity:

Example 1—when a payment program is run, or, in the case of

BCM when the final approval is executed, SAP sends the
payment information directly to the MBC Connector, without
generating a payment file. (There is no file sitting on a file
server. Instead the payment information is held in the SAP
database.) The MBC Connector then encrypts the payment
information and sends the encrypted message to SAP Multi-
Bank Connectivity, which sends the file to the bank. When the
bank sends back the payment acknowledgement files, SAP

196
6 SAP M -B C

Multi-Bank Connectivity sends the acknowledgement files to the

MBC Connector, which recognizes the file type and has the file
processed by the BCM acknowledgement class/program in
order to process the payment status files.
Example 2—when an inbound bank statement or lockbox file is
received at the MBC Connector, SAP knows what type of file it
is and sends it directly to the bank statement or lockbox
program that consumes the file. (The variants to use when the
messages are processed are set up during configuration of the
MBC Connector.)

Note that it is possible to configure certain message types to not be

processed automatically, but rather processed manually. It is also
possible to save copies of specific files on your file server, if desired.
These settings can be made when configuring the MBC Connector.

6.2 Advantages of using SAP Multi-Bank Connectivity

There are a number of additional advantages of using SAP Multi-
Bank Connectivity to transmit files to/from banks:

It provides the ability to standardize electronic communications

with external banks into one interface.
It enables various connection protocols to be supported.
It is faster to implement.
It enables companies to take advantage of new services that
might not be available via traditional communication channels;
for example, member banks might provide a means for their
customers to easily retrieve their bank account balances. This is
only a simplified example; the services that member banks can
provide are potentially limitless and are evolving over time.

197
6 SAP M -B C

SAP is continuously working with banks to become member

banks, for faster implementation and to provide advanced
capabilities to their customers.
SAP now provides a direct connection to the SWIFT network
without requiring SAP customers to manage SWIFT hardware
and software themselves.
There is less reliance on specific banks.
Companies require fewer interfaces with financial institutions.

6.3 Summary
In this chapter, we introduced SAP’s Multi-Bank Connectivity
product. Readers should now have a good understanding of the
system landscape when using SAP Multi-Bank Connectivity, the
aspects of implementing SAP Multi-Bank Connectivity, and the
benefits of using it.

198
7A P M

7 Advanced Payment
Management
Along with SAP Multi-Bank Connectivity, SAP has deployed
another new key module in the payment processing landscape
—Advanced Payment Management. In this chapter, we give
readers an overview of this new payment module.

7.1 Advanced Payment Management overview

The primary objectives of Advanced Payment Management are:
payment centralization, exception processing, and payment
standardization. In addition, there are a number of key features with
Advanced Payment Management that are important to understand
because they pull together payment processing in SAP.

Parts of the Advanced Payment Management module were

previously sold as the Payment Engine (component FS-PE), which
was targeted specifically to SAP Banking customers. In recent
years, SAP has made some changes to the module and is
positioning it to SAP corporate customers as Advanced Payment
Management.

The Advanced Payment Management module is a component that is

integrated into SAP’s S/4HANA payment processing landscape. The
solution centralizes payment activities specifically when a company
has multiple systems generating payment files. This could be an
environment that contains both SAP and non-SAP systems, or is a
multiple-SAP instance environment. The solution integrates with
other modules such as:

SAP S/4HANA Cash Management

199
7A P M

SAP In-House Cash

SAP General Ledger
Bank Communication Management
SAP Multi-Bank Connectivity

Figure 7.1 shows SAP’s payment processing landscape and where

Advanced Payment Management fits into it.

Figure 7.1: Advanced Payment Management landscape

Departments within an organization that would typically use the

Advanced Payment Management functionality are the Treasury
department or a shared service center.

Prerequisites to using Advanced Payment Management

In order to use Advance Payment Management

companies must be on SAP S/4HANA 1809 FPS2
or higher, and need to be using SAP S/4HANA’s
Cash Management solution. Advanced Payment

200
7A P M

Management can be included in either SAP S/4HANA Cloud or

On-Premise implementations. Note that in SAP S/4HANA Cloud
Essentials implementations, only the payment forwarding
scenario is currently supported. In addition, Advanced Payment
Management requires a separate license. This module is not
available on ECC.

7.2 Functionality included in Advanced Payment Management

When Advanced Payment Management is used, outgoing payments
are passed through it before being sent from SAP. Within Advanced
Payment Management, payments are converted to an internal
format using the Input Manager. They are processed based on rules,
which could result in updates to SAP Cash Management, the SAP
General Ledger, or SAP In-House Cash. Then, the payment file is
re-created, possibly in a different format to the one in which it was
delivered (if desired), using the Output Manager.

The diagram in Figure 7.2 shows an overview of Advanced Payment

Management.

201
7A P M

Figure 7.2: Diagram of Advanced Payment Management

The process within Advanced Payment Management is as follows:

Payments are imported into the Input Manager of Advanced

Payment Management where they are converted into an
internal format that can be easily enhanced within the module.
Payment enrichment and validation rules are executed on the
payments. These could be, for example, a watch list screening
using a Governance, Risk, and Compliance (GRC) solution,
Office of Foreign Asset Control (OFAC) sanctions, or a check of
the bank cutoff time.
The routing for the payments can be changed. The payment
can be routed to a different bank account based on the routing
rules entered as master data. The Cash Management module
and General Ledger are updated to reflect the routing changes.
Once all processing is complete within Advanced Payment
Management, the payments are batched and approved (if

202
7A P M

approvals are required) using BCM or Bank Account

Management (BAM) approvals.
In the Output Manager, the payment file is re-created—which
could be in a different format—before it is sent through the bank
communication channel and on to the bank. The payment
formatting is done using DMEEX (Extended Data Medium
Exchange Engine) functionality.

The above processing takes place automatically without any manual

intervention. Where there are errors or certain exceptions, manual
intervention is required, in which case exceptions are raised to alert
the appropriate users.

The functionality in Advanced Payment Management addresses a

number of exception scenarios, such as:

Enrichment of payment data

Validation of payment data (e.g., BIC validation)
Exception processing (e.g., bank cut-off times and fund
availability)
Incorporation of functionality relating to bank cut-off times
Watch-list screening
Initiation of one-off urgent payments
Recall or request for cancellation
Changes to payment routing
Controls on specific currencies, such as blocking payments
over a certain amount, or payments in restricted currencies
(note that there are other ways in SAP to address both of these
examples)

203
7A P M

The Advanced Payment Management module has a number of

additional attractive features, such as:

Payment formats can be transformed from one format to

another.
Payments can be accepted in the form of an IDoc and are
reformatted into a more standardized format, such as
PAIN.001.001.03.
Payee names can be masked (e.g., for payroll payments).
Integration with other modules is possible.
It is able to handle a very high volume of transactions.
It enables additional payment reporting.
It provides a user-friendly, graphical payment flow display that
shows the end-to-end payment process flow, as shown in
Figure 7.3.

Figure 7.3: Advanced Payment Management process flow diagram

7.2.1 Scenarios supported by Advanced Payment Management

204
7A P M

The Advanced Payment Management module supports four specific

scenarios:

Payments ‘in the name of’—payment forwarding

Payments ‘in the name of’—payment routing
IHC (In-House Cash) intercompany payments
IHC payments-on-behalf-of (POBO)

We will now walk through each of these four scenarios in more

detail.

Payments ‘in the name of’—payment forwarding

In this scenario, payments run through the validation and enrichment
rules in Advanced Payment Management and there is no change to
the debit bank account used for the payments. In addition, the
batching of the payments is not changed. The payment file format
can change in this scenario. This is a very straightforward payment
process. With this scenario, because the paying bank account is not
changed, there is no need to update the general ledger.

Advanced Payment Management reflects the payment amount in

Cash Management using a memo record.

Figure 7.4 shows the process flow for the payment forwarding
scenario through Advanced Payment Management.

205
7A P M

Figure 7.4: Advanced Payment Management—payment forwarding

Payments ‘in the name of’—payment routing

In this scenario, the debit account changes based on the routing
rules in Advanced Payment Management. A subsidiary generates a
payment file, but the bank account the payment is made from is not
specified. Instead, an internal routing account is used as the debit
account. The debit bank account that the payment is paid from is
determined by rules specified in Advanced Payment Management.
The process is as follows:

The payment file is consumed using the Input Manager, which

converts the payments into an internal format.
Next, validations and enrichments are carried out.

206
7A P M

The routing then takes place at the payment level based on

business-defined master data rules for routing payments, which
include characteristics such as currency, bank cut-off times,
value date, etc.
The payments are then batched and approved, using the
updated payment information (debit account and value date).
The payment approvals used can be from either the BCM
module or from Bank Account Management.
The SAP Cash Management and General Ledger are updated
to reflect the bank accounts the payments are being made from.
The Output Manager then takes the payment information in an
internal format and generates the payment files, which are sent
to the bank communication software and then onto the bank(s).

Figure 7.5 shows the process flow for the payment routing scenario
through Advanced Payment Management.

207
7A P M

Figure 7.5: Advanced Payment Management—payment routing

Note in this scenario that the payments are being made in the name
of the subsidiary but are being paid from a Treasury or shared
service center bank account.

In-House Cash scenarios

The SAP In-House Cash (IHC) module enables the

creation of an in-house bank or payment factory in
SAP. The IHC module supports the following
scenarios:

Intercompany payments

208
7A P M

Centralized payments—also known as payments-on-behalf-

of (POBO)
Centralized receipts—also known as receivables-on-behalf-of
(ROBO)
Cash pooling across company codes
Manual payments

In-House Cash intercompany payments

This scenario relates only to In-House Cash intercompany
payments. In other words, there is no external payment generated.

The payments are received into Advanced Payment Management,

and are converted into an internal format in the Input Manager.
Validation is then performed on the payments, and routing changes
are made if necessary. The payments are then sent to the IHC
module to settle on the internal IHC accounts.

Figure 7.6 shows the process flow for internal payments through
Advanced Payment Management.

209
7A P M

Figure 7.6: Advanced Payment Management—intercompany payments

In this scenario, the input to the Advanced Payment Management

module is the payment IDocs that are generated by the Accounts
Payable payment program (transaction code F110).

In-House Cash payments-on-behalf-of (POBO)

With IHC payments-on-behalf-of, Advanced Payment Management
determines the best payment method and external bank account to
use for the payment, based on the criteria defined in Advanced
Payment Management.

In this scenario, a subsidiary generates a payment, or payments,

from their in-house bank account; but the bank account the payment
is made from is determined by the rules defined in Advanced
Payment Management. The process is as follows:

The payment file is consumed using the Input Manager, which

converts the payments into an internal format.
Next, validations and enrichments take place.
The routing is then carried out at the payment level, based on
business-defined master data rules for routing payments, which
include characteristics such as currency, bank cut-off times,
value date, etc. The external bank account to be used for the
transaction is an external bank account tied to the
headquarters/in-house bank. The payment method to be used
for the transaction is also determined by the master data rules
in Advanced Payment Management.
The payments are then batched and approved, using the
updated payment information (debit account and value date).
This is performed using the BCM module. Bank Account
Management payment approvals may also be used.

210
7A P M

The SAP Cash Management and General Ledger are updated

to reflect the bank accounts the payments are being made from.
The Output Manager then converts the payment information
into an internal format and then generates the payment files,
which are sent to the bank communication software and then
onto the bank(s).

Note in this scenario that the payments are being made in the name
of the subsidiary but are being paid from a Treasury or shared
service center bank account, thus the name ‘payments-on-behalf-of’.

Figure 7.7 shows the process flow for internal payments through
Advanced Payment Management.

Figure 7.7: Advanced Payment Management – Payments-on-behalf-of

211
7A P M

The IHC module includes payment routing that is specified in

configuration. The payment routings in Advanced Payment
Management are master data rules controlled by the business user.

From configuration to master data

With the move to SAP S/4HANA, SAP has moved

functionality from configuration to application-side
processing. This is seen in the IHC routing rules,
moving from configuration to business-defined
master data rules in Advanced Payment Management. There
are other examples of this in a number of other areas of SAP,
such as the definition of house bank accounts moving from
configuration to master data.

7.2.2 Gaps filled by Advanced Payment Management

With Advanced Payment Management, SAP has introduced a
number of functionalities that were previously missing from SAP’s
payment solution offerings. In this section, we discuss some of
those.

Before the Advanced Payment Management module was

introduced, SAP did not have a way to integrate IDoc payments into
BCM. As mentioned earlier in Section 3.2.2 (subsection “Payment
Medium: Create/Assign Selection Variants”), the BCM module is
intended to be used with PMW payment methods only. Payment
methods with an IDoc payment medium format are not routed
through BCM.

Advanced Payment Management enables the payments generated

in SAP modules, such as FI-CA, to run through the BCM module.
The Advanced Payment Management module accepts IDocs as an

212
7A P M

input and converts the payments into an internal format that can be
integrated with the BCM module for approvals and payment status
reporting.

BCM and payments from the FI-CA module

For more information on this, see SAP Note

1577912—–“FAQ: BCM”—which states that
payments generated in FI-CA cannot be used with
BCM (transaction FPY1).

Advanced Payment Management has the ability to convert files from

SAP and non-SAP systems to a more standardized format such as
ISO 20022 XML payment files.

Advanced Payment Management enables users to perform

validations and make changes to payments if required. However, if
the source system is an SAP system, we believe that fixing the issue
at the source may be a better solution than changing the payment
information in Advanced Payment Management.

Payment files generated on third party systems, such as payroll

payments, can be passed through Advanced Payment
Management, even if there is no need to change the payment
details. Doing this enables SAP to be used as a centralized payment
hub for payment processing.

7.3 BCM Connector versus Advanced Payment Management

Both BCM Connector and Advanced Payment Management provide
functionality to import a payment file from a different source system
into a centralized SAP system.

213
7A P M

With BCM Connector, SAP imports the payment file by creating a

BCM batch. BCM Connector is not integrated with the Cash
Management module; therefore, there needs to be a manual
process to update the cash position for the payment file, if
integration with Cash Management is required. This integration is
available in Advanced Payment Management.

Advanced Payment Management is also integrated with Bank

Account Management, the general ledger, Bank Communication
Management, and SAP Multi-Bank Connectivity, and is therefore
able to provide a more comprehensive solution.

Whether to use the BCM Connector or Advanced Payment

Management depends on the company’s needs. For example, a
company on SAP S/4HANA with a large number of legacy systems
generating payment files should lean towards Advanced Payment
Management. But a company with few legacy systems generating
payment files might be better served with BCM Connector.

The decision to use Advanced Payment Management also depends

on the routing, validation, and payment transformation requirements.

Another important factor to consider is the company’s SAP release

level. BCM Connector is available with a BCM license from ECC 6.0
Enhancement Package 4 or higher, while Advanced Payment
Management requires a separate license and is available from SAP
S/4HANA 1809 FPS2 or higher.

7.4 Key benefits of Advanced Payment Management

The key benefits of using Advanced Payment Management are:

The ability to accept files from SAP and non-SAP systems in

various formats
The ability to handle high volumes of transactions

214
7A P M

The ability to convert payments from one format to another

Validation and enrichment of payment data
Payment routing based on business defined rules
The ability to screen payments through Governance, Risk, and
Compliance tools
Integration with other SAP payment modules

7.5 Summary
In this chapter, we introduced the Advanced Payment Management
module that can be used to further streamline payment processing
in SAP. We also provided a brief comparison of Advanced Payment
Management and BCM Connector, that can help users determine
the right tool for their needs.

215
8O

8 Other useful information

In this chapter, we cover some useful information that can be
helpful when implementing SAP’s Bank Communication
Management module, and when using it in daily operations.

8.1 Cutover to production

From our implementation experience, we recommend going through
an entire payment lifecycle in production before executing live
payments. This is typically referred to as Payment Validation Testing
(PVT) or penny testing. The amount is then written off once testing is
completed. This production test helps to validate the following:

Payment batching
Workflow settings
Approval steps
Schedule jobs
Payment delivery to the bank
Acknowledgement receipt from the bank
Acknowledgement imports into SAP
Alert notifications

Some of these steps can be triggered manually for the first time to
confirm that all the mechanisms are in place and are working as
expected.

8.2 Definition of terms

Table 8.1 shows a definition of terms.

216
8O

Table 8.1: Definition of terms

8.3 BCM Fiori apps and transaction codes

Table 8.2 shows the BCM Fiori apps.

Fiori app App ID

Approve Bank Payments F0673
Monitor Payments F2388
Manage Payment Media F1868
Table 8.2: BCM Fiori apps

The BCM Fiori tiles are shown in Figure 8.1.

217
8O

Figure 8.1: BCM Fiori tiles

Table 8.3 shows the BCM application transaction codes.

Description Transaction code

Creation of Cross-Payment Run Payment Media FBPM1
Approve Bank Payments BNK_APP
Batch and payment monitor BNK_MONI
Payment status for batching process BNK_MONIP
Reset a Merge Run with Batches BNK_MERGE_RESET
Bank Statement Monitor FTE_BSM
Table 8.3: Application side transaction codes and apps

Table 8.4 shows the configuration BCM transaction codes. We

recommend using the IMG path.

Description Transaction code

Assign Release Object to Release Pro BNK_BNK_COM_REL01
Payment approval-First step BNK_BNK_INI_REL01
Editing Alert Categories ALRTCATDEF
Define default rule currency BNK_MSG_TYPE
Define paymedium creation options BNK_PAYMED_OPT
Rule customizing BNK_RUL_CUST
Global data BNK_RULE_CURR

218
8O

Table 8.4: Configuration transaction codes

8.4 Authorizations
There are two authorization objects used in BCM:

F_STAT_MON—controls authorizations in the Monitor

Payments app (BNK_MONI) and BNK_APP (Approve
Payments) that users are allowed to process or display.
F_STAT_USR—is used to assign signature user ID.

The Business Catalogs relevant to BCM are:

SAP_SFIN_BC_BANK_APPROVE
SAP_SFIN_BC_CM_MANAGER

The security role relevant to BCM is:

SAP_SFIN_BCM

8.5 BCM tables

Table 8.5 lists the main BCM tables.

219
8O

Table 8.5: BCM Tables

8.6 Relevant SAP Notes

Table 8.6 lists SAP Notes relevant to BCM.

Table 8.6: Relevant SAP Notes

220
8O

You have finished the book.

Sign up for our newsletter!

Stay up to date!

Sign up for our newsletter for updates on new SAP

book releases and exclusive discounts.

Please visit us at newsletter.espresso-tutorials.com to find out

more.

221
AT A

A The Authors

Mary Loughran has been specializing in the SAP Financials area

since 1997 and has worked with numerous clients throughout North
America and Europe in the areas of finance and treasury. Mary’s
expertise is in SAP’s Treasury and Risk Management, In-House
Cash, Liquidity Planning, Accounts Payable, payments from SAP in
general, Cash Management, and Electronic Banking.

222
AT A

Praveen Gupta has been specializing in the SAP Financials area

since 2005 and has worked on numerous projects in the areas of
finance, treasury, banking and product management. Praveen’s
expertise is in SAP’s Treasury and Risk Management, Accounts
Payable, Electronic Banking, Cash Management, In-House Cash,
Payments, Bank Communication Management, and SWIFT.

223
BD

B Disclaimer
This publication contains references to the products of SAP AG.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP

BusinessObjects Explorer, StreamWork, and other SAP products
and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP AG in Germany and
other countries.

Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered
trademarks of Business Objects Software Ltd. Business Objects is
an SAP company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL

Anywhere, and other Sybase products and services mentioned
herein as well as their respective logos are trademarks or registered
trademarks of Sybase, Inc. Sybase is an SAP company.

SAP AG is neither the author nor the publisher of this publication

and is not responsible for its content. SAP Group shall not be liable
for errors or omissions with respect to the materials. The only
warranties for SAP Group products and services are those that are
set forth in the express warranty statements accompanying such
products and services, if any. Nothing herein should be construed as
constituting an additional warranty.

224
M E T B

More Espresso Tutorials

eBooks
Mary Loughran und Lennart Ullman:
Guide to SAP® In-House Cash (ICH)

SAP payment management fundamentals and tools

In-House Cash and In-House Bank functionality
scenarios
Useful transaction codes and reports
Tips and tricks for resolving common errors

Mary Loughran, Praveen Gupta:

Cash Management in SAP® S/4HANA

Principle areas of Cash Management powered by

S/4HANA
Comparison between ECC and SAP S/4HANA
functionality, including an overview of release 1809
Deployment options and implementation steps
SAP Cash Management implementation tips and tricks

Oona Flanagan:
A Practical Guide to SAP® S/4HANA Financial
Accounting

Financial accounting processes in SAP S/4HANA

225
M E T B

Finance organizational structure, key financial master

data
Daily transactions using SAP Fiori apps
SAP Fiori apps for displaying and reporting financial
data

Oona Flanagan:
Delta from SAP ERP Financials to SAP® S/4HANA
Finance

Key changes to financial accounting and structure in

SAP S/4HANA Finance
New general ledger structure in the universal journal
Master data changes in G/L accounts and the business
partner
SAP S/4HANA preparation and migration tools

Kees van Westerop:

New Fixed Asset Accounting in SAP® S/4HANA

Describes SAP Fixed Asset Accounting functionality in

SAP S/4HANA with SAP Fiori examples
Explores the complete lifecycle of an asset in SAP
Identifies differences between classic Fixed Asset
Accounting and the new SAP S/4HANA Fixed Asset
Accounting
Examines how Fixed Asset Accounting is integrated
with other SAP modules

226
M E T B

Maddie Mallenspach:
First Steps in SAP® S/4HANA Financial Accounting

Explore Financial Accounting in SAP S/4HANA

Delve into key SAP Fiori applications
Look at master data, flexible hierarchies, the universal
journal, and reporting tools
Learn how to tailor the user experience in SAP Fiori

227
M E T B

228
M E T B

229