Introducing Treasury and Risk Management TRM with SAP S4HANA __ Copy j3i6-csr2-wdum-gx4v

Prévia do material em texto

Introducing Treasury and 
Risk Management (TRM) 
with SAP S/4HANA®
SAP PRESS E-Bites
Arjun Krishnan
This E-Bite is protected by copyright. It contains a digital watermark, a signature that indicates
which person may use this copy. Full Legal Notes and Notes on Usage can be found at the end of
this publication.
Arjun Krishnan
Introducing Treasury and 
Risk Management (TRM) 
with SAP S/4HANA®
Copy No. j3i6-csr2-wdum-gx4v
for personal use of
Jennifer Ogbonna
jennyogbonna2@gmail.com
SAP PRESS E-Bites
SAP PRESS E-Bites provide you with a high-quality response to your specific project need. If you’re
looking for detailed instructions on a specific task; or if you need to become familiar with a small,
but crucial sub-component of an SAP product; or if you want to understand all the hype around
product xyz: SAP PRESS E-Bites have you covered. Authored by the top professionals in the SAP uni-
verse, E-Bites provide the excellence you know from SAP PRESS, in a digestible electronic format,
delivered (and consumed) in a fraction of the time!
Marcelo Trein
Introducing Central Payments with Central Finance and SAP S/4HANA
www.sap-press.com/5280 | $24.99 | 72 pages
Satyanarayana Rao Karri
Introducing Accruals Management with SAP S/4HANA
www.sap-press.com/5237 | $24.99 | 61 pages
Brijesh Singh, Santosh Kumar
Introducing Intercompany Matching and Reconciliation (ICMR) with SAP S/4HANA
www.sap-press.com/5247 | $24.99 | 86 pages
The Author of this E-Bite
Arjun Krishnan is a platinum-level SAP treasury professional and a certified
SAP S/4HANA financials expert. He has more than 24 years of experience with
working with Fortune 5 to 500+ companies and helping to transform their
treasury management systems, most recently on SAP S/4HANA. As a treasury
expert, Arjun has extensive experience in global SAP deployments, including
phasing strategy, migration, and integration of legacy TRM systems with SAP;
treasury and finance project management; and treasury and finance business
processes and best practices.
http://www.sap-press.com/e-bites
http://www.sap-press.com/5280
http://www.sap-press.com/5237
http://www.sap-press.com/5247
4
 
What You’ll Learn
Get your first good look at treasury and risk management in the new suite! Under-
stand your treasury data, and then explore key TRM areas such as transaction man-
agement, financial risk management, bank relationship management, and more. Dis-
cover SAP S/4HANA analyzers for market risk and credit risk. See what internal and
external integration possibilities await with TRM in SAP S/4HANA!
1 Treasury Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Treasury Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Treasury and Risk Management with SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Treasury Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Transaction Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Market Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Treasury Data Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Transaction Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Transaction Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Treasury Instruments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Payment Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5 Reporting and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4 Financial Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.1 Exposure Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2 Hedge Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3 Trading Platform Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.4 Hedge Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5 Hedge Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Analyzers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.1 Market Risk Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2 Credit Risk Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3 Portfolio Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4 Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6 Bank Relationship Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.1 Bank Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2 Bank Communication Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
1 Treasury Basics
5
6.3 Bank Statement Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.4 Foreign Bank and Financial Accounts Reporting . . . . . . . . . . . . . . . . . . . . . . . . 92
7 Cash and Liquidity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.1 Cash Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.2 Liquidity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.3 In-House Banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.1 Integration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.2 Integration Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
9 What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
 
1 Treasury Basics
We begin our journey into the exciting and dynamic world of treasury by under-
standing treasury transaction management and financial risk management’s key
functions and business drivers in Section 1.1. In Section 1.2, we’ll explore how SAP’s
solution for treasury and risk management works and how it meets the needs of a
treasury organization. We’ll also look at its evolution, how we got to where we are
today, and how SAP continues to improve its treasury management system offeringin an increasingly digitalized world.
1.1 Treasury Management
The typical treasury day starts early in the morning before the banks and capital mar-
kets open for the day. Market data and bank statements need to be received and
updated in the treasury system. Bank balances need to be reviewed, and daily cash
positioning for investing and daily borrowing needs have to be ascertained.
As the day progresses, prior day and intraday bank statements will start coming in.
Activities around cash concentration, wire transfers, check clearing, incoming lock-
box, and other receipts need to be monitored. Payments and intercompany transac-
tions need to be executed, and cash flow reports must be updated and monitored.
Investment and borrowing requirements as well as foreign exchange (FX) and hedg-
ing activities need to be planned for execution before market and bank cutoff times.
Trading activities and payments need to be approved, executed, confirmed, and
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
1 Treasury Basics
6
counter-confirmed by participating banks, counterparties, and other trading part-
ners.
Essentially, treasury business processes revolve around these activities, resulting in
transaction management of various products or instruments that are used to man-
age financial assets and liabilities. These include mitigating financial risk through
hedging using derivatives, and managing the cash and liquidity needs of the busi-
ness. They also take the form of FX trades; investment or borrowing of money market
instruments; securities issuance or purchase; trade finance activities, such as issuing
or receiving letters of credit or bank guarantees and surety bonds; and the use of
credit facilities, to name a few.
Treasury transactional activities will result in payment as well as incoming cash
flows. And the financial transactions need to be accounted for and reconciled. A trea-
sury management system (TMS) manages all payment activity and is fully integrated
with accounting and with external counterparties who transact with treasury. Mes-
sages for trade confirmation, payment confirmation, and other information are sent
and received, as is market data from data providers that is critical to treasury busi-
ness operations. The financial supply chain is complete with the receipt of incoming
electronic bank statements to allow for intraday cash positioning, or prior day state-
ments that will update balances, post transactions, and enable reconciliation in the
book of prime record to complete the cycle. All the information available in the sys-
tem is now available to report upon and forms the basis of cash positioning and
medium-to-longer term liquidity forecasting, enabling decisions around cash pool-
ing, cash concentration, bank-to-bank transfers, and intercompany transfers and set-
tlement.
Treasury usually operates in a high-value low-volume transactional environment,
and it’s imperative that sound controls are in place to prevent conflict of interest,
errors of omission or commission, and fraud. A TMS has extensive systemic as well as
process, security, and access controls to ensure compliance with regulatory require-
ments, and in alignment with sound internal control principles and best business
practices. This is achieved through workflow for approvals, alerts, and exception
reporting; segregation of duties (SoD) between functions using security access
through roles; audit trail and change logs for all transactional activity; and built-in
checks and balances such as online limit management.
A TMS uses standard reports, dashboards, analytical tools, and monitors to assist
treasury practitioners in carrying out their functions efficiently, effectively, and in
line with the goals and objectives specified by the organization for the treasury
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
1 Treasury Basics
7
function. With increasing automation and straight-through processing in treasury
operational processes, treasury managers can focus on exception-based action and
high value-added treasury activities.
1.2 Treasury and Risk Management with SAP
SAP’s own TMS—treasury and risk management (TRM) with SAP S/4HANA—is an
integrated solution that forms part its enterprise resource planning (ERP) software
and offers the ability to manage all of an organization’s operations and functions on
one system. Probably the single, most important factor that has led to it becoming
the system of choice for many organizations, especially ones with global operations,
can be summed up in one word: integration.
In keeping with the key concept of the SAP system as a single source of truth, TRM
with SAP S/4HANA is very tightly integrated with the other modules, especially the
finance general ledger. TRM with SAP S/4HANA is a subledger and feeds automatically
into the finance general ledger, the book of prime record. This process is finalized and
configured during implementation, so accounting entries are fully automated and
take place as part of the daily, period-end, and year-end close processes.
Although it’s important to recognize that most of the core treasury functionality was
available in the pre-SAP S/4HANA versions, SAP continues to add to its treasury func-
tionality—development that is facilitated by SAP S/4HANA’s new architecture.
Note
SAP’s latest ERP system is SAP S/4HANA. Pre-SAP S/4HANA versions of SAP are referred to
as SAP ERP in this E-Bite.
Core Functionality
At its core, any TMS is composed of the two key treasury functions: financial risk
management, and cash and liquidity management. All integration and functional-
ities are built around them.
In SAP landscapes, the SAP S/4HANA subnodes that support financial risk manage-
ment and cash and liquidity management are the Transaction Manager, Bank
Account Management, risk analyzers (Market Risk Analyzer, Credit Risk Analyzer,
and Portfolio Analyzer), and the Bank Communication Management, Advanced Pay-
ment Management, and In-House Cash submodules.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
1 Treasury Basics
8
Figure 1.1 shows the structure of TRM with SAP S/4HANA and how it integrates inter-
nally with the rest of SAP as well as with the external environment. We’ll cover each
of the components in subsequent sections and understand how they fit and work
together.
Figure 1.1 Integrated Treasury and Risk Management with SAP S/4HANA
Within these submodules, a variety of payment engines, analytical tools, dashboards,
and reporting functionality ensure that treasury operations, control, and monitoring
can be carried out on a daily basis. The submodules integrate with each other, inter-
nally with other modules, and with the external environment depending on the
needs of the business (e.g., market data providers, frontend trading platforms, and
counterparties such as banks and payment networks).
SAP S/4HANA has added new functionality for reporting, advanced analytics, inte-
grated planning, and trade finance—and it has enhanced existing functionality in,
for example, hedge management, exposure management, and cash and liquidity
management. A much-improved user interface (UI) and reporting tools have
replaced the rather clunky and bland UIs of earlier SAP ERP versions.
Structure and Application Menu
Treasury-related modules fall under the main Accounting node in the SAP S/4HANA
application menu, and further under the Financial Supply Chain Management sub-
node shown in Figure 1.2. The key treasury and treasury-related subsets are Cash and
Liquidity Management, In-House Cash, Bank Communication Management, and Trea-
sury and Risk Management.
Internal integration
Finance
Logistics
Supply chain
External integration
Trading platforms
Payment networks
Trade confirmation
Bank data
Financial market
data providers
Market data 
External business
partners
Internal business
partners 
Transaction
management 
Accountingand reporting
Analyzers
Market risk, credit risk, and portfolio risk
Bank
relationship
management
Cash and
liquidity
management
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
1 Treasury Basics
9
Figure 1.2 Treasury Functions in the Application Menu
Note
Although they are part of the financial supply chain management (FSCM) suite, the credit
management, SAP Biller Direct, collections management, and dispute management func-
tionalities are more related to collections and accounts receivable. Consequently, they are
typically a separate implementation from the main TRM project. Although they can be
implemented together as part of a broader project or separately in subsequent phases, it’s
important to note that they are a distinct and separate group of functional modules.
A new submodule for bank account management has been introduced with SAP
S/4HANA, which is only accessible through the portal-based SAP Fiori dashboard.
Prior to SAP S/4HANA, house banks and their related bank accounts were set up
through configuration, and used by the finance and treasury modules for banking
activity. In SAP S/4HANA, bank data is classified as master data, and it can be entered
and maintained by users with access to the Bank Account Management module.
This is a mandatory module for any finance or treasury implementation on SAP
S/4HANA, as both of these modules need to access bank data. We’ll look at Bank
Account Management in further detail in Section 6.1.
Of the treasury-related modules, In-House Cash and Bank Communication Manage-
ment can be implemented subsequent to and independent of a TRM implementa-
tion.
As shown in Figure 1.3, the Treasury and Risk Management node can be further
expanded to provide access to master data, market data, transaction management,
exposure management, hedge management, and analytical tools. These subnodes
can be further expanded to provide specific functionality. For example, the expanded
Transaction Manager node provides access to specific areas of treasury operations
such as foreign exchange, money market, securities, trade finance, and so on. These,
in turn, expand to context-specific actions under trading, back office, accounting,
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
1 Treasury Basics
10
and so on. For example, Figure 1.3 shows the menu options under the Foreign
Exchange subnode to create and edit various types of FX instrument spots, forwards,
swaps, and so on. We’ll look at these options by financial instrument in greater detail
in Section 3.
Figure 1.3 Treasury and Risk Management Subnode and the Foreign Exchange Subnode
Treasury functions can be accessed through SAP transaction codes that are linked to
reports, programs, and function modules in the backend of the system. An example
of a transaction code in shown in Figure 1.3, where clicking on Transaction FTR_
CREATE takes you to the initial screen for input of an FX contract.
These transaction codes and the resulting screens can be executed in two ways:
through standard SAP Graphical User Interface (GUI) directly in the system or
through the newer SAP Fiori launchpad. SAP Fiori launchpad contains specific tiles
that link back to the underlying transaction code; clicking on an individual tile will
bring you to the specific input screen or report. A sample of the dashboard is shown
in Figure 1.4. You’ll see examples of context-specific SAP Fiori tiles and dashboards in
subsequent sections. Increasingly, SAP is moving toward SAP Fiori–only access for
many functions and reports.
Tip
SAP Fiori is SAP’s web-based UI to access functionality in SAP S/4HANA. SAP is increasingly
moving to this form of access, and it has been adding new SAP Fiori tiles with every release
and upgrade of SAP S/4HANA. In some instances, such as bank account management,
access is available only through SAP Fiori launchpad.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
1 Treasury Basics
11
Figure 1.4 SAP Fiori Launchpad and Tile Menu
Evolution of Treasury with SAP
Before we delve into the specifics of SAP S/4HANA, it’s informative to look at the evo-
lution of SAP’s ERP-based TMS from the 1990s, and how we got to where we are today
in 2021.
The advent of enterprise resource planning (ERP) systems in the last decade of the
20th century was more about replacing aging multiple legacy systems, addressing
the Y2K issue, and integrating finance and accounting with other business functions,
such as sales, manufacturing, and logistics. Treasury was definitely not a priority in
this time, at least as far as enterprise system vendors such as SAP were concerned.
Although treasury management systems provided some basic functionality, they
were clunky bolt-ons, seemingly an afterthought to the broader ERP system. Treasury
managers weren’t too concerned about being bypassed in the first big wave of SAP
ERP implementations: standalone systems such as SunGard’s Quantum, Wall Street
Systems, and a host of other excellent software products were built specifically for
treasury applications and offered all the functionality managers required, allowing
treasury personnel not to worry about costly complex ERP implementations affect-
ing their function. (To be sure, the many pioneering companies that did take a leap of
faith and become early implementers of SAP TRM enabled the product to evolve and
improve.)
The first decade of the new millennium saw two developments that would drastically
change treasury’s integration into the world of enterprise-wide systems, especially
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
1 Treasury Basics
12
SAP. First, software vendors such as SAP recognized the increasing importance of the
treasury function, as the world seesawed through many financial and cash crises
between 2001 and 2010. They started focusing on building native functionality for
treasury and financial risk management in their ERP systems, and on adding new and
improving functionality through their upgrade strategy. As a result, the gap between
ERP treasury functionality and standalone treasury systems functionality started
narrowing considerably, as the value proposition for ERP-based treasury manage-
ment systems started gaining momentum. As a result, 2000-2009 saw a great spurt
in ERP-based treasury systems implementations, as treasury organizations across
the world started integrating their operations into SAP. And SAP continued to add
key treasury functionality within a fully integrated systems environment.
Secondly, the early 2010s saw major innovations in systems architecture, processing
power, data processing, and analytics. For all the benefits of ERP systems, the prob-
lem that finance managers and SAP functional implementers encountered was that
SAP systems architecture had begun falling behind rapidly changing technology,
changing consumer expectations, and increasing customization for meeting com-
plex and dynamic changing business, regulatory, and local requirements. This was
especially true in highly specialized areas such as treasury. SAP saw the writing on the
wall and identified the need to completely re-architect its ERP platform and applica-
tions. Enter SAP S/4HANA!
SAP S/4HANA is SAP’s latest ERP software. It’s the successor to SAP’s R/3 and SAP ERP
legacy offerings, and offers a completely redesigned (and vastly improved) architec-
ture and set of tools and technologies built for the digital age. SAP S/4HANA software
and applications run atop SAP’s proprietary database, SAP HANA. The interest in and
demand for SAP S/4HANA is strong and on an upward trajectory. SAP is improving
existing functionality and adding new functionality rapidly, releasing new versions
with at least one on-premise version and multiple cloud version updates each year.
At the time of writing, SAP S/4HANA 2020 is the latest on-premise version, released
in October 2020.
The period from 2010 onward saw four majortechnological advances that brought us
to where we are today.
� Rapid improvements have occurred in processing power using commodity serv-
ers, parallel processing, and new architectures. It’s now possible to process massive
amounts of data in real time at a fraction of the previous cost.
� The rise of big data and advanced analytics meant huge amounts of structured,
semistructured, and unstructured data available to companies through social
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
1 Treasury Basics
13
media and external and internal sources that could now be mined to provide real-
time predictive and prescriptive intelligence in the area of consumer behavior,
marketing, and, increasingly, finance. The storage of an organization’s historical
and current data in a single virtual database allows all the tools that harness big
data to be applied to corporate data.
� Business users now expect the same experience when accessing enterprise data as
they get when they interact with consumer-based applications on a daily basis on
the Internet.
� The advent of cloud-based computing has allowed a cost-effective alternative for
organizations. This is particularly noticeable with respect to ERP system deploy-
ment options from on-premise traditional licensing, to less-expensive and lower
maintenance private or public subscription-based cloud implementation, to a
hybrid of the two. This will allow more medium-sized and small companies to
leverage the benefits of ERP systems; as total cost of ownership decreases, the value
proposition increases.
So, what’s different about SAP S/4HANA compared to previous legacy SAP versions?
Essentially, the new features revolve around speed; user experience (UX); real-time
access; embedded, advanced, and predictive analytical and machine learning capabil-
ities; increasing digitization; access through mobile devices; integration with the
Internet of Things (IoT); and multiple deployment options. The finance functionality
of SAP S/4HANA in particular has been redesigned to integrate financial and manage-
ment accounting data, with financial, managerial, asset, and material accounting
combined into a single table or line item for each accounting entry.
All this development bodes well for the treasury function, which is fully integrated
with the finance functionality and feeds into it as the book of prime record. In simpli-
fying the finance functionality architecture, the submodules—especially treasury—
greatly benefit from integration with the single source of truth, real-time access to all
historic data, and the ability to use internal and external data for advanced analytical
applications on an enterprise-wide basis.
It has enabled organizations to leverage the new technologies and architecture to
transition treasury practices from a record-and-report model to a predict-and-act
model, and to enable treasury’s truly dynamic function. The introduction of SAP
S/4HANA resolved many of the issues surrounding the legacy SAP ERP systems. It
positioned SAP’s ERP treasury systems to be truly dynamic and proactive, and to
leverage data and tools to provide real-time or near-time information. Advanced ana-
lytical capabilities enable treasury organizations to move from routine processing to
exception-based dynamic decision-making. Leveraging the preceding capabilities
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
2 Treasury Data
14
has allowed SAP to add functionality, for advanced analytical capabilities, machine
learning, predictive analytics, and fraud prevention. SAP also has provided new and
enhanced functionality in bank relationship management, trade finance, exposure
management, hedge management, and cash and liquidity management in subse-
quent SAP S/4HANA releases.
Now that we’ve established the baseline treasury functions and described the current
treasury solution, in the next section we’ll look at the structure and features of data
and how it’s used in SAP S/4HANA to enable the full suite of treasury functionality
available.
 
2 Treasury Data
In a data-driven ERP system such as SAP S/4HANA, where the same data is now avail-
able to all users across the enterprise regardless of geographical location, the controls
over and access to data take on special importance. We’ll look at the different types of
data used to conduct treasury operations, starting with master data in Section 2.1 and
transactional data in Section 2.2, and understand how they are used in transaction
processing with specific examples of the more important types of data and their sig-
nificance. Additionally, in Section 2.3, we’ll cover market data, which could be a com-
bination of master data and transactional data, but is typically received from external
sources, for example, market data providers such as Bloomberg or Reuters.
SAP data falls into two main categories: system-relevant data and application-relevant
data. System-relevant data is mostly technical, comes predelivered, and typically
should not be amended unless required or recommended by SAP. Application-relevant
data is typically used by applications such as treasury and, as shown in Figure 2.1, is cre-
ated within the system in two categories:
� Application data 
This data is used in the daily operations of the business after a system goes live.
� Configuration data 
This data is set up during implementation, based on the blueprint design for the
various treasury business processes, and is built and tested prior to going live. Typ-
ically, configuration data has the following features:
– Based on business requirements and defines application behavior
– Maintained as business needs change or are added post-go-live
– Created and moved between systems using transport management
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
2 Treasury Data
15
Figure 2.1 Data Types Used by Treasury
Application data in turn is composed of master data and transaction data. Let’s look
at those now.
2.1 Master Data
Together with configuration settings, master data drives transaction data. Master
data usually has a one-time setup with minimum maintenance, and it’s typically
available centrally for all applications that use it. For example, bank accounts can be
used by finance, treasury, accounts receivable, and accounts payable functionalities.
Although individually unique, master data can be high volume, for example, busi-
ness partners or bank accounts. Although inputs to treasury-related master data are
provided by treasury, they are usually created and maintained in the system by a
master data team that functions separate from treasury. This ensures good internal
control and SoD, especially with respect to the setup of business partners, banking,
and payment data.
SAP master data is created during implementation either through conversion of leg-
acy data or the creation of new data. After go-live, master data is added or maintained
directly in the productive system. In Section 2.4, we’ll look at some examples of trea-
sury master data in greater detail, such as business partners and securities class data.
SAP data 
System-
relevant data
Application-
relevant data
Application
data
Master data
Transaction
data
Configuration
data
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
2 Treasury Data
16
2.2 Transaction Data
Transaction data is created in the normal course of business, usually in high volumes.
It draws upon master data, market data, and configuration data as required in the
execution of daily and periodic transaction processing.
A distinction needs to be made here between application master data and configura-
tion data. Configuration data is set up one time as part of the TMS implementation by
consultants based on the blueprint as part of the project’s design and build phase
prior to going live with the system. Master data is also converted or created en masse
during the initial implementation,but it becomes maintainable by users after go-live
and doesn’t require access to configuration.
Note
Configuration access is typically tightly controlled and limited to authorized technical or
functional experts, and configuration additions or changes are migrated to the production
system through strict transport protocols. Master data is typically maintained by autho-
rized user groups, and after going live, it’s maintained directly in the production system,
providing greater flexibility to the business.
In SAP S/4HANA, some frequently used configuration data, such as house bank
accounts data, is now maintainable as master data through SAP Fiori launchpad. This
trend is likely to continue because it allows flexibility while ensuring adequate con-
trols over creation and maintenance through approval workflows and systemic con-
trols. This is particularly important for time-sensitive master data such as business
partners and bank accounts that drive payment processing.
2.3 Market Data
Market data is key to the routine processing requirements of a dynamic treasury
organization. Market data typically comprises FX rates, forward exchange rates or
swap rates, FX and interest rate volatilities, reference interest rates, commodity
prices, and so on. These can be loaded on a daily or periodic basis depending on the
valuation and operational needs of the business. FX rates are also used by finance for
period-end accounting purposes. These can be differentiated from accounting-
related rates through exchange rate type (e.g., if a different rate type needs to be used
for treasury planning purposes).
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
2 Treasury Data
17
SAP Fiori launchpad, shown in Figure 2.2, gives a comprehensive view of the various
market data management functions that can be executed. These include the import
function for loading market data for an entire group (the Import Market Data app) or
individual classes such as FX rates (the Import Foreign Exchange Rates app) through
file upload. You can use the request function to load current or historical market data
through the automated data feed function using the Request Current Market Data
and Request Historical Market Data apps. Market data providers such as Bloomberg
or Reuters are connected to SAP S/4HANA through interfaces to provide this daily
data feed. You can also enter market data manually directly into the relevant tables
using the enter function; this can include FX rates (the Enter FX Spot Rates and Enter
FX Swap Rates apps), or volatilities (the Enter Exchange Rate Volatilities app). Most
daily processing is automated using batch programs, with reporting done on an
exception basis to ensure that all data expected to be received was received, and, if
not, to determine what errors or missing data were detected so that appropriate cor-
rective action can be taken.
Figure 2.2 SAP Fiori Launchpad for Market Data Management
2.4 Treasury Data Examples
Table 2.1 provides some examples of data used in treasury operational and transac-
tion processing. We’ll look at business partner and security class data in a little more
detail to illustrate some of the features and integration points between the different
data types in a TMS.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
2 Treasury Data
18
Business Partner
In SAP S/4HANA, the business partner is a key master data element and represents all
external and internal organizations with which a treasury department transacts busi-
ness. These could be external counterparties such as banks or brokers, or internal
subsidiaries that engage in intercompany transactional activity.
Data Description Origin Example
Product type Used to identify trea-
sury financial instru-
ments
Configuration FX, intercompany 
loan, fixed-term 
deposit
Transaction type Action related to prod-
uct type
Configuration Investment, borrow-
ing, spot, forward
Business partner External or internal 
counterparty
Master data Bank (external), sub-
sidiary company 
(internal)
Securities class 
(FWZZ)
Maintains all informa-
tion relating to an 
issued security or bond 
available under the 
Committee on Uni-
form Securities Identi-
fication Procedures 
(CUSIP) or Interna-
tional Securities 
Identification Number 
(ISIN)
Master data Corporate or govern-
ment securities, 
bonds
Repetitive code Code used in execut-
ing bank-to-bank 
transfers to identify a 
unique combination of 
sending and receiving 
bank account
Master data Can be freely defined 
or with specific nam-
ing convention in 
agreement with part-
ner banks
FX spot transaction FX spot instrument 
created in the Transac-
tion Manager
Transaction data Identified by transac-
tion number in the 
system
Bank account Internal and external 
bank accounts used by 
the organization
Master data Set up in bank 
account management 
under the specific 
house bank
Table 2.1 Treasury Data Examples
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
2 Treasury Data
19
A business partner is set up with different roles depending on what kind of transac-
tional business the business partner conducts with your organization. Typical trea-
sury roles are counterparty, depository bank, guarantor, vendor, customer, and so
on; many of these are shown in the dropdown menu of key roles in Figure 2.3.
Figure 2.3 Business Partner Roles
Business partners can be grouped by external (e.g., banks) or internal (e.g., subsidiar-
ies) classification. Business partners are created and assigned functional roles such as
counterparty or depository bank.
Each role has context-sensitive tabs and fields specific to that role that will require
input. For example, the counterparty role provides access to tabs for payment details
and authorizations for financial instruments that are set up by company code, thus
enabling each to have specific settings relevant to it.
As shown in Figure 2.4, payment details specific to the legal entity are entered in the
Payment Details tab; here you specify by currency paying bank account, recipient
bank account of the counterparty, and the payment method if a payment request is
to be created. When this counterparty and legal entity combination is used to create
a trade transaction, these details default into the Transaction Manager as shown in
Figure 2.5.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
2 Treasury Data
20
Figure 2.4 Counterparty Payment Details
Figure 2.5 Counterparty Payment Details Default into Transaction Management
As shown in Figure 2.6, bank accounts can be authorized for specific instrument
types, giving treasury practitioners greater control over payments. Such authoriza-
tions can be specified down to the individual product type if necessary, as well as by
incoming and outgoing payments.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
2 Treasury Data
21
Figure 2.6 Paying Bank Accounts Assigned to Financial Instruments
Securities Class
Another example of how master data is used in conjunction with transactional data
is the creation of class data in the Securities module (covered in further detail in Sec-
tion 3.2). Here you can enter all constant information relating to say, a debt issue; this
data might include CUSIP or ISIN, nominal value, coupon rate, call notice periods,
premium or discount on issue, and so on. This information is called when individual
tranches are issued or redeemed and recorded in transaction management; it’s used
to calculate cash flows, interest payable, amortization of premium/discount, and so
on. Positions are managed and reported on based on the class identifier (ID number).
Figure 2.7 shows the basic standing data that can be added as part of class data, such as
details of issuer, currency, nominal value, start and end dates, and so on.
Figure 2.7 Securities Class Data
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com3 Transaction Management
22
In the next section, we’ll look at the treasury functionality available for transaction
management. In SAP S/4HANA, the Transaction Manager lies at the heart of treasury
practices.
 
3 Transaction Management
In this section, we’ll look at the Transaction Manager and all its related functionality.
In Section 3.1, we’ll follow the end-to-end processing of a typical treasury transaction
from creation to termination, and we’ll look at related functions of trade confirma-
tion, trade approvals, and netting of transactions. In Section 3.2, we’ll look at the fea-
tures of specific financial instruments that can be processed through the Transaction
Manager. Section 3.3 addresses the various aspects of payment management and
available functionality. In Section 3.4, we’ll review the accounting, valuation, and
period-end processes that need to be completed for statutory and regulatory pur-
poses. We’ll end in Section 3.5 with examples of tools and reports that are used to
report and monitor activities within the Transaction Manager.
3.1 Transaction Manager
The Transaction Manager is where all transaction processing takes place. It supports a
wide variety of treasury instruments such as foreign exchange, money market, secu-
rities, debt management, commodities, trade finance, and derivatives.
Treasury processes are generally split among front office (where trading takes place),
middle office (where trade confirmation, settlement, approval, and payments take
place), and back office (where accounting, valuation, and reconciliation take place).
The split allows the correct SoD between key treasury functions to ensure proper con-
trols and governance. Access to these functions is controlled by assigning specific
roles that are tied to transaction codes. These codes are what allow the functions to be
executed. These roles are then assigned to authorized treasury users, keeping in
mind SoD between the various functions. Because corporate treasury departments
tend to be fairly small, when designing and assigning roles, it’s important to main-
tain the correct balance between good internal control and operational flexibility to
run the business. Standard and custom workflow is available within the Transaction
Manager to enable approval of transactions created by the front office.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
23
Let’s walk through the end-to-end process in treasury transaction management as
the transaction flows from the front office to the back office, and then on to payment
processing.
Processing
As shown in Figure 3.1, the process of creating a contract in the Transaction Manager
starts with accessing the initial screen and entering the transaction details. After the
contract has been created, any subsequent changes or actions will be made through
an edit/change transaction. A workflow can be triggered so that an authorized person
other than the one creating it must approve the trade. An approver can also reject the
deal, in which case, the approver sends the deal back through the workflow with the
reason for the rejection so it can be corrected and resubmitted. Otherwise, it will
lapse.
After the deal is approved and saved in the system, it needs to be confirmed by the
contracting counterparty. This is called trade confirmation and involves the match-
ing of Society for Worldwide Interbank Financial Telecommunication (SWIFT) confir-
mation and counter-confirmation messages (message type [MT] format) sent and
received through the SWIFT network. In TRM with SAP S/4HANA, the SWIFT MT mes-
sage can be automatically triggered when the trade is approved in the system. Any
change to the originally approved trade contract terms can be set up to trigger the
workflow approval process again and to generate another confirmation message for
counter confirmation.
Figure 3.1 Trade Processing in the Transaction Manager
Master data
group
Treasury
front office
Treasury
back office
Start
Create and
edit deal
Change deal
Reverse
deal
Create and maintain
business partner
Yes
No
End
Counterparty
confirmation
Counterparty
matched?
No
Yes
Accounting
Settle
deal
Payment
processing
Approve
deal?
Change
or reverse?
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
24
One important point to note is that in SAP S/4HANA, there is a settlement process
prior to payment. This settlement needs to take place before cash flow accounting
entries can be posted. This sets up the trade for the payment process. In the context
of the front office, settlement is an intermediary step to allow for the transaction to
be approved and authorized before further processing can occur. (Note that approval
workflow is an optional control that has to be configured to be activated but is
strongly recommended as part of the process design.)
After the deal is confirmed and counter-confirmed, settlement within SAP can take
place, which in turn will enable processing of subsequent steps in the trade’s life cycle
to occur on the due dates. Let’s look at these steps in Figure 3.2.
Figure 3.2 Trade Payment Processing in the Transaction Manager
If a payment is required, a payment request will be generated and executed through
a payment run using treasury payment Transaction F111. If the Bank Communication
Management module is active (more about this in Section 6.2), then payment runs
can be batched, additional approvals obtained, and a payment file created to be sent
to the bank. Acknowledgment messages are received back from the bank. The status
of payments can be monitored through the bank payments monitor dashboard,
which will be updated as the payment moves through to settlement. After the pay-
ment is cleared through the banking system, the bank will send a prior day bank
statement reflecting the payment; this will be uploaded and reconciled in the system
to complete the cycle. The status of incoming bank statements can be monitored
using the bank statement monitor. (The payment monitor and bank statement mon-
itor are discussed further in Section 6.)
Back office:
payment
creation
Create payment
request 
Execute treasury
payment run
Accounting
Debit payment request clearing
Credit bank clearing
From trade
processing
Back office:
bank
communication
manager 
Create
batches
Approval
workflow
triggered
Batch approval
required?
Yes
Approved?
Correct
and
resubmit
Payment file
created and
sent to bank
No
End
Accounting
Debit bank clearing
Credit main bankBank executes
payments
and sends
ACK/NACKs
and bank
statements 
Payment and
bank monitors
updated
Prior day bank
statements
uploaded and
reconciled
MBC,
SWIFT, EBICS
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
25
The Transaction Manager’s menu structure and input screens follow a standard nav-
igation schema regardless of the type of instrument. The fields available for input are
context sensitive, however, and will change depending on the instrument or process-
ing function. Transactional information is entered on the Structure, Administration,
Other Flows, Payment Details, Cash Flow, Memos, Status, and a few other tabs. If Hedge
Management is activated, an additional Hedge Management tab is available (covered
in further detail in Section 4.2).
Figure 3.3 shows the initial input screen for creating a trade transaction. This screen is
common to all financial instruments and provides the key input elements of legal
entity (company code), product type (financial instrument), transaction type (nature
of the transaction), and business partner (counterparty), all of which are mandatory
fields (marked with a red asterisk) for input, at a minimum.
Figure 3.3 Initial Entry Screen for Creating a Transaction
Figure 3.4 provides an example of the Structure tab using an FX spot/forward as an
example. It shows input fields relevant to an FX contract andprovides information
on the current spot rate (vs. the contract rate). Threshold limits on amounts entered
can be set with a warning message or hard stop if exceeded. Traders can be authorized
to trade with limits in place. Unauthorized traders won’t be able to create a trade.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
26
Figure 3.4 The Structure Tab for FX Spot/Forward
The Administration tab contains input fields that drive accounting, reporting, and
integration points with other modules such as project and management accounting.
Table 3.1 describes some of the key fields available as shown in Figure 3.5 (upper
screen) and Figure 3.6 (lower screen).
A custom tab can also be added with a user-specified list of fields that can be set up for
input.
Field Function
Portfolio Used to classify assets and liabilities for reporting 
purposes, but can also be used to differentiate 
accounting postings, depending on the portfolio 
selected from a dropdown list
Gen. VAln Class (general valuation class) Preconfigured balance sheet classification that is 
set to default value depending on the type of 
asset or liability
Hdg Classific. (hedge classification) Relevant to hedge management and will be dis-
cussed in Section 4 on financial risk management
Assignment, Internal Reference, 
Characteristics
Freely definable fields for input by user
WBS Element, Profit Center, 
Business Area
Integration points with project, managerial 
accounting, and other organizational structures
Table 3.1 Administration Fields
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
27
Figure 3.5 The Administration Tab (I)
Figure 3.6 The Administration Tab (II)
The Other Flows tab shown in Figure 3.7 allows manual input of any one time or non-
recurring charges such as fees where such expense isn’t captured automatically in
the cash flow based on inputs in the Structure tab.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
28
Figure 3.7 The Other Flows Tab
The Payment Details tab in Figure 3.8 shows the banking and payment details
defaulted from the counterparty settings in master data.
Figure 3.8 The Payment Details Tab
The Cash Flow tab shown in Figure 3.9 provides cash flows for the entire life of the
contract and value dates when cash flows are due or receivable.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
29
Figure 3.9 The Cash Flow Tab
In this example, on 11/10/2020, the payment for FX charges is due, and when the post
cash flows transaction is run on 11/10/2020, a payment request for that amount will
be created for further processing. The actual trade will settle on 11/12/2020 because
it’s a spot transaction created on 11/10/2020 with a two-day settlement period, and
payment requests will be created for these flows on 11/12/2020. These flows will also
update the cash and liquidity forecasts, as discussed in Section 7.
The Memos tab shown in Figure 3.10 allows you to maintain free-form notes and
attachments relating to the transaction. In this example, the treasury practitioner
has left a note about the trade terms.
As a transaction progresses through the various steps in the financial supply chain,
the Status tab provides an overview of the processing status with respect to activity,
release, confirmation, and counter-confirmation. Figure 3.11 shows the status of the
transaction as an active contract (i.e., Release Not Required), date and time stamp of
creation, and user who created it. On settlement, the activity will move to Settled sta-
tus. In this example, the Activity 1 field shows it’s active and in Contract status. The
Correspondence section shows that trade confirmation and counter-confirmation is
required. And, under the Transaction section, the system indicates that release isn’t
required, meaning approval isn’t a prerequisite to settlement.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
30
Figure 3.10 The Memo Tab for Notes and Attachments
Figure 3.11 The Status Overview Tab
Figure 3.12 shows a different view of status by business process and what further
actions are or are not permitted. For example, some activities (e.g., change, confirm,
counter-confirm) are permitted and are shown with a green light; other activities
aren’t permitted and are shown with a red light.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
31
Figure 3.12 The Status Tab by Business Processes
After a trade transaction has been created, it’s processed further through the Edit
Financial Transaction screen shown in Figure 3.13. You can select a specific financial
instrument group to get context-sensitive selections for action. Editing here is done
at the individual transaction level by company code and transaction number.
Figure 3.13 Editing a Single Transaction
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
32
There are also input screens available for mass processing of transactions by range or
category, as shown in Figure 3.14. SAP S/4HANA offers a variety of selection criteria,
enabling large volumes of transactions to be processed simultaneously.
Figure 3.14 Processing Multiple Transactions
Correspondence
Trade confirmations triggered through the Transaction Manager and counter-con-
firmations received back from counterparties are managed through the corre-
spondence monitor. Mappings for SWIFT MT formats are predelivered for the
main confirmation types, but they can be modified per any bank’s specific require-
ment. Although many companies use web-based trade confirmation, SAP
S/4HANA leverages existing interfaces and connections with business partners
and automates the confirmation and matching process.
The Transaction Manager can be set up to trigger an outgoing SWIFT MT message as
soon as a trade is approved. The counter-confirmation is received back as an incom-
ing message that can be uploaded into the Correspondence Monitor and automati-
cally trigger settlement of the deal. If the match is confirmed, the accounting flows
can be posted and the payment request for payment processing can be generated on
the due dates. As shown in Figure 3.15, the Correspondence Monitor – Standard View
screen displays the results and status of various SWIFT confirmations. For example,
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
33
transaction number 4000000005917 shows that an email confirmation message in
PDF format was initiated internally, and an MT300 message file was sent to the con-
tracting counterparty (in this case, to Citibank).
Figure 3.15 Tracking SWIFT Confirmation Messages in the Correspondence Monitor
Workflow
The use of workflow in the approval process has always been an integral part of legacy
SAP systems. Prior to the arrival of SAP S/4HANA, workflows were configured by IT
experts specialized in workflow setup. SAP S/4HANA introduces the concept of a
flexible workflow based on preconfigured templates and scenarios that can be set up
and activated by the business user. The standard or classic workflow that predated
SAP S/4HANA is still available.
Workflow functionality is increasingly being used in many business processes within
SAP S/4HANA and particularly within treasury operations because treasury transac-
tions are typically high value, low volume, and require increased diligence, controls,
and approval processes before a payment can be processed and submitted to the
external world for settlement. In TRM with SAP S/4HANA, workflow functionality is
available for master data creation and update (business partner and Bank Account
Management), treasury trade approvals (the Transaction Manager), and payment
approvals (Advanced Payment Management, and Bank Communication Manage-
ment).
Netting and Linked Transactions
Transactionsthat are linked to each other are automatically referenced by the sys-
tem, depending on the type of underlying transaction. For example, an intercom-
pany loan set up with automatic mirroring will be linked through a reference cate-
gory mirror (MIR) transaction link. Transactions can also be linked manually through
netting or referencing.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
34
Note
Netting in this context is defined as the consolidation of multiple payments due to a coun-
terparty with the same legal entity, currency, and value date to reduce the number of pay-
ments made to the counterparty.
Figure 3.16 shows the various reference categories used by the system to link and ref-
erence transactions. The ones most commonly used in treasury are for netting, mir-
roring, general reference, FX swap, and offsetting transactions.
Figure 3.16 Reference Categories Linking Transactions
Figure 3.17 shows a netting proposal that combines a variety of transactions due to a
counterparty on a specific value date and currency, showing the net amount due.
When the payment request is run, SAP S/4HANA uses the netting information to pay
the net amount to the counterparty.
Figure 3.17 Netting Proposal with Net Amount Due to Counterparty on Value Date
An example of automatic linking is shown in Figure 3.18, where an FX spot back-to-
back contract between two subsidiaries is automatically linked as a mirror transac-
tion and can be viewed through the reference menu.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
35
Figure 3.18 Mirror Transactions Automatically Linked
3.2 Treasury Instruments
All supported treasury instruments are processed and recorded through the Trans-
action Manager and fully integrated with payment processing, accounting for the
resulting flows, and period-end closing activities.
The term product type is used to depict the various instruments that are supported in
the Transaction Manager. Product types are classified by the underlying purpose of
the instrument and fall under the following general product categories:
� Money market
� FX
� Securities
� Commodities
� Trade finance
� Derivatives
Specific market instruments or product types are set up under each of these major
product categories. Each product type is tied to transaction types that describe the
action you want to execute (e.g., investing or borrowing a money market instrument,
creating a spot or forward FX contract, or issuing/investing in debt securities). Prod-
uct types, transaction types, and related linkages are set up in configuration based on
the finalized and approved blueprint design during implementation.
Specific treasury market instruments (remember, these are product types) are sup-
ported under the main product categories. There are special categories called cash
flow and interest rate instruments that can be customized to reflect specific properties
and cash flows. A new product type called current account has been added in SAP
S/4HANA; it can reflect positive and negative balances to mimic a current account
that also has overdraft protection.
Let’s take a close look at the primary transaction product categories, starting with
money market.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
36
Money Market
Money market product types are interest rate–related instruments that can be used
to record investments and debt. These are recorded by legal entity and business part-
ner and then classified as an investment or debt through the transaction type. The
main instruments supported within the Money Market node in TRM with SAP
S/4HANA are as follows:
� Fixed-term deposit/borrowing
� Deposit at notice (fixed and variable rate)
� Commercial paper
� Bilateral and syndicated facility
� Current account style instrument
� Interest rate instrument
� Cash flow transaction
These product types can be used to provide a variety of financial instruments such as
money market mutual funds, term loans, intercompany loans, bank overdrafts, and
so on. A new product type called the current account style instrument has been intro-
duced in TRM with SAP S/4HANA; this type mimics the attributes of a current
account that can record credit as well as overdraft (debit) balances within the
account. Two special types of product types, cash flow and interest rate instrument,
can be customized to specific terms should any of the standard delivered instru-
ments not meet the requirements. This provides great flexibility in setting up finan-
cial instruments and ensures that they match exactly to the terms and cash flows
thereof.
The Structure tab provides all the fields necessary for creating money market instru-
ments that will enable it to calculate cash flows, value dates, interest flows, and fixing
dates for variable rates, as shown in Figure 3.19.
Additions and redemptions of capital can be updated in the Structure screen at any
time during the life of the instrument, and cash flows, interest calculations, and
future cash flows will be updated in the Cash Flow Analyzer app reports. In our exam-
ple in Figure 3.20, on 11/18/2020, there is an actual increase in the principal amount of
$200,000, and there are planned decreases or redemption of principal of $50,000 on
12/31/2020 and $150,000 on 02/28/2021. The Calculation Date column shows the
dates when interest calculations will be effective to take these principal inflows and
outflows into account and update cash flows accordingly.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
37
Figure 3.19 The Structure Tab for Money Market Instruments
Figure 3.20 Increasing or Decreasing Principal
Intercompany Loans
Intercompany loans are very common between group subsidiaries, especially global
corporations that conduct business in diverse geographical locations.
These can be set up using the Money Market node in TRM with SAP S/4HANA with
mirroring, so that only one side of the transaction needs to be entered, and a mirror
transaction will be automatically created. Additionally, if in-house banking is active,
the intercompany loan can be routed and managed through the in-house bank with-
out necessarily involving an external bank.
Figure 3.21 and Figure 3.22 show the two sides of the mirror transactions for an inter-
nal FX transaction executed between two subsidiaries within a group. The mirror
transaction created automatically flips the legal entity/business partner and the buy/
sell currencies but keeps all other inputs, such as contract dates and due dates, the
same. Cash flows will reflect the flipped currencies and equivalent amounts.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
38
Figure 3.21 Spot Transaction with Mirror (Buy)
Figure 3.22 Spot Transaction with Mirror (Sell)
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
39
Foreign Exchange
The Foreign Exchange node in TRM with SAP S/4HANA is used for making spot or for-
ward purchases or sales for operational or risk management requirements. FX trans-
actions are usually executed with an external counterparty but can also be traded
internally within a group of subsidiaries. Nondeliverable forwards, FX options, and
cross-currency swaps are also supported by SAP S/4HANA.
Derivatives
Derivatives are used by treasury practitioners primarily to hedge against financial
risk. These usually comprise FX forwards, FX or interest rate swaps, and a variety of
derivatives, such as calls, puts, floor, collar, equity, and exotic options. These can be
tied to underlying exposures (if they are identified and qualify for hedge accounting)
or can be natural standalone hedges. We’ll look at hedge management in further
detail in Section 4.2.
Figure 3.23 shows an example of the Structure tab for an interest rate swap; Figure 3.24shows the cash flows generated during its full duration.
Figure 3.23 The Structure Tab for Interest Rate Swap
As variable interest rates are set on the fix dates, the system is updated, and cash
flows are updated based on the new rate.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
40
Figure 3.24 Interest Rate Swap Cash Flows
Securities
The Securities module builds on the Money Market module and is meant specifically
for managing quoted investments and issued corporate debt, equity, and a variety of
other similar products. It offers specific functionality to manage complex and sophis-
ticated requirements with respect to cash flow and interest calculations, amortiza-
tion, premiums and discounts on issue, impairment of value, and corporate actions
(e.g., rights issues, call notices, etc.).
Recall from Section 2.4 that class data adds important standing data that is used to
manage securities positions.
Trade Finance
Trade Finance is a new module introduced with SAP S/4HANA that fills a long-awaited
gap for recording and processing bank guarantees, letters of credit, and standby letters
of credit, either issued to vendors or obtained from customers. It’s a separate product
category within the Transaction Manager, as it has special features for managing bank
and other guarantees such as surety bonds and similar off-balance sheet trade instru-
ments. Trade Finance includes the collateral and document management feature and
the presentation and payment feature in the event of exercising the guarantees. It’s
fully integrated with financial accounting, cash management, payment processing of
fees, workflow for approvals, SWIFT messaging for contract confirmation, and the
Credit Risk Analyzer for limit management. It integrates with the logistics modules to
tie guarantees back to a sale or a purchase transaction, or to a business partner that is
a vendor or customer.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
41
In addition to integration with logistics, presentation, and collateral management,
one of the important features within Trade Finance is that it can be linked to a facility
or revolver. Thus, if the guarantee issued is part of a credit facility, the facility will be
adjusted for any drawdowns or repayments, and the facility can be reinstated when
the guarantee lapses or is terminated. This linking can take place when the bank guar-
antee is created in the Transaction Manager and is tied to its related facility, which
should already exist in the system. In case of presentation or collateral requirements,
Trade Finance is fully integrated with payment processing, as well as for making pay-
ments for fees and other expenses on specific due dates or on a recurring basis.
The SAP Fiori tile menu in Figure 3.25 provides access to the main processes in trade
finance in one dashboard. SAP S/4HANA has SAP Fiori applications that include Cre-
ate Letter of Credit, Create Bank Guarantee, Process Trade Finance Transaction, and
Create Presentation.
Figure 3.25 SAP Fiori Apps for Trade Finance
In Figure 3.26, the Structure tab for an issued bank guarantee allows entry of key data
relating to issue detail and beneficiary detail that could be set up as a business part-
ner (either through the selection of a business partner that already exists in SAP
S/4HANA in the role issuer or guarantor, or through one entered manually), and can
also be linked to logistical information such as a related purchase order.
The Collateral tab shown in Figure 3.27 provides input for cash collateral details,
including payment amount and due dates. If the guarantee is tied to a credit facility,
then it can be linked to the facility in the Facility assignment field. After the link is cre-
ated, the credit facility is automatically reduced by the amount of the bank guarantee
and reinstated after the guarantee is released.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
42
Figure 3.26 The Structure Tab for Trade Finance
Figure 3.27 The Collateral Tab with Link to Facility
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
43
3.3 Payment Factory
Most treasury transactions result in payments to external counterparties, funding
transfers between internal banks or subsidiaries, and interest and dividend pay-
ments, to name a few. SAP S/4HANA has a robust payment platform and payment
engine that enables full payment processing functionality using a variety of inte-
grated submodules that are also fully integrated with general ledger accounting and
cash management.
The payment engine in SAP S/4HANA integrates all payment-related functions
within the treasury modules so that payments can be processed; payment files and
messages can be sent to the bank; and acknowledgments, incoming receipts, bank
statements and inbound messages can be received, uploaded, updated, posted, and
reconciled in the system. SAP S/4HANA supports all major payment formats
(National Automated Clearing House Association [NACHA], Fedwire, SWIFT, ISO
20022, and Electronic Banking Internet Communication Standard [EBICS]) and corre-
sponding acknowledgement messages that are sent back by counterparty banks.
Payment Formats
Although the SWIFT MT messages and other bank formats (e.g., Bank Administration
Institute [BAI]) are standard, many banks and counterparties require variants from
the standard formats due to their own system or local country requirements.
The Payment Medium Workbench (PMW) tool in SAP S/4HANA is available to create
custom formats or variations to standard formats. The PMW’s test mode allows prac-
titioners to see what the file will look like so they can match it exactly to the bank
requirement. This is a useful feature that eliminates time going back and forth with
the bank, getting the format validated and approved by them. The PMW and a bank
format created with test data is shown in Figure 3.28. The left window shows the input
to PMW, and the resultant output of the file in shown in the right window.
A similar tool is available to customize and adapt standard SWIFT MT messages, as
again, these tend to vary depending on country and counterparty.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
44
Figure 3.28 The Payment Medium Workbench
Treasury Payments
Treasury payment processing is at the heart of any good TMS. TRM with SAP
S/4HANA has a robust and well-established payment engine that processes pay-
ments through the four-step cycle shown in Figure 3.29:
1. Create payment request in TRM with SAP S/4HANA:
– Construct file formats through PMW.
– Execute treasury payment runs.
– Set up repetitive codes.
– Initiate bank-to-bank transfers using repetitive, nonrepetitive, and free-form
wires.
– Generate outbound payment files (if Bank Communication Management isn’t
active).
2. Utilize Bank Communication Management (optional):
– Batch cross-payment media payment runs.
– Process approvals through the workflow prior to releasing payments.
– Set approval limit rules based on threshold amounts and other criteria.
– Monitor outbound payments and inbound messages and bank statements.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
45
3. Send payment files through middleware connection to SWIFT/payment networks:
– Process outbound and inbound file and message transfers.
4. Perform external bank processing:
– Process and clear payment files.
– Send acknowledgement and payment confirmation SWIFT messages.
– Send electronic bank statements.
Figure 3.29 Treasury Payment Cycle
Treasury payments aren’t dependent on invoices and are instead based on the cash
flows generated when a transaction is created in the Transaction Manager. Thus, trea-
sury has its own payment transaction code for external payments triggered through
the TransactionManager (Transaction F111), or for direct bank-to-bank (Transaction
FRFT_B), bank-to-business partner (Transaction FRFT_TR), or free-form wire transfers
(Transaction RVND) through generation of a payment request. These transactions are
also available through the Make Bank Transfers and Process Free-Form Payments
apps in the Cash Operations SAP Fiori dashboard.
The other payment transaction code (Transaction F110) is used for invoice-based
accounts payable payments to vendors, as well as internal transfers for in-house
banking purposes. (We’ll explain more about that in Section 7.3.) Payment informa-
tion relating to counterparties and specific to company codes are set up within the
Payment requests
in TRM on
SAP S/4HANA
Bank
Communication
Manager in TRM on
SAP S/4HANA
(optional)
Middleware
connection to
SWIFT/payment
networks 
Banks 
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
46
business partner master data and integrated with the Transaction Manager. When a
transaction is created in the Transaction Manager, this payment information will
automatically default into the Payment tab of the transaction based on its input
parameters: company code, product type, transaction type, and business partner.
This enables strong controls around bank account setup by counterparty, and
through SoD, ensures that Sarbanes-Oxley (SOX) and internal controls are main-
tained to prevent fraud or error.
Treasury also makes direct payments between internal bank accounts as well as
transfers between banks for cash concentration, pooling, internal settlement, or
other funding requirements. TRM with SAP S/4HANA supports the creation of repet-
itive, nonrepetitive, and free-form wires. Repetitive codes for wire transfers are set up
as master data and tied to sending and receiving bank accounts by legal entity and
currency. Additional built-in controls for these direct transfers ensure that only
authorized payments are made and prevent the creation of unauthorized repetitive
codes. These would include a requirement to release a repetitive code when created
before it can be used for payment transfers. The Bank Communication Management
module complements the payment engines in TRM with SAP S/4HANA. We’ll be look-
ing at the Bank Communication Management module and how it integrates with the
payment engine and payment functionality in Section 6.2.
Bank-to-Bank Transfers
Funding transfers between internal bank accounts for cash pooling and concentra-
tion purposes or for one-time payments to external counterparties can be made
through repetitive, nonrepetitive, or free-form wires. Repetitive wires are enabled
through the creation of a repetitive code that is unique to a sending and receiving
bank account; this code contains all the relevant information and payment instruc-
tions in the payment file sent to the bank to execute the funds transfer. The repetitive
code needs to be approved and released to be able to transfer funds, as shown in
Figure 3.30.
Both bank-to-bank and bank-to-business-partner funding transfers can use repeti-
tive codes. After the repetitive code has been created and released, the transfer can be
made using the repetitive code, where all the data elements are automatically popu-
lated, and the amount and message can be updated. Once entered, the payment
request is created; after the release has been approved, the payment can be pro-
cessed. These actions can be completed in the input screen, as shown in Figure 3.31.
Controls can be added to ensure SoD between create and release functions.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
47
Figure 3.30 Creating and Releasing a Repetitive Code
Figure 3.31 Processing a Bank-to-Bank Transfer Using Repetitive Codes
An example of the confirmation log of the payment on release and payment is shown
in Figure 3.32.
Figure 3.32 Displaying the Payment Request Log
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
48
Free-form wire transfers can be sent using an input screen populated with one-time
ad hoc information entered manually. There are additional controls available around
this form of payment with multiple levels of approval if required. Figure 3.33 shows
the free-form fields available for input. Business partners can be selected from the
dropdown or entered manually. Payee details, their bank information, currency, and
amount can be entered manually. Posting data, paying bank details, and payment
method must be available in the system for selection within the free-form wire tem-
plate.
Figure 3.33 Creating a Free-Form Wire Payment
Advanced Payment Management
Advanced Payment Management is a new module released with SAP S/4HANA 1909
that provides payment processing functionality in SAP S/4HANA for payments from
legacy systems and other systems. These can be processed in SAP S/4HANA and
routed through its bank connectivity channels to external banking partners. Each
source system is assigned to a unique clearing area, which acts as the repository for
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
49
reconciling payments made with incoming electronic bank statements. A file conver-
sion tool automatically converts incoming legacy file formats to SWIFT- and ISO
20022–compatible formats for outbound processing. An exception handling capabil-
ity corrects any errors in the outbound files. Approval processes for payments are
available through the standard workflow for payment processing. This process
involves the three steps and activities shown in Figure 3.34:
1. Files are received from legacy, SAP ERP, and SAP S/4HANA systems into the input
manager:
– Process payment files.
– Process payment orders.
– Create unique clearing areas.
2. Files received are enrichment and validated:
– Convert to SWIFT or ISO 20022 format.
– Process and correct exceptions.
3. Files are processed through output manager for onward processing through pay-
ment networks:
– Process approvals through the workflow.
– Route to external networks and through to banks.
Figure 3.34 Advanced Payment Management Process Flow
Input
manager
Enrichment
and validation
Output
manager
Feeder and
legacy systems
On-premise
or cloud SAP
S/4HANA
systems
Multi-bank
connectivity
SAP
EBICS
SWIFT
SAP S/4HANA 
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
50
3.4 Accounting
One of SAP S/4HANA’s most powerful features is that most of the accounting is pre-
configured and takes place automatically in the operational post-go-live environ-
ment.
The accounting process in the Transaction Manager starts with the posting of flows
after settlement. That creates a payment request or clearing posting, depending on
whether a payment needs to be sent out or is a direct debit or credit initiated by the
bank. In the case of direct debit, rather than posting to the payment request clearing
account, it posts to the bank clearing account, to be reconciled when the prior day’s
electronic bank statement is received and cleared against the amount.
At month end, the SAP S/4HANA system will calculate accruals and deferrals, valua-
tion with unrealized gains and losses, amortization amounts, and so on based on all
the relevant positions, and then will post them into the general ledger. Posting rules
are configured as part of the implementation and will be automatic; if errors happen,
postings can be reversed.
Note
You can’t just delete a posting; you must reverse it to ensure a full audit trail and that a
change log is always available for review.
Additionally, realized gains/losses for completed transactions, interest fixing for
variable interest rate instruments, and hedge accounting are all completed as part of
period-end processing. A posting journal shows all postings relating to a transaction,
with linkages to the financialand original documents relating to it, and, if applicable,
to the payment reference.
Clearing and Reconciliation
Clearing accounts are used extensively in SAP S/4HANA to facilitate automatic
matching and reconciliation; they also act as a buffer to help correct any unrecon-
ciled items or errors before they are posted.
For example, bank reconciliation is an automated self-reconciling process. Let’s walk
through the steps:
1. The trade transaction is posted with the post flows transaction (Transaction TBB1).
This initial posting records the asset/expense in SAP S/4HANA and sets up the pay-
ment request that will execute on the due date.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
51
– Debit the asset or expense account.
– Credit the payment request clearing account.
2. The payment run is executed (Transaction F111), which posts and clears the pay-
ment request clearing account, posts the other side to the bank clearing account,
and creates the payment file that is sent to the bank.
– Debit the payment request clearing account.
– Credit the bank clearing account.
3. The bank settles the payment and sends the prior day’s bank statement, which is
uploaded and posted in TRM with SAP S/4HANA. SAP S/4HANA uses clearing
accounts in between initial and final postings to facilitate automatic posting and
reconciliation. Any errors are flagged for postprocessing. This ensures the integrity
of the final accounting postings in the book of prime record. Individual items are
matched and auto-cleared based on Note to Payee information in the bank state-
ment and based on search string rules that can be preconfigured and added as new
information is received on an ongoing basis.
– Debit the bank clearing account.
– Credit the main bank general ledger account.
4. The process can be automated end to end, and the bank statement is self-reconcil-
ing. When all transactions from an electronic prior day’s bank statement are
posted, the closing balance per bank statement should equal the balance per the
bank general ledger account because one side of every transaction in the electronic
bank statement will always post to the main bank general ledger account.
Transaction Accounting
Daily transactional activities require processing to generate payments or calculate
realized gains and losses on completed transactions. These generate posting entries
in SAP S/4HANA and typically are run daily either manually or automatically through
batch jobs.
After the entries have posted, a posting log is available to display the subledger
entries in the treasury module, as well as links to the accounting document, pay-
ment, and other references, as shown in Figure 3.35.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
52
Figure 3.35 Posting Cash Flows
When a contract is terminated, gains or losses are calculated and posted as shown in
Figure 3.36.
Figure 3.36 Posting Realized Gains and Losses
Period-End Closing
A period-end close process typically is composed of the following activities in TRM
with SAP S/4HANA as on the key period-end date:
� Calculating and posting interest accruals and deferrals
� Valuation and posting unrealized gains and losses on positions that need to be
brought up or down to match the market price on the key date (also known as
mark-to-market process)
� Amortization of expenses relating to securities and debt
� Management of hedge positions that may involve effectiveness testing, de-desig-
nation, and dissolution, which would trigger automatic accounting transfers
between other comprehensive income (OCI) and profit and loss (P&L) accounts on
the period-end date
Let’s look at accruals and valuation in some more detail. Accruals and deferrals are
calculated automatically by the system based on open positions primarily in interest
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
53
rate–related instruments such as money markets and securities. SAP S/4HANA will
calculate all interest due but not payable at the period-end date, and proposes and
posts the amounts. A reset option is available that reverses the period-end entry on
the first day of the next period and recalculates the amounts accrued and deferred
afresh at the next period-end close date. Accrual without the reset option is available,
which will add the incremental amounts of the accrual as the accounting year pro-
gresses, without any reversal.
Let’s walk through the accounting steps for interest expense as well as income, using
the variant with reset as an example.
1. Interest payable accrual is created through the post accruals (Transaction TPM44):
– Debit the interest expense account.
– Credit the interest payable liability account.
2. If the reset option is used, automatic reversal of the entry takes place on the period-
end date +1 (i.e., the first day of the new period):
– Debit the interest payable liability account.
– Credit the interest expense account.
3. Interest income receivable is also created through the post accruals transaction
(Transaction TPM44):
– Debit the interest receivable asset account.
– Credit the interest income account.
4. If the reset option is used, automatic reversal of the above entry takes place on the
period-end date +1 (i.e., the first day of the new period):
– Debit the interest income account.
– Credit the interest receivable asset account.
If any error is discovered after the postings are made, these can be reversed using the
reverse accruals transaction (Transaction TPM45).
At period-end or month-end, open positions need to be valued and adjusted to market
value (i.e., mark-to-market) in accordance with accounting principle requirements.
SAP S/4HANA uses discounted cash flow principles to calculate the net present value
(NPV), which is then used as the basis for the mark-to-market valuation and posting.
NPV of a trade or transaction can be entered manually or calculated by the system
based on FX or interest rate yield curves that in turn are fed by market data.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
54
Figure 3.37 shows the manual entry of NPV, Figure 3.38 shows the valuation run that
calculates and prepares the valuation entry, and Figure 3.39 shows the financial post-
ing to the subledger and general ledger on the period-end date, with reset on the first
day of the new accounting period.
Figure 3.37 Manual Entry of Net Present Value
Figure 3.38 Mark-to-Market Valuation Run
Figure 3.39 Mark-to-Market Postings with Reset
Local Accounting and Valuation
Most global corporations have to comply with multiple statutory and regulatory
accounting requirements when preparing their periodic and annual financial state-
ments. In addition to international accounting standards such as International
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
55
Financial Reporting Standards (IFRS) and US Generally Accepted Accounting Princi-
ples (GAAP), many companies need to prepare financial statements to comply with
local or country-specific regulatory or accounting requirements. Additionally,
period-end valuations and FX gains and losses for local versus group reporting
requirements may differ from country to country.
In SAP S/4HANA, these requirements are met through the setup of valuation areas.
Each valuation area is assigned to an accounting principle such as IFRS, US GAAP, or
local (operational), as shown in Figure 3.40. By default, valuation area 001 is always
assigned to the primary reporting accounting principle of the legal entity, and addi-
tional valuation areas are assigned as required. When an accounting posting takes
place, all valuation areas are posted, but—as shown in Figure 3.41—to different gen-
eral ledger accounts, depending on the requirements of the accounting principle.
Note that account assignment by valuationarea is set up in configuration. It’s
important that during the design and blueprint phase, the group responsible for
accounting stay fully involved in establishing their requirements for postings for the
various treasury transactions.
Figure 3.40 Accounting Principle Assigned to Legal Entity
Figure 3.41 Automatic Postings in Both Valuation Areas
3.5 Reporting and Monitoring
Reports convert data into information and form the basis for good decision-making.
The quality of standard treasury reporting has been steadily improving in legacy sys-
tems, but with SAP S/4HANA, SAP is making a determined effort to upgrade the qual-
ity of reporting to consumer-grade expectations and experience. So far in this E-Bite,
you’ve seen examples of SAP Fiori–based dashboards that are driving this transition,
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
3 Transaction Management
56
and SAP S/4HANA introduces additional SAP Fiori tiles and dashboards with every
release.
Another important development in SAP S/4HANA is the leveraging of the new archi-
tecture to provide advanced analytical capability and move from the backward-look-
ing record-and-report model to the forward-looking predict-and-act model. Later in
this section, we’ll look at an example of how predictive analytics can be used for
working capital optimization with SAP S/4HANA.
First let’s focus on treasury. A wide variety of standard SAP GUI and SAP Fiori–based
dashboards and transaction codes are available for payments, treasury positions, risk
reporting, alert management, accounting postings, and position cash flows, to name
a few.
SAP Fiori dashboards are role-based but can also be customized for specific users or
roles. Apart from standard operational reports that show historical information and
performance, there are an increasing number of exception-based reports that lever-
age real-time or near-real-time data to provide feedback for action. Figure 3.42 pro-
vides an overview of treasury reports available in the SAP Fiori dashboard under the
Treasury Reporting tab. For example, the Review Balance Sheet FX Risk, Market Data
Overview, and Foreign Exchange Overview apps are available to view different
aspects of FX transaction and position management through one window.
Figure 3.42 Treasury Reporting
Alert monitors provide information on upcoming or overdue tasks requiring action
such as the release and settlement of financial transactions, payment and posting of
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
3 Transaction Management
57
cash flows pending, correspondence not matched, or interest rate updates. Figure
3.43 shows the SAP Fiori dashboard for treasury alerts that show 41 pending posting
items, 3 payment items, and 1 settlement outstanding. Clicking on any of these tiles
will take you into the detail.
Figure 3.43 SAP Fiori Dashboard for Treasury Alerts
For example, the alert monitor shown in Figure 3.44 informs you that there is one
transaction created on 11/29/2020 that is still open and requires settlement. Clicking
on the transaction number from the monitor will take you to the underlying trans-
action, where it can be settled. The alert monitor report can be run manually or
scheduled as a regular batch job. It can also be set up to trigger email alerts to desig-
nated recipients.
Figure 3.44 Alert Monitor Messages for Action
In the next section we’ll look at the key treasury function of financial risk manage-
ment, arguably a raison d'être of any good TMS.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
58
 
4 Financial Risk Management
Financial risk management is one of the most important functions of treasury. Risk
arises due to uncertainty about the future. There isn’t much we can do about
“unknown unknowns,” but organizations need to protect themselves against the
“known unknowns.”
There are several types of risk, but we’ll focus on the financial risks that take the form
of FX risk, interest rate risk, commodity price risk, and counterparty risk. When you
enter into financial transactions that involve elements of risk, such as foreign cur-
rency, interest rates, or credit rating, any adverse movement in these types of risk
exposes your company to financial loss. This exposure is what you need to hedge
against. Thus, this process of financial risk management involves identifying expo-
sures and then hedging the risk associated with them.
Because the primary purpose of hedging is to protect the income statement from
variability of cash flows due to monthly or periodic fluctuations and resultant
changes in the value of hedges, very specific regulatory and accounting rules laid out
by US (GAAP) and international (IFRS) accounting boards determine what can and
can’t be hedged and, if eligible, under what circumstances. Protection against all
these risks is called hedging and managing this process is called hedge manage-
ment—a critical component of any TMS.
Figure 4.1 provides an overview of the hedging process in TRM with SAP S/4HANA.
The entire lifecycle of hedging risk starts with identifying the raw exposures that
need to be hedged. These exposures are represented by an organization’s forecasted
transactions, firm commitments, and assets and liabilities that are potentially sub-
ject to adverse movements in price resulting in loss of cash flow or fair value. Once
identified, these exposures are entered into the Exposure Management 2.0 tool in
TRM with SAP S/4HANA. Sources of input can be through manual entry, Microsoft
Excel upload, or integration with logistics, legacy, or planning systems. TRM with SAP
S/4HANA collates all the exposure information in one table, using the term One
Exposure to denote the consolidation of this information. The One Exposure infor-
mation is available as raw exposures that need to be hedged are released to hedge
management for further processing involving designation, valuation, effectiveness
testing, de-designation, dissolution, compliance, documentation, and accounting.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
59
Figure 4.1 Integrated Hedge Management in TRM with SAP S/4HANA
Increasingly, SAP provides standard interfaces to connect with frontend trading plat-
forms, which further automates the end-to-end processing. Thus, after hedge
requirements are ascertained based on input from exposure management, trades
can be triggered by the front office using the frontend trading platforms. Completed
trades can be passed back into SAP S/4HANA for recording, confirmation, settlement,
and further processing. All the information is now available in SAP S/4HANA, and
hedge management and hedge accounting can be executed during the lifetime of the
hedged item and its underlying exposure.
Let’s look at these in more detail. Section 4.1 looks at exposure management and its
integration with hedge management. We’ll then review hedge management in Sec-
tion 4.2, with a focus on FX risk, balance sheet risk, and interest rate risk. We’ll then
discuss frontend trading platform integration in Section 4.3, hedge documentation
in Section 4.4, and, most importantly, the hedge accounting required for reporting,
regulatory, and compliance purposes in Section 4.5.
4.1 Exposure Management
In SAP S/4HANA, hedge management is integrated with exposure management as
well as transaction management, and related hedge accounting is automated and has
to be configured and activated to allow for hedging to take place within the system.
Note that if you want to use exposure management for hedge management in SAP
S/4HANA, you must use Exposure Management 2.0 (see Figure 4.2).
Integrate with
frontend trading
system 
Hedge management,
compliance, and
documentation
Market data
Market Risk
Analyzer
Reporting
Start
Input
One Exposure
Create raw exposures
Release to hedge
management
Create hedging
relationship
Createhedging
instrument 
Accounting
settlement
valuation GAAP/IFRS
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
60
Figure 4.2 Entering Raw Exposures Manually (Header Data)
The detail line input for raw exposure capture contains a comprehensive list of input
fields; as shown in Figure 4.3, this includes fields for profit center, work breakdown
structure (WBS) element, cost center, and on-behalf-of legal entity, allowing robust
reporting and analysis to enable the appropriate exposures to be transferred to
hedge management.
Figure 4.3 Entering and Releasing Raw Exposures Manually (Line Item Data)
The raw exposures can be automatically released for further processing within hedge
management, as shown in Figure 4.4.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
61
Figure 4.4 Raw Exposures Release Log
The release of exposures triggers the hedge management process. Let’s turn our
attention there.
4.2 Hedge Management
Hedge management in TRM with SAP S/4HANA is available for FX risk, commodity
price risk, and interest rate risk. These were available in prior SAP ERP systems, but
the tools to manage them have improved as greater integration and automation
were phased in. Let’s look at these in the following sections.
Foreign Exchange Risk
In an increasingly interdependent and globalized world economy, the management
of foreign currency risks forms an important component of any organization’s trea-
sury function. The foreign currency exchange market is open 24/7, and at any point
in the day, currencies are being traded somewhere on the globe. Domestic companies
with overseas vendors and customers, and global corporations with operations
around the world are exposed to the adverse impact of their foreign currency cash
flows losing value on conversion to their domestic currencies on settlement dates.
In SAP S/4HANA, there are two options for hedge management of FX and commodi-
ties price risk. The first option, E-Hedge, is based on legacy functionality and man-
aged through a standard transaction code that provides access to a dashboard. The
second is new to SAP S/4HANA and is appropriately called New Hedge Management;
with this tool, all hedging activity is managed through an integrated hedge manage-
ment cockpit. Both options can be configured and set up concurrently. Depending on
an organization’s needs, these two options can be used for its hedge management
requirements. Cash flow, fair value, and net investment hedges in foreign operations
are supported hedge strategies. After the hedge instrument and underlying exposure
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
62
are linked in a hedging relationship, all hedge management activities can be exe-
cuted through the respective cockpits in E-Hedge or New Hedge Management. This
includes hedge documentation; effectiveness testing (both retrospective and pro-
spective); designation, de-designation, and dissolution of hedges; and related
accounting flows between OCI and P&L accounts during the lifetime of the hedge or
at its termination.
Table 4.1 shows some of the key differences between the two options for hedge man-
agement in SAP S/4HANA. Note that both E-Hedge and New Hedge Management can
be used for FX risk, and both are fully integrated with exposure management, trans-
action management, and hedge accounting, However, New Hedge Management
doesn’t currently support interest rate risk hedging, and has a separate process. New
Hedge Management was designed to optimize the functionality enabled by SAP
S/4HANA. Additionally, all new functionality will be added to New Hedge Manage-
ment, making it the tool of choice for hedge management in SAP S/4HANA.
Function E-Hedge Management New Hedge Management
Integration among exposure 
management, transaction 
management, and hedge 
accounting
Yes, exposures transferred 
manually to hedge manage-
ment
Yes, exposures released auto-
matically to hedge manage-
ment
Matching between underly-
ing exposures and hedge
Linked manually Automatic based on match-
ing criteria set up though 
hedging area
Highest level of classification 
of hedges
Based on hedge plans set up 
in the hedge management 
dashboard
Hedging area, highest level of 
master data under which all 
hedging activities are man-
aged
Reporting of hedging activity Based on entry of key dates in 
standard reporting
Based on daily snapshots that 
can be captured and saved
Compliance with new IFRS 
hedging requirements and 
regulations
No Yes
OCI reclassification after 
hedge dissolved or de-desig-
nated
Manual Can be set up based on pay-
ment terms or days inventory 
outstanding
Types of risks covered FX, commodity and interest 
rate risk, net investment in 
foreign subsidiaries
Currently only FX forwards, FX 
options, FX swaps, and bal-
ance sheet FX risks
Table 4.1 E-Hedge vs. New Hedge Management
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
63
Let’s look at these in a bit more detail.
E-Hedge Management
Compared to New Hedge Management, E-Hedge is considered more manual because
transfer of exposures, creation of hedging relationships, and other functions need
manual intervention. However, E-Hedge is simpler to set up and use, and it’s tried
and tested, having been made robust over the years.
If a specific product type has been designated as relevant to hedge accounting, an
additional E-Hedge Accounting tab will be available in the Transaction Manager (see
Figure 4.5) that allows the hedging instrument and hedged item to be linked when
creating the transaction. By contrast, in New Hedge Management, the link is provided
in the Administration tab as explained in the next section.
Figure 4.5 Hedge Instrument Linked to Exposure in Transaction Management
The hedge instrument is linked to hedge management through a hedge plan and
hedge ID. After this link is established, hedging activities such as effectiveness test-
ing, de-designation, dissolution, and so on can be managed through the dashboard,
as shown in Figure 4.6.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
64
Figure 4.6 E-Hedge Dashboard for Hedge Management
New Hedge Management
New Hedge Management has been available since the early versions of SAP S/4HANA
and is regularly updated to comply with new and changing regulations (especially
IFRS 9, which most companies with global operations will need to comply with in one
form or other). It currently supports only FX-related risks. New Hedge Management
has new master data requirements, automatic transfer of exposures to hedge man-
agement, and hedging relationship creation using “snapshot” versions.
In New Hedge Management, the timing of transfers from OCI to P&L accounts can be
linked to logistical information in the system, such as payment due dates or days
inventory outstanding. Valuations can be entered manually at month end or calcu-
lated by the system through yield curves set up and maintained based on exchange
rates, reference interest rates, and volatilities data brought in through market data
providers.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
65
New Hedge Management is managed through a newly introduced hedge manage-
ment cockpit that allows the user to manage the entire end-to-end process through
the SAP Fiori dashboard shown in Figure 4.7.
Figure 4.7 SAP Fiori Dashboard for Hedge Management
Before treasury practitioners can begin managing hedges in New Hedge Manage-
ment, though, it’s critical that some master data elements have been set up that are
key to the integrated and automated processes within New Hedge Management. One
of these is the new hedging area, which forms the highest organizational level under
which hedging activity can take place: by currency,legal entity, region, or any other
classification that allows you to manage and execute your organization’s hedging
policy. The hedging area needs to be set up initially and contains all the information
required by the system to manage the hedging process, including transfer of expo-
sures to hedge management, matching the exposure with the hedging instrument in
the Transaction Manager, and enabling activities such as de-designation, termina-
tion, effectiveness testing, and accounting. The initial screen for hedging areas, Dis-
play Hedging Area, is shown in Figure 4.8.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
66
Figure 4.8 Main Data Screen for Hedging Areas
Multiple hedging areas can be created as needed, and each hedging area can be man-
aged through versioning with effective-from dates. Filters help determine matching
criteria for exposures and hedging instruments. Hedge accounting requirements are
added through the accounting tabs. In addition to the SAP Fiori dashboard, hedge
management functions can also be accessed through the SAP application menu
shown in Figure 4.9.
Figure 4.9 Application Menu for Hedge Management
With the hedging area set up, let’s walk through some of the key steps in the process
in the system, as shown in Figure 4.10.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
67
Figure 4.10 Process Flow for New Hedge Management
The raw exposures are entered with multiple differentiation fields to enable match-
ing based on exposure filters and hedge filters defined in the hedging area, as shown
in Figure 4.11.
Figure 4.11 Entering Raw Exposures
The exposures are transferred to the hedge management cockpit through creation of
a snapshot within the designated hedging area, as shown in Figure 4.12.
Figure 4.12 Transferring Exposures through Snapshot
Capture
exposure
Create
snapshot
Create FX or
commodity
contract
Hedge
relationship
created
automatically
Manage
hedges in hedge
management
cockpit 
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
68
These exposures are now available to view in the hedge management cockpit, as
shown in Figure 4.13.
Figure 4.13 Exposures Transferred to the Hedge Management Cockpit
The stage is now set to create the hedging instrument based on target ratios and
hedging policy. A hedge request is created manually or, with some setup, created
automatically. The hedging instrument will be created by the front office using its
trading platform or through direct contact with a broker. (We’ll discuss trading plat-
form integration further in Section 4.3.)
A hedge request can also be generated from the hedge management cockpit that pro-
vides all the information to the front office for the purpose of executing the trade, as
shown in Figure 4.14. A confirmation message is generated upon submission of the
request, as shown in Figure 4.15.
The hedging instrument is created and entered manually in SAP S/4HANA. If the
trading platform integration application is active, the trade will automatically be
uploaded and entered in TRM with SAP S/4HANA, making it available for matching
with the related exposures. The created hedging instruments are shown in Figure
4.16.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
69
Figure 4.14 Creating a Hedge Request
Figure 4.15 Hedge Request Submission Message
Figure 4.16 Hedge Instruments Created
The original hedging instrument is created in the Transaction Manager and linked to
hedge management in the hedge management cockpit, as shown in Figure 4.17.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
70
Figure 4.17 Hedging Instrument Created in Transaction Manager
The link between transaction management and hedge management is through the
Administration tab when the hedging instrument is created in the Transaction Man-
ager using the Hdg. Classific. (hedge classification) field, as shown in Figure 4.18.
Figure 4.18 Assigning a Hedge Classification in Transaction Manager
The matching process can also be triggered through SAP Fiori or the application
menu. On successful matching, the hedge management cockpit will be populated
with all the relevant details of the hedging relationship, hedged item, hedging instru-
ment, documentation, and so on, as shown in Figure 4.19.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
71
Figure 4.19 Hedging Instrument Detail in the Hedge Management Cockpit
After the hedging instrument is available in the hedge management cockpit, it can be
further processed as key dates and events relating to the hedge occur. For example, as
shown in Figure 4.20, the hedge can be de-designated or terminated. The request can
optionally be integrated with the workflow for release approval.
Figure 4.20 Further Processing Options in the Hedge Management Cockpit
Clicking on the de-designation request will prompt an input screen, which has all the
information to enable approval and process the de-designation, as shown in Figure
4.21.
In the hedge management cockpit, other tabs are available for conducting effective-
ness testing (the Effectiveness Test tab) or generating hedge documentation (the Doc-
umentation tab), as shown in Figure 4.22.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
72
Figure 4.21 Making a De-Designation Request
Figure 4.22 Hedge Management Cockpit Tabs
Balance Sheet FX Risk
SAP S/4HANA has functionality to identify balance sheet FX risks based on financial
postings to balance sheet accounts; for example, open items such as accounts
payable and receivable and bank balances can be viewed through an SAP Fiori
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
73
application, Review Balance Sheet FX Risk, which enables an appropriate hedging
strategy. The application menu for this function is shown in Figure 4.23.
Figure 4.23 Balance Sheet FX Risk Menu
The snapshot function will propose all balance sheet assets and liabilities that have
been defined as risk relevant in settings, as shown in Figure 4.24. These can then be
managed further in accordance with hedging policy and operational requirements.
Figure 4.24 Report of Balance Sheet Exposures
Interest Rate Risk
Interest rate risk exposures must be managed through E-Hedge. The underlying
exposure that could be a debt or investment instrument is linked to the hedging
instrument through the hedge management cockpit, as shown in Figure 4.25.
Figure 4.25 Hedging Interest Rate Risk
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
4 Financial Risk Management
74
The icon beside the hedging instrument number in the bottom-left corner is the link
to the Transaction Manager.
4.3 Trading Platform Integration
A typical interface with a frontend trading platform such as FXall or Bloomberg will
involve executing trades on the frontend platform and then downloading the
information into SAP for further processing in the Transaction Manager. The hedge
management cockpit in New Hedge Management has a setting to activate trading
platform integration, as shown in Figure 4.26.
Figure 4.26 Trading Platform Integration
Integration between a TMS and frontend trading platforms allows trades executed on
the trading platform to automatically be transferred to and created in TMS, thus
eliminating the need for manual input. The result is better automation of the hedge
management process.
4.4 Hedge Documentation
Hedge documentation is an important component of hedge management, and it’s
required to ensure compliance with the hedge eligibility criteria established by
accounting standards such as GAAP and IFRS.
There are two options available in TRM with SAP S/4HANA for hedge documentation.
The first is to enter details withinthe hedge instrument created in the Transaction
Manager using the Memos tab, as was shown earlier in Figure 3.10.
The second method is to use the functionality provided in the hedge management
cockpit. This can be configured to automatically create relevant hedge documenta-
tion. The system provides this documentation through PDFs with a general format,
as well as in specific formats for FX forwards, FX options, and collars used as hedging
instruments. Additionally, the built-in Form Builder tool is available to create your
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
4 Financial Risk Management
75
own variant or amend an existing form. The Documentation tab is integrated into the
hedge management cockpit, as shown earlier in Figure 4.19.
4.5 Hedge Accounting
Hedge accounting in a TMS is a fully integrated function that allows for compliance
with the latest IFRS guidelines, as well as end-to-end automation of the accounting
postings during the lifetime of the hedge. An extract of the functional Accounting
menu for hedge accounting is shown in Figure 4.27, displaying key functions for
determining NPVs, valuation, and classification.
Figure 4.27 Accounting Application Menu for Hedge Management
Transfers between P&L and OCI are triggered depending on the type of function
being executed (e.g., de-designation, dissolution, termination, unwinding, etc.).
Figure 4.28 provides an example of the same transaction posting to two valuation
areas. Transaction number 4000000000001 posts the unrealized valuation gains of
$236,920.22 to the P&L account in valuation area 001 and to the balance sheet (OCI) in
valuation area 003, and the other side of the entry to the asset general ledger
accounts per IFRS (valuation area 001) and US GAAP (valuation area 003).
Figure 4.28 Hedge Management Postings by Accounting Principle
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
5 Analyzers
76
In the next section, we’ll look at the risk analyzers that support transaction manage-
ment in TRM with SAP S/4HANA.
 
5 Analyzers
SAP S/4HANA’s treasury analyzers support the Transaction Manager in a variety of
functions. There are three primary analyzers: Market Risk Analyzer, Credit Risk Ana-
lyzer, and Portfolio Analyzer. Let’s review each of these.
5.1 Market Risk Analyzer
The Market Risk Analyzer is by far the most important one and is primarily an analyt-
ical tool that is also required for month-end mark-to-market valuations of treasury
positions. It uses a daily or monthly market data feed composed typically of currency
exchange rates, reference interest rates, FX swap rates, interest and FX volatilities,
and commodity prices to build the yield curves required for period-end valuation.
Additionally, it includes a variety of tools for “what-if” analysis, simulation, market
data shift scenarios, and value at risk (VaR) analysis.
The Market Risk Analyzer provides the following functionality through standard
month-end processing as well as ad hoc tools for simulation:
� Market data maintenance
� Yield curve maintenance
� Period-end valuation
� NPV calculation
� Simulation scenarios
� Market data shift
� Options calculator
Let’s look at some of these tools in further detail.
Valuation
Valuation of treasury positions at month-end or period-end and mark-to-market is a
standard requirement for accounting and reporting purposes. So, for example, an
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
5 Analyzers
77
open FX contract will have an unrealized gain or loss on the period-end close date,
depending on how FX rates in the contract have changed since inception or the last
valuation date. SAP uses NPV as the basis for valuing a contract, based on discounting
the future cash flows according to a specified discount rate.
SAP S/4HANA supports valuation calculations based on the setup of yield curves
maintained by market data that feed the different types of yield curves with the latest
FX rates, reference interest rates, volatilities, swap points, and commodity prices.
NPV for a contract can also be entered manually, where the volume is low and doesn’t
justify setting up yield curves and calculations using the market data feed.
Let’s walk through an example of period-end valuation using yield curves for an
interest rate swap (IRS). An IRS is a derivative instrument that allows an organization
to convert an underlying interest rate asset or liability instrument that it holds from
fixed to floating rate or vice versa. Therefore, for example, if you have issued debt
that pays interest based on a variable rate, such as a three-month London Interbank
Offered Rate (LIBOR), and you expect rates to go up in the future, you would purchase
a pay-fixed receive-floating IRS, effectively converting your variable rate debt into
fixed rate debt. The IRS is based on a notional principal amount, according to which
the fixed and variable leg interest is calculated, and the net difference between them
is settled between the contracting parties on the due dates. Valuation for period end
is accordingly based on net future interest cash flows, discounted to NPV based on
zero coupon or bond rates.
Figure 5.1 shows the proposed valuation (in test run mode) for our example IRS that is
based on a notional principal amount of $10,000,000. From this screen, you can drill
down into the details of the calculations if required, and after they have been vali-
dated, deselect the Test Run button and run it in live mode to enable the system to
update the valuation for the key date.
Figure 5.1 Net Present Value of Derivative on Key Valuation Date
Let’s look at the detailed calculations that got us to a NPV (loss) of $16,657.13. Figure 5.2
shows the basis of the yield curve calculation for the US dollar denominated IRS, and
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
5 Analyzers
78
the zero-bond discounting factor (ZBDF) used in the NPV discounting calculations.
Based on this yield curve, the system uses the appropriate rate on the curve that
matches the number of days that need to be discounted (future due date minus cur-
rent period-end date), which is applied against the interest flows to arrive at the NPV.
Figure 5.2 Yield Curve Basis for Calculation
Figure 5.3 provides header information on transaction number (here, this is
6000000000002), instrument type (here, this is IRS), and whether it’s payer or
receiver based (here, this is Payer).
Figure 5.3 Details of Net Present Value (Header)
Figure 5.4 provides details of calculations for the fixed leg, which first calculates the
cash flows based on the fixed rate (6%) on notional of $10,000,000 for 69 days (top
screenshot), and then discounts these flows based on the discount factor from the
yield curve to arrive at the NPV of the fixed leg.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
5 Analyzers
79
Figure 5.4 Details of Net Present Value (Fixed Leg)
Figure 5.5 provides details of calculations for the floating leg, which first calculates the
cash flows based on the variable rates on a notional of $10,000,000 for 69 days (top
screenshot), and then discounts these flows based on the discount factor from the
yield curve to arrive at the NPV of the fixed leg.
Figure 5.5 Details of Net Present Value Calculations (Floating Leg)
Figure 5.6 shows the NPV of the floating leg of -$113,386.58, and how that value was
reached: by applying the discount factor to each cash flow by date, and then adding
up the discounted cash flows.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
5 Analyzers
80
Figure 5.6 Summary of Net Present Value Calculations (Floating Leg)
The net amounts of the fixed leg ($96,729.45) and floating leg ($113,386.58) of $16,657.13
calculated is proposed as the valuation, as shown in Figure 5.7.
Figure 5.7 Net Present Value to Be Posted
The valuation can now be executed in live mode, as shown in Figure 5.8, by removing
the TestRun setting, and clicking on the Execute Valuation button.
Figure 5.8 Valuation Run for the Interest Rate Swap
The period-end valuation process is complete with the postings to the ledgers, as
shown in Figure 5.9, with a valuation decrease (loss) reflected on the period-end date
of 11/22/2020 and reversed on 11/23/2020 (valuation with reset option used).
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
5 Analyzers
81
Figure 5.9 Period-End Valuation Posting with Reset
Analytical Tools
A variety of analytical tools are available in the Market Risk Analyzer to simulate dif-
ferent what-if scenarios, perform sensitivity analysis, and utilize calculators for NPV
calculations and pricing options, to name a few. Although data in TRM with SAP
S/4HANA can be downloaded into Microsoft Excel for further analysis, an important
new feature is the ability to integrate Microsoft Excel with SAP S/4HANA to enable
real-time analysis without the need for manual downloads.
One of these integrated analytical tools is market data shift, which allows a what-if
scenario simulation of the effect of a price change or an interest rate change on the
NPV of a portfolio or individual position.
For example, Figure 5.10 shows the input parameters for a market data shift of
100 basis points (market data shifts) for currency USD on the evaluation date of
12/31/2020 and the effect that would have on NPV (key figure) of a selected port-
folio of derivatives and money market instruments for company code 3000 (not
shown in this screen).
On execution, the resultant output is shown in Figure 5.11. The output shows the pos-
itive impact on the derivatives portfolio of $8,921.79 and a negative impact of -$38.25
on the money market portfolio, for an overall positive impact of $8,883.54. Note that
similar to the IRS valuation example earlier in this section, you can click on the Detail
Log and Calc. Basis buttons to obtain details of how the NPVs were calculated and
review the source of data for those calculations.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
5 Analyzers
82
Figure 5.10 Market Data Shift
Figure 5.11 Results of Market Data Shift Calculations
5.2 Credit Risk Analyzer
The Credit Risk Analyzer enables you to control the risk of default by counterparties
and business partners. It also facilitates limit management for different types of risk
exposures, such as currency trading limits for front-office traders or the amount of
total exposure allowed for a counterparty or bank, by currency and legal entity. While
the Credit Risk Analyzer can be customized for specific limit management criteria
based on your particular requirements, typically the important default criteria are for
enforcing limits by legal entity for the following:
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
5 Analyzers
83
� Trading amount by trader
� Counterparty exposure
� Portfolio exposure
SAP S/4HANA can be set up to provide real-time alerts with hard stops or warnings if
any of the limits have been transgressed. End-of-day reports are also available to
review activity for the day and note whether any exceptions were encountered.
Although the Credit Risk Analyzer is an optional module, it plays a critical role in
ensuring good internal control and runs systemic checks to ensure operating policies
and guidelines established by the board or organization are complied with.
For example, Figure 5.12 shows the limit set up for counterparty bank (BKDT-
BANKDE), by period (effective from 01/01/2004 onwards), legal entity (company code
1000), and amount and currency (200,000,000 EUR). The system will create an alert
message if this limit is transgressed.
Figure 5.12 Limit Setup
An example of an online warning message when a limit is exceeded is shown in
Figure 5.13. This can also be set up as a hard stop message to prevent the user from
proceeding any further.
The end-of-day limit utilization report in the Credit Risk Analyzer shows that the
limit was exceeded by EUR 2,468,014 in the account at branch D-60325 (the third row
with the red traffic light on left, and exceeded amount on right) in Figure 5.14. Drilling
down on that item provides the detailed transactions that make up the amounts in
the limit exceeded, as shown in Figure 5.15.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
5 Analyzers
84
Figure 5.13 Warning Message of Limit Exceeded
Figure 5.14 End-of-Day Report of Limits Exceeded (I)
Figure 5.15 End-of-Day Report of Limits Exceeded (II)
5.3 Portfolio Analyzer
The Portfolio Analyzer provides tools to calculate the performance of an organiza-
tion’s investments against benchmarks. It can also measure actual versus target per-
formance and return on investment (ROI), maintain a yield book for comparative
analysis, and calculate value at risk.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
5 Analyzers
85
Reporting of portfolio performance is facilitated through the setup of portfolio hier-
archies, which can be grouped into various combinations depending on the report-
ing requirements. Figure 5.16 shows an example of various portfolio hierarchies, with
different combinations whose positions will be selected when the reports are exe-
cuted. Here you can see that portfolio hierarchy 300 is reporting by company code,
currency, business partner, and contract type. So, using this hierarchy, you can view
the portfolio for derivatives and money market in instruments, contracted through
CITIBANK, in USD for company code 3000.
Figure 5.16 Portfolio Hierarchies
5.4 Analytics
One of the biggest advantages of TRM with SAP S/4HANA is its advanced analytical
capabilities. Using speed, processing power, and big data in the system, SAP has pro-
vided tools to enable predictive, prescriptive, and preventative analytical applica-
tions to be built. Tools such as the Predictive Analytical Library (PAL) and Expert Ana-
lytics can be deployed in the cloud or on a desktop, making them cost-effective
additions that add high-value functionality to finance and treasury applications in
the system. Examples of advanced analytical applications that can be built using
standard-delivered or custom algorithms are cash forecasting, risk management, and
fraud prevention.
Let’s now look at some new analytical tools available in SAP S/4HANA.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
5 Analyzers
86
Bank Fee Analytics
Banks derive their banking income from corporate clients through three main
sources: service fees, float, and spread between borrowing and lending rates. The
Bank Analyzer app is available as a part of the Bank Account Management module
and is a recent addition to the suite of tools available in SAP S/4HANA. It enables an
organization to analyze and monitor the service fees being charged by their banks
and to compare them to contractually agreed-upon rates and thresholds. The applica-
tion is compatible with ISO 20022-based CAMT.086 files that are received from the
banks.
Figure 5.17 shows an example of a report generated by the bank fee analyzer that pro-
vides metrics around fees charged by the bank for the period under review. The bank
fee analyzer uses the master data set up in the Bank Account Management module,
which will be discussed in Section 6.1. So, for example, bank groups set up in Bank
Account Management for cash pooling purposes can also be used to report fee analy-
sis in the bank fee analyzer. The report is user driven and can be set up to report by
legal entity, bank, group of banks, or service fee type. In our example, the report
shows the bank fee analytics for two months, August 2017 for EUR 461.10 and June
2019 for EUR 490.60, by bank (BANK1) and bank key (routing number). The fees are
split by service type: service fees of EUR 694.70 and taxes thereon of EUR 257.00. A
graph on the top left of the screen shows the increase between the two time periods.
Figure 5.17 BankFee Analysis Report
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
5 Analyzers
87
Advanced Analytics
SAP has introduced advanced analytical tools to leverage the new architecture, pro-
cessing power, and access to big data in SAP S/4HANA. With tools like PAL and Expert
Analytics, which can also be accessed and deployed through SAP Business Technol-
ogy Platform, it’s possible to build applications for predictive and prescriptive analyt-
ics, fraud prevention, outlier analytics, and machine learning algorithms within the
finance and treasury modules in SAP S/4HANA. We’ll now look at an example of how
predictive analytics can be used in SAP S/4HANA to optimize working capital using
the Expert Analytics tool.
It’s estimated that corporations hold $1.6 trillion in excess working capital that can be
released to pay down debt, fund investments, and increase free cash flow. Working
capital optimization, then, is becoming a major source of internally generated financ-
ing and contributes to major initiatives in many corporations.
The use of predictive analytics in SAP S/4HANA can best be demonstrated with the
example of a prototype demo application built using SAP S/4HANA and its PAL and
Expert Analytics tools. We’ll use a sample set of fictitious customer data (50,000
records) to analyze the customer’s historic payment behavior patterns using test
data.
Based on the difference between the actual payment date and payment due date, the
model converts these into day sales outstanding (DSO) and average days deficit
(ADD) and calculates the opportunity loss of interest and cash flow due to late pay-
ments, based on past behavior, covering the time span under review. Further, based
on this information, the model uses time-series and auto-regression algorithms to
predict future payment patterns to calculate the potential future loss of cash flow
and interest to the organization, if past behavior were to continue and corrective
action isn’t taken.
This information can be summarized by customer, region, country, and so on; it
allows appropriate action to be taken by corporate or local managers to follow up
with regional heads or directly with the customers involved. Predictive models can
extract and analyze millions of rows of SAP table data in real time and provide
advanced analytical information for immediate proactive corrective action. While
this model uses receivables (one component of working capital) as an example, the
concept can be applied to any aspect of working capital management such as inven-
tory management or accounts payable. Similar algorithms can be used to enhance
the accuracy of cash forecasting or outlier detection algorithms to detect potential
fraud or exceptional activity that needs further investigation.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
5 Analyzers
88
The resulting output, shown in Figure 5.18, provides the following information,
ranked from highest to lowest:
� Based on historical payment dates, the actual opportunity cost of interest lost due
to late payments
� If historical payment behavior were to continue unchecked, and no corrective
action taken, the future potential opportunity loss of interest to the organization
Figure 5.18 Predictive Analysis Report of Historical and Potential Future Interest Opportunity Loss
Machine Learning
SAP has started developing machine learning applications for the finance function
that “learn” what actions to suggest based on historical data. Although this func-
tionality is still in its infancy, it will have benefits for treasury such as increasing
automatic matching of incoming bank statements with clearing information in the
system through learning based on historical matching.
Effective treasury management depends on multiple external relationships, and one
of the most important of these is the one with banking partners. In the next section,
we’ll look at bank relationship management features within TRM with SAP S/4HANA,
many of which are new in SAP S/4HANA.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
6 Bank Relationship Management
89
 
6 Bank Relationship Management
Bank relationship management is the confluence of processes and technology to
enable an organization to manage and track all its bank-related activities in a holistic
manner, enabled by systems and technology.
SAP’s offering for bank relationship management has matured and been consider-
ably strengthened in TRM with SAP S/4HANA with the introduction of new submod-
ules and functionality for bank account management, flexible workflow, foreign
bank and financial accounts reporting (FBAR), bank fee analytics, and bank signatory
maintenance, and has improved existing functionality around bank account cre-
ation, workflow approvals, and bank grouping for pooling and concentration.
Bank relationship management in SAP S/4HANA encompasses the Bank Account
Management and Bank Communication Management submodules that contain
most of the features mentioned previously. Let’s look at some of these in a bit more
detail, covering Bank Account Management in Section 6.1, Bank Communication
Management in Section 6.2, bank monitors in Section 6.3, and one of the new addi-
tions, FBAR reporting, in Section 6.4.
6.1 Bank Account Management
Bank Account Management is a new module in SAP S/4HANA that fills important
gaps in bank relationship management from previous versions of SAP ERP. Bank
Account Management is primarily used to create and maintain bank accounts that
are used in the system. This includes external banking relationships, as well as inter-
nal bank accounts used for in-house banking.
The Bank Account Management module enables the end-to-end process for creating
and maintaining a bank account with the following key functionality:
� Create, maintain, and close bank accounts.
� Maintain authorized signatories.
� Release approvals through flexible workflows.
� Create bank hierarchy grouping for reporting and bank fee analytics, cash concen-
tration, and cash pooling.
� Enable the file upload of bank data from external bank data providers.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
6 Bank Relationship Management
90
As with all areas within SAP S/4HANA, there is a clear audit trail for all transactions
and activities relating to bank account management.
Prior to SAP S/4HANA, creating house banks and bank accounts used to be a configu-
ration activity. In SAP S/4HANA, bank data is entered and managed by the end user as
part of master data. A house bank usually is tied to a specific branch or head office
with a unique routing number or SWIFT address. Creation of the house bank is a pre-
requisite before the bank accounts relating to the house bank can be created in Bank
Account Management.
6.2 Bank Communication Management
Bank Communication Management is a very useful module, but not a mandatory
one for a TRM implementation, although most companies do implement it sooner or
later. It controls outbound payment files, outbound SWIFT messages to banks and
counterparties, inbound receipt and processing of bank statements, and SWIFT con-
firmation messages.
Bank Communication Management adds many features such as batching payments,
approval and release workflows, and dashboards for monitoring the status of out-
bound and inbound files and messaging. You can think of Bank Communication
Management as the conductor of an orchestra: it sits on top of the payment engines
covered in Section 3.3 and manages the entire end-to-end process.
Let’s walk through the payment process when the Bank Communication Manage-
ment module has been activated:
1. After payment requests are created in payment processing, then payment requests
are batched and consolidated within Bank Communication Management based on
specific configurable criteria (e.g., legal entity, counterparty, currency, value date,
etc.).
2. At this stage, rules for approval canbe set up based on the type of transaction or
amount limits. So, for example, an amount below a certain threshold can be auto-
approved and go through for payment automatically, or if it falls between a certain
limit or over a certain limit, it will trigger an approval process, and the payment file
will only be sent after the authorized approver or approvers release the batch. The
approver can also reject the batch or part of the batch for amending and resubmit-
ting.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
6 Bank Relationship Management
91
3. Once approved and released, the payment files are sent to the middleware for for-
warding onto the payment network and through to the paying bank. The end-to-
end payment cycle is managed through the payment monitor dashboard.
4. Acknowledgment (ACK) and negative acknowledgment (NACK) messages will be
sent back by the bank, confirming the successful (ACK) receipt of the payment file
or rejection (NACK) of the file with reason thereof by the bank; these messages can
be uploaded into the payment monitor dashboard to update the status of that par-
ticular batch. A second level of acknowledgment after the payments have been exe-
cuted by the bank called the payment status report (PSR) confirms that the pay-
ment was successful. With this, the payment process is completed.
Figure 6.1 shows the Bank Communication Management application menu, which pro-
vides access to processing payments for merging and approval, messaging, workflow,
digital signatures, and status monitors, which we’ll review in the next section. These
functions are also available through the Bank Relationship tab on the SAP Fiori dash-
board.
Figure 6.1 Bank Communication Management Menu in SAP GUI
6.3 Bank Statement Monitor
In previous sections, we looked at the bank payment monitor and alert monitor. The
bank statement monitor is available for monitoring incoming electronic bank state-
ments and reporting on any exceptions or missing bank statements. It will also flag
errors in loading and balance mismatch with previous closing balance or general
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
7 Cash and Liquidity Management
92
ledger balance that will require follow-up action. A sample bank statement monitor
report is shown in Figure 6.2.
Figure 6.2 Bank Statement Monitor
6.4 Foreign Bank and Financial Accounts Reporting
Most corporations that maintain foreign currency balances and financial assets out-
side the United States must file an annual foreign bank and financial accounts (FBAR)
report. Information from the system to create this report (e.g., closing and maximum
balance can be extracted from selected bank accounts whose statements are avail-
able in the system for the period under review) is available through an SAP Fiori tile;
the data is exportable to Microsoft Excel, enabling completion and submission to the
US Department of Treasury. The report can be produced by legal entity, group of
banks or signatories, based on the bank accounts, hierarchies and authorized signa-
tories set up in Bank Account Management as part of master data.
In the next section, we’ll look at one of the most critical functions of treasury—cash
and liquidity management—with an overview of its highly integrated functionality
within TRM with SAP S/4HANA.
 
7 Cash and Liquidity Management
Cash is the lifeblood of a business. All productive assets that generate goods and ser-
vices are of little value if they don’t ultimately result in cash flow that pays the bills,
fuels further growth through reinvestment in the business, services debt, and pays
returns to shareholders in the form of dividends.
SAP’s cash module is tightly integrated with all modules in treasury and enables
short-term daily cash positioning, and medium- to long-term liquidity forecasting
that incorporates all financial information available in the system in the other mod-
ules such as logistics, sales, and finance. It also integrates with SAP’s payment engine
and the Bank Communication Management and In-House Cash modules.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
7 Cash and Liquidity Management
93
The types of cash management, forecasting, and analytical inputs that comprise the
cash management and forecasting cycle are daily cash positioning and longer-term
liquidity planning and forecasting. As shown in Figure 7.1, they form the basis of the
output of forecast and analytical reports to enable cash and liquidity management in
the short-, medium-, and long term.
Figure 7.1 Cash Forecasting Cycle
In Section 7.1, we’ll look at cash positioning for immediate and short-term cash
requirements. Section 7.2 will cover the medium- to longer term cash-forecasting
horizon. We’ll conclude with Section 7.3 on In-House Cash, the submodule of TRM
with SAP S/4HANA that enables internal cash and payment management between
subsidiaries within a group.
7.1 Cash Positioning
Cash management in TRM with SAP S/4HANA can be performed at two levels:
� Cash positioning
Daily cash positioning looks at the immediate cash needs of the business and is
usually a timeframe of one to three days.
� Liquidity forecasting
Medium- to long-term liquidity forecasting can include all cash flows recorded in
the system based on value dates. This could include, for example, future treasury
flows from the Transaction Manager, accounts receivable, accounts payable, and
other logistical transactions (e.g., purchase orders and sales orders) if you want to
capture commitments even earlier in the financial supply chain.
The daily cash positioning process starts with the import of intraday electronic bank
statements and update of opening bank balances based on the early morning import
of prior day electronic bank statements. This information can be displayed on a cash
Daily cash
positioning
Liquidity
planning and
forecasting
Reporting and
predictive
analytics
CFA liquidity
forecast
SAP Fiori and
analytical
reports
Cash Flow
Analyzer (CFA)
cash position
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
7 Cash and Liquidity Management
94
position report that will also contain, in addition to the intraday information and
bank balances, cash flows both incoming and outgoing that are due in the Transac-
tion Manager for the period under consideration.
Additionally, the cash forecast will also display payment requests that are pending
for sending to the bank during the day. Manual entries called memo records can be
entered to update the cash forecast for any known payments or receipts that haven’t
yet been entered in the system.
Having ascertained the cash position and requirements for the day, the next steps are
to make investment or borrowing decisions with surplus or deficit requirements,
determining FX and hedging requirements, funding for corporate and subsidiary
operations, cash concentration, and pooling, to name a few. Daily cash operations
can be managed through the SAP Fiori dashboard shown in Figure 7.2; it allows a cash
manager to execute multiple tasks from within the dashboard, as well as get real-time
updates on cash position, risk analysis, status of bank statements received, manage
funding transfers, and so on.
Figure 7.2 SAP Fiori Dashboard for Cash Operations
After these decisions have been made, payments have to be executed, sent to the
bank, and acknowledged. A late-afternoon intraday statement can be received and
loaded to confirm the activity that has taken place during the day. It’s important to
note that only prior-day statements with the actual settled bank transactions post
into the system. Intraday statements don’t generate any general ledger postings but
only memo records that populate the cash forecasts and can be edited, deleted, or
modified, as required for forecasting purposes. With automation, it’s possible to
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
7 Cash and Liquidity Management95
achieve a high level of straight-through processing to enable the reports to be avail-
able first thing in the morning and updated as the day progresses. This means that
decisions can be made dynamically and in a real-time or near real-time environment.
Payment requests during the day will appear in the cash position report as it moves
through the payment process. It’s denoted by a classification called the planning
level, which can be uniquely identified with each type of stage in the flow.
1. The treasury transaction is created with cash flows, and the value date is based on
payment date.
2. The payment request is created on value date with planning level PR.
3. The payment is made, and the amount moves to planning level B2, which denotes
the bank clearing account. The bank clearing account is an intermediary account
that holds the amount pending receipt of the bank statement that confirms final
recording of the payment in the book of prime record.
4. The bank statement is received, uploaded, and posted, clearing the clearing
account referred to previously, and posting to the main bank account with plan-
ning level B0.
The integration of cash management with Transaction Manager is done through con-
figuration as part of a TRM with SAP S/4HANA implementation. A sample of a cash
position report is displayed in Figure 7.3, which shows cash balances on a particular
day, 01/08/2020, and forecast for two subsequent days, by various currencies.
Figure 7.3 Cash Position Report Sample
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
7 Cash and Liquidity Management
96
7.2 Liquidity Management
Liquidity forecasting builds on cash positioning information and enhances it with
liquidity items that are value dated in the future. It incorporates logistical informa-
tion such as accounts receivable and payable based on value dates, and future-dated
treasury payments extending out over the time horizon under review; it also uses
manual or integrated information from planning and other feeder systems to build a
comprehensive forecast. Each class of information is assigned to a liquidity item,
which is displayed in the Cash Flow Analyzer app reports. As shown in Figure 7.4,
logistical activity moves through the financial supply chain from as early as purchase
order generation through to settlement at the bank and reflected accordingly in the
forecast:
1. The purchase order is created. The value date is derived by the system based on the
payment terms.
2. The invoice is received. The value date on the cash forecast will be based on the due
date.
3. The payment request is created. The value date will be based on the payment
scheduled date.
4. The payment run is executed, and the file is sent to the bank.
5. The bank settles the payment and sends a prior day bank statement that shows the
payment that is uploaded and posted into the book of prime record.
Figure 7.4 Logistical Transaction Flow in Liquidity Forecast Report
The forecast can extend as far out as there is information in the system and is also
configured to pick up all future cash flows from the Transaction Manager, such as
interest payments, investments, redemptions, FX transactions, and so on, as well as
cash flows that aren’t related to Transaction Manager. It’s important to note that
the forecast is only as good as the information available in the system. With SAP
S/4HANA, SAP has introduced an integrated business planning module as part of the
cash and liquidity management module that is Microsoft Excel–based and allows dif-
ferent operating entities within the organization to input their plans; these can be
Purchase
order
created
Invoice
received
Payment
request
created
Payment run
executed; file
sent to bank 
Bank statement
received from
bank
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
7 Cash and Liquidity Management
97
extended to be included in the cash forecast. Plan data can be uploaded through a
Microsoft Excel template or entered manually.
Because reporting for cash positioning and forecasting in the legacy SAP system has
been quite rudimentary, most organizations have had to customize their reporting
depending on the needs of their business. SAP has tried to address this in SAP
S/4HANA, leveraging SAP Fiori applications to provide a greater variety of reporting
views and adding new tools such as the Cash Flow Analyzer app to enhance the UX
and enabling standard views for dynamic real-time cash management through one-
window SAP Fiori dashboards, an example of which is shown in Figure 7.5.
Figure 7.5 SAP Fiori Dashboard for Liquidity Management
Cash management in SAP S/4HANA is almost completely based on SAP Fiori. The
liquidity forecast is based on liquidity items that are assigned to general ledger
accounts, bank statements, and source documents. Manual entries are facilitated
through memo records that can be used to trigger trade requests for front-office trad-
ing. An example of a liquidity forecast is shown in Figure 7.6, which is the closing fore-
cast of daily EUR closing bank balances for the period 01/08/2020 to 02/02/2020. It
shows a stable cash balance until 01/22, when there is an inflow of $60.5K, and
another one on 01/31 for $27K, and an estimated closing balance on 02/02/2020 of
$240.23K.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
7 Cash and Liquidity Management
98
Figure 7.6 Liquidity Forecast Report
7.3 In-House Banking
The concept of in-house banking in a TMS is that rather than using external banking
relationships for intercompany transactions, a corporate in-house bank is created
with notional internal bank accounts for all subsidiary companies through which
corporate head office and subsidiaries transact between themselves and each other.
This reduces substantially the number of external banking relationships required
globally, resulting in reduced bank fees and cross-border FX conversion fees, as well
as exchange rate losses.
In SAP S/4HANA, in-house banking is provided by the In-House Cash module, one of
the most value-adding modules in the TRM with SAP S/4HANA suite. It allows a
global organization to manage all group and intercompany transactions using an in-
house bank, enabling payment and settlement of intercompany loans, dividends,
pay-on-behalf-of functionality, and receive-on-behalf-of functionality. One outcome
is a significant reduction in the need for external banking relationships and bank
accounts. Global corporations with operations in many countries benefit from
reduced bank fees, cross-border payment transfer costs, FX conversion costs, and effi-
ciencies in cash management, making In-House Cash a module with a high ROI from
a cost/benefit perspective. Although it’s tightly integrated with the treasury and
finance modules, it’s an independent module and typically implemented concur-
rently or subsequent to a treasury implementation.
The In-House Cash module enables transactions to take place internally, maintaining
current accounts between head office and subsidies as well as between subsidiaries
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
7 Cash and Liquidity Management
99
themselves; actual settlement can take place on a periodic basis depending on the
specific laws of the country in which the subsidiary is based.
For the purposes of external settlement, organizations must use external bank
accounts. So, typically, a group of legal entities within a country would have at least
one external bank account to be used for pay-on-behalf-of or receive-on-behalf-of
subsidiaries within the country, or within a trading area that uses a common cur-
rency such as the euro. Loans between subsidiaries can be set up with automatic mir-
roring, so that any borrowing by one subsidiary from another is automatically mir-
rored as an investment in the lending company’s book of record.
In-house banking can also be used to take advantage of transfer pricingand transfer
interest to help create profits for the overall entity by reducing taxes in some entities
as part of tax planning strategies.
In-house bank accounting can be set up to be fully automated and self-reconciling,
with internal current accounts getting updated daily through generation of internal
bank statements that can be loaded and posted in the same way as external bank
statements. Payments between subsidiaries are done using payment orders; these
are notional or cashless unless a physical payment is warranted (in which case, stan-
dard payment processes within SAP can be used).
The treasury payment method is used in in-house banking only when an external
payment is required, for example, pay on behalf to a vendor, or for making actual
cash payments between subsidiaries that will involve external bank accounts. Day-
end processing takes place daily to update the books of records with all the transac-
tions for the day, so that the In-House Cash current accounts, subledger, and general
ledger are posted and in sync. Additionally, internal bank statements are issued by
the internal house bank for upload into the various subsidiary’s accounts, just like
external bank statements. Because they are all part of an organization’s internal sys-
tems, these bank statements and payment orders are transferred between transact-
ing group entities using an SAP interface called Application Link Enabling (ALE).
Concentration, netting, pooling, and settlement activities can be executed on a daily
or periodic basis as required. When implementing the In-House Cash module, it’s
important to take into account the tax and legal requirements in specific countries
that may have restrictions around pay-on-behalf-of or cross-border transactions.
Accordingly, subsidiaries can be participating or nonparticipating entities; nonpar-
ticipating entities can still transact with participating entities, but they are subject to
the restrictions in place for that country and must be set up accordingly in the sys-
tem.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
7 Cash and Liquidity Management
100
Figure 7.7 shows the application menu for the In-House Cash module; it has subnodes
for major functions such as account management, cash management integration,
day-end and periodic processing, internal bank statement management, and cash
concentration.
Figure 7.7 In-House Cash Application Menu for Intercompany Operations
In-house banking day-end processing enables full accounting and reconciliation to
take place, with current accounts balanced and internal bank statements issued to
subsidiaries for uploading and updating their company code general ledger accounts.
The day-end processing flow is shown in Figure 7.8, where account balancing, cash
concentration, bank statement upload, and general ledger postings can be executed.
Month-end processing will need special processing with cut-off dates to allow for bal-
ancing and reconciliation for statutory reporting purposes.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
7 Cash and Liquidity Management
101
Figure 7.8 In-House Banking Day-End Processing
We’ve now covered the major functionality available in the key treasury submodules
of the Transaction Manager (Section 3), financial risk management (Section 4), the
analyzers (Section 5), bank relationship management (Section 6), and cash and liquid-
ity management (Section 7). A common overarching theme is the high level of inte-
gration internally between treasury and risk submodules, with the other modules in
SAP S/4HANA, and with the external environment. Indeed, this is one of the key fac-
tors when organizations choose a TMS. In the next section, we’ll provide a synopsis
with some scenario-based integration centric views of the TMS, the different types of
integration, and why integration continues to be a priority for SAP as it rolls out new
TRM functionality.
Set posting
date
Execute cash
concentration
Perform
account
balancing
Generate
bank
statements
Balance
notification
General ledger
transfer and
posting
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
8 Integration
102
 
8 Integration
Treasury is a dynamic function that ultimately touches every part of an organiza-
tion’s functions, from sales and purchasing to finance, accounting, and governance.
Additionally, it has multiple functional requirements for external connections such
as banks, brokers, counterparties, market data providers, third-party consolidators,
vendors, and customers.
As organizations streamline and implement best practices within their functional
processes, key drivers such as the elimination of manual processes, increased auto-
mation, and straight-through processing have arisen; integration between the vari-
ous touch points becomes vital to its success. It follows that any successful treasury
transformation will depend on the extent of automation of its repetitive and transac-
tional processing, which would allow treasury practitioners to focus on exception-
based and value-added activities. SAP recognizes this, as can be seen from its increas-
ing focus on automating as much of the treasury financial supply chain as possible,
through direct integration, or providing appropriate tools to enable the same result.
In Section 8.1, we’ll review some of the straight-through processing scenarios that
we’ve encountered so far, and in Section 8.2, we’ll look at some specific integration
interfaces that facilitate these processes.
8.1 Integration Scenarios
The following examples of treasury process flows we’ve already reviewed have the
potential for a high level of automation and straight-through processing:
� Integrated payment factory connecting transaction management with payment
engines, and processed through Bank Communication Management, Advanced
Payment Management, and SAP Multi-Bank Connectivity provide an end-to-end
seamless payment cycle
� Integration between exposure management, transaction management, and hedge
management; market data; and frontend trading platforms provide an integrated
solution for managing financial risk
� Intercompany loans and other internal transactions between group companies are
integrated with the Transaction Manager, as well as internal and external payment
processing
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
8 Integration
103
� Trade finance and collateral management is integrated with payment processing,
logistical information, and linked to facilities that are tied to trade finance instru-
ments
� All treasury modules and submodules operate as subledgers and are fully inte-
grated with cash and liquidity management as well as the general ledger
These are made possible through the various built-in connections and interfaces that
are part of TRM with SAP S/4HANA. Let’s look at some of these key interfaces.
8.2 Integration Interfaces
Integration in TRM with SAP S/4HANA is facilitated either through built-in systems
design and architecture for internal integration or through interfaces for integration
with the external environment. We’ll now look at how internal integration is
achieved within SAP S/4HANA and review some of the external applications that can
be integrated with SAP S/4HANA. Finally, we’ll explore SAP’s new cloud-based solu-
tion for bank connectivity, all in the context of treasury requirements,
Internal Integration
A TMS’s integration within SAP S/4HANA’s modules is primarily for financial
accounting, managerial accounting, and cash management visibility. This is facili-
tated through the use of common tables to capture, for example, exposure data
through One Exposure; merging financial, cost, project, and asset accounting infor-
mation in common tables; and using liquidity items to capture cash management
information for reporting and analytical purposes.
From a functional standpoint, this internal integration is facilitated through theabil-
ity to enter financial, costing, and project data within transaction management (e.g.,
cost center, profit center, WBS element, and portfolio), as well as enabling automatic
account assignment and derivation rules through the configuration process. All such
information is captured in tables such as the Universal Journal that contains all finan-
cial and management accounting data, or the One Exposure table that contains all
exposure-related items from various modules within SAP S/4HANA to be available
for hedge management purposes.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
8 Integration
104
The main internal integration areas with the TRM with SAP S/4HANA module and
function are as follows:
� FSCM
– Credit management
– Dispute management
– Collections
– Bill pay
� Finance
– General ledger accounting
– Cost object
– Project systems
– Accounts payable and receivable
� Logistics
– Materials
– Sales
– Purchasing
� Planning
– Budgeting
– Forecasting
Analytics External Integration
Treasury is one of the few functions that has the need for multiple external relation-
ships, with a high volume of transactional data that passes between them on a daily
or periodic basis. Each interface requires a different type of structure, format, connec-
tion, and business process.
The key external providers typically connected with TRM with SAP S/4HANA are as
follows:
� Market data providers of the following information:
– FX rates
– Commodity prices
– FX and interest rate volatilities
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
8 Integration
105
– Swap or forward rates
– Reference interest rates
� Banks acting in the following roles:
– Counterparty
– Custodians
– Brokers
– Bank data providers
� Third-party integrators providing the following:
– File consolidation services for electronic bank statements
– Acting as SWIFT messaging intermediaries
� Trading platforms for the following:
– Executing FX trades
– Purchasing or selling money market instruments
– Issuing or purchasing securities and debt instruments
– Trading commodities
Bank Connectivity
One of the options for bank connectivity that is new in SAP S/4HANA is a tool called
SAP Multi-Bank Connectivity. This cloud-based solution for bank connectivity con-
nects SAP S/4HANA and banking partners through direct host-to-host connection,
SWIFT Alliance Lite, or EBICS.
SAP Multi-Bank Connectivity’s inputs comprise payment requests out of TRM with
SAP S/4HANA arising from Transaction Manager transactions, in-house cash exter-
nal payments, bank-to-bank transfers, manual or free-form payments, payments
generated through the Advanced Payment Management submodule, and non-trea-
sury-related payments such as accounts payable, payroll, and so on. These inputs are
then processed through the system, and flow through to the banking environment
through SAP Multi-Bank Connectivity that is the link between the SAP S/4HANA sys-
tem and the external banking environment. Note that this is one of the options for
bank connectivity offered specifically by SAP. There are other middleware connectiv-
ity solutions available that can connect to payment and banking networks as well.
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
9 What’s Next?
106
 
9 What’s Next?
This introduction to treasury and risk management with SAP S/4HANA is just the
beginning. After this discussion of key data elements and core TRM processes in
transaction management, exposure management, and beyond, you’re now ready to
kick off your SAP S/4HANA Finance project or dive deeper into core TRM. SAP PRESS
resources are here to help!
Recommendation from Our Editors
Ready to survey the broader finance field? This introduction to SAP
S/4HANA Finance shows you next-generation finance in the new
suite: accounting, controlling, risk management, financial plan-
ning, and more. See how each process works in SAP S/4HANA, and
take your first steps toward financial transformation.
Visit www.sap-press.com/4784 to purchase your copy of SAP S/4HANA Finance: An Intro-
duction!
In addition to this book, our editors picked a few other SAP PRESS publications that
you might also be interested in. Check out the next page to learn more!
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
http://www.sap-press.com/4784 
 More from SAP PRESS
Central Finance and SAP S/4HANA
Start your CFin project! Learn how Central Finance fits in
to your IT landscape, and how it will impact your finance
processes, reporting, and master data. Get step-by-step
instructions for implementation and tips for project
management from this one-stop shop for everything
Central Finance!
606 pages, 2nd edition, pub. 01/2029 
E-book: $69.99 | Print: $79.95 | Bundle: $89.99
www.sap-press.com/5006
SAP S/4HANA Finance: The Reference Guide to What’s New
SAP S/4HANA has changed finance—but are you ready
for change? Consult the experts’ list of the most import-
ant innovations in SAP S/4HANA Finance. Evaluate their
impact on your business users’ daily routines, and learn
how to make SAP S/4HANA work for you.
505 pages, pub. 04/2019 
E-book: $69.99 | Print: $79.95 | Bundle: $89.99
www.sap-press.com/4838
SAP Treasury and Risk Management
The treasury and risk encyclopedia is here! Manage
financial risk more effectively with this comprehensive
guide to SAP TRM. Dig into transaction management,
position management, market data, and hedge manage-
ment in great detail. Learn how to maximize the poten-
tial of SAP Treasury and Risk Management!
1,114 pages, 2nd edition, pub. 04/2013
E-book: $89.99 | Print: $99.95 | Bundle: $109.99
www.sap-press.com/3166
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
http://www.sap-press.com/5006
http://www.sap-press.com/4838
http://www.sap-press.com/3166
1 
Usage, Service, and Legal Notes
Notes on Usage
This E-Bite is protected by copyright. By purchasing this E-Bite, you have agreed to
accept and adhere to the copyrights. You are entitled to use this E-Bite for personal
purposes. You may print and copy it, too, but also only for personal use. Sharing an
electronic or printed copy with others, however, is not permitted, neither as a whole
nor in parts. Of course, making them available on the Internet or in a company net-
work is illegal.
For detailed and legally binding usage conditions, please refer to the section Legal
Notes.
Service Pages
The following sections contain notes on how you can contact us.
Praise and Criticism
We hope that you enjoyed reading this E-Bite. If it met your expectations, please do
recommend it. If you think there is room for improvement, please get in touch with
the editor of the book: Emily Nicholls (emilyn@rheinwerk-publishing.com).
We welcome every suggestion for improvement but, of course, also any praise! You
can also share your reading experience via Twitter, Facebook, or email.
Technical Issues
If you experience technical issues with your e-book or e-book account at SAP PRESS,
please feel free to contact our reader service: support@rheinwerk-publishing.com.
About Us and Our Program
The website http://www.sap-press.com provides detailed and first-hand information
on our current publishing program. Here, you can also easily order all of our books
and e-books. Information on Rheinwerk Publishing Inc. and additional contact
options can also be found at http://www.sap-press.com.
© 2024 by Rheinwerk Publishing Inc., Boston (MA)
http://www.sap-press.com
http://www.sap-press.com
mailto:emilyn@rheinwerk-publishing.com
Legal Notes
This section contains the detailed and legally binding usage conditions for this E-Bite.
Copyright Note
This publication is protected by copyright in its entirety. All usage and exploitation
rights are reserved by the author and Rheinwerk Publishing; in particular the right of
reproduction and the right of distribution, be it in printed or electronic form.
© 2021 by Rheinwerk Publishing,Inc., Boston (MA)
Your Rights as a User
You are entitled to use this E-Bite for personal purposes only. In particular, you may
print the E-Bite for personal use or copy it as long as you store this copy on a device
that is solely and personally used by yourself. You are not entitled to any other usage
or exploitation.
In particular, it is not permitted to forward electronic or printed copies to third par-
ties. Furthermore, it is not permitted to distribute the E-Bite on the Internet, in
intranets, or in any other way or make it available to third parties. Any public exhibi-
tion, other publication, or any reproduction of the E-Bite beyond personal use are
expressly prohibited. The aforementioned does not only apply to the E-Bite in its
entirety but also to parts thereof (e.g., charts, pictures, tables, sections of text). Copy-
right notes, brands, and other legal reservations as well as the digital watermark may
not be removed from the E-Bite.
Digital Watermark
This E-Bite copy contains a digital watermark, a signature that indicates which per-
son may use this copy. If you, dear reader, are not this person, you are violating the
copyright. So please refrain from using this E-Bite and inform us about this violation.
A brief email to info@rheinwerk-publishing.com is sufficient. Thank you!
Limitation of Liability
Regardless of the care that has been taken in creating texts, figures, and programs,
neither the publisher nor the author, editor, or translator assume any legal responsi-
bility or any liability for possible errors and their consequences.
1 
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.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 lan-
guage, without the prior consent of Rheinwerk Publishing, 2 Heritage
Drive, Suite 305, Quincy, MA 02171.
Rheinwerk Publishing makes no warranties or representations with
respect to the content hereof and specifically disclaims any implied war-
ranties of merchantability or fitness for any particular purpose. Rheinwerk
Publishing assumes no responsibility for any errors that may appear in this
publication.
“Rheinwerk Publishing” and the Rheinwerk Publishing logo are registered
trademarks of Rheinwerk Verlag GmbH, Bonn, Germany. SAP PRESS is an
imprint of Rheinwerk Verlag GmbH and Rheinwerk Publishing, Inc. 
All of the screenshots and graphics reproduced in this book are subject to
copyright © SAP SE, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany.
SAP, ABAP, ASAP, Concur Hipmunk, Duet, Duet Enterprise, ExpenseIt, SAP
ActiveAttention, SAP Adaptive Server Enterprise, SAP Advantage Database
Server, SAP ArchiveLink, SAP Ariba, SAP Business ByDesign, SAP Business
Explorer (SAP BEx), SAP BusinessObjects, SAP BusinessObjects Explorer,
SAP BusinessObjects Web Intelligence, SAP Business One, SAP Business
Workflow, SAP BW/4HANA, SAP C/4HANA, SAP Concur, SAP Crystal
Reports, SAP EarlyWatch, SAP Fieldglass, SAP Fiori, SAP Global Trade Ser-
vices (SAP GTS), SAP GoingLive, SAP HANA, SAP Jam, SAP Leonardo, SAP
Lumira, SAP MaxDB, SAP NetWeaver, SAP PartnerEdge, SAPPHIRE NOW,
SAP PowerBuilder, SAP PowerDesigner, SAP R/2, SAP R/3, SAP Replication
Server, SAP Roambi, SAP S/4HANA, SAP S/4HANA Cloud, SAP SQL Any-
where, SAP Strategic Enterprise Management (SAP SEM), SAP Success-
Factors, SAP Vora, TripIt, and Qualtrics are registered or unregistered
trademarks of SAP SE, Walldorf, Germany.
All other products mentioned in this book are registered or unregistered
trademarks of their respective companies.
Imprint
This E-Bite is a publication many contributed to, specifically:
Editor Emily Nicholls
Copyeditor Julie McNamee
Cover Design Graham Geary
 Icon made by Smashicons from www.flaticon.com
Layout Design Graham Geary
Production Graham Geary
Typesetting SatzPro, Krefeld (Germany)
ISBN 978-1-4932-2112-7
© 2021 by Rheinwerk Publishing, Inc., Boston (MA)
1st edition 2021
Personal Copy for Jennifer Ogbonna, jennyogbonna2@gmail.com
	The Author of this E-Bite
	What You’ll Learn
	1 Treasury Basics
	1.1 Treasury Management
	1.2 Treasury and Risk Management with SAP
	Core Functionality
	Structure and Application Menu
	Evolution of Treasury with SAP
	2 Treasury Data
	2.1 Master Data
	2.2 Transaction Data
	2.3 Market Data
	2.4 Treasury Data Examples
	Business Partner
	Securities Class
	3 Transaction Management
	3.1 Transaction Manager
	Processing
	Correspondence
	Workflow
	Netting and Linked Transactions
	3.2 Treasury Instruments
	Money Market
	Intercompany Loans
	Foreign Exchange
	Derivatives
	Securities
	Trade Finance
	3.3 Payment Factory
	Payment Formats
	Treasury Payments
	Bank-to-Bank Transfers
	Advanced Payment Management
	3.4 Accounting
	Clearing and Reconciliation
	Transaction Accounting
	Period-End Closing
	Local Accounting and Valuation
	3.5 Reporting and Monitoring
	4 Financial Risk Management
	4.1 Exposure Management
	4.2 Hedge Management
	Foreign Exchange Risk
	Balance Sheet FX Risk
	Interest Rate Risk
	4.3 Trading Platform Integration
	4.4 Hedge Documentation
	4.5 Hedge Accounting
	5 Analyzers
	5.1 Market Risk Analyzer
	Valuation
	Analytical Tools
	5.2 Credit Risk Analyzer
	5.3 Portfolio Analyzer
	5.4 Analytics
	Bank Fee Analytics
	Advanced Analytics
	Machine Learning
	6 Bank Relationship Management
	6.1 Bank Account Management
	6.2 Bank Communication Management
	6.3 Bank Statement Monitor
	6.4 Foreign Bank and Financial Accounts Reporting
	7 Cash and Liquidity Management
	7.1 Cash Positioning
	7.2 Liquidity Management
	7.3 In-House Banking
	8 Integration
	8.1 Integration Scenarios
	8.2 Integration Interfaces
	Internal Integration
	Analytics External Integration
	Bank Connectivity
	9 What’s Next?
	More from SAP PRESS
	Usage, Service, and Legal Notes
	Notes on Usage
	Service Pages
	Legal Notes
	Imprint
<<
 /ASCII85EncodePages false
 /AllowTransparency false
 /AutoPositionEPSFiles true
 /AutoRotatePages /All
 /Binding /Left
 /CalGrayProfile (Dot Gain 20%)
 /CalRGBProfile (sRGB IEC61966-2.1)
 /CalCMYKProfile (coated_FOGRA39_GCR_bas.icc)
 /sRGBProfile (sRGB IEC61966-2.1)
 /CannotEmbedFontPolicy /Warning
 /CompatibilityLevel 1.6
 /CompressObjects /Tags
 /CompressPages true
 /ConvertImagesToIndexed true
 /PassThroughJPEGImages false
 /CreateJobTicket false
 /DefaultRenderingIntent /Default
 /DetectBlends true
 /DetectCurves 0.1000
 /ColorConversionStrategy /sRGB
 /DoThumbnails false
 /EmbedAllFonts true
 /EmbedOpenType false
 /ParseICCProfilesInComments true
 /EmbedJobOptions true
 /DSCReportingLevel 0
 /EmitDSCWarnings false
 /EndPage -1
 /ImageMemory 1048576
 /LockDistillerParams false
 /MaxSubsetPct 100
 /Optimize true
 /OPM 1
 /ParseDSCComments true
 /ParseDSCCommentsForDocInfo true
 /PreserveCopyPage true
 /PreserveDICMYKValues true
 /PreserveEPSInfo true
 /PreserveFlatness false
 /PreserveHalftoneInfo true
 /PreserveOPIComments false
 /PreserveOverprintSettings true
 /StartPage 1
 /SubsetFonts false
 /TransferFunctionInfo /Preserve
 /UCRandBGInfo /Preserve
 /UsePrologue false
 /ColorSettingsFile ()
 /AlwaysEmbed [ true
 ]
 /NeverEmbed [ true
 ]
 /AntiAliasColorImages false
 /CropColorImages false
 /ColorImageMinResolution 150
 /ColorImageMinResolutionPolicy /OK
 /DownsampleColorImages true
 /ColorImageDownsampleType /Average
 /ColorImageResolution 300
 /ColorImageDepth -1
 /ColorImageMinDownsampleDepth 1
 /ColorImageDownsampleThreshold 1.50000
 /EncodeColorImages true
 /ColorImageFilter /DCTEncode
 /AutoFilterColorImages true
 /ColorImageAutoFilterStrategy /JPEG
 /ColorACSImageDict <<
 /QFactor 0.40
 /HSamples [1 1 1 1] /VSamples [1 1 1 1]
 >>
 /ColorImageDict <<
 /QFactor 1.30
 /HSamples [2 1 1 2] /VSamples [2 1 1 2]
 >>
 /JPEG2000ColorACSImageDict <<
 /TileWidth 256
 /TileHeight 256
 /Quality 10
 >>
 /JPEG2000ColorImageDict <<
 /TileWidth 256
 /TileHeight 256
 /Quality10
 >>
 /AntiAliasGrayImages false
 /CropGrayImages false
 /GrayImageMinResolution 150
 /GrayImageMinResolutionPolicy /OK
 /DownsampleGrayImages true
 /GrayImageDownsampleType /Average
 /GrayImageResolution 300
 /GrayImageDepth -1
 /GrayImageMinDownsampleDepth 2
 /GrayImageDownsampleThreshold 1.50000
 /EncodeGrayImages true
 /GrayImageFilter /DCTEncode
 /AutoFilterGrayImages true
 /GrayImageAutoFilterStrategy /JPEG
 /GrayACSImageDict <<
 /QFactor 0.40
 /HSamples [1 1 1 1] /VSamples [1 1 1 1]
 >>
 /GrayImageDict <<
 /QFactor 1.30
 /HSamples [2 1 1 2] /VSamples [2 1 1 2]
 >>
 /JPEG2000GrayACSImageDict <<
 /TileWidth 256
 /TileHeight 256
 /Quality 10
 >>
 /JPEG2000GrayImageDict <<
 /TileWidth 256
 /TileHeight 256
 /Quality 10
 >>
 /AntiAliasMonoImages false
 /CropMonoImages false
 /MonoImageMinResolution 1200
 /MonoImageMinResolutionPolicy /OK
 /DownsampleMonoImages true
 /MonoImageDownsampleType /Average
 /MonoImageResolution 300
 /MonoImageDepth -1
 /MonoImageDownsampleThreshold 1.50000
 /EncodeMonoImages true
 /MonoImageFilter /CCITTFaxEncode
 /MonoImageDict <<
 /K -1
 >>
 /AllowPSXObjects false
 /CheckCompliance [
 /None
 ]
 /PDFX1aCheck false
 /PDFX3Check false
 /PDFXCompliantPDFOnly false
 /PDFXNoTrimBoxError true
 /PDFXTrimBoxToMediaBoxOffset [
 0.00000
 0.00000
 0.00000
 0.00000
 ]
 /PDFXSetBleedBoxToMediaBox true
 /PDFXBleedBoxToTrimBoxOffset [
 0.00000
 0.00000
 0.00000
 0.00000
 ]
 /PDFXOutputIntentProfile (ISO Uncoated)
 /PDFXOutputConditionIdentifier ()
 /PDFXOutputCondition ()
 /PDFXRegistryName ()
 /PDFXTrapped /Unknown
 /CreateJDFFile false
 /Description <<
 /DEU <FEFF005B004200610073006900650072007400200061007500660020002200670061006C0069006C0065006F005F00650062006F006F006B005F007600330022005D0020007A00750072002000450072007300740065006C006C0075006E0067002000650069006E00650072002000660069006E0061006C0065006E0020005000440046002D004400610074006500690020006600FC0072002000640065006E00200045002D0042006F006F006B002D0057006F0072006B0066006C006F0077002E0020005A00690065006C0020006900730074002000650073002C00200064006900650020004400610074006500690067007200F600DF00650020006D00F60067006C006900630068007300740020006B006C00650069006E0020007A0075002000680061006C00740065006E00200028006400750072006300680020005200470042002D0046006100720062006500200075006E0064002000420069006C0064006B006F006D007000720069006D0069006500720075006E00670029002C0020006400690065002000420069006C0064007100750061006C0069007400E40074002000610062006500720020006700750074002000650072006B0065006E006E0062006100720020007A0075002000680061006C00740065006E002E00200073005200470042002D004600610072006200700072006F00660069006C00200077006900720064002000650069006E00670065006200650074007400650074002E002000480079007000650072006C0069006E006B0073002000770065007200640065006E0020006700670066002E0020006D0069007400670065006E006F006D006D0065006E002E0020004B006F006D007000610074006900620069006C0069007400E400740020006100750066002000500044004600200031002E0036002000650072006800F600680074002E0020004B006F006D007000720069006D0069006500720075006E006700200061007500660020004F0062006A0065006B0074006500620065006E00650020004D006100780069006D0061006C002E0020004100750066006C00F600730075006E0067002000610075006600200034003500300020006400700069002E>
 >>
 /Namespace [
 (Adobe)
 (Common)
 (1.0)
 ]
 /OtherNamespaces [
 <<
 /AsReaderSpreads false
 /CropImagesToFrames true
 /ErrorControl /WarnAndContinue
 /FlattenerIgnoreSpreadOverrides false
 /IncludeGuidesGrids false
 /IncludeNonPrinting false
 /IncludeSlug false
 /Namespace [
 (Adobe)
 (InDesign)
 (4.0)
 ]
 /OmitPlacedBitmaps false
 /OmitPlacedEPS false
 /OmitPlacedPDF false
 /SimulateOverprint /Legacy
 >>
 <<
 /AllowImageBreaks true
 /AllowTableBreaks true
 /ExpandPage false
 /HonorBaseURL true
 /HonorRolloverEffect false
 /IgnoreHTMLPageBreaks false
 /IncludeHeaderFooter false
 /MarginOffset [
 0
 0
 0
 0
 ]
 /MetadataAuthor ()
 /MetadataKeywords ()
 /MetadataSubject ()
 /MetadataTitle ()
 /MetricPageSize [
 0
 0
 ]
 /MetricUnit /inch
 /MobileCompatible 0
 /Namespace [
 (Adobe)
 (GoLive)
 (8.0)
 ]
 /OpenZoomToHTMLFontSize false
 /PageOrientation /Portrait
 /RemoveBackground false
 /ShrinkContent true
 /TreatColorsAs /MainMonitorColors
 /UseEmbeddedProfiles false
 /UseHTMLTitleAsMetadata true
 >>
 <<
 /AddBleedMarks false
 /AddColorBars false
 /AddCropMarks false
 /AddPageInfo false
 /AddRegMarks false
 /BleedOffset [
 0
 0
 0
 0
 ]
 /ConvertColors /ConvertToRGB
 /DestinationProfileName (sRGB IEC61966-2.1)
 /DestinationProfileSelector /UseName
 /Downsample16BitImages true
 /FlattenerPreset <<
 /ClipComplexRegions true
 /ConvertStrokesToOutlines false
 /ConvertTextToOutlines false
 /GradientResolution 300
 /LineArtTextResolution 1200
 /PresetName <FEFF005B0048006F006800650020004100750066006C00F600730075006E0067005D>
 /PresetSelector /HighResolution
 /RasterVectorBalance 1
 >>
 /FormElements false
 /GenerateStructure false
 /IncludeBookmarks false
 /IncludeHyperlinks true
 /IncludeInteractive false
 /IncludeLayers false
 /IncludeProfiles true
 /MarksOffset 6
 /MarksWeight 0.250000
 /MultimediaHandling /UseObjectSettings
 /Namespace [
 (Adobe)
 (CreativeSuite)
 (2.0)
 ]
 /PDFXOutputIntentProfileSelector /UseName
 /PageMarksFile /RomanDefault
 /PreserveEditing false
 /UntaggedCMYKHandling /UseDocumentProfile
 /UntaggedRGBHandling /UseDocumentProfile
 /UseDocumentBleed false
 >>
 ]
>> setdistillerparams
<<
 /HWResolution [450 450]
 /PageSize [476.220 680.315]
>> setpagedevice