Chapter 3

Setting Up Organizational Structures

Setting Up Organizational Structures

When you implement SAP Treasury in your company, you mold the application to
precisely meet your requirements by making customizing settings. This process of
making adjustments is supported by the SAP Implementation Guide (IMG) which
provides all the information and functions you need in the form of a tree structure.
Customizing primarily involves entering basic data, company-specific framework
conditions, the financial product types you use, and processing and calculation rules.
The flexibility of these settings allows you to represent your Treasury department in
the system regardless of whether it is group-wide or partially decentralized. The
settings additionally allow you to define various Treasury processes and flows.
A wide range of product types and related variables are available for representing
your business processes.

Customizing

When it comes to individually configuring processes, SAP customizing provides

a great deal of flexibility. Treasurys customizing settings allow you to represent
the necessary functional segregation between trading, back office and posting
activities as well as limit the product types used.

Fig. 3-1: Customizing molding SAP Treasury to individual company requirements

The most important control elements for configuring SAP Treasury are:

Control elements

Company organizational structures

Business partner concepts
Financial product types and their variables
Processes for recording and managing financial transactions
Principles for data transfer to financial accounting
The following sections describe the most commonly used organizational forms
and their conversion into SAP organizational elements.

3-1

Setting Up Organizational Structures

Organizational Forms
Treasury divisions are organized in many different ways. This ranges from fully
decentralized to centralized (e.g. Treasury coordination centers). The basic organizational forms are :
Decentralized organization
Centralized organization
Centralized and decentralized (mixed) organization.

Decentralized organization

Centralized organization

Divisions featuring fully decentralized organization are usually divided into enterprise areas, countries, or profit centers. Decentralized Treasury departments are solely
responsible for monitoring the cash flows and exposures specific to their areas and
undertake financial transactions on this basis. The only common elements in larger
enterprises are a standardized system for reporting to the central Treasury department and generally applicable instructions or specifications.
With this more risk-averse organizational form, short reaction times are the norm.
However the sizes of contracts in operational areas tend to be smaller and the
distribution of know-how tends to lead to a slight increase in personnel requirements.
Holding companies are often organized centrally. Here all areas of responsibility
from group-wide cash management to trading and management of financial transactions - are controlled by the central Treasury department which acts as an inhouse bank.
This organizational form results in netting effects in the group exposure and provides opportunities for comparing the cash flows between subsidiaries. As a consequence of group-wide control, financial transactions are concluded in the
corresponding contract sizes and transaction costs are kept to a minimum. In addition to this, currency-specific clearing is possible between the subsidiaries. With
this organizational form, only services, such as an additional, local cash management office, or the maintenance of contacts to local banks, are decentralized.

Mixed organization

3-2

This is the most commonly used organizational form in practice, although subsidiaries tend to undertake some financial transactions with the central Treasury
department and some directly with external partners. The underlying organizational structure varies from enterprise to enterprise, since the areas of responsibility
defined for subsidiaries depends on what is considered practical and advantageous.

Setting Up Organizational Structures

Fig. 3-2: Typical organization of the Treasury division in a group.

In this typical set-up, it is possible to access both the aggregated data for the entire
group and the data for the individual companies. The following examples, which
reflect typical financial transactions and liquidity planning requirements, show
what a range of possibilities need to be catered for:
Representation of currency exposure for one or more subsidiaries
Currency-specific clearing between subsidiaries
Internal financial transactions between group and subsidiary
External financial transactions between central Treasury department or subsidiary and banks
External financial transactions by the central Treasury department on behalf
of the subsidiary
When these requirements are represented in the system, two main questions need
to be born in mind:
From which organizational unit in the company are liquidity and risk positions viewed?
With which internal or external partner are financial transactions concluded?
On this basis you can decide which areas of responsibility you want to centralize
and which areas of responsibility you want to decentralize.

3-3

Setting Up Organizational Structures

Areas of Responsibility
The discussion as to how to distribute responsibilities and skills typically affects
the cash management, liquidity management and treasury management areas.

Banking policy and

payment processing

Banking policy is a key question in Cash Management. In particular, you need to

decide which bank details are maintained globally and which are maintained
locally. Another key question is what form payment processing is to take and which
steps you want to be automatic.

Investment and
borrowing policy

For liquidity management you need to decide on your short- to mid-term investment and borrowing policy. Larger groups need to specify whether financial investment and borrowing decisions are made for the whole enterprise or per
individual company. In this context you also need to decide which financial transactions are permitted.

Interest rate and currency

risk analysis

Because financial transactions are recorded in the money market, forex, derivatives, securities and loans areas, you can link these up to operational cash flows.
Moreover, SAP Treasury provides instruments for analyzing your interest rate
and currency risk as well as conventional and modern valuation procedures (such
as mark-to-market) and simulation procedures (such as Value at Risk).

SAP Organizational Elements

To implement the organizational scenarios described and achieve the required
range of evaluations, SAP Treasury uses the central organizational elements of the
SAP Enterprise Data Model. This ensures integration with other SAP applications
and the use of common terminology. The central organizational elements of the
SAP Enterprise Data Model are:
Company code
Chart of accounts

Company code

This is the smallest organizational unit for which a complete self-contained set of
accounts can be drawn up for purposes of external reporting. The process of external reporting involves recording all relevant transactions and generating all supporting documents for financial statements such as balance sheets and profit and
loss statements.
For Treasury, the company code is an organizational unit in the group, in whose
name financial transactions are executed. You assign each financial transaction to
a company code. The company code, together with the chart of accounts, are the
organizational elements which ensure integration with SAP Financial Accounting. Using the company code as your analysis unit you can begin to represent
parts of the described organizational structures in the system.
You can define each enterprise area (such as subsidiary, central Treasury
department) as a company code.
You can assign each financial transaction to one company code respectively.

3-4

Setting Up Organizational Structures

Fig. 3-3: Cash position in Treasury across various company codes as well as internal and
external financial transactions

For each company code (that is, for each individual company or division) you
can also carry out liquidity and risk evaluations on a cross-company code
basis (reflecting a group view).
You can display views of the foreign currency exposure of a subsidiary as well
as views of the aggregated currency position across the entire group (that is,
for all subsidiaries).
You can run the flexible financial transaction evaluations to acquire a list of
closed forward exchange transactions or a list of expiry dates for OTC
options, for example either individually, per company code, or across all
company codes.
In line with accounting principles, a standardized system of accounts is required to
ensure the orderly transfer of data to Financial Accounting. The chart of accounts
defined by the accounting department is a system of accounts for recording values
and value flows which helps to ensure orderly accounting. Your chart of accounts
should be designed in such a way that it ensures precise assignment of transactions
to accounts together with reporting in the respective balance sheet and profit and
loss items (in compliance with commercial and tax law). Each company code is
assigned to a specific chart of accounts.

Chart of accounts

3-5

Setting Up Organizational Structures

Account assignment
references and
account determination

In SAP Treasury, posting information is passed on to Financial Accounting using

account assignment references and account determination. In general, Treasury
uses the account structures and charts of accounts defined in Financial Accounting. You should use a standardized account structure which supports the level of
detail you require (via clearing accounts, for example).
A systematic chart of accounts also supports the representation of various Treasury organizational forms in the system. The following scenario gives an example
of how a partially centralized or decentralized structure could be represented:
The central Treasury department and the connected companies are defined as
company codes and use a common chart of accounts.
The common chart of accounts contains the accounts for all enterprise divisions. Typically these are Intercompany clearing accounts specially created
for the Treasury area per currency and subsidiary.
This account structure allows you to carry out currency-specific account clearing or netting within Cash Management across all subsidiaries; the component automatically takes care of the corresponding account transfers.
You can calculate interest for the accounts.
Within this chart of accounts, you can define a clearing account structure which
makes it possible for postings between the central Treasury department and a
subsidiary to be recorded. If a subsidiary invests money at the central Treasury, it will manage this as a financial transaction; when the payments are posted, the transaction is settled with the central Treasury via a clearing account.
The process is mirrored at the central Treasury department.
You can run flexible evaluations which incorporate both internal transactions
and financial transactions with external banks. At the same time you can reaggregate the analysis data across various company codes.

Using the company code and the chart of accounts you can represent various organizational forms and ensure integration of Treasury with other SAP applications.

You can make further refinements in SAP Treasury by defining Treasury-specific

organizational elements. In addition to the described organizational structures,
you could represent financial transactions in such a way that both internal transactions and external transactions with banks can be undertaken with the central
Treasury department, for example.

Business partners

3-6

The organizational element business partner has its roots in the business partner
concept. A business partner is an organization or private individual in which you
have a business interest. In Treasury you undertake financial transactions with a
business partner. Typical partners might be banks or a central Treasury department. You assign roles (or functions) to your business partner (such as counterparty, issuer, paying bank or borrower), which reflect the roles of the partner in
the transactions undertaken. Each business partner may be assigned several roles.
You can display an overview of your relationships with business partners in a tree
structure.

Setting Up Organizational Structures

You can use transaction authorizations to ensure that only transactions of a certain product type are concluded with a business partner.

Transaction authorizations

You can store standing instructions for your business partner. If, for example, you
want to always use the same bank and payment details for a business partner and
certain product types, you can define standing instructions so that the relevant
information is automatically inserted. The further automatic processing which is
based on this, provides great scope for rationalizing processes.

Standing Instructions

If you apply the business partner concept to the described organizational structures, the following is the result:
The central Treasury department, which undertakes financial transactions with
external banks as business partners, is defined as a company code and as a
business partner.
Each company code can conclude transactions with a business partner.
The company codes central Treasury or subsidiary can therefore conclude
external transactions with the business partner external bank.

Fig. 3-4: External financial transactions

You can specify that internal financial transactions between the company codes
(such as a subsidiary) and the internal business partner (such as the central
Treasury, as an in-house bank) can be concluded.

3-7

Setting Up Organizational Structures

Fig. 3-5: Internal financial transactions

Such an organizational structure has the following advantages for the central
Treasury department and the subsidiaries:
The central Treasury department can conclude financial transactions with both
the external banks and the subsidiaries.
Each subsidiary can conclude financial transactions both at an external bank
and internally at the central Treasury. You can also represent the central Treasurys transactions with the subsidiary.
You can use the transaction authorization concept to only allow certain financial transactions between subsidiaries.

Securities account
Portfolio

In addition to structuring how Treasury is organized, you need to decide how to

structure your financial transaction management. For transaction management,
the Treasury system borrows the terms securities account and portfolio.
Securities accounts help you administer your securities positions and typically
reflect actual securities accounts held at banks.
A portfolio is an organizational unit within the company code which you can use to
group together financial transactions and positions and evaluate aggregate positions. Portfolios allow you to group financial transactions according to traders or
product types, for example. In the securities area, you can additionally use portfolios for valuation purposes, such as calculate the average price of securities purchases
on portfolio level. More generally, you can set up a valuation or position management hierarchy by assigning individual financial transactions to portfolios, or securities positions to securities accounts, which in turn are assigned to portfolios.
Grouping transactions and positions into portfolios is also a Risk Management instrument which you can use to control and evaluate the risk positions of your company.

By combining these Treasury-specific organizational elements with those from Financial

Accounting, you can represent internal and external financial transactions as well as numerous evaluations for liquidity and risk positions.

3-8

Setting Up Organizational Structures

Treasury Workstation
In addition to the described possibilities for structuring the way individual company units are organized, you can also represent physical distribution scenarios
in the system. Perhaps different company units are represented in local systems
and these need to be brought together for liquidity control or to ensure the correct
conclusion of financial transactions. This is relevant for:

Distribution scenarios

Companies that use an R/2 System for operational parts of their information
processing such as procurement, sales and distribution or accounting.
Head offices of groups that determine the cash position of their subsidiaries
by collecting information from various R/2 and R/3 Systems.
At the same time, you want to use the Treasury functions so that you can adequately represent your financial transactions. The problem is that integrating information from operational goods and services processes into central cash management
decisions is very time-consuming. So that your requirements can be met, the SAP
components provide several ways of acquiring the requisite information from the
basic systems.

Fig. 3-6: Treasury workstation

The SAP R/3 System to which the liquidity information is imported is generally
known as the Treasury workstation. The interface both in the transporting
system and in the Treasury workstation is Cash Management. The transporting
(or basic) system captures the current cash position of the operational areas and
calls the relevant dataset at defined points in time in order to transfer the information to the Cash Management application in the Treasury workstation.

Treasury
workstation

3-9

Setting Up Organizational Structures

Cash position

In the Treasury workstation you can carry out aggregated evaluations of the cash
position. This means that, even with a distributed physical set-up, you can run
global evaluations covering different organizational units such as the various
company codes or subsidiaries in the group structure shown.

Financial transactions

You manage your financial transactions entirely in the Treasury workstation, that
is, in the R/3 System. There, in addition to a broad range of product types, you
can make use of all the Treasury administration functions provided. These support the complete process cycle from trading through back office processing to
the transfer of data to Financial Accounting. Market Risk Management, moreover,
provides you with an integrated view of your risk positions, as well as various
risk valuation methods. Once the transactions have been transferred to Financial
Accounting, you can use special functions to transfer the relevant accounting
information to the operational systems. Parts of the General Ledger are maintained in the Treasury workstation and updated by the postings in Treasury Management. The relevant documents are transferred to the General Ledger of the
basic system (R/2 or R/3) from these R/3 accounts.

Coupling scenarios

The previous section described the logical coupling alternatives in the Treasury
workstation. The following section describes the technical coupling alternatives
via which data transfer between distributed systems can take place:
You can use reports or transactions which employ Application Link Enabling
(ALE) technology to couple operational R/2 or R/3 applications with the Treasury workstation. The reports ensure that cash management data can be transferred to the Treasury workstation.
You can also use ALE technology to transfer relevant accounting information
from the Treasury workstation back to the operational system.
SAP is planning to support further Treasury scenarios to supplement these distribution scenarios. The reflection of financial transactions between head offices and
subsidiaries is a key issue here, as are possibilities for coupling up with non-SAP
systems. In the next few years, the various distribution scenarios will gradually
become accessible via the Internet, thereby extending the technical possibilities
offered by the R/3 System.

With the Treasury workstation you can represent distributed enterprise scenarios in the
system and thus analyze and compare individual and cross-enterprise liquidity and risk
positions.

3-10