SAP IN-HOUSE CASH (FIN-FSCM-IHC)

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_erp60_sp/helpdata/en/39/239739f4e38a2ce10000000a11402f/frameset.htm

Created on March 12, 2014

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure.
Subtopics from other structures are not included.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You
can manually download the missing subtopics.

© 2014 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any
form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior
notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software
vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP
Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the
express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or
registered trademarks of SAP AG in Germany and other countries. Please see www.sap.com/corporate-
en/legal/copyright/index.epx#trademark for additional trademark information and notices.

PUBLIC Page 1 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 TABLE OF CONTENT
1 SAP In-House Cash (FIN-FSCM-IHC)
1.1 Bank Area
1.2 Current Account Master Data
1.2.1 Business Partner in the Current Account System
1.2.2 Conditions
1.2.2.1 Creation of Conditions
1.2.2.1.1 Creating Conditions
1.2.2.1.1.1 Creation of Interest Conditions
1.2.2.1.1.1.1 Interest Calculation Method
1.2.2.1.1.2 Creation of Charge Conditions
1.2.2.1.1.2.1 Period Charge Not Based on Balancing
1.2.2.1.1.2.2 Direct Charge
1.2.2.1.1.2.3 Posting Charges Separately
1.2.2.1.1.3 Creation of Value Date Conditions
1.2.2.1.1.4 Scaled Conditions
1.2.2.1.1.4.1 Creation of Scaled/Interval Condition Items
1.2.2.1.1.5 Creation of Markup and Markdown Conditions
1.2.2.1.2 Creating Condition Items
1.2.2.1.2.1 Special Features of Interest Condition Items
1.2.2.1.2.2 Special Features of Charge Condition Items
1.2.2.1.2.3 Special Features of Value Date Condition Items
1.2.2.1.2.4 Special Features of Scaled/Interval Conditions
1.2.2.2 Changing Conditions
1.2.2.3 Releasing Conditions
1.2.2.4 Deleting Conditions
1.2.2.5 Releasing Deleted Conditions
1.2.2.6 Assigning Standard Conditions to an Account
1.2.2.6.1 Assigning Standard Conditions to a Condition Group
1.2.2.6.2 Assigning a Condition Group to an Account
1.2.2.6.3 Interest Calculation Method
1.2.2.6.3.1 Days Calculation Method: 360
1.2.2.6.3.2 Days Calculation Method: 360E
1.2.2.7 Creating Individual Conditions
1.2.2.8 Releasing Individual Conditions
1.2.3 Limits
1.2.3.1 Additional Limit Functions in SAP In-House Cash
1.2.3.2 Assigning Limits to an Account
1.2.3.3 Releasing Limits
1.2.3.4 Deleting Limits
1.2.4 Product Definition
1.2.4.1 Product Configurator
1.2.4.2 Creation of Products
1.2.4.3 Management of Products
1.2.5 Account
1.2.5.1 Creation of Accounts
1.2.5.1.1 Creating an Account
1.2.5.1.2 Maintaining Basic Data
1.2.5.1.3 Maintaining Balancing Data
1.2.5.1.4 Maintaining Limits
1.2.5.1.5 Maintaining Holds
1.2.5.1.6 Maintaining Details on Payment Transactions
1.2.5.1.7 Maintaining Bank Statement Data
1.2.5.1.8 Maintaining Control Data
1.2.5.1.9 Maintaining Administration Data
1.2.5.2 Displaying an Account
1.2.5.3 Changing an Account
1.2.5.4 Creation of a Reference Account for Balancing
1.2.5.5 Creation of a Reference Account for Account Closure
1.2.5.6 Account Locks
1.2.5.6.1 Assigning Locks to an Account
1.2.5.6.2 Removing Locks from an Account
1.2.5.7 Creating Account Hierarchies
1.2.5.7.1 Creating an Account Hierarchy for Interest Compensation
1.2.5.7.2 Creating an Account Hierarchy for Cash Concentration
1.2.5.7.3 Creation of an Account Hierarchy with a Template
1.2.5.7.3.1 Creating an Account Hierarchy with a Template
1.2.5.7.4 Displaying an Account Hierarchy
1.2.5.7.5 Changing an Interest Compensation Account Hierarchy
1.2.5.7.6 Changing a Cash Concentration Account Hierarchy
1.2.5.8 Closing Accounts
1.2.5.9 Reactivating an Account
1.2.6 Euro Changeover
1.2.6.1 Changeover of the Account Currency
1.2.6.1.1 Changing Over an Account
1.2.6.1.2 Changing Over an Account after Account Balancing
1.2.6.2 Payment Transactions in the Dual Currency Phase
1.2.6.3 Display Options for Turnovers and Amounts
1.2.6.4 Overview of Currencies Posted for Balancing
1.3 Account Management and Manual Editing of Items
1.3.1 Route Processing for External Payments

PUBLIC Page 2 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.3.1.1 Editing Route Processing
1.3.2 Payment Item
1.3.2.1 Creating Payment Items
1.3.2.2 Creating Payment Items (Special)
1.3.2.3 Processing Items in Postprocessing
1.3.2.4 Postprocessing Payment Items
1.3.2.5 Processing Payment Items on a CpD (Suspense) Account
1.3.2.6 Reversing Payment Items
1.3.2.7 Displaying Payment Items
1.3.2.8 Payment Items "on Standby"
1.3.2.9 Releasing Payment Items
1.3.3 Planned Item
1.3.3.1 Processing Planned Items
1.3.4 IHC Payment Order
1.3.4.1 IHC Payment Orders Versus Payment Orders
1.3.4.2 IHC Payment Order Browser
1.3.4.3 Creating an IHC Payment Order
1.3.4.4 Editing IHC Payment Orders
1.3.4.5 Displaying IHC Payment Orders
1.3.4.6 Displaying a Payment Order
1.3.5 Forwarding Instructions for the House Bank
1.3.5.1 Editing Instructions
1.3.6 Processing Foreign Currencies
1.3.7 Business Workflow
1.3.7.1 Executing Workflow for Payment Items
1.3.8 Returns
1.3.8.1 Returning a Payment Item
1.3.8.2 Free Returns
1.3.9 Forcing Postings with the Feeder System
1.4 Periodic Tasks
1.4.1 Process Flow of End-of-Day Processing
1.4.1.1 End-of-Day Processing as Event Control
1.4.1.2 Establishing a Job Chain
1.4.1.2.1 Proposal: Process Flow of End-of-Day Processing
1.4.1.2.2 Maintenance of Selection Variables in the TVARV Table
1.4.1.3 Displaying an Overview of Mass Runs
1.4.1.4 Displaying an Overview of Locked Accounts
1.4.2 Setting the Posting Date
1.4.3 Account Balancing
1.4.3.1 Balancing Accounts
1.4.3.2 Early Balancing
1.4.3.3 Interest Compensation
1.4.3.3.1 Interest Compensation Process
1.4.4 Bank Statements
1.4.4.1 Executing a Bank Statement Run
1.4.4.1.1 Creating Bank Statement Duplicates
1.4.4.2 Generating Balance Notifications
1.4.5 General Ledger Integration
1.4.5.1 Executing Balance Sheet Preparation
1.4.5.2 Executing Accrual/Deferral of Interest/Charges
1.4.5.3 Transferring Postings to the General Ledger
1.4.5.4 General Ledger Transfer After Currency Changeover
1.4.5.5 Postings on the FI General Ledger
1.4.5.6 Handling the Netting of Accounts
1.4.6 Cash Concentration
1.4.6.1 Process Flow of Cash Concentration
1.4.6.1.1 Cash Concentration (Example)
1.4.6.1.2 Cash Concentration / Clearing Accounts
1.4.6.1.2.1 Creating a Cash Concentration Hierarchy (Example)
1.4.6.1.3 Simulating Cash Concentration
1.4.6.1.4 Cash Concentration: Restarting a Run
1.4.7 Tolerated Overdraft
1.4.7.1 Executing a Monitoring Run
1.4.7.2 Executing Notification
1.4.7.3 Displaying Tolerated Overdrafts
1.4.8 Changing Business Partners
1.5 Information System
1.5.1 Creating Condition Histories
1.5.2 Displaying the Balance List
1.5.3 Balance List by Key Date

PUBLIC Page 3 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1 SAP In-House Cash (FIN-FSCM-IHC)

Purpose
SAP In-House Cash is used for processing internal and external payment transactions within a group or company. By using SAP In-
House Cash you can reduce the number of external bank accounts you hold and the volume of foreign payments you have to make.
SAP In-House Cash is implemented at a central location within a group of companies, for example, in head office.
With SAP In-House Cash, you can process the following transactions:
· Internal payments
· Central payments
· Local payments
· Central incoming payments
The following graphic shows the flow of data within a group of companies that uses SAP In-House Cash in its head office.

Implementation Considerations
To use the In-House Cash functions, make the necessary system settings in the Implementation Guide (IMG) by choosing Financial
Supply Chain Management → In-House Cash.
Make the following settings in the implementation guide (IMG) under Financial Accounting for the subsidiary companies and head office.

This documentation refers to the new functions in SAP ERP2004. If under exceptional circumstances, you do not use these functions,
you can refer to the documentation for previous release (SAP Enterprise 4.70) of SAP In-House Cash in the SAP Help Portal.

Integration
SAP In-House Cash is connected to the head office's Financial Accounting (FI) system, and uses its functions, such as the payment
program. The affiliated companies also use Financial Accounting (FI) functions. For instance, they also use the payment program to
clear open items. The IDocs generated as a result automatically forward payment orders to the in-house cash center. Electronic
account statements for the house bank of the head office can be imported to Financial Accounting (FI), and the data is passed on to
the in-house cash center. The affiliated companies also receive an account statement from the in-house cash center.
If you create an IHC financial status, you can forward this to SAP Cash Management.

Scope of Functions
The main component of SAP In-House Cash is the in-house cash center which processes payments between the various subsidiary
companies. The in-house cash center is basically a virtual internal bank where subsidiaries hold current accounts. Current account
processing depicts receivables and payables between the in-house cash center and affiliated subsidiary companies. It calculates the
turnover and balances of the current accounts and forwards this information in summarized form to Financial Accounting (FI).

You can decide to implement one or more in-house cash centers within your group of companies.
You can find the SAP In-House Cash functions on the SAP Easy Access screen under Accounting → Financial Supply Chain
Management → In-House Cash.

Example
The following graphic shows a group of companies, organized to enable both cross-bank-area and local payments:
· Two companies use SAP In-House Cash and both serve as internal banks for a certain number of subsidiary companies.
· They are also mutual clearing partners.
· Subsidiaries 3 and 4 carry out local payments as clearing partners for other subsidiaries.
International Group Structure

PUBLIC Page 4 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.1 Bank Area

Definition
The bank area is the central organizational unit of the current accounts system, in which complete and independent account
management and processing takes place. This means that the account numbers that exist in a bank area must be clear and
unmistakable.

In the case of SAP In-House Cash, an In-House Cash Center corresponds to a bank area. If there are more than one In-House Cash
Centers, you will need more than one bank areas.

Structure
By means of Customizing you must assign certain specifications to the bank area in which you work:
· the bank key - for example, the bank identification number in Germany (only for banks).
· the check digit method that controls or checks the issuing of account numbers
· the products you can use in this bank area
· the shift of the execution date for standing orders as a default setting
· the time at which posting cut-off is to be automatically executed every day
· the exchange rate category in which you store conversion rates in the system
· country, language and the public holiday calendar used
Special feature: Bank area and bank key
The bank key is particularly significant, as bank keys, along with the account number, are used for the processing of payment
transactions. All banks participating in payment transactions can be identified by a unique numerical labeling. In Germany, this bank key
is the eight-digit bank identification number. Branch offices either have their own bank identification number or one relating to their main
office. It is possible that the internal organization of a bank requires that the bank's structure is depicted in several bank areas.
One bank key can involve several bank areas.
An account number in all bank areas with the same bank key must be unique. The system checks that this is the case. In addition, this account number is
blocked in all bank areas belonging to the bank key to avoid the same account number being simultaneously created in different bank areas.

If the previous/feeder system transfers payment items, the bank area must first be determined by means of the bank key. The
system is equipped with suitable checks for this..

The case of bank areas not clearly being able to be determined only arises for payment items forwarded externally. If such a
payment item is forwarded per BAPI to the current account system and the system cannot determine the bank area, the BAPI is
terminated with the return code system error. This means that no items are processed.

Integration
The bank area, as central element, affects almost every unit of the system.

PUBLIC Page 5 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 If you use SAP FI, you must assign exactly one company code to a bank area. It is possible for several bank areas to be assigned to a
company code, but not several company codes to a bank area.

1.2 Current Account Master Data

Purpose
Normally you create master data once, and this then serves as point of reference for transaction data. However, if necessary, it is possible to make changes.
Master data forms the data basis to enable you to work with the system.

Implementation considerations
You must first have created master data before you create transaction data for this master data.

Integration
The current account system uses the Financial Services Business Partner.

Scope of functions
The following components belong to the master data of current accounts:
Business partner
This data contains all details on business partners with whom a bank or the In-House Cash Center is affiliated. Business partners can be customers, other banks
or In-House Cash Centers, but also internal organizational units that, for example, assume the role of account manager.
Conditions
The master data of the conditions contains all the important information needed for interest and charge settlement of an account and also for value date activities
.
Limits
The master data of the limits is needed to restrict the amount-based drawing on an account and therefore affects account management.
Product definition
Products can be configured, step by step, much along the lines of a 'building block' principle. An account is characterized by the attributes of the freely definable
product assigned to it. Contained in the product are the possible conditions, relevant transaction types and functions, and also the media with which the customer
has access to the account.
Account
You create accounts as characteristic of a product. In the master data of an account you find all the important information on account management and on the
administration data.

Business Partner in the Current Account System

Definition
Bank Customer Accounts (BCA) uses the SAP Business Partner for Financial Services. For more information, see SAP Business
Partner for Financial Services. In this section there is a short description of the special features that you must be aware of when you use
the SAP Business Partner for Financial Services in Bank Customer Accounts (BCA).

Use
A business partner can have different roles for an account. The following standard roles are supported by the standard system:
· Account holder
A business partner in this role must be assigned to every account. As well as being a source of information, this business partner is also checked during
payment transactions. Only one account holder can exist for an account. If the account was opened for a group of persons, (a married couple, for example),

PUBLIC Page 6 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 you must define this as a separate business partner. You must assign the individual persons to the account accordingly as authorized drawers.
· Authorized drawer
An authorized drawer has the same access to the accounts as the account holder. The account holder is also the authorized drawer for the account. If the
account holder is not a natural person, you must specify at least one authorized drawer for the account.

In Customizing you can set the check for the existence of an authorized drawer when an organization is assigned as account holder.
The system runs the check by using a function module stored for event BKK_BKKA_EVENT_DCHCK_AUTH_AV. If you deactivate
this event in the business partner event control, the system does not run the check. See also: Events (Business Transaction
Events)

· Account maintenance officer

Organizational unit of the bank that is responsible for the management of the account. This is normally one of your employees.
· Bank statement recipient
If a bank statement recipient has not been specified, the account holder takes on this role. However, if a business partner is assigned in the role of bank
statement recipient, only this partner receives a statement, not the account holder. If you want the account holder to also receive a statement, create the
holder as another bank statement recipient. The account holder then receives a copy.
· Contact person
If the account holder is an organization, you can assign more than one contact person to an account. The assignment is purely for information purposes.
These roles are standard roles in the SAP Business Partner system. Use only the following standard roles delivered by the component:
· BKK010 Account Holder
· BKK020 Authorized Withdrawer
· BKK030 Bank Statement Recipient
· BKK200 Account Maintenance Officer
Validity Restriction
The validity of a role of a business partner is restricted in the system. When you create the business partner, it has unlimited validity in
this role from the system date of creation.
BCA enables you to shift the validity start into the past. You may only make a change for a future date if there are no active accounts for
this business partner.
You cannot directly change the Valid To date. This date is set to the account closure date when you close the account, if the business
partner in this role is not active in any other account.
Delete and Archive the Business Partner
You can delete a business partner in a role if the business partner is not active in this role in an account.
You can archive or delete business partners only if the business partner is not associated to an active account.
Total Commitment for a Business Partner
You can use the Total Commitment feature to view a cross-system summary of the accounts and contracts for a business partner, with
a limited amount of master data. You can also navigate to the account maintenance screen in Bank Customer Accounts from the Total
Commitment tab page.

1.2.2 Conditions

Use
A condition determines the basis for balancing in account balancing and payment transactions. Interest calculation, charge levying and
value date methods are controlled by conditions.
Each condition is of a certain category. This condition category determines the functions with which a condition is applied to the
calculation of charges, interest and the value dating. The customer can create additional condition categories, but these are not
recognized by the system unless you make additions to the standard system. The condition categories are divided into the following
groups: interest, charges and value date.
The following displays the condition categories supplied in the standard system:

PUBLIC Page 7 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Group Condition categories
Interest Debit interest
Debit interest is used for calculating the interest on debit
balances.
Credit interest
Credit interest is used for calculating the interest on credit
balances.
Overdraft interest
Overdraft interest is used for calculating the interest on amounts
that exceed the overdraft limit defined for the account. The
overdraft interest relates to the debit interest.
Transaction interest
The transaction interest is used for certain business transactions
such as returned debit memos, and relates to the transaction
type.
Commitment interest
Commitment interest is used for non-utilized limits. This is based
on the difference between overdraft limits and value date
balances.
Interest penalty
The interest penalty is used for amounts that are included in the
allowance, and is based on the transaction type. The penalty is
calculated when the withdrawal is made.
Bonus
The bonus calculation is enabled by business transaction event
00010860 in account balancing.
Charges Transaction charge
Transaction charges are levied for certain transactions and
depend on the operation.
Item charge
Item charges are levied for each item posted to an account.
Dispatch expenses
Dispatch expenses are levied for each bank statement sent out
(counter must be updated externally).
Account maintenance charge
Account maintenance charges are levied each time the account is
balanced.
Direct charges:
Direct charges can be levied for functions used on the account
(for example, account closure).
Value dating Value date
Value date conditions determine the point in time of the value
dating.
Value date subject to final payment
Subject to final payment conditions determine the inclusion of an
item in the subject to final payment balance.

Conditions are organized (as are condition groups and item counters) in condition areas. You need to assign a condition area to a
product in Customizing (the decision must be made globally). First you set up the condition areas and then, with the help of the Product
Configurator, you assign them to the product.

Structure
A condition consists of a condition header and one or more condition items (note on terminology: The condition header is described
in the system as a condition, which also applies in this documentation. The term Condition Header is only used if there is some doubt as
to whether the term Condition describes the condition header and condition items, or only the condition header).
In the condition you define what the condition is, the calculation methods it is based on, and the data that controls it.
Depending on Customizing, a condition can be time-dependent or static. For time-dependent conditions you must specify time periods
to which the header data to apply. Static conditions apply without restriction from the time the condition is created. Note that you cannot
change the condition data once the condition has been used to balance an account.
The condition items contain interest and charge rates and are always time-dependent, meaning that they have a certain validity period.
You can assign more than one condition item to a condition if:
· The condition items have differing validity periods. This means you can view the historical condition items for the condition at any time.
· The condition is scaled, whereby different conditions are defined for different areas of the assessment basis.
Example: The interest rate applied up to 10,000.00 is different from that applied to higher amounts.

PUBLIC Page 8 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 You assign a new condition to an account by means of a condition group (individual conditions are an exception to this) in which all
relevant standard conditions for a group of accounts are summarized.
A condition group always belongs to a certain condition group category. The standard system contains the categories Interest
Condition Group, Charge Condition Group and Value Date Condition Group.

Integration
You can assign certain conditions to a product by using the condition area for which the conditions were created. You define the
possible assignment in Customizing by choosing Master Data → Conditions → Basic Settings.
In Customizing, you can specify the duration of the interest guarantee for selected products when offers are created. Choose Master
Data → Conditions → Specify Periods for Interest Guarantee for Offers. If the account contract is created within this period, it is not
possible to change the conditions. Once this period has expired, you can decide whether the fixed interest is to still be transferred if a
contract is created.
Principle of dual control
Once you have created conditions, it is possible to prevent their use for balancing accounts until after they have been released by
another user with the appropriate authorization. In the Implementation Guide (IMG) you can decide to apply the principle of dual control
by choosing Master Data → Conditions → Basic Settings →Define Conditions (Dual Control Principle indicator).

1.2.2.1 Creation of Conditions

Purpose
You create conditions as basis for balancing and for payment transactions. It is important to identify the validity range for which you wish
to create a condition. The condition can be valid for all accounts of a product, it can be assigned to more than one account, or be
restricted as an individual condition to one account. The general procedure is described below, whereby there are a few special
features that apply to the assignment of standard conditions to products, and to individual conditions, but the basic process flow
remains the same.

Process Flow
1. You determine the condition area for which you create conditions. The condition area determines the products that are to be
affected by the conditions according to your customizing settings.
2. You select the condition category (such as Interest Condition, Charge Condition, or Value Date Condition) to be created and then
create a condition header. Next you define the basic calculation methods to be used, and specify whether you want to divide the
condition into levels.
To create more complex conditions, you can divide a condition category even further by using differentiation types. You can use any customer or account
attributes to divide the category. The combination of a condition category with the characteristic of a differentiation type (known as differentiation value) each
forms a new condition.

However, note that all conditions of the same condition category must have the same differentiation type and that each differentiation
value (or combination of two differentiation values) can only have one condition.

You can combine the condition category Transaction Charge and the differentiation type Transaction Type to control the calculation
of a transaction charge for each item according to the transaction type that created the item.

Condition category Differentiation type Differentiation value Amount

Transaction charge Transaction type Debit 0.30
Transaction charge Transaction type Credit 0.10
Transaction charge Transaction type Cash deposit 0.00

The use of up to two differentiation types enables more complex combinations.

The Periodic Charge condition category could, for example, be differentiated according to the creditworthiness of the customer and
the category of card used.

PUBLIC Page 9 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1. Diff. type 1. Diff. value 2. Diff. type 2. Diff. value Amount
Credit rating Good Card Debit card 10.00
Credit rating Good Card Credit card 15.00
Credit rating Good Card Customer card 0.00
Credit rating Poor Card Debit card 20.00
Credit rating Poor Card Credit card 30.00
Credit rating Poor Card Customer card 10.00

The following differentiation types are provided in the standard system: Transaction Type, Medium, Item Counter, Dispatch Expense Counter, Transaction
Type Category, Feature, Activity, Dynamic Balance, Term Unit Days/Month/Year and Term Level Month/Year. In Customizing you can also create other
differentiation types based on any kind of account or business partner attributes.
If you have defined your own differentiation values to calculate your balances for the term-dependent conditions and the bonuses in Customizing, you can also
use these as additional differentiation types (choose Master Data -> Conditions -> Differentiation Values -> Maintain Differentiation Values). You are
provided with a BTE for the calculation of the balances and bonuses. Account balancing includes the differentiation values for the terms.
3. You create condition items for this condition, in which you specify the validity term and the amount or the percentage rate of interest
or a charge. In the case of interest conditions you can choose between linear and exponential interest calculation. You must enter
several items for a condition if you want to specify different validity periods or if you want to create a condition with different levels (for
example, interest scale).
As a result, you have a condition master record, which you assign to one or more products using the condition area. You can assign a condition to a certain
group of accounts by using a condition group (for more information, see Assigning Standard Conditions to an Account).
If you activated the principle of dual control for conditions in Customizing, the condition cannot be used for a balancing until it is released
by another user.
For more information, see: Releasing Conditions.

1.2.2.1.1 Creating Conditions

1. Choose Conditions -> General Conditions (or the respective condition class)-> Edit, and choose the appropriate interest, charge or
value date condition category, and the condition area for which the condition is to apply. The following condition categories are
supported by the standard system:
Interest conditions Charge conditions Value date conditions
Debit interest Transaction charges Value date
Credit interest Item charges Subject to final payment value date
Overdraft interest Account maintenance charges
Transaction interest Direct charges:
Commitment interest Dispatch charges
Interest penalty
Bonus

2. The system displays an overview of all the conditions of the selected condition category already existing for this condition area.
Choose Conditions -> Create, or the appropriate button. Enter the name of the condition, the currency and, if required, a sort term.
3. To differentiate the condition using on certain characteristics of the account or the business partner, choose one of the preset
differentiation types and the corresponding value.
To further differentiate the condition, enter another differentiation type and the corresponding value.
If you have chosen time-dependency for conditions, you base the following settings on a certain time period. In this case, specify as of when the condition is
to apply.
4. For interest conditions and some charge conditions you can also make specifications regarding the calculation methods to be used.
5. For various interest and charge conditions you can scale the condition according to intervals. You can create the amount of interest,
for example, making it dependent on the size of the existing balance (scaled/interval conditions).
6. In the case of interest conditions you can choose between linear and exponential interest calculation. If you select the Exponential
Interest Calculation field, you specify exponential interest calculation for this condition item.
7. Choose Transfer. You have now created a new condition.
8. If the principle of dual control for conditions is activated, release the condition (Releasing Conditions).

1.2.2.1.1.1 Creation of Interest Conditions

When you create an interest condition, you need to specify its calculation methods. The following settings are available:
· Interest method

PUBLIC Page 10 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 You specify an interest calculation method.
· Linear interest calculation
If you do not select the field for exponential interest calculation, the system calculates the interest as follows:
Amount = calculation base amount x percentage rate / 100 x days / base days
· Exponential interest calculation
If you select the field for exponential interest calculation, the system calculates the interest as follows:
Amount = calculation base amount * ( q** (days / base days) - 1)
where
q = 1 + percentage rate / 100 (compounding factor).
When you create a transaction interest condition, you can specify an allowance for which no transaction interest is calculated.
When you create an overdraft interest condition, you can use the Additional Debit Interest indicator to calculate the interest that you
defined in the condition in addition to the debit interest defined for the account.
When you create an interest penalty condition you can define the number of days for which the interest penalty is to be calculated in
the Calculation Method of Interest Penalty field. The 90 and 900 day methods are implemented.

1.2.2.6.3 Interest Calculation Method

The interest calculation method determines according to which time-dependent basis interest is calculated for mid-year payments. The various methods take
differences in the length of the months and leap years into consideration in different ways.
The interest calculation method is defined by the quotients
days
---------------
daily basis
.
The methods for calculating the number of days of each calculation period (meaning the number in the counter) are:
ACT
The actual number of calendar days between two dates is calculated.
360
For this method the year is considered to have 360 days and a month 30 days. The 31st of a month is not considered to be an interest day.
Contrary to method 360E, the time from February 27 to February 28 is considered to be one day, the time from February 28 to March 1 as three days.
Example: Days Calculation Method 360
360E
For this method, used, for example, on the Euro market, the number of days results similarly to the formula above.
The number of days between two dates D1/M1/Y1 and D2/M2/Y2 is calculated as follows:
(Y2 - Y1)*360 + (M2 - M1)*30 + (D2 - D1)
The time between February 27 and February 28 of a year is calculated as three days.
Example: Days Calculation Method 360E
The following are defined for the daily basis (denominator value):
360
A year is considered to have 360 days.
365
A year is considered to have 365 days.
366
A year is considered to have 365 days, a leap year 366 days.
The system supports the following so far:
360E/360 (bank calendar Euro market)
360/360 (German method)
ACT/360 (French method)
ACT/365, ACT/366

Creation of Charge Conditions

When you create certain charge conditions you can calculate the charge in different ways. The following settings are available:
Free items: When you create an item charge, enter the number of posting items to be executed free of charge in each balancing
period. When the system balances accounts it deducts the number of free items from the item counter and thus charges for fewer items.
The number of free items must not exceed the total number of items.
Time period and time unit: When you create a periodic charge, enter the frequency (time period) for the charge. You define the time
unit in a separate field.
Example: A charge of 10.00 USD is incurred on a monthly basis (time period of one month). For a balancing period of three months,
therefore, a charge of 30.00 USD is levied.
When you create conditions for the calculation of item charges, note the following:
You need to create conditions for item charges as differentiation conditions. Choose the supplied differentiation type Item Counter. The
individual differentiation values correspond to the item counters defined in Customizing. The value of each counter is multiplied by the
respective charge amount. Any free items (see above) are taken into account.

PUBLIC Page 11 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Example:
There is an item counter for interest and charge items (free) and an item counter for all other items. These are to be charged at 0.05
USD.

The differentiation type would be Item Counter in this case. Specify a charge amount of 0 for the differentiation value of item counter
1 and a charge amount of 0.05 for the differentiation value of item counter 2.
The same applies to dispatch expenses (differentiation type dispatch expense counter).

Period Charge Not Based on Balancing

Purpose
It is possible to levy account maintenance charges in two different ways:
· Based on the defined balancing period
· Based on when they are due
The system uses the whole period to calculate the charge based on the balancing period. If the charge is levied based on when it is
due, the amount is related to the actual time period involved.
You can levy function of charges when they are due for opening and closing accounts, and when you change the balancing data.
You can define this charge for new accounts and also for existing account maintenance charges.

Function Description
An account maintenance charge is generally due on a monthly basis. When an account is opened or closed, however, the time period
on which the charge is based can differ from one month.
When you create an account maintenance charge, the Time Period, Time Unit, and Pro Rata Calculation fields allow you to adjust the
charge. If you use these fields, you can specify that the charge amount is not to be levied for the balancing period as a whole, but is only
to apply for a certain length of time.
Example of a period-based calculation:
Condition: 20 USD account maintenance charge for two months
Balancing period:
1 month -> 10.00 USD
2 months -> 20.00 USD
3 months -> 30.00 USD
Condition: 0.10 USD account maintenance charge for one day
Balancing period:
12/31/99 – 01/31/00 -> 3.10 USD
12/31/99 – 02/28/99 -> 5.90 USD
12/31/99 – 03/31/00 -> 9.00 USD

Procedure
1. Choose Conditions → Charges → Edit
2. Enter the condition area and choose Account Maintenance Charge as the condition category.
3. Choose Create Condition or double-click on an existing account maintenance charge.
4. Enter the Valid From date.
5. Enter the time period and the time unit.
This data means that the charge amount is not calculated for the whole balancing period, but proportionately.
6. Specify whether the calculation is to be pro rata.
The system uses this field to determine how the remaining days are to be dealt with. You have three alternatives to choose from:
· No inclusion: The charge is only levied for the full months.
· Full inclusion: The whole charge is levied for an additional full month.
· Pro rata calculation: The system calculates the charge amount proportionately for the remaining days.
Example without pro rata calculation:
Condition: 10.00 USD account maintenance charge for one month
Period for balancing: Two months and 15 days
No inclusion 20.00 USD
Full inclusion 30.00 USD

Example of pro rata calculation:

Condition: 20 USD account maintenance charge for two months
Balancing from 15/06/99 to 08/31/99
Ø The charge amount is 10 USD per month.
Ø The balancing period amounts to two months and 16 days

PUBLIC Page 12 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Ø End date of the period of full months is 08/15/99
Ø The next end date would be 09/15/99
Ø The period between 08/15 and 09/15 is 31 days
Ø The charge for the period of the full months is 20 USD
Ø The charge for the remaining days is 10 USD/31 days x 16 days = 5.16 USD
Ø This means the entire charge is 25.16 USD.

1.2.2.1.1.2.2 Direct Charge

Definition
A direct charge is a condition category that is applied in your bank / company for one-off activities. This can include, for example, a
percentage rate or fixed rate charge for the provision of credit. A direct charge could also be a charge for copying a bank statement.

The statements relating to checks / check management and standing orders apply for banks only.

Use
To create conditions for the calculation of direct charges, proceed as follows:
Note that for direct charges the differentiation type must always be ‘Feature’, so that this can correspond to the Customizing settings.
The following settings are necessary for bank statement duplicates:
1. Choose Conditions → Charges à Edit → Direct Charges, and then Create Condition.
2. As the first differentiation type, enter ‘Feature’.
3. As the differentiation value, enter ‘Bank Statement’.
4. As the second differentiation type, enter ‘Activity’.
5. As the differentiation value, enter ‘Create Duplicate’ (D1).
6.
The following settings are necessary for issuing and locking checks:
1. As the first differentiation type, enter ‘Feature’.
2. As the differentiation value, enter ‘Check’.
3. As the second differentiation type, enter ‘Activity’.
4. As the differentiation value, enter ‘Create’ (01) or 'Lock' (05).
Note:
¡ ‘Direct charges’ are always linked to features. If features are not defined, no automatic charge postings are generated.
¡ You want to define different charges for issuing checks, for example, a different charge for Euro checks than for crossed checks. In this
case, instead of choosing the differentiation type Activity, choose the differentiation type Position Type. The direct charge specified then
applies for issuing checks of the selected position type.

Structure
It is possible to levy a charge in the following areas:
· Bank statement:
¡ For the creation of a bank statement duplicate
· Check (cheque) management:
¡ For issuing checks
¡ For locking checks
· Account closure
· Standing orders
Overview of possible differentiation types:

PUBLIC Page 13 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Operation 1. Diff. type 1. Diff. value 2. Diff. type 2. Diff. value
Bank statement Feature Bank statement Activity Creating duplicate
Check (Cheque) Feature Check (cheque) Activity Create / lock
Management
Position type Euro-check / order
check...
Account closure Feature Account closure Activity Execute
Medium Document / EFT /
online...
Transaction type Account closure
internal / account
closure external ...
Standing Order Feature Standing Order Activity Create / change /
delete

The differentiation type feature is used exclusively for the determination of the transaction type for charge posting (assignment:
Feature - charge transaction type).

In a condition group, the differentiation types for all 'Direct Charges' conditions must be identical (to ensure uniqueness).

This does not apply if the condition is a markup condition.

1.2.2.1.1.2.3 Posting Charges Separately

Use
To show the income from different charge types separately (possibly as a service for your customers or for accounting reasons), you can post the charges
separately depending on what they are for.

Prerequisites
Prerequisite 1:
In the Implementation Guide (IMG), set the indicator "Post charges separately" by choosing
Master data → Product definition → Product → Create product → Feature → Account balancing → Indicator: Post charges separately.
If the indicator is set, the charges are posted as separate transaction types and shown as such accordingly.
If the indicator is not set, the charges are grouped together and posted as one transaction.
You can specify the following charge types:
22 - item charge debit
23 - item charge credit
24 - dispatch expense charge debit
25 - dispatch expense charge credit
26 - account maintenance charge
(The credits of the above-mentioned charge types are not direct reversals of the debits, but apply in the case of negative values on item counters. Negative items,
on the other hand, can result from reversals).
Prerequisite 2:
Create new transaction types in the Implementation Guide (IMG). Do this by choosing Account management → Basic functions account management →
Maintain transaction types. In this IMG section you can also create your own transaction types.
The following transaction types are supplied with sample Customizing:
1220 - item charge
1230 - dispatch expenses
1240 - account maintenance charge
6220 - credit from item charge
6230 - credit from dispatch expenses
Prerequisite 3:
Assign the transaction types to the posting categories in the Implementation Guide (IMG). To do this, choose Account management → Assign posting categories
to transaction types.

Procedure
Choose Account → Create.
Choose Balancing.
In the Account balancing section, set the indicator "Post charges separately".
If you create an account, the default setting stored for the product applies. However, you can change this setting on the account and have the charges grouped
together as usual.

Result
If the indicator is set, the charges are shown separately. However, if it is not set, the charges are grouped together and also transferred together as one posting to
the general ledger.

PUBLIC Page 14 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.2.2.1.1.3 Creation of Value Date Conditions
When you create value date conditions, note that you must differentiate them with the differentiation type "Transaction type".

If the value date condition is to apply globally for all transaction types, use the default control by entering " " (blank) in the differentiation value.

Since value date conditions often relate only to differentiation type and differentiation value, you have the option of creating a value date condition for all currencies.
If you wish to do this, enter " " (blank) in the currency field. When editing this condition, the system first checks if there is a condition for the account currency. If
this is not the case, the system then checks if the condition was saved under a blank space, meaning it applies for all currencies.

1.2.2.1.1.4 Scaled Conditions

As scaled condition, the credit interest rate is calculated using the scales/levels.
Scale/level from to Interest rate
1 0 5000 2%
2 5000 5%

If the balance is 4,000.-, 2% of 4,000.- is credited. If the balance is 7,000.-, 5% of 7,000.- is credited.
If the credit interest rate is defined as scaled condition based on intervals, in accordance with the example above, if the balance is 4,000.- there is a credit of 2%
of 4,000.-. If the balance is 7,000.-, 2% of 5,000.- + 5% of 2,000.- is credited.
This means it is possible to depict interest-free base amounts.

Creation of Scaled/Interval Condition Items

To create a scaled condition, you need to create a condition item for every level of the condition or for every interval. In the field
amount limit, specify what limits apply for the level.
If you activated the Amount To field when you created the condition, then it applies to up to and including the amount entered. The next
level above begins after this amount has been reached. If you did not activate the field, the specified amount is the lower limit for the
level.

Example:
The credit interest for an account is to be 2% for a balance of 5,000 USD and 4% for a balance of 10,000 USD.
There are two options for creating the condition items:

If the indicator Amount To is not activated:

Scale Amount limit Interest rate

1 5,000 2%

2 10,000 4%

This is the usual procedure, which is clarified below in an illustration of what happens when the Amount To indicator is set:

Scale Amount limit Interest rate

1 5,000 0%

2 10,000 2%

3 99,999,999,999 4%

However, this option is only useful if the amount for which interest is to be calculated is to have an upper limit.
You can specify the valid to date only for the first scaled condition item, which is entered automatically for the other items.
For debit and credit interest, and interest penalty, you can either create a scaled calculation based on the current balance, or a scaled
calculation based on the contract amount.

PUBLIC Page 15 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Creation of Markup and Markdown Conditions
The system uses the Markup Condit. (Condition) indicator to determine if a condition applies as a markup or a markdown on an existing
condition of the same condition category.

Before defining a markup or markdown condition, you must create a base condition.
The system adds the value of a markup condition to the base condition value and reduces the value of a markdown condition from the
base condition value.

The value of the base condition is internally set to zero if the markdown condition results in a negative overall condition.
The following rules determine the condition combinations that are used for balancing:
· A standard markup condition is always only added to a standard condition while a standard markdown conditions is always only reduced from a standard
condition.
· If both an individual condition and an individual markup or markdown condition exist, both are taken into account. Any existing standard conditions and
standard condition markups or markdowns are ignored.
· If a standard condition, a standard markup or markdown condition, and an individual markup or markdown condition exist, all 3 conditions are totaled.
The markup or markdown condition is ignored if the Level Interval indicator has different values for the standard condition and the
markup or markdown condition.

1.2.2.1.2 Creating Condition Items

Prerequisites
After you have created a condition you create items for this condition.

Procedure
Position your cursor on a condition in the condition overview and choose Item (position) → Create.
Specify from which date and to which date the condition item is to apply (including the first and last day).
Setting the end date for the validity range of a condition is optional and this, initially, usually remains blank. If you specify an end date, for example for individual
conditions or for expiring products, the condition no longer applies after this date and you must create a new condition item.
Always ensure that no account exists without conditions. If you create a new condition item with a current valid from date, this automatically applies without you
having to set a valid to date for the old item.
If an individual condition and a standard condition are assigned to an account and the individual condition expires, the standard condition assigned to the account
applies automatically.
Depending on the condition category, the following other details are also necessary:
Interest condition item
Charge condition item
Value date condition item
05. If you wish to create another item for this condition, choose the ‘New item’ icon. If you wish to adopt the item, choose ‘Transfer’.
06. Save your entries.

Note:
You can only create condition items with a start date in the past provided they have not been used for a settlement balancing or by payment
transactions.
When editing, by choosing All items or Current item you can choose if you want to have all condition items shown or only those valid currently and in
the future.

1.2.2.1.2.1 Special Features of Interest Condition Items

When entering items for an interest condition, you must enter additional interest data.
Specify either
a fixed interest rate in percentage points or alternatively
a reference interest rate (internal reference interest rate such as standard interest rate for the product or external reference interest rate such as the LIBOR) with
appropriate markups or markdowns. Make entries in the fields as follows:

Enter the interest markup / markdown in percentage points (absolute). Markdowns are identified by a minus sign after the amount. Markups have no
+/- sign.
For those interest conditions that depend on a reference rate, the minimum and maximum interest rate limit the lower and upper interest amount
respectively. Specify these interest rates in percentage points.

PUBLIC Page 16 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 You can update the values for the reference interest rates by choosing Current settings → Define reference interest rates.

Special Features of Charge Condition Items

When creating items for a charge condition, you must enter additional data.
In the case of items of a transaction charge you enter the transaction charge either as a percentage of the transaction amount, or as
an absolute amount. If you specify the transaction charge as a percentage, you can additionally specify a minimum and maximum
amount that is used if the charge calculated falls below or exceeds the minimum and maximum amount.
For account maintenance and periodic charges there is no provision for calculation of a percentage-based charge. Absolute
amounts are handled as above.

For a markdown charge, enter a minus sign (-) after the value and for a markup charge enter the value without a plus (+) or minus (-)
sign.

1.2.2.1.2.3 Special Features of Value Date Condition Items

When creating items for a value date condition, you must enter additional data.
Valid to:
This date restricts the validity of a condition item. Note that for standard conditions and individual conditions, the following applies:
Standard condition:
If, after the valid to date, you do not enter a new condition item with a later valid from date, no further calculation for the condition takes place.
Individual condition:
If you do not enter a new condition item with a later valid from date after the valid to date, the standard condition of the condition group applies again.
Number of days
: Here you define the number of days by which the value date is to be later or earlier (in the case of negative values) in relation to the posting date (posting date +
number of days = value date).
Tolerance days:
(Value date max) and tolerance days (value date min.): Using the fields value date max. and value date min. you can control what value dates specified by the
ordering party are accepted. The basis for this comparison is the value date calculated for number of days (above).
Value date max:
This field for the upper limit of the tolerance range indicates the maximum number of days the specified value date can be in the future.
Value date min:
This field indicates the maximum number of days a specified value date can be in the past.
Shift to a working day:
If the value date day determined falls on a Sunday or public holiday (determined in accordance with the public holiday calendar stored for the account), with the
indicator Shift to a working day you can control if and in which direction the value date is to be shifted to the next or previous working day. When updating the
value date you can specify calendar days and working days.
The following applies if you update with calendar days: If the value date falls on a public holiday, this indicator determines if and in which direction a shift to a
working day is made.

0 no shift
+ shift to the next working day
- shift to the previous working day

If you update with working days (value W), value dates fall always only on the following working days. For the calculation of the tolerance limits the system also
interprets the days stored as working days.

Special Features of Scaled/Interval Conditions

You can stagger the intervals of most conditions. Staggering is possible for the condition categories debit interest, credit interest,
transaction interest, transaction charge, item charge, dispatch expenses and for value date and subject to final payment value date
conditions (in the case of the last two, however, only as a scaled condition). To do this you must enter the following for the condition:
· Scaled/Interval:
You specify whether to stagger the condition, and if so, the type of calculation that is required.
If you choose Scaled Calculation, the condition item created applies to the whole balance up to the each level.
If you choose Interval Calculation, the condition item created applies only to the amount between the lower interval limit and the upper interval limit.
Examples for Scaled Conditions
· Amount To:
If you have created the condition as an interval or scaled condition, specify here whether the condition items/positions apply up to the specified value or from
the specified value. Valid From values apply including the limit, Valid To values excluding the limit.

PUBLIC Page 17 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 You must create a condition item for every level of the condition.

Note that there are scale conditions based on the account balance and based on the contract amount.

1.2.2.2 Changing Conditions

Prerequisites
You can enter Customizing settings to determine whether retroactive condition changes are allowed or not, by choosing Master Data
→Conditions →Define Basic Settings for Conditions. If you allow retroactive condition changes, then you can also define the number of
periods to which these changes may apply. You can decide whether the retroactive condition changes are to also apply to a fiscal year
that has already been closed.

Retroactive condition changes not allowed

If retroactive condition changes are not allowed, you can make a retroactive change to a condition (header and position) only if this
condition has not been used to balance an account, or if the condition has not yet been used in payment transactions.
You have the following options:
· You can specify a new validity period for the condition header data. This option is only possible if you have activated time-dependency of the conditions in
Customizing. If this is not the case, you need to create a new condition.
· To change the condition item data you must create a new item with a current validity date and changed values.
To change a single condition item of a scaled condition or insert an additional level from a certain date, you need to create the entire
scale with a new date.

Retroactive condition changes allowed

If retroactive condition changes are allowed, you can change standard or individual conditions that have already been used in account
balancing. There are, however, two restrictions: The Valid From date and the interest calculation method cannot be changed
retroactively.
Once you have changed standard conditions, you need to find the affected accounts, by choosing Retroactive Change to Standard
Condition →Find Affected Accounts.
During the next balancing, the system runs retroactive accounting for all the accounts found from the relevant date onwards.

Change History
To see a history of all changes that affect conditions (such as creations, deletions, or field changes), choose Goto →Condition History.
To display a list suitable for auditing, choose Information System →Condition History.

1.2.2.3 Releasing Conditions

The system locks new and changed conditions if you have activated the dual control principle in customizing under Master Data →
Conditions → Define Basic Settings for Conditions. These must be released by another user.

Procedure
1. ChooseConditions → General Conditions (or each condition class) → Release.
2. The system displays an overview of all conditions not yet released. Place your cursor on a condition and choose Release. If you
choose Release All, you release all the displayed conditions.

1.2.2.4 Deleting Conditions

PUBLIC Page 18 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 To delete a condition, proceed as follows:
1. Choose Conditions → Condition Assignment → Edit and delete the assignment of the condition to the condition group.
2. Choose Conditions →General Conditions (or the respective condition type) →Edit and specify the condition area and condition
category.
The system displays the condition overview.
3. Place your cursor on the item and choose the Select Item button.
4. Select the entry and choose the Delete button.
To delete a single condition item, follow steps one and two above, then proceed as follows:
Steps 1 and 2 as above.
1. Place your cursor on the item and choose the Select Item button.
2. Select the line with the position to be deleted and choose the Delete button.

A condition can be deleted only if it has not been used in account balancing or been used by payment transactions. You can delete
all entries except the last entry in the condition header.

In all other cases, you can void conditions by setting the Valid To date of a condition item or by creating a new condition item as of
the current date.

Principle of dual control

The system flags the conditions for deletion only, if you have activated the dual control principle in customizing under Master Data ®
Conditions ® Define Basic Settings for Conditions. The flagged conditions are deleted only when another user releases them.

1.2.2.5 Releasing Deleted Conditions

Use
The system locks new, changed, and deleted conditions if you have activated the dual control principle in customizing under Master
Data → Conditions → Define Basic Settings for Conditions. These must be released by another user.

Procedure
1. Choose Conditions → General Conditions → Release Deleted Conditions.
2. Choose the condition area and a condition category, then choose Continue.
The system displays an overview of all conditions that are flagged for deletion.
3. Place your cursor on a condition and choose Release.
If you choose Release All, you release all the displayed conditions. Choose Reactivation to reject the deletion.

1.2.2.6 Assigning Standard Conditions to an Account

Purpose
Typically, when an account is created, certain standard conditions are already assigned to it by virtue of the choice of the product and the condition group defined
for it. If you do not want these conditions to apply or if you want the conditions of another product to apply, it is possible to assign other standard conditions
.

Prerequisites
The conditions must already have been defined. To find out how to do this, read
Creating Conditions. In this case you also need to consider if the change to the conditions is only to apply to this one account and if it would not be preferable to
create an individual condition instead.

Process flow
Check to see if the required combination of standard conditions already exists in a previously defined condition group. If this is not the case, create a new
condition group and assign the conditions to it.
Within the account, change the assigned condition group for the corresponding condition group category.

PUBLIC Page 19 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.2.2.6.1 Assigning Standard Conditions to a Condition Group
Prerequisites
You must already have defined the conditions. To find out how to do this, read
Creating Conditions.
If the condition group does not yet exist, first create it. You do this in the Customizing of the condition master data (in the IMG by choosing Master data →
Conditions → Define condition groups).

Procedure
Choose Conditions → Condition assignment → Edit, and specify the condition area and the category of the condition group. Using the function button F4 you
obtain a preselection of the condition groups of the corresponding category. Choose a condition group.
This brings you to an overview of the conditions assigned to the condition group. Review this to see if a condition for the required condition category already exists
in the condition group. Delete the assignment by positioning the cursor on the condition and choosing Undo assignment.
Choose Assign, and enter the required condition category. For this category choose one of the conditions already created.
Within a condition group there can always only be one condition of a condition category. There are exceptions for differentiated conditions. Note, however, that all
conditions of the same condition category must have the same differentiation type and that per differentiation value (or per combination of two differentiation values if
you are using two differentiation types) there can only be one condition.
It is also possible that several conditions of the same condition category are assigned in different currencies. The condition created in the respective account
currency always applies for an account.
As an alternative to assigning conditions already created, you can also create conditions directly on this screen by positioning the cursor on the condition group
and then choosing Create condition. The condition created is automatically assigned to the condition group.
If you have activated the principle of dual control for conditions, the assignment of the condition to the condition group must first be released by another user. To
do this, choose Conditions → Condition assignment → Release.

Tip:
For a history of all changes concerning the assignments of conditions to condition groups (new creations, deletion), choose Goto → Assignments
history.

1.2.2.6.2 Assigning a Condition Group to an Account

Prerequisites
There must already be a condition group defined in the Implementation Guide (IMG) and you must already have assigned standard conditions to this.

Purpose
Generally, when an account is created, condition groups for interest, charge or value date conditions are already assigned to the account. These default settings
relate to the condition area that applies for an account. If there are no default settings, assign the respective condition groups. It is also possible to change the
specified condition groups.
To assign a condition group to an account, proceed as follows:
01. Choose Account → Change and enter the account number. Then choose the screen Balancing.
02. In the section Condition groups, assign the respective condition group for interest, charges and value date. Note that you must assign a condition group for
value date conditions to every account.
If you wish to change the assignment of the condition group and change the condition group of the account, note the following:
The conditions that apply are not used proportionately for the settlement period. For the settlement of the whole period, the condition group assigned at the time of
settlement is the one that always applies.
If individual conditions exist, these initially remain unchanged when the condition group is changed.
Proceed as follows:
01. In the section Condition groups, change the respective condition group for interest, charges or value date.
02. Save your entries. If you have changed a condition group for which individual conditions exist, a dialog box appears in which you are asked how you want
these handled. You have the following options to choose from:
Continue
: The new condition group is adopted and the individual conditions remain in existence, unchanged.
Delete:
The new condition group is adopted and the existing individual conditions are deleted.
Termination
: The old condition group and the individual conditions are retained.

1.2.2.6.3 Interest Calculation Method

The interest calculation method determines according to which time-dependent basis interest is calculated for mid-year payments. The various methods take
differences in the length of the months and leap years into consideration in different ways.
The interest calculation method is defined by the quotients
days
---------------
daily basis
.
The methods for calculating the number of days of each calculation period (meaning the number in the counter) are:
ACT
The actual number of calendar days between two dates is calculated.
360
For this method the year is considered to have 360 days and a month 30 days. The 31st of a month is not considered to be an interest day.

PUBLIC Page 20 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Contrary to method 360E, the time from February 27 to February 28 is considered to be one day, the time from February 28 to March 1 as three days.
Example: Days Calculation Method 360
360E
For this method, used, for example, on the Euro market, the number of days results similarly to the formula above.
The number of days between two dates D1/M1/Y1 and D2/M2/Y2 is calculated as follows:
(Y2 - Y1)*360 + (M2 - M1)*30 + (D2 - D1)
The time between February 27 and February 28 of a year is calculated as three days.
Example: Days Calculation Method 360E
The following are defined for the daily basis (denominator value):
360
A year is considered to have 360 days.
365
A year is considered to have 365 days.
366
A year is considered to have 365 days, a leap year 366 days.
The system supports the following so far:
360E/360 (bank calendar Euro market)
360/360 (German method)
ACT/360 (French method)
ACT/365, ACT/366

1.2.2.6.3.1 Days Calculation Method: 360

There are 28 days in the period from February 1 until February 28, 1999 (inclusive).
There are 32 days in the period from February 28 until March 3, 1999 (inclusive).

1.2.2.6.3.2 Days Calculation Method: 360E

There are 30 days in the period from February 1 until February 28, 1999 (inclusive).
There are 30 days in the period from February 28 until March 3, 1999 (inclusive). This method treats February 28 as if it were February
30.

1.2.2.7 Creating Individual Conditions

Use
Individual conditions are conditions that you assign directly to an account and that are only valid for this account. They are used to
modify conditions for an account, without having to define a completely new product. If an individual condition is created for an account,
this is indicated next to the standard condition groups assigned to the account.
An individual condition assigned to an account overrides the respective standard condition assigned to the account. Special features
apply for markup conditions (Special Features of Markup Conditions).
If the individual condition is deleted or no longer valid, the standard condition automatically applies again.
You create individual conditions directly on the account for which the individual condition is to apply. The basic procedure is similar to
the creation of a standard condition.

Procedure
1. Choose Account →Change and then the Account Balancing tab page.
2. The Condition Groups group box displays the condition groups for interest, charge and value date conditions used for the account.
To add more conditions to these individual conditions, or to overwrite them, choose either the Detail Interest or Detail Charges or Detail
Value Date buttons next to the condition group.
3. The system displays the condition overview, where you create your individual condition and the items belonging to it. For more
information, see Creating Conditions. Note the following important points:
The validity period is defined in the condition header. If you specify a Valid To date, the standard condition becomes active again for the account after this
date has expired.
You create the various condition items with their validity data. If you have defined an end date for an item that extends beyond the validity period defined in the
condition, the period defined in the individual condition is the maximum that applies.
To change an individual level of a scaled condition, you need to identify all levels as an individual condition.

PUBLIC Page 21 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 4. Go back to the main screen.
5. Save the account.
The word Individual is displayed next to the condition group. This shows if individual conditions exist that are valid on the system date.

1.2.2.8 Releasing Individual Conditions

Use
You can have individual conditions displayed cross-account by the system according to various selection criteria. It is possible to
branch from the displayed list to any account itself or to a total overview of all conditions for an account. You can also select just those
conditions you wish to release. When you enter the "valid to" date, the system selects all individual conditions that expire on this date.
You effect release either by branching to the respective account or by a mass release of all conditions on the list by setting the indicator
in front of the condition in question.

Prerequisite
If you have activated the principle of dual control in the Implementation guide (IMG), new, changed, and deleted conditions are initially
locked. These must be released by another user.

Procedure
1. Choose Account → Release → Release Individual Condition or Release Deleted Individual Condition.
2. Enter the account whose individual conditions or deleted individual conditions are to be released.
3. Choose Execute. This brings you to the list displaying the individual conditions for the selected account or account interval.
4. Select the condition you wish to release and choose single or mass release.

Result
The individual conditions have been released.

1.2.3 Limits
Use
Limits serve basically to restrict the amount-based disposal of accounts.
SAP supports six categories of limits:
Account overdraft limit: Basis for the calculation of overdraft interest for account balancing. The debit interest rate is applied to any overdrafts tolerated that exceed
this limit.
Internal account limit: Controls the coverage check of payment transactions. The account may be overdrawn up to this limit.
External account limit: The limit of which the customer is informed. This limit is for information purposes only and is generally identical to the account overdraft limit.
The external limit must always be lower than or equal to the internal limit.
Limit categories for interest compensation:
Interest compensation overdraft limit:
Basis for the calculation of overdraft interest for interest compensation.
Internal interest compensation limit: Controls the coverage check of payment transactions. The account pool for interest compensation
may be overdrawn up to this limit.
External interest compensation limit: The limit of which the customer is informed. This limit is for information purposes only.
The limit categories for interest compensation are defined exclusively on the root account. They are needed during the posting
operation since they provide information as to whether or not, according to the limit, a posting is permitted. For more information, see
the documentation on Interest Compensation.
Note:
You can define other limit categories in the IMG. These are not supported by functionality in the standard system and must be customer-
specifically programmed.

Integration
The issuing of limits can be subject to release in accordance with the principle of dual control, meaning that every limit must first be released by a second user
with the appropriate authorization before it can be used for an account. You set whether or not the limit of an account is subject to the principle of dual control in the
Implementation Guide (IMG) by choosing Master data → Limits → Maintain the principle of dual control for limits. An entry in this table means that the principle
of dual control is to apply.
You must grant separate authorization for releasing, since releasing limits is an activity in its own right. The authorization for releasing limits is independent of the
authorization for changing an account.
When a limit is released, this replaces any limit existing for the same time period.
If you wish to assign a new limit to an account, note the following: The to-date of a limit being newly created is open, meaning you can choose it freely.
When you newly create and release limits, the system checks if limits already exist and if the time periods possibly overlap.

PUBLIC Page 22 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Checking of the limit to be released is always in comparison with the limits already released.
Limits not released at the time of creation are checked against the limits that are not yet released.
For a certain time period you can only assign a limit of a certain category to an account, as the limits are time-dependent.
In Customizing you can define standardized limits for a bank area and a currency. This simplifies their application. You can assign these reference limits to the
account in the same way as an individual limit.
If the interval range of a new limit to be released overlaps the time period of a limit that already exists, the time period of the existing limit is reduced. This means
that during the overlapping period, the new limit applies.
Following are some examples to illustrate this:

Old limit New limit

from to from to
1.1.98 10.1.98 9.1.98 15.1.98

From 01/01/98 - 01/08/98, the old limit applies, from 01/09/98 - 01/15/98 the new limit applies. After this date there are no specifications.

Old limit New limit

from to from to
1.1.98 10.1.98 3.1.98 15.1.98

From 01/01/98 - 01/02/98, the old limit applies, from 01/03/98 - 01/15/98 the new limit applies. After this date there are no specifications.

Old limit New limit

from to from to
1.1.98 10.1.98 30.12.97 8.1.98

From 12/30/97 - 01/08/98, the new limit applies, from 01/09/98 - 01/10/98 the old limit applies. After this date there are no specifications.

Old limit New limit

from to from to
1.1.98 10.1.98 3.1.98 7.1.98

From 01/01/98 - 01/02/98, the old limit applies, from 01/03/98 - 01/07/98 the new limit applies, from 01/08/98 - 01/10/98 the old limit applies.

Additional Limit Functions in SAP In-House Cash

In addition to the limit checks listed under Limits, the system also carries out a limit check on the payer account when payments are
initiated internally (such as a bank transfer). In the case of provisionally and finally posted IHC payment orders, the system also takes
the amounts in the provisionally posted IHC payment orders into account.
An IHC payment order cannot be provisionally or finally posted if the payer account check in the account management system reveals
that the total amount of the following postings exceeds the limit:
· Postings to the payer account
· Provisionally posted payment orders
· Outgoing payments to be posted
The system converts the currency of provisionally posted IHC payment orders with a transaction currency that differs from the account
currency. It converts the total of the amounts listed above for each currency, using the average rate on the date of execution, into
account currency and uses the total amount in account currency for the limit check.

When postings are reversed or payments are initiated externally (such as debit memos), the system does not take provisionally
posted IHC payment orders into account.

Nor does it take credit memos from provisionally posted payment orders into account.
The amounts set as limits in the account master data of the account management system therefore denote the upper limit of all finally
posted transactions including all debit memos from provisionally posted payment orders.

1.2.3.2 Assigning Limits to an Account

To assign standard or individual limits to an account, proceed as follows:
01. Go in change mode into the account whose limits you wish to change.

PUBLIC Page 23 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 02. Choose the limits screen.
You are now in the limits overview where the following sections are displayed:
- Account limits - account overdraft limit, internal and external account limit
- Interest compensation limits - needed for interest compensation
- Other limits - these are displayed if you have defined your own limit categories in the Implementation Guide (IMG).
The system only displays the currently valid limits. Using the time breakdown icon you can branch to the detail display of every limit category supplied by SAP.
03. Choose the time breakdown icon.
04. Choose Create limit.
05. Now you can decide if you want to assign a standard limit (the reference limits used for this are predefined by Customizing) or if you want to individually control
limit assignment. You have the following options:
Reference limits:
06. Specify the validity period and select the ID of a reference limit. Any specified individual limit amount is always overwritten by the limit amount of the reference
limit. The account currency applies as currency.

Reference limits can change in the course of time. To enable you to react quickly to changes in the reference limits, by choosing Environment → Current settings
you have the option of making adjustments. You can change a reference limit without having to create a new reference limit with a new ID and without having to
maintain it in the affected accounts. Furthermore, the change is valid in the past and does not lead to erroneous account balancing results.
Individual limits:
07. Enter the validity period, the amount and the currency.
08. Choose Continue.

Whether or not the limits are subject to the principle of dual control is defined in Customizing. If the principle of dual control is defined, the limits must be released
by another user with authorization for the account before they can be used.
Note that overdraft limits must always be released if they are subject to the principle of dual control. If overdraft limits exist that are not released, the account is not
balanced. The unreleased limit is only taken into consideration for a simulation.

Limit check of the internal limit

If the limit check is activated for the product, it is possible to maintain the internal limits for the account.
An internal limit must exist at all times. The system enters limits for any missing intervals. To do this, the system sets the indicator ‘Limit check’ and sets the limit
amount at 0. If the limit check for the product is inactive, the system sets a limit on the account anyway. This limit has the validity period 01/01/0001 -
12/31/9999, the amount is zero and the limit check is inactive.
Procedure
Activate the limit check in the Implementation Guide (IMG) by choosing Master data → Product definition → Product.

1.2.3.3 Releasing Limits

Use
Before it can be used, (depending on the setting in the Implementation Guide (IMG)), it is possible that the limit must be released in
accordance with the principle of dual control by a second user with authorization for the account.
Releasing can be done directly on the account or using a list that displays all limits to be released. In the list of limits to be released, the
processing status is displayed by a traffic-light symbol.
· Green = releasing is possible
· Yellow = an indication that you were already in the detail display “Account”
· Red = unreleased limits in mass processing due to an error
· No traffic-light = limit has been released.

Procedure
1. Choose Account → Release →Release Limit.
A list of limits to be released appears in accordance with your specifications.
2. To release all the limits, choose the mass release icon or to release selected limits, choose the single release icon.

Result
The created limits have been released and are now available for account management and payment transactions.

Limits that you cannot release due to the principle of dual control or the authorization checks are not displayed in the list.

1.2.3.4 Deleting Limits

Use

PUBLIC Page 24 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Deletion of a limit, (depending on the setting in the Implementation Guide (IMG)), might need to be released in accordance with the principle of dual control by a
second user with authorization for the account before the limit is actually deleted.
You can delete limits directly on the account or using a list that displays all limits flagged for deletion. In the list of limits to be deleted, the processing status is
displayed by a traffic-light symbol.
Green = deletion is possible
Yellow = an indication that you were already in the detail display "Account"
Red = limits not deleted in mass processing due to an error
No traffic-light = limit has been deleted.

Overdraft limits that are valid before the last account balancing cannot be deleted. (They are still needed for postings in periods already settled.)
Before the deletion process, create a new limit that is valid from the account balancing and then delete the old limit. The system automatically
deletes any overlaps in the validity periods between the old and the new limit.

Procedure
If limits are subject to the principle of dual control
Flagging limits for deletion:
Go in change mode into the account whose limit you wish to delete.
Choose the Limits screen.
Set the delete indicator next to the limit you wish to delete.
Choose Save.

The limit is now flagged for deletion.

Releasing the deletion process:

Choose Account → Delete → Limits.
Choose the account whose limit you wish to delete.
Release the deletion process of the limit with the icons mass release or single release.
If limits are not subject to the principle of dual control
Go in change mode into the account whose limit you wish to delete.
Choose the Limits screen.
Choose the limit you wish to delete. Choose Delete limits.
Choose Save.

The limit is now deleted.

Result
The limit has been deleted.

1.2.4 Product Definition

Purpose
In the area of customer current accounts, product definition flexibly supports products and their special features for every individual customer group. Products can
be configured, step by step, much along the lines of a 'building block' principle. An account is characterized by the attributes of the freely definable product
assigned to it. Contained in the product are the possible conditions, relevant transaction types and functions, and also the media with which the customer has
access to the account. You can create products in several versions, enabling you to react flexibly to market requirements.

Implementation considerations
You define products in the Implementation Guide (IMG) by choosing Master Data → Product Definition In the application, you can only have the products
displayed.

Scope of functions
You can define products flexibly, fast and without programming. As well as determining the conditions, transaction types and functions, the product also controls
the view of the account data. This results from every attribute being assigned to exactly one view, although every view can relate to one or more products. It is also
possible for you to set up specific additional fields as customer-specific enhancements, without having to modify the program. See the documentation on the
Business Data Toolset.
This flexibility for product configuration enables you to adapt various transaction types such as debit transactions at points of sale, overdraft arrangements, check
operations and other account movements using Customizing functionality.
The transaction type describes the business operation on which the payment item that is to be processed is based. It controls, among other things, if the account
is debited or if the amount is credited and also the checks that are to be made before updating is executed.
When configuring products, it is possible to define the calculation of standard conditions dependent on various characteristics as, for example, the calculation of
debit interest depending on a customer’s creditworthiness. It is possible to design an account (product) in such a way, that it is tailor-made to suit the individual
requirements of a customer. (The following graphic applies mainly to banks).

PUBLIC Page 25 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Example (for banks)
A product for schoolchildren or students without their own income "Young Account" could be configured so that it is managed exclusively in credit and includes
interest payment on the balance. In addition, you could restrict the issuing of checks and credit cards, exclude debit collections and permit or prohibit access
using T-Online.

1.2.4.1 Product Configurator

Definition
The Product Configurator is a tool using which you can define products without any programming effort.
The Product Configurator facilitates the definition of the business and technical features of a product, its version creation and the layout of the functions on the
interface. In addition, it enables you to make simple enhancements with regard to the inclusion of attributes and offers general services such as change
documents.
With the Product Configurator you can maintain all information on a product and have the different information (transaction types, media, field modification,
assignment of conditions) uniformly displayed.

Use
The product reflects the activities of a current account. You need the Product Configurator to design the products. From the perspective of the current account
system, the product is the result of the definition of fields, features and payment transaction operations. General processing characteristics are controlled by
products, these processing characteristics being transferred to the assigned accounts.
You define a product and create accounts for this product. The products serve as a template and framework for accounts. A product can exist in several versions.
An account is always linked to one version of the product. If you change a product, you decide if you wish to save the change in the existing version or in a new
one. If you create a new version, the change only affects accounts created in the future, the existing ones are not affected.

Structure
The structure of the Product Configurator is designed as follows:
The Product Configurator is base on the
Business Data Toolset.
SAP supplies sample products.
You create products with the help of the Product Configurator in the Implementation Guide.
The interface of the Product Configurator is divided into three parts:
The initial screen
The administration data
The attributes
The last two are also applications from the perspective of the
Business Data Toolset.

Advantages
Simple and user-friendly creation of bank products
Graphical support
No programming required
Proposed default values when defining products
Administration of various versions of individual products

1.2.4.2 Creation of Products

Prerequisites
Before creating products, you must first have maintained a prefix for your name range and the attributes.
Prefix:
The prefix is part of a globally unique internal identification key. This key consists of the prefix and a consecutive number. It is automatically generated and
assigned to every attribute or product. This means you set the prefix once, and subsequently, for every new creation of an attribute or product, the system
automatically assigns the identification key in the set name range.
The prefix is needed to enable differentiation between attributes and products from different manufacturers. Use an own prefix for each system so that newly

PUBLIC Page 26 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The prefix is needed to enable differentiation between attributes and products from different manufacturers. Use an own prefix for each system so that newly
created attributes and products do not overwrite existing ones.
You maintain the prefix in the Implementation Guide (IMG) by choosing Master data → Product definition → Set prefix.
It is not possible to save attributes and products without specifying a prefix.
Attributes:
Attributes determine the functionality of a product, so the more attributes you assign to a product, the greater its functional quality. This assignment is optional.
For a clearer overview, attributes are arranged in hierarchies. For technical reasons, the grouping attribute is on the first hierarchy level and the other hierarchy
levels are attached to it. The grouping attribute has no other function.
Each attribute belongs to exactly one attribute category, the following of which are supplied:
Grouping attribute: Attributes of this category have no direct function. They serve primarily to construct the attribute hierarchy, to classify the attributes and to
assign them to attribute groups.
Field: This attribute is a visible field in an account. You can assign a default value and a field modification (required, optional, display, hidden) to a field. You
can assign several default values to multiple-value fields. An example of a field with one value is the currency, an example of a field with several kinds is the
check type.
Feature: Each feature attribute involves a function that you activate by assigning the feature attribute, or deactivate by not assigning it. Example: Bank
statement, checks (cheques).
Matrix: This attribute involves two values, the cross product of which you assign to the product. Example: Payment transaction operation. An operation consists
of a transaction type and a medium. There is a certain number of transaction types (n) and a certain number of media (m). You can assign each of the possible
n*m cross products to a product.
When you maintain attributes, you first set the attributes you basically wish to use. You have the following options:
01. You can adopt the attributes supplied by SAP without changing them, and need then make no other settings.
02. You can alter the attributes supplied by SAP by changing the hierarchy or the name.
03. You can create your own attributes in addition to those supplied.
Consider the following before maintaining the attributes: Which attributes do you need in your company and which can you do without? How do you want the
products to be designed, meaning which general and which specific characteristic features do you want to apply? In which sequence do you want the individual
screens with the attributes to appear?
You define attributes in the Implementation Guide (IMG) by choosing Master data → Product definition → Product attributes. There is a description of how to
change attributes or create new ones in the Implementation Guide.

Process flow
In the Implementation Guide (IMG), choose Master data → Product definition.
Create a prefix for the name range in which you wish to operate.
Maintain the attributes you wish to use. All attributes used by the current account system are supplied.
Maintain the products you wish to use.

Note:
You cannot literally delete products. If you no longer wish to use products, archive them. You can reactivate the archived products again if necessary.
If required, assign products to bank areas, as products are first created cross-bank area. This assignment is advisable if you wish to restrict the selection of
products. You can use a product in several bank areas.

Result
You have successfully created products and can now assign accounts to them. In the application itself you have the option of having the products displayed.
Choose Product → Display product.

1.2.4.3 Management of Products

Purpose
The products are stored in product management in accordance with the following criteria:
Product name
Version
Status
Validity period
Cross-version data
Product name:
This name is the external product ID. You assign this name when you create a product. It clearly and unmistakably identifies the product. The description, that

PUBLIC Page 27 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 contrary to the product name is language dependent, is part of the product name.
Version:
There can be several different versions of a product. When you create a product, the first version of this product is created. When you change a product, you have
the option of creating a new version when you save. Versions with the status "active" may not overlap the validity period of one another. If you create an account for
a product, this relates to the version that is active on the account opening date.

Example (for banks)

In version 001 of the product Checking - Junior the securities ID is hidden. In version 002, however, it is shown.

Status:
A version of a certain product can be either active or inactive. You can only create accounts for a version of the product if it has the status "active". For all other
status types it is inactive, meaning you cannot create any accounts.
You can change the status by selecting a pushbutton. This pushbutton is to take into consideration whether you have just created a product or if it is already
active. The system proposes the status changes accordingly.
SAP makes provision for the following statuses:
Parked/new product
Parked/new version
Flagged to be activated
Active
Flagged for archiving
As long as accounts exist for a version, this version must keep the status "active". If accounts still exist for a version in your productive system, this version may
also not be deactivated in the previous/feeder system (‘flagged for archiving’).
Validity period
: The term of a version ("valid from" and "valid to") indicates the time period in which accounts can be created for an active version. At any certain point in time
there can only be one active version of a product, meaning that the validity periods of the active versions may not overlap .
Cross-version data:
Some of the administrative data is cross-version, other is version-dependent. The cross-version data includes the description, authorization group, old and internal
product ID, administrative data on the creation of the product.

Authorization group:

To create the authorization group for a product, specify an authorization group in the cross-version data. Only employees with authorization for this
authorization group can maintain the products.

Version concept
You can hold versions in parallel, if, for example, you are planning a new version for a later point in time. Note that in this case you can create active versions and
also create accounts for these versions, but that their opening date must be in the future.
During any one validity period always only one version can be active, meaning that active versions may not overlap each other in their validity area.
Versions can also have accounts when they are not valid but only active. However, you cannot create accounts for invalid versions.

Example:

In your currently valid version 1 the default setting for currency is DEM. From July 1 you wish to define the default currency Euro for a version 2.
All accounts created in the validity area of version 1 have DEM as default currency and those created for version 2 have Euro. Already as of 01/01 you can
'park' accounts for version 2, even though the opening date may not be before 07/01.

1.2.5 Account

Use
The account is the central object of the current account system.
You can use accounts within the current account system for the normal purposes of a current account (demand deposit account). The
components of a current account are supported, such as balance-based balancing and processing payment transactions. The system
also supports term deposits (fixed deposits, overnight money, deposit at notice), savings bonds (normal interest) and savings deposits
with an agreed or a three-month period of notice.
You create accounts as characteristic of a product. A product is a group of services based on the requirements of individual bank
customers. You define the product using fields, features and payment transaction operations. General processing characteristics are
controlled by products, whereby these processing characteristics are transferred to the assigned accounts.
SAP provides you with the Product Configurator to enable you to configure products. The Product Configurator facilitates the definition of

PUBLIC Page 28 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 the business and technical features of a product, its version creation and the layout of the functions on the interface. You can use the
Product Configurator to add to the features of the products. (See also: Product Definition).

Structure
The structure of products and accounts in connection with the tool Product Configurator is as follows:
The Product Configurator is used for creating different products such as a junior bank account, a commercial bank account, fixed
deposits of 30 days, and variable fixed deposits of between 60 and 90 days. These products serve as a template and basis for
accounts that you create for them. An account is always related to one version of the product, although the products can exist in several
versions. You can make use of these versions when, for example, you have changed a product but the accounts relating to the old
version of the product have not been closed.
The product controls
· The functions that can be used on the account
· The posting operations that can be used
· The media used for initiating postings
· The attributes that exist for an account and the way in which the fields are displayed in the application.
Every product is defined according to a Bank Area. However, in the Implementation Guide (IMG) you can restrict the products for certain
bank areas.

Integration
Similar characteristics apply for the definition of accounts as for the definition of business partners. The technical tool used for the
creation of the account master data is the SAP Business Data Toolset. This has the same advantages as listed for the central
business partner. Account creation is flexible, which means that you can create as many bank fields as you require by using the
product, and without the need for modifications.
You can define the layout of the screens to suit your bank requirements. Online transactions and interfaces for data transfer are
provided to enable you to process account master data. The search function is supported by search and matchcode fields.

Scope of Functions
You can choose the definition and description of the products as required. As mentioned above, attributes are assigned to each
product or account, which control the executable functions, the standard conditions and the screen layout or the view of an account. You
can provide the account with individual conditions, limits and the appropriate business partners.
· You achieve the depiction of single or joint accounts by assigning an account holder to an account. It is also possible to display different relationships
between accounts and business partners. One business partner assigned to an account, for example, can be the account holder, another business
partner the authorized drawer, and another business partner the bank statement recipient.
· You can define the allowed business transactions for every account type (for example, it is not permitted to overdraw an account kept on a non-borrowing
basis).
· It is possible to manage accounts “for the benefit of a third party”.
· You define nostro and vostro accounts accordingly, and maintain and use them in a similar way as customer current accounts. The only differences are the
different attributes.
· An account can be managed in any currency. Provision is made for the conversion accounts to Euro and also the alternative display in Euro and the EMU
joining currency. A customer can have the account managed in Euro from the date she or he requires.
· You can create relationships between different accounts as a tree structure (account hierarchy). Operational usage includes cash concentration (the clearing
of lower-level accounts in favor of a higher-level account) and interest and charge compensation.
· You always create accounts for a certain bank area. This means it is possible for accounts with the same account number to exist in different bank areas.
· You can assign conditions to the account as standard conditions or individual conditions.
Special functions for deposit banking are as follows:
· Rollover and notice (partial and full amount) and their management.
· Monitoring of the term start, overpayment, or underpayment on each account.
· Control over the processing of incoming and outgoing payment items (post, in postprocessing, reject) during one of the saving phases (preliminary phase,
fixing phase, maturity phase).
· Interest calculation with account-based interest rates (term, amount and currency based), the preliminary interest calculation and posting interest calculation
results.

1.2.5.1 Creation of Accounts

Purpose
The account is the central element of the current account system. The system provides convenient entry options for creating the
account master records. Different information is required or already defaulted according to the product to which you have assigned the
account to be created.

PUBLIC Page 29 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Prerequisites
The business partner or partners related to the account can already be created before you create the account.

Process Flow
The creation of an account is divided into the following steps:
1. You choose a product for the creation of the account. This controls the main characteristics, such as the screen sequence for the
creation of the account, the data to be entered, any standard conditions assigned, and the basic functions that can be used on the
account.
2. You maintain the account master data, for example, the account number.
3. You assign an account holder and, where necessary, other business partners in various roles to the account. You must enter the
account holder for all account types (for organizations you also need to specify an authorized drawer). Other assignments such as the
bank statement recipient or authorized drawer can be useful for some products. The following are possible scenarios:
¡ The business partner is already created in the correct role.
In this case you can assign the business partner directly.
¡ The business partner is already created, but in a different role.
In this case you need to allocate the correct role to the business partner in partner management before you can make the account
assignment. This ensures that all information relevant for the role is maintained in the business partner master record.
¡ The business partner is not yet created.
You need to create the business partner in partner management in the appropriate roles. Alternatively you can create the business
partner in a role when you create the account.
The above steps are required for all cases. The following steps may also be useful in some situations and with some products:
4. The condition groups for interest calculation, charges and value dates set for the product are already assigned to the account. You
have the following options:
¡ If the account corresponds to the standard product, leave these as they are.
¡ To adjust the product for the customer, you can assign other conditions from the pool of standard conditions already created for other
products to the customer, or you create an individual condition especially for this customer.
5. You can restrict the functions assigned to the account via the product assignment by specifying lock reasons. For more information,
see Locking Accounts.
6. You define the conditions for amount notice and rollover for deposit products.
7. You can assign different limits to the account (for example, overdraft limit, internal and external account limit) that control the extent
to which an account can be overdrawn. If you do not assign limits to an account, the system sets the corresponding limit at 0. In this
case, the account cannot be overdrawn.
8. You also need to specify if checks are to be issued for the account.
9. You specify when the account is to be balanced.
10. You manage the standing orders here and also the time that bank statements are to be created.
Administration of the direct debit orders is also part of account management.

Result
Once you have completed the steps above and saved your data, the account is created in the system.

1.2.5.1.1 Creating an Account

1. Choose Account → Create.
2. Specify the bank area to which the account is to be assigned.
If you want the program to assign the account number internally, leave the Account Number field blank. The system then assigns a number from the set
number range, determined in accordance with the set check digit procedure.
The system initially ‘flags’ the assigned account number and then displays it when you save the account.
If you assign the account number (external number assignment) manually when you save the account, or if you select the Check button, the system also
checks the number in accordance with the set check digit procedure. You can deactivate this check by selecting a checkbox.
3. If necessary, change the opening date.
4. Specify the product to which the account relates.
5. If required, set the checkboxes to Offer and Deactivate Check Digit.
6. Enter a bank control key.
In Customizing, you can specify if and how the bank control key is to be entered when the accounts are created, according to the country and the product.
Choose Master Data → Account → Define Country Settings for Bank Control Key. When you create standing orders, payment orders, forward orders, and
reference accounts, you can specify it to identify an external account.
7. Choose Continue.
The system displays the next screen with the different tab pages that are available. These tab pages contain fields grouped by business topic. Depending
on the product, you can display either all or only some of the followng tab pages:
¡ Basic Data
¡ Term Agreement for Fixed Deposits
¡ Balancing
¡ Limits
¡ Holds

PUBLIC Page 30 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 ¡ Payment Transactions
¡ Amount Notice
¡ Bank Statements
¡ Correspondence Receiver Administration
¡ Standing Orders
¡ Control Data
¡ Administration Data

1.2.5.1.2 Maintaining Basic Data

Use
As basic data you maintain the base data of the account, for example, assigned business partners or the account currency.

Procedure
1. In the Identification section, enter the currency in which the account is to be managed, the account description, and the search terms.
The account description is normally the name of the account holder, but can be freely chosen. You can also freely choose the search
terms. They later serve as search help for accounts.
2. In the Administration section, specify the status of the account. The current status is displayed. Prerequisite for this is that you have
stored the possible statuses in Customizing for Bank Customer Accounts (BCA) by choosing Master Data → Account → Define Status.

You activate the account by using the Status field.

You can also specify that the customer must be informed when the account master data is modified by setting the Print Change Correspondence indicator.
The system calls the Business Transaction Event (BTE) 00011060 when you save the changes. You must implement the BTE to use this function.
3. In the Notes section you can record comments and events for this account. You can create the notes in different languages and
have the notes that are already created displayed, either in a short overview or long overview.
4. In the Account Holder section, define the account holder.
Assigning affiliated business partners to the account:
Note that at this point you can only assign business partners who have been created in the role of account holder. Selecting the F4 help brings you to a
search screen that helps you search for existing business partners.
Creating business partners during account assignment:
If the business partner you wish to use as account holder has not yet been created, you can do this by choosing with the quick info text Create Business
Partner. On the following screen, enter the appropriate data, and save your entries.
5. In the Other Business Partners section, create business partners in the role of authorized drawer and account maintenance officer.
In this section you can, of course, define other business partners in different roles (for example, contact person). You can use business
partners who are already created or create new business partners.

Enter the proof of identity for the business partners on the Identification tab page of the business partner maintenance screen.

Result
You have maintained the basic data for the account.

1.2.5.1.3 Maintaining Balancing Data

Use
On the balancing data screen you specify the condition groups and the dates for account balancing and cash concentration.

Procedure
The condition groups that were assigned to the product are stored in the section "Condition groups". Clicking on the icon "Details" brings you to the detailed view
for this condition group.
See also: Assigning a Condition Group to an Account
In the section "Account balancing", define the time periods for account balancing. Specify whether or not the balancing is to be carried out on a reference
account. Using the icon "Create" you can create a new reference account if you so wish.
See also: Creation of a Reference Account for Balancing.

PUBLIC Page 31 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 If an internal or external reference account is stored, the bank area and account number or bank country, bank key and account number are also displayed.

Note:
Note that the reference account may not already refer to another account.
In the section "Cash concentration", specify the circumstances under which the actual account balancing with interest and charge calculation is to take place.

Example:
Period Period unit Day of the week Key date Meaning
1 days every day
1 week 1 every week on Monday
3 months 15 every 3 months
1 months 31 on the last day of every month

You can also enter on which date the next balancing is to be performed.

Result
You have maintained the period data for account balancing and cash concentration.

1.2.5.1.4 Maintaining Limits

Use
On this screen you maintain the limits. Limits serve basically to restrict the amount-based disposal of accounts.
SAP supports six categories of limits, three account limits and three interest compensation limits. You can also define other limit categories by means of
Customizing. (See
Limits).

Procedure
To learn how to maintain the limits of an account, read
Assigning Limits to an Account.

1.2.5.1.5 Maintaining Holds

Use
Holds enable you to adapt the available amount for an account by increasing or decreasing it.
You decrease the available amount if certain amounts are to be held as securities or as part of another business transaction on the
customer account. This prevents money from being withdrawn from the remaining available amount on the account.
You increase the available amount if you want to provide the customer with an extra limit for a particular period of time.

Prerequisites
You have activated the Holds feature for the product under Conditions and Limits.
You can define an amount-based authorization check in Customizing for the product in bank area currency under Authorization
Management -> Amount-Dependent Authorization -> Maintain Amount Limit for Hold.

Procedure
The holds are displayed on the Holds tab page in the Holds group box. You can create, change, and delete holds. The changes made
are saved only when you save the account.
The following parameters define a hold:
· Reservation category
01 for long term holds that reduce the available amount by the reserved amount (hold).
02 for suspending the long term hold that reduces the available amount by the negative reserved amount.
· Reserved amount (hold)
Amount in account currency by which the available amount is to be reduced. You need to enter the amount with a negative plus minus sign to suspend the
long term hold.
· Valid from and to
Period of time during which the hold is valid, whereby more than one hold can be valid at one time.
In addition, you can specify a reference number for internal use.
Choose Account Balance to display an overview of the outstanding holds.

Result
The active holds affect the payment transaction and balancing. If you process a payment item, the active holds are summarized and

PUBLIC Page 32 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 subtracted from the available amount. If the payment item exceeds the available amount, the system issues an error message.
During balancing, the system checks whether there are any open active holds, issues an error message if there are, and places
account balancing in postprocessing.
Choose Information System -> List of Holds to generate a list of holds for selected accounts. The list also displays the deleted holds
with their deletion date.

1.2.5.1.6 Maintaining Details on Payment Transactions

Use
On this screen you maintain the payment transaction operations and the check types (check types only for banks).

Procedure
In the section "Blocked functionalities", specify the functionality you wish to block.
You must have maintained the blocking reasons in the (Implementation Guide) IMG by choosing Master data → Account → Blocking reasons. Any number of
blocking reasons can be assigned to each account. A feature or a payment transaction operation can only be used for an account if this is allowed for the account
product, and is not blocked by one of the blocking reasons for the account.
Both the blocked functionalities and the available functionalities are displayed in the section "Functionalities". All existing features and payment transaction
operations are always displayed. The following applies:
Red traffic-light = blocked by a blocking reason
Green traffic-light = assigned by the product
No traffic-light = not assigned and not blocked.
To obtain an overview of what is allowed for the account, choose the detail view for the account.
See also: Account Blocks.
In the section "Extended functionalities", specify whether the payee is allowed to collect receivables by means of collection authority and specify the dispatch
type.
The indicator "Agreement for collecting receivables with debit memos" shows whether the bank has an agreement for debit collection from the account holder. This
means that the collection of debits and crediting to this account is possible (the indicator controls the appropriate check with payment transactions).
(Only for banks): In the section "Check types", maintain check number issuing. The following applies:
In the account master record you can define special attributes for every check type possible for an account. These control the issuing of checks for the respective
account.
Number on issue
This attribute means that every issued check is entered with a check number in the check (cheque) position table at the time of issue. The indicator is for
organizational purposes only, meaning that the employee who issues the checks must enter the checks him/herself in the system. If the indicator is not set, both
checks with numbers and checks without numbers can be issued.
Number on presentation
This attribute means that every check presented for debit by payment transactions that does not have one of the check numbers existing in check management
must be entered in the check position table. Sensibly, this indicator can only be set, if issuing checks without numbers is allowed, meaning that the indicator
number on issue is not set.
Both indicators control
01. the entering of the check numbers in check management both at the time of issue and when cashed.
02. the checking of the check numbers for check debits for incoming payment transactions and the handling of check numbers not entered.
The checks within payment transactions take place as follows:
You receive a check (cheque) debit with check (cheque) number. The system checks if the check (cheque) number already exists in check (cheque)
management.
If this is not the case, the next check is to see if it is possible to issue checks without being entered in the check table (and so without a number issued by the
bank). This would mean that the indicator number on issue is not set.
If this is the case, the check can be cashed. Additionally, the system checks if the cashed check is to be transferred to the check table (meaning the indicator
number on presentation is set). If this is the case, the check is transferred to check management with check number and the status cashed.

Result
The payment transaction data has been maintained.

1.2.5.1.7 Maintaining Bank Statement Data

Use
On the Bank Statements tab page you maintain the administration data for bank statements and balance notifications in the respective
group boxes.

Procedure
1. In the Bank Statements group box, enter the time periods for the bank statements. Specify the next date also.

Example:

PUBLIC Page 33 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Period Period unit Day of the week Key date Description
1 Days Every day
1 Week 1 Every week on Monday
3 Months 15 Every 3 months
1 Months 31 On the last day of every
month
1 End of quarter At the end of each
quarter
1 End of year At the end of each year

2. Specify the business partner that is to be the bank statement recipient. Specify whether the bank statement original is to be sent and
the dispatch method you want to use.
To obtain paper bank statements, choose IHCPAP as the bank statement format, and the dispatch type 01 (applies for SAP In-House Cash only).
3. To display the existing bank statements, choose Environment -> Bank Statement -> Current or Historic, or choose the relevant
buttons.
4. In the Balance Notification group box, enter the time periods and the next date for the balance notification.
Only set the With Interest Information indicator if the recipient of the balance notification requires interest information also. The data is transferred by event
00012900 ( Balance Notification: Transfer Data).
5. To display existing balance notifications, choose the Balance Notifications button.

Result
You have maintained the data for the bank statement and the balance notification.

1.2.5.1.8 Maintaining Control Data

Use
You specify the data for the processing control on the Control Data tab page.
In the General Ledger Transfer group box, you specify information on the cumulation of the data during the transfer of the account flows
to the general ledger.

Prerequisites
The system offers the general ledger groups for selection that are defined in Customizing under Periodic Tasks → General Ledger
Transfer → Maintain General Ledger Group.
The Business Area attribute has been set up accordingly for the product on which the account is based.

Procedure
Group Box Control
1. You specify whether the account to be created is a single, AND, or OR account.
2. If required, set the Third Party Benefit indicator. You can set the indicator only in combination with the indicators for individual or joint
accounts.
Group Box General Ledger Transfer
1. Assign the account to one general ledger group.

When the general ledger is updated, the cumulated postings of all accounts with the same general ledger group are transferred to
the general ledger in separate debit and credit totals to ensure that the balance sheet display is correct. The cumulated debit or
credit totals of the period of time to be transferred is calculated in such a way that one balance is initially calculated for each account
(including the balance carryforward from the previous transfer). This balance then determines (according to its plus/minus sign)
whether the total of account flows from the transfer period is to be added to the debit or credit total of each general ledger group.

If you change the assigned general ledger group, you need to note the following:
¡ The general ledger group can be changed only if the balance sheet preparation for the account has been completed, and there are
no items in postprocessing or in release.
¡ During the next balance sheet preparation, the balances of the receivables and payables accounts from the old general ledger group
are transfer posted to the receivables and payables accounts in the new general ledger group.
2. Assign the account to a netting group if there is to be netting for at least one additional account with the same business partner.
Otherwise, leave this field blank for performance reasons. The name of a netting group is of no more than four characters.

PUBLIC Page 34 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The general ledger update must add to a single receivable or payable all the flows not yet transferred from the accounts, and that
have the same account holder, and that formally have the same interest conditions. This complies with the legal requirements of the
balance sheet statement (for example, § 10 of the German bank accounting law). The corresponding accounts of an account holder
must all have the same netting group, and be balanced before the cumulation of the general ledger groups to make this possible.
This operation is called balance netting.
3. Assign the account to a business area if the product allows this.
If you change the assigned business area, you need to note the following:
¡ You can change the business area only if the balance sheet preparation for the account has been completed, and there are no items
in postprocessing or in release.
¡ During the next balance sheet preparation, the balances of the general ledger accounts are taken off the books with the old business
area and put back on again with the new business area. They are then posted on the general ledger during the general ledger transfer.
Group Box Legacy Data Transfer
If there is a legacy data transfer for the account to be created, specify the Go-Live Date and the Balance Transfer Date. SAP provides
a report for the legacy data transfer. The system does not post balancing data from the period between the Balance Transfer Date and
the Go-Live Date. These fields are relevant if you want to balance accounts before the go-live date.

1.2.5.1.9 Maintaining Administration Data

Use
On this screen you maintain the administration data.

Procedure
1. In the section “administration data”, enter the number of the presented proof of identity. This is generally the passport number.
2. Enter the authorization group. To be able to edit accounts, the user must have authorization for the authorization group entered here.
3. Specify the public holiday calendar. The public holiday calendar key indicates the public holiday calendar on which value dating is
based. If required, enter another public holiday calendar, for example, if you often execute postings with a certain country.
4. Specify whether or not the account is relevant for capital yield tax (CYT) and if an exemption request exists.
5. Specify a resubmission reason and the resubmission date. The possible resubmission reasons are defined in Customizing under
Master Data →Account →Maintain Resubmission Reasons. Under Infosystem → Accounts for Resubmission , you can select the
accounts pending resubmission.

Result
The administration data has been maintained.

1.2.5.2 Displaying an Account

You can view the data for an account in different places in the system. This topic describes how you display the account master record
centrally.

Procedure
1. Choose Account → Display.
The system displays the initial screen for the display of an account.
2. Enter the bank area, account number, and, if required, the business partner data.
3. Choose Continue.
The account master data takes up more than one screen. You can scroll up or down by choosing Previous Screen or Next Screen.
4. You leave the display by choosing Account → Exit or Back.
From the account screen, you can display the following additional information:
· The current account balance by choosing Account Balance.
To avoid the display of unwanted information to customers, the external view is displayed here first. You can choose Internal <-> External to switch to the
internal view.
· A list of all items posted on the account (parked items or those in postprocessing are not displayed) by choosing Display Turnovers and specifying a posting
period.
If you double-click on a list entry you go to the detailed item display. The traffic-light indicates the items for which you have already viewed the details. For
these items the traffic-light is “yellow”.

PUBLIC Page 35 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 · The interest penalty that is to be posted during the next account balancing run.
Choose Display Interest Penalty and specify a posting period. The system displays a list of payment items. Double-click on a list entry to view the item
details.
The system displays this button only if you have selected the Amount Notices feature for the product on which the account is based, and if interest penalty is
due for posting during the next balancing run.
· The data for another account by choosing Account → Other Account.

1.2.5.3 Changing an Account

To change the master data of an existing account, proceed as follows:
01. In the application menu choose Account → Change.
02. Specify the account number of the account and the corresponding bank area.
03. Choose Continue, change your data and save your entries.
To assign another product to an account, proceed as follows:
01. In the application menu choose Account → Change.
02. Specify the account number of the account and the corresponding bank area and then, on the initial screen, choose Edit → Assign product.
03. Specify the new product.
Note the following when you change the assignment of a new product to the account:
You must appropriately maintain any additional fields, particularly the required fields, that have possibly been added by the change to the new product.
If changing the product also leads to a change in the conditions, you must take this into account accordingly. Before changing the product, we recommend you
balance the account to avoid any inconsistencies.
You can only change the condition area (that could be different for the new product) if you have so far made no postings to the account and have not executed a
balancing.

Creation of a Reference Account for Balancing

Purpose
When you balance accounts, you can either post the result on the account itself or on another account (the reference account).
You can define the root account of an interest compensation hierarchy as a balancing reference account. A reference account cannot,
in turn, refer to another account.
To prevent a debit account balance for accounts with the Amount Notices feature, you can also post the result of the balancing run on a
special CpD (suspense) account. You specify the special suspense account in Customizing for Bank Customer Accounts (BCA) by
choosing Account Management → Maintain CpD-Accounts for Special Purposes.
It is also possible to balance an account that has an external reference account (that is managed by an external bank). In this case, the
system creates a payment order. The interest and charges are posted on the account referring to the reference account (referencing
account) as usual (one payment item position per condition category). The offsetting item is posted as one total.

Prerequisites
If you have created an entry in Customizing for the account bank area for which you are creating the reference account for the account
balancing, you can select the account identification for an external reference account. You make this entry in Customizing for BCA by
choosing Account Management → Basic Functions in Account Management → Set up Recipient Account Identification.

Process Flow

Creating a reference account

1. Choose Account → Change.
The system displays the initial screen for the display of an account.
2. Enter the bank area, account number, and, if required, the business partner data.
3. Choose Continue.
The account maintenance screen appears.
4. Choose the Account Balancing tab page.
5. In the Account Balancing group box, choose a reference account type (whether internal or external).
6. Choose with the quick info text Create Reference Account.
7. Enter the required data and choose Continue.

If a reference account already exists, you need to delete it first by choosing with the quick info text Delete Reference Account.

Displaying a reference account

PUBLIC Page 36 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The Balancing group box has the following buttons that that enable you to specify the type of reference account:
· No Reference Account
This indicator shows that the balancing result is not posted to a reference account.
· Internal Reference Account (Direct)
This indicator shows that the balancing result is posted directly to a reference account. In this case, the account referring to another account (referencing
account) and the reference account are both in the same bank area. The interest and charges are posted directly to the reference account. No posting is
made to the referencing account itself, but the interest and charges are displayed in the referencing account overview for the balanced periods. The general
ledger is updated in accordance with the general ledger account assignment of the referencing account.
· Internal Reference Account (Indirect)
This indicator shows that the balancing result is posted to the referencing account and then transferred to the reference account. In this case, a payment order
is created automatically, and can be a bank transfer or a debit.
· External Reference Account
This indicator shows that the balancing result is posted to the referencing account and then transferred to the reference account. In this case, a payment order
is created automatically, and can be a bank transfer or a debit. An external reference account is a reference account that is in a different bank area from the
account referring to it.
When you specify an internal or an external reference account, the bank area and account number (for internal accounts), or the bank
country, bank key, and account number (for external accounts) are also displayed.

Result
The reference account is created. You can now use the reference account for account balancing.

Error Processing:
Internal reference account (direct) If an error occurs on the referencing account, nothing is balanced.
You must correct the error and then restart the account balancing
run.
If the error occurs with the reference account, the balancing item
(interest and charges) is placed in postprocessing. The
referencing account is still completely balanced.
Internal reference account (indirect) If an error occurs on the referencing account, nothing is balanced.
You must correct the error and then restart the account balancing
run.
If the error occurs on the recipient side of the payment order (for
example, the transaction type is locked), the ordering party side is
posted and the recipient side is placed in postprocessing.
If the error occurs on the ordering party side, the system does not
balance the account interval that contains the incorrect account. If
the error cannot be corrected immediately, it is advisable to lock
the referencing account before the restart, to allow the rest of the
account interval to be balanced.
External reference account See the description for the internal reference account (indirect)

Creation of a Reference Account for Account Closure

Purpose
When you close an account, you can specify another account to which the remaining balance is to be transferred when the account is
closed. This reference account can be an external or an internal account.
For accounts with an external reference account for account closure, you can also define a special CpD (suspense) account for
collecting the debit balance on account closure in Customizing for Bank Customer Accounts (BCA). Define the special suspense
account by choosing Account Management → Maintain CpD-Accounts for Special Processes.

Prerequisites
If you have created an entry in Customizing for the account bank area for which you are creating the reference account for account
closure, you can select the account identification for an external reference account. You make this entry in Customizing for BCA by
choosing Account Management → Basic Functions in Account Management → Set up Recipient Account Identifications.

Process Flow
1. Choose Account → Change.
The system displays the initial screen for the display of an account.

PUBLIC Page 37 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 2. Enter the bank area, account number, and, if required, the business partner data.
3. Choose Continue.
The account maintenance screen appears.
4. In the Basic Data tab page, enter the date of the closure.
5. Specify if the reference account is managed internally or externally (at another bank).
6. Choose with the quick info text Create Reference Account.
7. Specify the account details of the reference account on which the balancing result of the account closure is to be posted.
8. Save your entries.

Result
You have successfully created the reference account that is used in account closure.

Account Locks

Use
The scope of functions of an account is always determined by the product to which the account is assigned. You use account locks to
exclude other features, media and transaction types from this basic scope of functions.
To lock an account completely or for certain transaction types, features and media, there are two options that you use in combination:
· Setting the account status:
You can set an account either as Active or as Inactive. If you set an account at Inactive, no postings can be made to the account.

You set the status using the status field on the Basic Data screen.
· Assignment of defined account locks
To only permit certain business transactions, functions and access media for an account, you can individually lock certain functions. You do this by
assigning locks to the account. These locks must be defined in Customizing.

Example for banks

The features standing order, account balancing and bank statement, the media EFT and T-Online, and the transaction types credit,
debit, cash deposit and cash withdrawal/payment are assigned to the product checking account online. You assign the New Opening
lock to a new account, and this excludes the transaction types cash payment and debit and also the medium T-Online. After this, all
functions of the product can be used on the account, but only the transaction types credit and cash deposit. Access is only possible
using the medium EFT. All other accounts assigned to the product remain unaffected.

Example for In-House Cash Centers

A subsidiary company leaves the group. No more payments can be processed.
You do not have to specify just one lock, but can define several locks at the same time. These can also involve locks for functionalities
that are not contained in the product.
Features can be subdivided as follows:
· Medium
Identifies the medium with which a payment order was initiated.
Examples of this include
- EFT (electronic funds transfer)
- T-Online, Internet
- Document
- EDIFACT
- Internal (internally initiated payment order)
· Feature
This concerns features predefined by SAP, for example, balancing, standing order, bank statement, bank closure, cash concentration.
· Transaction type
The customer defines transaction types of payment transactions. In the previous or legacy payment transaction system, text keys and text key
enhancements are displayed by a neutral transaction (in Germany by DAT). You must maintain these transactions in the payment transaction system and in
the SAP system. In the SAP system, attributes that specify the payment transactions are assigned to the transactions. The attributes are predefined by
SAP.
To restrict functions for one individual account, you use locking reasons. Like the function group, a locking reason can include entries of
media, transaction types and features, and locks the specified functions in the scope of functions of an account.

Other notes
If you select One Lock on the function section, the system displays what effect this lock has.
If you select All Locks, the system displays what effect all locks have.

PUBLIC Page 38 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.2.5.6.1 Assigning Locks to an Account

Prerequisites
Before you can assign locks to an account, you need to define locking reasons in Customizing (in the Implementation Guide (IMG) by
choosing Master Data → Account → Define Locking Reasons).

Procedure
1. When you maintain the account, choose the Payment Transactions screen.
2. In the Locked Functions section, choose a line and specify a locking reason using the F4 help.
You can control the functions locked for the account by choosing the detail view of the account in the Functions section.
The Functions section displays the locked and available functions. All existing features and payment transaction operations are always displayed. The
following applies:
Red traffic-light = locked by a locking reason
Green traffic-light = assigned by the product
No traffic-light = not assigned and not locked.
3. Save your entries.
The Functions section shows all the functions still available for the account. This list includes the predefined functions for the product,
and those that you have locked using locking reasons. The display is based on the criteria above.

1.2.5.6.2 Removing Locks from an Account

Procedure
1. When you maintain the account, choose the Payment Transactions screen.
2. In the Locked Functions section select a line.
3. Choose the Delete icon.
You can control the individual functions that are locked for the account by choosing the detailed view of the account in the Functions section.
The system displays the locked and the available functions in the Functions section. All existing features and payment transaction operations are always
displayed. The following applies:
Red traffic-light = locked by a locking reason
Green traffic-light = assigned by the product
No traffic-light = not assigned and not locked.
4. Save your entries.

Result
The locks are deleted and the functions are all available again.

1.2.5.7 Creating Account Hierarchies

Use
Relationships can exist between accounts in the form of a hierarchy, which you can show in a tree structure.
You can create any types of hierarchies. In the standard system, the hierarchy types for cash concentration and interest compensation
are used, but you can also create other hierarchy types, for example, for information purposes.
A hierarchy consists of a root account, for which n subordinate accounts can exist. You can also assign n subordinate accounts to each
of these subordinate accounts. The number of hierarchy levels depends on the hierarchy type.
Relationships within the hierarchy are always valid for a certain time period. You specify this when you create the hierarchy. To ensure
clarity, an account may exist only in one hierarchy at any given time, and within one hierarchy type.

PUBLIC Page 39 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Within the hierarchy it is possible for accounts to belong to different bank areas, provided these are internally managed accounts. You
can only use external accounts as a root account. You can manage the accounts in different currencies, provided the currency is one
participating in the EURO changeover. You can impose restrictions for every hierarchy type, for example, to prevent your employees
from using any cross-bank area accounts.
For more information, see also:
Cash Concentration
Interest Compensation

Creating an Account Hierarchy for Interest Compensation

Use
You use this function to create a hierarchy of the account pool for interest compensation. You define the root account of the hierarchy
first, and can later assign subordinate accounts to it.

Procedure
1. Choose Account → Account Hierarchy → Create.
2. Specify the bank area and account number of the root account for the account hierarchy.

A root account cannot refer to another account in an interest compensation hierarchy.

3. Enter the validity period.

Note on the validity period

Valid From Date
· If you have created the root account specifically for this purpose, the Valid From date of the hierarchy must be the same as the
opening date. In this respect, a new account is one that has not been balanced before, but postings are permitted.

PUBLIC Page 40 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 · If the root account has already existed for some time, the Valid From date must be one date after the date of any of the future
balancing runs. Also, the root account may not be balanced on the same date as the Valid From date. This means that the date of the
last balancing must be before the Valid From date.
If you enter any other date, the system issues an error message.
You cannot change the balancing data for an account once it is used in a hierarchy, (even if the hierarchy becomes valid only after a
few months). The balancing data includes the balancing date, key date, and time periods. This restriction is due to technical reasons,
since the checks that the system makes regarding the suitability of the data only take place during the creation of a hierarchy. If you wish
to change the balancing data, remove the account from the hierarchy, change it, and then insert the account back into the hierarchy.
Valid To Date
· If you do not enter a date, the system automatically enters 12/31/9999 in this field. This means that the hierarchy has an unlimited
validity.
· If you wish to enter the date, ensure that the Valid To date corresponds to one of the future balancing dates of the root account.
If you enter any other date, the system issues an error message.
4. Enter the Interest Compensation Method as the Hierarchy Type, and choose Continue.
The system displays the hierarchy tree, which initially comprises only the root account.
5. Assign (subordinate) accounts to this hierarchy tree by choosing Hierarchy → Account → Create, or with the quick info text
Create.
6. The system displays an overview where you can specify the accounts on the next hierarchy level. Specify the bank area and
account number of the subordinate account for each line.
Subordinate accounts for interest compensation:
Note the following prerequisites for interest compensation subordinate accounts:
¡ If the account was created after the Valid From date of the hierarchy, the balancing date of this account must be the same as the next
balancing date of the hierarchy.
¡ If the account was created before the Valid From date of the hierarchy, ensure that the balancing date +1 at some time corresponds
to the Valid From date of the hierarchy.

The next balancing date of the subordinate account is December 31, 2000, and the Valid From date is February 1, 2001. The
subordinate account is balanced on January 31, 2001. If you add a day, this results in the following date: February 1, 2001.This date
corresponds to the Valid From date, making it valid.
7. Once you have entered all the accounts of this hierarchy level, choose Transfer.If you wish to assign other accounts to the
hierarchy, position the cursor on the relevant account and repeat the steps from point 6. You can do this until the first account balancing
for this hierarchy.
8. Save the hierarchy structure.

Result
You have successfully created an account hierarchy for interest compensation.

Creating an Account Hierarchy for Cash Concentration

Use
You create the account hierarchy that you need for the cash concentration. Cash concentration is the generation of payment orders to
credit or debit accounts in an account hierarchy that a user has created.

Procedure
1. Choose Account -> Account Hierarchy -> Create.
2. Specify the bank area and account number of the root account for the account hierarchy.
You cannot use accounts that have the Term Agreement Control feature as a root account.
3. Choose Cash Concentration as the hierarchy type and specify the time period in which the hierarchy is to be valid.
To specify an external root account, choose the Root Account Int/Ext button, then enter the bank country and the bank key.
4. Specify the type of carryforward.
5. The system displays the hierarchy tree, which initially comprises only the root account. Assign (subordinate) accounts to the
hierarchy tree by choosing Hierarchy -> Account -> Create, or the Create symbol.
6. The system displays an overview where you can specify the accounts on the next hierarchy level. Specify the bank area and
account number of the subordinate account for each line.
You cannot use accounts that have the Term Agreement Control and/or Amount Notice feature as the subordinate account.
Subordinate accounts for cash concentration:
In addition to the bank area and account number, specify the required minimum and maximum balance and the minimum transfer
amount or base amount, and choose Copy (Enter). The system checks that your entry exists and if it is unique.
For carryforward types that are divided into debit and credit:

PUBLIC Page 41 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Minimum balance: The minimum balance that an account must have after cash concentration and to which it is filled if this amount is not reached.
Maximum balance: Any amounts above this are cleared to higher-level accounts. If you do not specify a value here, the account is fully cleared, providing there
is no specified minimum.
The text for the payment notes is transferred during the carryforward to the higher-level account.
Minimum transfer amount: The amount from which an account amount is carried forward.
If you only specify a minimum balance, the system sets the maximum balance to the same level as the minimum balance. If you do not
enter a value for the minimum balance, the system sets this to zero (if you do not want to specify a minimum value for an account, you
can set the minimum value to a high negative amount).
7. Once you have entered all the accounts of this hierarchy level, choose Transfer/Copy. To assign other accounts to an account,
place your cursor on the relevant account and repeat steps 4 and 5.
8. Save the hierarchy structure.

Result
The account hierarchy of the hierarchy type cash concentration has been successfully created.

1.2.5.7.3 Creation of an Account Hierarchy with a Template

When you create a new account hierarchy, you can make use of the structure of a hierarchy that already exists. This is particularly useful when you want to create
the same account hierarchy with a different validity period.
When you create an account with a template, a new hierarchy tree is formed. This consists of the new root account specified by you and all the subordinate
accounts of the template hierarchy.
The definitions you make for the new root account (validity period) apply to all relationships in the new hierarchy.
It is only possible to create a hierarchy using a template within one hierarchy type.
If both the current and the template hierarchy belong to cash concentration, all the cash concentration amounts (minimum balance, maximum balance, minimum
transfer amount) are also copied to all the copied accounts.
When you create the hierarchy tree, the system informs you how many accounts have been transferred.

Creating an Account Hierarchy with a Template

Use
If you wish to create an existing account hierarchy for cash concentration with a different validity period, you can copy this to another
root account.

Prerequisites
The account hierarchy you are using as a template has the same hierarchy type, but a different validity period.

Procedure
1. In the main menu choose Account ® Account Hierarchy → Create.
2. Specify the bank area and account number of the root account for the account hierarchy. Choose a hierarchy type and specify the
time period in which the hierarchy is to be valid.
3. Specify the root account and all other data from the template hierarchy. Using the F4 help provides you with a selection of all
hierarchies already created.

Result
When you create the hierarchy tree, the system informs you how many accounts and cash concentration amounts have been
transferred, and displays the new hierarchy tree.

1.2.5.7.4 Displaying an Account Hierarchy

In the main menu choose Account → Account hierarchy → Display.
Specify the bank area and the root account of the required hierarchy. Choose a hierarchy type and specify the time period in which the hierarchy in question
exists. If there is only one hierarchy with the same root account, you need not enter the time period.
Using the F4 help in the account number field you can view all the root accounts already used.
If the chosen hierarchy is a hierarchy for cash concentration, go to one of the hierarchy nodes and choose ‘display’ to see the cash concentration amounts.

PUBLIC Page 42 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Double clicking on a node provides you with more information on the account behind a node. The system then branches to the account display.

Changing an Interest Compensation Account Hierarchy

Prerequisite
To change a current (used) interest compensation hierarchy, you must first neutralize this, then copy it and make the changes to the
copy.
If a hierarchy is being used, the following actions cannot be performed directly in the hierarchy. Used in this connection means that an
interest compensation run has already been executed.
· You cannot add an account to the hierarchy that was created before the hierarchy, or to which you have already made postings.
· You cannot remove an account from the hierarchy
· You cannot change the interest compensation method of the hierarchy
· You cannot change the “valid from” date of the hierarchy
· You cannot change the balancing date, key date and time periods of an account in the hierarchy

Do not frequently change the interest compensation account hierarchy. Frequent changes have a negative effect on the performance
of account balancing: Every change to the interest compensation account hierarchy has to be taken into consideration during account
balancing.

Procedure
1. In the main menu choose Account → Account hierarchy → Change.
2. Specify the bank area and the account number of the root account and choose Enter.
3. Choose either the icon Change interval or the menu option Hierarchy → Change interval.
4. Change the “valid to” date to the last balancing date of the hierarchy and save your entries.
The current interest compensation hierarchy has been neutralized.
5. In the main menu choose Account → Account hierarchy → Create.
6. In the upper section “Account Hierarchy”, specify the bank area and the account number of the root account of the hierarchy just
neutralized.
7. In the upper section “Account Hierarchy”, as "valid from" date enter the last balancing date +1.
8. In the lower section “Template”, also specify the bank area and the account number of the root account of the hierarchy just
neutralized.
9. Save your entries.

Result
The new hierarchy corresponds exactly to the neutralized hierarchy, the only difference being that the copied hierarchy has not yet been used and can,
therefore, be changed. Now you can add new accounts to or remove accounts from the hierarchy.

1.2.5.7.6 Changing a Cash Concentration Account Hierarchy

In the main menu choose Account → Account hierarchy → Change.
Choose the required account hierarchy.

The hierarchy tree is displayed. Now you have the following options:

To newly create a node, position your cursor on the next higher (next superior) hierarchy level and choose Hierarchy → Account → Create, or the
corresponding icon. The input screen for accounts appears and you can create new nodes on the next lower hierarchy level.
To change the cash concentration amounts, go to one of the nodes and choose Change.
To shift a node within the structure, first select the node (Edit → Select node). Then go to the node to which the target node is to be attached and choose
Hierarchy → Account → Reassign, or the respective icon. Now you can choose if you want to insert the target node on the same hierarchy level or on the next
lower lever. If you wish to shift an entire sub-tree, select it by choosing Edit → Select subtree and proceed as above. During reassignment, the system checks
the currencies of the accounts. You can only reassign accounts managed in the currencies participating in the Euro changeover or in Euro itself.
To change a node, go to the node and choose Hierarchy → Account → Rename. Then overwrite the account number of the node with the new account
number. This change has no effect whatsoever on the master data of the account. All that happens is that the hierarchy is adjusted.
To change the type of carry forward, choose Hierarchy → Type of carry forward. The input screen for the carry forward appears and you can now change
the type of the carry forward.
It is possible to display all the changes made with the change history pushbutton.

PUBLIC Page 43 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.2.5.8 Closing Accounts
In Bank Customer Accounts (BCA), you revoke a business connection by the closure of one or more accounts. A closure involves both
the master data of the account and the balancing runs.
You can close accounts in two ways:
· Close a single account by using the Direct Closure function
· Close several accounts by using the mass run

Prerequisites
· There may be no outstanding checks (PF). Any checks that still exist must have the Returned or Locked status (only applies for banks).
· Payment items may not be In Postprocessing or subject to Dual Control.
· Account closure must be allowed for the product on which the account is based.
See the table at the end of this section for a complete list of checks.

Process Flow for Closing a Single Account

You need to carry out the following activities to close a single account:
1. Choose Account → Change.
The system displays the initial screen for the display of an account.
2. Enter the bank area, account number, and, if required, the business partner data.
3. Choose Continue.
The account maintenance screen appears.
4. On the Basic Data tab page, set the closure date.
The account is flagged for release when you change the account closure date, if you have activated the principle of dual control in Customizing for BCA by
choosing Master Data → Account → Principle of Dual Control for Account Closure.
5. Choose Account → Direct Closure → To Internal Account or To External Account.
6. On the screen that appears, specify the account details of the reference account on which the system must post the result of the
account closure.

For accounts with an external reference account (for account closure), you can define a special suspense account for collecting the
debit balance on account closure. Define this suspense account in Customizing for BCA by choosing Account Management →
Maintain CpD-Accounts for Special Purposes.

Payment notes are also available if you have enabled payment note lines for the type of account closure reference account (internal or external). You can
enable payment notes in Customizing for BCA by choosing Master Data → Product Definition → Product → Create Product or Change Product.
If you have set up the principle of dual control for the bank area, the product and/or the type of reference account in Customizing for
BCA, the account is flagged for release (account closure).
If you have not set up the principle of dual control, the account is automatically closed and released.

Process Flow for Releasing Account Closure

1. Choose Account → Release → Release Account Closure.
2. Enter the required data.
3. Choose Execute.
The system lists the account closures to be released, according to your selection criteria.
4. Double-click an account number.
The account data is displayed.
5. Check the data for the account that has to be released.
6. Choose Back twice.
7. To release the account closure, select the account, and choose Release.
8. The list of account closures to be released appears again.
The released account closure now has the Released status.
9. Repeat the previous steps for all account closures that you want to release.

Process Flow for Closing Several Accounts

1. Choose Account → Change.
The system displays the initial screen for the display of an account.
2. Enter the bank area, account number, and, if required, the business partner data.
3. Choose Continue.
The account maintenance screen appears.
4. On the Basic Data tab page, set the closure date.
5. Choose Account → Direct Closure → To Internal Account or To External Account.

PUBLIC Page 44 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 On the screen that appears, specify the account details of the reference account on which the system must post the result of the account closure.
Payment notes are also available if you have enabled payment note lines for the type of account closure reference account (internal or external). You can
enable payment notes in Customizing for BCA by choosing Master Data → Product Definition → Product → Create Product or Change Product.

For accounts with an external reference account (for account closure), you can define a special suspense account for collecting the
debit balance on account closure. Define this suspense account in Customizing for BCA by choosing Account Management →
Maintain CpD-Accounts for Special Purposes.

If you have set up the principle of dual control for the bank area, the product and/or the type of reference account in Customizing for BCA (by choosing Master
Data → Account → Principle of Dual Control for Account Closure),the account is flagged for release (account closure).
6. Balance the account by using either a single account balancing run or a mass run. If you are using a mass run, note the following:
Accounts with a closure date before the current balancing date are selected automatically. You must start the balancing mass run again if there is another
regular balancing date between the last balancing date of the account and the closure date. In the first run, the account is balanced on the regular date and in
the second run on the closure date. (Note: You can avoid this procedure by balancing accounts on a daily basis).

You only need to balance the account on the closure date if the balancing type Account Balancing and the corresponding time
periods are defined in the account master. Otherwise, the account is closed without final interest or charges being calculated.
7. Choose Periodic Tasks → Account Closure to start an account closure run.
If you have defined a charge condition for account closure, the closure charge is calculated and posted to the account.
The system creates a payment order to transfer the final account balance to the reference account.
Background:
The account closure process ends with an error if any of the following checks fail during direct or mass closure:
Check Description
Account The account is not locked by any other process.
Product The Account Closure feature is enabled for the product.
Checks (only applies for banks) Locked or Issued checks (PF) do not exist for the account.
Standing orders (only applies for banks) Standing orders are not due for execution before the account
closure date.
Locks Credit or debit locks do not exist for the account.
Individual value adjustment (IVA) IVA postings do not exist for the account
Reference account The account is not a reference account for account closure or
balancing.
Reference account for account closure A reference account for account closure is defined for the
account.
Member of an account hierarchy The account does not belong to an account hierarchy.
Payment items Payment items with the In Postprocessing or a control status do
not exist.
Payment items with a value date after the account closure date
do not exist.
Forward orders Forward orders in which the account is an ordering party do not
exist.
Planned items Planned items do not exist for the account.
Amount notices If the Amount Notices feature is enabled, full amount notice with
closure is specified for the account.
Reserved amount (hold) Active holds do not exist on the account.
Account balancing The account balancing does not fail during the account closure
process.
Bank statement The bank statement generated during the account closure
process does not fail.

Result
When you complete these steps, the system prepares the data for the bank statement and supplies it to the bank statement interface. It
creates a payment order for the remaining balance and sets the account status to Closed/Flagged for Archiving.
In addition, the system restricts the validity of released limits to the closure date, if limits that are valid after the account closure date
exist. Limits that are not yet released are deleted.
Change documents record all the changes, including those made to the limits. This document is the basis for limit reactivation.

PUBLIC Page 45 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.2.5.9 Reactivating an Account

Use
You can use this function to reactivate an account that has already been closed (this function is used by banks).
When an account is closed, the system performs several checks before actually closing the account. These include, for example, the
check to see if standing orders still exist or if the account is used in account hierarchies. Additionally, the account is balanced and the
balance brought to zero. See also: Closing Accounts
You can reset account closure if required. Once an account has been successfully reactivated, it shows the status "New" and a balance
of zero.
If standing orders exist for this account, (at closure they were given the status "deleted"), the system issues a warning and also a note in
the long text suggesting you check the deleted standing orders and create them again if necessary.
You can define whether limits are to be reactivated if they were changed by the account closure. The system finds these by means of
the change documents of the account closure.
If an account was involved in an account hierarchy, the system issues an appropriate message when you reactivate it. This serves as
an aid if an account was closed by mistake and you wish to include it in this hierarchy again.

Prerequisites
You have closed an account and want to reactivate it for a particular reason (for example, a customer request).

Procedure
1. Choose Account → Change.
2. Enter the data for the account you want to reactivate.
3. Choose Edit → Reactivate account.
The system displays the Reactivate Account dialog box.
4. Select the check box Reactivate Limits Changed by Closure to reactivate limits.
5. Choose Continue.

Result
The account has been successfully reactivated and is now available for further processing. If you select the selection field, the limits
changed during the account closure regain the status they had when the account was closed.

1.2.6 Euro Changeover

Purpose
This section describes how you can depict the currency changeover to the European uniform currency with the help of the current account system.
This system supports you during the dual currency phase with the changeover of the account currency and with the processing of payment orders in different
currencies. The changeover of the account currency to Euro can only be performed for accounts in one of the participating currencies.
Definition of terms:
In the following explanations the following terms apply:
Account currency:

The currency in which an account is managed. Postings are always made in account currency.

Reporting account currency:

During the dual currency phase, for every account managed in one of the participating currencies, there is, in addition to the actual account currency, a
reporting account currency purely for information purposes. All turnovers are shown both in the account currency and in the reporting account currency.

Participating currency:

A currency taking part in the changeover process to Euro.

Transaction currency:

The transaction currency is the currency in which cash flows from one account to another.

Integration
The "Euro changeover" part of the current account system serves to:
Change over the currency of accounts from a participating currency to Euro.
Process payment transactions during the dual currency phase in Euro and in participating currencies.
Display the turnovers, items and balances during the dual currency phase.

Scope of functions
During the dual currency phase, the following dependencies between the account currency and the reporting account currency apply:

PUBLIC Page 46 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Original currency of the account Account currency Reporting account currency
Non-participating currency, e.g. US $ US dollars Not supported
Participating currency, e.g. German Marks DM Euro
Participating currency, e.g. German Marks Euro DM
New opening in Euro Euro The bank area currency applies
If the bank area is a participating currency, this
applies.
If the bank area currency is Euro, the bank area
currency before the changeover applies.

1.2.6.1 Changeover of the Account Currency

Purpose
This process describes how you can changeover accounts in the current account system to the European single currency Euro.

Since clearing accounts and CpD (suspense) accounts are currency-dependent and are not changed over, you must create these before
changeover per bank area and per currency as new accounts in the Euro currency.

Process flow
Adjust the limits.
You must newly create individual limits from the changeover date in Euro.
Newly create both overdraft limits as well as internal and external account limits. SAP also offers a report for these limits that converts the amount in accordance
with the exchange rate to Euro for the period after changeover and enters a new limit in EUR.
Reference limits are currency-dependent. This means that for an account that refers to a reference limit, the limit always applies in account currency.
Example: There is an internal reference limit for students of 1,000 DEM. A reference limit of 500 EUR has already been created with the same reference limit ID.
An account with this reference limit has an internal limit of 1,000 DEM before changeover and 500 EUR after changeover.
Create conditions in Euro. You can assign conditions in Euro to the condition groups at any time. Until one day before the changeover key date, the conditions in
the old account currency apply for the individual accounts and as of the changeover key date these conditions are replaced by the "Euro" conditions. You have to
maintain individual conditions manually.
Note on each respective account that it is intended for changeover of the currencies.
Activate the executable program that periodically changes over all accounts flagged for changeover.

Result
During the changeover, items and balances in a participating currency are first taken off the books and then put back on the books again in Euro. After the
changeover of the account, all items from balancing are posted in Euro - including those for periods ending before the changeover key date (value dates in the
past). The account is now managed in Euro.

Changing over an account from DM to Euro

Posting date Value date Amount Account currency

05/15 05/01 + 500 DM
05/15 05/04 - 200 DM
05/30 06/02 + 50 DM
Euro Changeover on June 1.
06/01 06/01 -300 DM
06/01 06/02 -50 DM
06/01 06/01 + 150 Euro
06/01 06/02 +25 Euro

1.2.6.1.1 Changing Over an Account

Prerequisites
In the Implementation Guide (IMG), define per bank area which currencies you plan to change over to Euro and set the indicator for
release according to the principle of dual control. This indicator prevents an erroneous currency changeover. Releasing in accordance
with the principle of dual control is optional, but SAP recommends you adopt this procedure.

PUBLIC Page 47 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 It is not possible to undo an erroneous currency changeover of accounts.

Procedure
1. Go in change mode into the account you wish to change over.
2. Specify the account number of the account and the corresponding bank area.
3. Choose the section ‘currency changeover’.
4. Enter the request/order date and the changeover date.
Once you have maintained the changeover dates, the account has the changeover status (not the account status) ‘created’. Until released, the dates can be
changed.

Alternatively, you can execute a mass changeover by choosing Periodic tasks →Currency changeover →Prepare currency
changeover.You can make the selection of the affected accounts using bank area, account number, account holder, product and
currency before changeover.

Release
1. Release the changeover data by choosing Account →Release → Release Currency Change.
2. Enter the required data and choose Execute.
Executing the release is subject to the authorization check. After execution, the accounts for processing appear in list form. In the first column of the list, a
traffic-light shows the editing status of the accounts:
Red = release must be effected by another user
Yellow = release has been executed
Green = release is to be executed
3. Position your cursor on the relevant line.
4. Press the button ‘Release’.
Once released, the changeover data can no longer be changed. The status of the currency changeover stands at ‘Flagged for changeover (released)’.
5. On the specified changeover date, a program is automatically started that checks which changeover dates are before the next
posting date and then changes over these accounts.

Deletion of the release

If you have erroneously released the changeover data and wish to undo this action, you must delete the release.
In the currency changeover section, a delete indicator also appears after release. Select the delete indicator field in the currency
changeover section and then release the deletion, so that the release is removed from the account master data.
If the changeover data is flagged for deletion in the account master, (delete indicator is set), there is an error message in the log of the
execute program (report) that checks the changeover data on the changeover date. The system does not perform currency
changeover for these accounts.

Changeover without principle of dual control

Prerequisite for this is that you have not set the principle of dual control indicator in the Implementation Guide (IMG).
1. Go in change mode into the account you wish to change over.
2. Specify the account number and the corresponding bank area.
3. Choose the section ‘currency changeover’.
4. Enter the request/order date and the changeover date.
Once you have maintained the changeover dates, the account has the changeover status ‘flagged for changeover’ (released). You can
still change the dates until the execute program changes over the account.

Result
The selected account has been changed over from one of the participating currencies to Euro.

By flagging an account for Euro changeover, a block indicator is automatically set on the account. As long as the account is not
changed over to Euro, all postings with a posting date after or on the changeover date are held back. These items are noted in a
separate table and updated later. No updating of the general ledger takes place. Prerequisite for the floating of items is that the
amount can be determined in account currency after the currency changeover. If this is not the case, the item is rejected showing the
indicator ‘import error’.

1.2.6.1.2 Changing Over an Account after Account Balancing

Use

PUBLIC Page 48 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 It is possible to set for the bank area that the date for currency changeover of an account is linked to account balancing. This means that the currency changeover
must always take place one day after an account balancing.
The public holiday calendars are taken into consideration for the calculation of the changeover date.
There are two options in the algorithm for the calculation of the changeover date.
01. It is assumed that an account balancing is executed on a working day. This means that if, in the list of future account balancing dates, one of the dates falls on
a public holiday, the system increases this until it falls on a working day.
02. It is assumed that the currency changeover also only takes place on a working day. This means that once the system has added one day to the potential
account balancing date, it then checks if the potential currency changeover dates fall on a public holiday. If this is the case, the system once again adds a
day until the respective date falls on a working day.
This is illustrated in three examples:
Example 1:
Official account balancing Monday
Assumed account balancing Monday
Account balancing + 1 day Tuesday
Calculated currency changeover day Tuesday

Example 2:
Official account balancing Friday
Assumed account balancing Friday
Account balancing + 1 day Saturday
Calculated currency changeover day Monday

Example 3:
Official account balancing Saturday
Assumed account balancing Monday
Account balancing + 1 day Tuesday
Calculated currency changeover day Tuesday

Prerequisite
You must have entered the public holiday calendar in the Implementation Guide (IMG).

Procedure
The changeover takes place automatically. If the date of the changeover is changed, a warning message appears.

Result
The changeover is related to account balancing.

1.2.6.2 Payment Transactions in the Dual Currency Phase

Use
Postings to an account are always only in the currency in which it is managed. This means that before changeover, postings to the account are in the participating
currency. After the changeover, postings to the account are in Euro. This applies independently of the posting date and value date. To ensure smooth-running
payment transactions during the dual currency phase, the amounts of the individual payment items exist both in an account currency and also in a reporting
account currency.
It generally applies that a payment order must always be specified in the account currency (a currency participating in Euro changeover and Euro) of the ordering
party.
The following currency fields are provided for payment items:
Account currency
Transaction currency
Reporting account currency

A payment item with the transaction currency of 200 DM is received for an account managed in the account currency Euro. The system converts
this payment item and credits the amount in Euro.

Internally initiated payment transactions:

Before the dual currency phase, the transaction currency corresponded to the account currency. During the dual currency phase, the transaction currency can
correspond to the account currency or the reporting account currency.
Externally initiated payment transactions:
In the case of externally initiated payment transactions, the system assumes either the transaction currency or the reporting transaction currency.

Scope of functions
Direct debit orders (only applies for banks)
Direct debit orders can be entered both in account currency and also in reporting account currency. If there is a direct debit order in reporting account currency,
the conversion from account currency to reporting account currency is done in the system.
Direct debit orders can be changed over independently of the account changeover.
Changing over standing orders (only applies for banks)
Standing orders can be entered both in account currency and also in reporting account currency. If there is a standing order in reporting account currency, the
conversion from account currency to reporting account currency is done in the system.

PUBLIC Page 49 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 You can change over the standing orders independently of the account changeover.
Account balancing:
After the changeover of the account, all items from balancing are posted in Euro - including those for periods ending before the changeover key date (value dates
in the past).
Postings to prior periods:
For postings to prior periods containing payment items with a posting date before the changeover, Euro applies as account currency.

Postings to prior periods

Item Post. date Value date Amount

(10) 03/29 04/30 75.- EUR
Transaction Post. date Value date Currency Amount
figures:
(0) 03/30 03/28 DEM 800
(0) 03/29 04/02 DEM 200
(1) 04/01 04/01 DEM -200
(1) 04/01 04/02 DEM -800
(3) 04/01 04/01 EUR 400
(3) 04/01 04/02 EUR 100
(4) 04/03 03/30 EUR 500
(10) 03/29 03/30 EUR 75
Value date Post. date Currency Amount
balance carry
forward
(0) 03/31 DEM 800
(4) 03/31 EUR 500
Post. date balance Value date Currency Amount
carry forward
(1) 03/31 DEM 800
(10) 03/31 EUR 75
Account balance:
(4) EUR 1000
(10) EUR 1075

Returns:
It is assumed that a payment item with transaction currency Italian Lire (ITL) and account currency German Marks (DM) is posted to and account in DM. Then the
account is changed over to the Euro currency (EUR). Following this, the payment item is to be returned.
Since the account currency after changeover is EUR, interest and charges for the return can only be calculated in EUR. Returns are always made in the original
currency. Since in this case, the original transaction currency was ITL, the interest and charges are also converted to Lire. For this reason, the system creates and
executes a return order with the original transaction currency ITL and the account currency EUR.

1.2.6.3 Display Options for Turnovers and Amounts

Use
To enable the display of the prepared currency changeover data stored on databases, the display options have been enhanced by a few fields.
Amounts Display formats
Turnovers Account currency
Payment orders Reporting account currency
Transaction currency
Limits Account currency
Subject to final payment balance Reporting account currency
Subject to final payment-free account balance
Conditions
Account balances
Available amount

Scope of functions
Limits:
The limits are displayed depending on their validity in account currency.
Account balance:
The account balance and also the limit relating to this account, the subject to final payment balance, the subject to final payment-free balance and the available
amount are displayed in account currency. With the help of a pushbutton you can switch the display to the reporting account currency. If the account is in the
changeover phase, the account balance is automatically displayed in the reporting account currency.
Turnovers:

PUBLIC Page 50 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The turnovers are displayed in accordance with the pre-setting in account currency. It is possible to switch to display in the reporting account currency using a
pushbutton. Note that before the account changeover, the amount of the turnovers in reporting account currency is 0. The list overview provides you with a view of
the turnovers in account currency, reporting account currency and transaction currency.
Bank statement:
The following columns are provided for bank statements:
Account currency
Old account balance
New account balance
Reporting account currency
If the transaction currency is not the same as the account currency, this is explicitly displayed as for foreign currency.
A check module is called up within the conversion report before the currency changeover. This checks if current items for the account exist with a posting date
before or on the changeover date that were not yet on a bank statement. If the check result is positive (meaning items do exist), a statement is created. The items
are shown in the current account currency (for example, DEM) and in the reporting account currency (for example, Euro). If the account currency is not the same
as the transaction currency, there is an additional display in transaction currency. The balance is only displayed in account currency.
If no items are selected, no action is taken.
Within the conversion report a bank statement is created in all cases after the currency changeover. This contains notification that the account has been changed
over. The old balance is shown in the old account currency (DEM) and the new balance in the new account currency (EUR).

<Address>
Changeover date: 01/01/99
Date of request/order: 12/01/98
Old balance: 500 DEM
Your account has been changed over from DEM to EUR.
New balance: 250 EUR

The subsequent bank statements are the same as those before the changeover, except that the account currency (now EUR) and the reporting account currency
(now DEM) have been swapped. The balance is again only shown in the account currency (now EUR).
Interest scale:
If the Euro changeover key date falls in a period for which an interest scale is created, the turnovers, balances and interest are shown before the changeover key
date, for example, in DM and after the changeover key date in Euro.

Turnover Balance Interest

03/31 1,000.- DM 1,000.- DM 10.- DEM
04/04 200.- DM 1,200.- DM 12.- DEM
04/08 Changeover 600.- EUR 6.- EUR
04/12 300.- EUR 900.- EUR 9.- EUR

This means it will not be possible to display the whole period only in DM or only in Euro.

Activities
To have the amounts displayed in the respective currencies, go to the overview function as required, for example, to the document overview of the turnovers. To
look at the turnovers in the currency you want, press the pushbutton to have the display in account currency or reporting account currency and for payment
transactions also the transaction currency.

For overview lists relating to account balances, the amounts are first displayed in the account currency. To enable a display for the whole bank
area, it is possible to make a conversion from account currency to bank area currency.

1.2.6.4 Overview of Currencies Posted for Balancing

Use
The combination of the data listed below determines the currency display of the periods to be settled and the currency in which posting actually takes place.
In most cases, the currency display of the balancing and the currency in which is posted are identical.
One exception is the combination of "next balancing date is before the changeover date" and "changeover date is before the posting date of the next balancing".
In this case the currency displayed (DEM) is not the posting currency (EUR) if the account has already been changed over to Euro. The system automatically
executes a balancing (in DEM) and converts to Euro. The difference in the currencies has no effect on the posting.
If you wish to avoid the situation of having different currencies in the display and for posting, ensure that the posting date of the balancing is before the changeover
date.
The following statements of the balancing currency and actual posting currencies result, depending on the dates:

PUBLIC Page 51 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Combination of the dates Displayed balancing Actual posting Note
Next balancing date for account DEM DEM Before the changeover can take
before the place, balancing must be carried out
posting date of balancing,
before the
changeover date
Posting date of balancing, DEM DEM Before the changeover can take
before the place, balancing must be carried out
next balancing date for account
before the
changeover date
Next balancing date for account DEM EUR Account is Euro-blocked, meaning it
before the must be changed over before
changeover date balancing can take place.
before or on the
posting date of balancing,
Posting date of balancing, EUR EUR Account is Euro-blocked, meaning it
before the must be changed over before
changeover date balancing can take place.
before or on the
next balancing date for account
Changeover date EUR EUR Account is Euro-blocked, meaning it
before or on the must be changed over before
next balancing date for account balancing can take place.
before the
posting date of balancing,
Changeover date EUR EUR Account is Euro-blocked, meaning it
before or on the must be changed over before
posting date of balancing, balancing can take place.
before or on the
next balancing date for account

Account Management and Manual Editing of Items

Purpose
Accounts are managed in the in-house cash center on the basis of the payment items (turnovers) posted - in general automatically - to
the account. The payments are entered by the affiliated companies and transferred by IDoc to SAP In-House Cash for posting. From
the perspective of SAP In-House Cash, these payments fall under the heading of externally initiated payment transactions.
Internally initiated payment transactionsare triggered in SAP In-House Cash as a result, for example, of a telephone request from
one of the affiliated companies. The principle of dual control based on amount-dependent release functions is available for IHC
payment orders and payment items.
Flexible route processing lets you manage payments if the payer and payee accounts are in different bank areas. You do this by
defining clearing partners and rules for route determination in Customizing.
For more information on route processing, see Route Processing for External Payments.

Implementation Considerations
Make the necessary settings in Customizing under Account Management → Payment Processes in In-House Cash.

Scope of Functions
When processing payment transactions we differentiate between IHC payment orders and payment items:
· IHC payment orders are orders from internally initiated payment transactions, comprising one ordering party item and several recipient items.
· Payment items are individual items, updated to an account within the current account system.
In the context of account management, the following functions are available for manual entry and post processing:
· Create, create (backdated), post process, return, reverse, delete, and release payment items
· Create planned item
· Create, post process, and release internal and external IHC payment orders

PUBLIC Page 52 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Route Processing for External Payments

Purpose
You can use this process for all types of external payments:
· Cross-bank-area payments using one or more in-house cash centers
The in-house cash center forwards the incoming payment order to a second in-house cash center which serves as a clearing partner. This process can be
repeated. Each in-house cash center is based on a separate bank area. The in-house cash centers can be located as follows:
¡ In the same client
¡ In different clients
¡ In different SAP systems
· Local payments
The in-house cash center forwards the payment orders to a subsidiary company which is also defined as a clearing partner.
· Central payments

You do not need route processing for internal payments.

Prerequisites
You have determined the parameters for route processing. For more information, see Editing Route Processing.

Process Flow
This is a basic version of the critical process flow steps. The aim of route processing is to determine a clearing partner to make the
payment.
1. When the in-house cash center receives an IHC payment order, the system checks if it is an external payment.
If this is the case, in other words if the bank numbers or bank countries of the payer and payee are different, the system triggers route processing.
2. The system checks the fields in the IHC payment order.
If a route processing rule matches the fields, the system adds the route to the list of routes found.
3. The result is a list of one or more routes that are permitted according to the specified rules. A clearing partner is defined in
Customizing for each route and the IHC payment order can be forwarded to this clearing partner.
The system ultimately determines the clearing partner from the route with the highest level of priority.

Example
You let the system determine the clearing partner based on the transaction currency of the payment orders to avoid foreign payments.

1.3.1.1 Editing Route Processing

Use
This function lets you create a set of rules for determining routes. The system uses route processing for external payments when the
recipient’s account is not located within the same bank area as the payer.
For more information, see Route Processing for External Payments and the SAP In-House Cash configuration guide.

Prerequisites
You must have defined a clearing partner. In Customizing for SAP In-House Cash, choose Account Management → Payment
Processes in In-House Cash → Define Clearing Partner.
You must have assigned clearing partners to routes. In Customizing for SAP In-House Cash, choose Account Management →
Payment Processes in In-House Cash → Make Basic Settings for Payment Processes.

Scope of Functions
· Initial Screen Set of Rules for Route Processing
¡ Display routes
¡ Create routes
¡ Copy routes
The system will only copy if the set of rules does not yet exist. This prevents you from overwriting an existing set of rules.
If you want to replace a set of rules, delete it before you copy a new one.
¡ Change routes

PUBLIC Page 53 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 ¡ Transport routes
¡ Delete routes

You cannot restore a deleted set of rules.

¡ Display log
· Editing Screen Set of Rules for Route Processing
On the left of the screen you can see the set of rules for editing, laid out in a graphic structure. The route, rules and conditions are shown here in a logical tree
structure.
In the screen area on the right you can see the input fields for data relating to the set of rules. Under the input fields, the graphic structure is reproduced in the
form of a table. You cannot change this display.
The symbols in the editing screen can be interpreted as follows:

Symbol Description Use

Set of rules. The name is always exactly Once
the same as the bank area.
Route Multiple uses possible
Rule Multiple uses possible
Logical condition. Based on fields in the Multiple uses possible
IHC payment order.

· Structure of the Set of Rules

You create one single set of rules per bank area. However, you can define any number of routes, rules and logical conditions. An IHC payment order field
selection is available to help you to define conditions.
The rules are linked with an disjunction (OR). Only one rule needs to apply for the system to add the route to the list of routes found.
The conditions of a rule are linked with a conjunction (AND). All conditions defined for the rule must apply for the system to consider the rule as true.
Set priorities for the routes if the set of rules contains more than one route. Number 1 represents the highest priority. If you change the priority of a route, the
system interprets the change as having priority and adjusts the priorities of other routes if necessary.

If you use the context menu for editing the graphic set of rules, you can tell directly which functions are available on the level you are
currently processing.

Note the following restrictions when structuring your set of rules:

Activity Restriction
Insert as subnode · You can only insert routes on set of rules level.
· You can only insert rules on route level.

Insert on the same level · You can only insert routes on route level.
· You can only insert rules on rule level.

Delete You can only delete the nodes of routes and rules.
Call field selection of IHC payment order The field selection is called by double clicking on the rule
symbol.

Activities
In Customizing for SAP In-House Cash, choose Account Management → Payment Processes in In-House Cash →Set Up Route
Processing to edit route processing. You create a set of rules for route determination for each bank area.

Example
The following graphic shows a simple example of a processing screen. Set of rules IHC contains a single route, called Route 1.
The route in turn contains 2 rules.

PUBLIC Page 54 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.3.2 Payment Item

Definition
A payment item is an individual posting on a current account. The payment item can either originate from an internally initiated payment
transaction (entered directly or during posting of a payment order) or from an externally initiated payment transaction.
An item can be posted, parked, or placed in postprocessing. The status Parked means that it has already been assigned to an account
but is not yet included in the account balance.
A payment item is a one-sided turnover on a current account, representing either a credit or a debit.

Structure
A payment item can consist of more than one position, which can be the case, for example, with account balancing items. Items created
internally and items transferred from the payment transaction system consist of one position or item. You can, however, create one or
more additional positions (such as charges, tax or interest penalty) during posting.
Every payment item comprises information regarding:
· The transaction type describing how the item was updated.
· The medium via which the item or the payment order belonging to the item was brought to the bank.
· The payment method with which the corresponding item was forwarded.
· The value date from when interest and charges are applicable.
The system successfully posts the payment item only if the value date lies within the time limit that you define in either of the following features:
¡ Value date conditions
¡ Value date limits
You define the value date limits in Customizing for Bank Customer Accounts by choosing Account Management → Default Values →
Define Limits for Value Date.
If customer fields were maintained in Customizing for the bank area, they are also available and transferred from the system to the bank
statement.
You can differentiate payment items according to the following criteria:
· Status: Depending on whether the item is “in postprocessing” or “posted”, there are various options for editing the item.
· The account to which the item was posted: CpD (suspense), clearing account, and other accounts.

1.3.2.1 Creating Payment Items

Payment items are created by payment transactions when payment orders are updated or transferred from the payment transaction
system. You can also manually create payment items for internal postings, for example, goodwill postings.

Procedure

PUBLIC Page 55 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1. Choose Account Management à Payment Item à Create.
2. Specify the transaction type, the bank area, and the account number.
3. If the account has the Amount Notice feature enabled and if the transaction type has been flagged as relevant for interest penalty,
then you can display the current and future allowances by choosing Extras → Allowances when you are processing disbursements.
Allowances are amounts that the customer can withdraw during the withdrawal period without incurring penalties.
Choose the Interest Penalty button to display the interest penalty incurred for the item. You need to then decide whether or not to post the payment item (you
may not post the item for reasons of goodwill towards the customer).
If you do not make the decision here, you are needed to do so when you enter the posting (required by the system).
4. On the item entry screen, specify the value date of the posting and the posting amount. You can also enter payment notes, if
required.
5. You then have the following options for further processing:
¡ You can post the item. Depending on the transaction type, the system runs the appropriate checks (such as account, limit, check (PF
for banks only), business partner, and locked transaction type). If you have defined a minimum deposit on the account and activated the
limit check, the system also checks the minimum deposit when it checks the limits.
¡ If the check fails, you can force the posting and the system excludes all relevant checks.
¡ It is still possible to park the item first, which can then be processed in postprocessing.

Payment items are parked with the corresponding control status if you have set up the (amount-dependent) principle of dual control
for the processing of payment items in Customizing for Bank Customer Accounts. You set up dual control for the processing of
payment items by choosing Authorization Management → Amount-Dependent Authorizations → Maintain Amount Limit/Principle of
Dual Control for Payment Item. Dual control applies to the following activities related to payment items:
§ Create and change
§ Post, transfer post, and force post
§ Reverse and return
Another user with appropriate authorization must then release the payment item. To release the payment items, choose Account
Management → Payment Item → Release. The system lists all the items that have not yet been released. Go to the detail view and
choose Release.

Creating Payment Items (Special)

Use
In addition to creating payment items on the current posting date, you can also create payment items in former periods (backdated in
previous settlement periods).
This allows you to depict transactions whose posting date is in the past.

Procedure
Creating Backdated Payment Items
1. Choose Account Management → Payment Item → Create (Special) → Backdated.
2. Specify the transaction type with which the item is to be updated, and the bank area and account number of the respective account.
3. On the item entry screen specify the posting date and the value date of the posting, and the posting amount. In addition, you can
enter payment notes and view the details about the transaction and the references (day book).

Result
You have successfully created a payment item in the past.
On further processing, see also: Creating Payment Items

The payment item is parked with the corresponding control status if you have activated the (amount-dependent) principle of dual
control for the processing of payment items in Customizing for BCA. You set up dual control for payment item processing by choosing
Authorization Management → Amount-Dependent Authorizations → Maintain Amount Limit/Principle of Dual Control for Payment Item.
Dual control applies to the following activities related to a payment item:
§ Create and change
§ Post, transfer post, and force post
§ Reverse and return
Another user with appropriate authorization must then release the payment item. To release the payment item, choose Account
Management → Payment Item → Release. The system lists all the items that have not yet been released. Go to the detail view of a
payment item and choose Release.

PUBLIC Page 56 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.3.2.3 Processing Items in Postprocessing

Use
Payment transaction items in postprocessing or parked items involving cash flow must also be transferred to the general ledger, even
though none of the items is posted to the account in the current account system. The system takes this into consideration.

Prerequisite
You can specify if and how postings are to be made to separate general ledger accounts in the Implementation Guide (IMG) by
choosing Periodic Tasks àGeneral Ledger Transfer àDefine GL Account Assignment for Items in Postprocessing.

Process Flow
Possible cases for items being transferred to postprocessing include the following:
· Ordering party and recipient items (in externally initiated payment transactions) that failed a limit or account check.
· Recipient items (in an internally initiated payment transaction) that failed a check.
Manually parked items (with no payment order) are not transferred.
Once the item is no longer in postprocessing, it is transfer posted accordingly during the next general ledger transfer.

For more information, see the documentation on automatic reports, under Process Flow of End-of-Day Processing.

1.3.2.4 Postprocessing Payment Items

Use
With the help of this function you can post items, change item data, force postings, transfer post items, delete, or reject items.

Prerequisites
Items can be in postprocessing because:
· They were only parked during manual entry.
· The checks for externally initiated ordering party items failed.
· The checks for recipient items and turnover items failed. Depending on the Customizing of the corresponding transaction type, this could mean, for example:
¡ The internal credit/planning limit of the account was exceeded
¡ The specified value date is beyond the tolerance range
¡ There are locks on the account for the transaction type
¡ The relevant transaction type has not been maintained for a direct debit order or the collection authority for a debit collection is
missing
¡ A check cannot be cashed (only applies for banks)
¡ There is a lock on the business partner
In addition to your normal authorization, you also have the F_PAYM_ACT authorization for the activities Transfer Post and Force
Posting.

Procedure
All items with the status In Postprocessing can be edited as follows:
1. Choose Account Management → Payment Item → Postprocess.
You can either select the required item by means of the bank area, account number, business partner number of the account maintenance officer, and
posting date or by means of the item type (ordering party, recipient, routing, and turnover item) and the posting process from which this has resulted (for
example, online entry payment order or transfer posting). For more detailed selection options, choose Dynamic Selections.
2. The system displays an overview of the items that meet your selection criteria. Note the following:
¡ For payment items with several positions, the individual positions along with position number are listed under one another.
¡ The traffic-light shows the status of the editing in this selection run. On this subject, read the corresponding explanation on the editing of
payment orders.( Editing Payment Orders)
Double clicking a item or a position brings you to the detailed display of the payment item. You now have the following options:
· Post the item
If the reason that caused the postprocessing no longer applies (for example, check is now covered or limit extension), the item can be posted.
· Change item data

PUBLIC Page 57 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Depending on the type of item, certain details can be changed (for example, the check number) to enable correct posting.
· Force the posting
When you post a payment item, the system performs various checks. Some of these checks depend on the business transaction and the transaction types
used. If any of the checks fails, the transaction is not posted. The system displays an error message to explain the reason for the check failure. You can
choose the Force Posting button to enter the posting despite the errors. The system excludes all relevant checks.
Additionally, you have the option of switching in display mode from the error message to the ordering party account to review and analyze the message (for
example, Locked or Limit Exceeded).
· Transfer post
Payment items can be transfer posted to another account.
¡ If the payment item has not yet been posted, you can achieve this by changing the account number.
¡ If the item has already been posted, the system creates the respective reversal and new posting.
You can also transfer post payment items to accounts that belong to a different bank area. Prerequisite for such a transfer posting is that the payment item
has the Posted or Posted (Open Item) status.
· Delete/reject
Items for which cash has not yet flowed (internal postings) can be deleted.
Externally initiated ordering party items can be rejected or deleted. The ordering party item is deleted and, if there is a reference number from the external
payment transaction system, the deletion is registered with the external payment transaction system.
· Enhance direct debit order
If a payment item is in postprocessing because the transaction type of the payment item includes the "Check for direct debit order", and there is no direct
debit order for the payment recipient defined in the payment item, you can add another item to an existing direct debit order for an account.
Choose Edit → Assign Name → Direct Debit Order. The system displays all existing direct debit orders for this account. Select the relevant direct debit
order.
A new item is added to the direct debit order for the payment recipient. The proposed values for Amount and Currency are taken from the first item in the
direct debit order.

If you are looking at the detail data of the payment item, choose Goto → Account or Goto → Payment Order to display the account
or payment order belonging to this item.

The payment item is parked with the corresponding control status if you have activated the (amount-dependent) principle of dual
control for the processing of payment items in Customizing for BCA. Set up dual control for payment item processing by choosing
Authorization Management → Amount-Dependent Authorizations → Maintain Amount Limit/Principle of Dual Control for Payment Item.
Dual control applies to the following activities related to a payment item:
§ Create and change
§ Post, transfer post, and force post
§ Reverse and return
Another user with appropriate authorization must then release the payment item. To release the payment item, choose Account
Management → Payment Item → Release. The system lists all the items that have not yet been released.

Processing Payment Items on a CpD (Suspense) Account

Use
(Turnover) items are posted on the CpD (suspense) account if:
· The recipient account specified in the item does not exist.
· An item is diverted to the CpD (suspense) account during postprocessing.

Procedure
The items have the Posted/Open Items status and can be processed as follows:
1. Choose Account Management → Payment Item → Edit CpD (Suspense).
2. Specify the bank area and account number of the CpD (suspense) account.
You can further limit your selection of the required items by specifying the item number and posting date. Choose Dynamic Selections for an even more
detailed selection option.
3. The system displays an overview of the selected items.
To view the payment item details, click an item or position. You now have the following options:
· Transfer Post
When the correct recipient has been determined, payment items can be transfer posted to another internal account.
· Transfer External
You can transfer post a payment item to an external account.

PUBLIC Page 58 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 · Reverse
Items resulting from internal postings can also be reversed.
· Return
You can use all the functions described under Returning a Payment Item, provided you have defined return reasons.

Reversing Payment Items

You can reverse payment items that are already posted (status Posted (Open Item) or Posted) if the following prerequisites are met:
· The item is created online or originates from the data transfer of balances. (Note: It is also possible that items resulting from internally initiated payment orders
are reversed by the reversal of the payment order).
· Reversing is allowed for the transaction type of the payment item.
You can allow reversal for a transaction type in Customizing for Bank Customer Accounts (BCA) by choosing Account Management → Basic Functions in
Account Management → Maintain Transaction Types.

Procedure
1. Choose Account Management à Payment Item à Edit (Special) à Reverse.
2. You can either select the required item by means of the bank area, account number, and posting date or by means of the item type
(ordering party, recipient, routing, and turnover item) and the posting process from which the item has resulted (for example, online entry
payment order or transfer posting). For more detailed selection options, choose Dynamic Selections.

You can specify that all payment items (those on the CpD (suspense) account, those In Postprocessing, and the posted items) are
to be selected for reversal by choosing All Items.
3. The system displays an overview of all reversible items that meet your selection criteria. Double-click on an item or choose Select
Detail to display details.
4. Choose Reverse.
The system carries out the following activities:
¡ Posts the reversed item with the same transaction type and the opposite sign (plus (+) or minus (-)).
The system uses the current posting date as the posting date. If the original payment item was a backdated posting, you can decide
whether the reversed item is to use the current or the old posting date.
¡ Reverses the interest penalty that is to be posted during the next account balancing run when you reverse a payment item that has
incurred an interest penalty.
¡ Records the document number of the corresponding item for both the original and the reversed item in the Reverse Item field.
¡ Resets any item counter that has been set up.
The reversed item is also displayed on the bank statement.

The payment item is parked with the corresponding control status if you have activated the (amount-dependent) principle of dual
control for the processing of payment items in Customizing for BCA. You set up dual control for payment item processing by choosing
Authorization Management → Amount-Dependent Authorizations → Maintain Amount Limit/Principle of Dual Control for Payment Item.
Dual control applies to the following activities related to a payment item:
§ Create and change
§ Post, transfer post, and force post
§ Reverse and return
Another user with appropriate authorization must then release the payment item. To release the payment item, choose Account
Management → Payment Item → Release. The system lists all the items that have not yet been released. Go to the detail view of a
payment item and choose Release.

1.3.2.7 Displaying Payment Items

Prerequisites
Individual payment items have been entered for an account and you wish to view these items and possibly edit them from this overview.
You can have all payment items for an account (general) displayed or only the payment items for a CpD (suspense) account.

PUBLIC Page 59 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Procedure
1. Choose Account Management → Payment Item → Display.
2. If you do not wish to have an overview of all payment items displayed, select an account, or further limit your selection.
On the selection screen you can set the All Items indicator to specify that all positions are to be selected. If you do not set this indicator but choose positions
in the General Selections section, only the selected positions are displayed.

Result
The system displays an overview of the payment items. Double-click on the item number to view the detail screen.
In addition to the item data, the detail screen contains information about the general ledger account assignment, account determination,
and other data regarding the general ledger. This information is on the General Ledger Information tab page.
If you click on a general ledger account, the system displays the balance of this general ledger account. An important prerequisite for
this, however, is that the general ledger is managed in the same SAP system as the current account system.
You can also see if the interest penalty was waived during the creation process by choosing Interest Penalty. The system displays this
button only if you have selected the Amount Notices feature for the account.
Editing payment items from display mode
You can also edit individual payment items from the overview list by carrying out the following activities:
1. Choose the required payment item by double-clicking on the item number.
The system displays the detail screen of the payment item.
2. Choose Edit.
If you press this button, you automatically trigger the ‘General authorization check’. If you do not have adequate authorization, the display mode remains.
The system also checks which functions are possible for this payment item (for example, transfer posting, return, or reverse).

1.3.2.8 Payment Items "on Standby"

Use
The posting of payment items can fail because of a block. SAP AG provides you with a report (RFBKENQ1) that enables you to have the items posted by the
system once the block has been lifted. It is advisable to start the report periodically, several times a day if necessary, so that initially blocked items are posted.
The system collects and continually updates items that could not be posted in a table (BKKITENQ). This means that the system does not have to check all items
to see if they have been posted.
Before starting report RFBKENQ1, you can check for what reasons payment items have not been posted. If the accounts are still blocked because of currency
changeover, for example, items cannot be posted.
The remaining payment items are displayed as totals and can be checked.

Scope of functions
Open payment items blocked for the following reasons are included:
Block error account balance

Posting could not take place because the account was already blocked by a simultaneous posting.

Currency changeover

Posting could not take place because the account was blocked by currency changeover.

Activities
Choose Account management → Totals records in queue.
The totals of the current entries in table BKKITENQ are displayed in a list. Totals are formed per currency and day.
You can expand one or all totals and display the individual payment items or one or all totals. (The payment items have a green background, the totals lines a
yellow one).
You can select Only totals lines and then you only see the totals lines per currency.
Select a payment item and choose Select detail if you wish to have this payment item displayed in the detail window.

1.3.2.9 Releasing Payment Items

Use
Payment items may require an additional authorization check before posting, deletion, reversal, or return is possible. You can assign
these amount-dependent authorizations by using the authorization administration. In addition to the amount-dependent authorization, you
can specify whether payment items need to be released under the principle of dual control.
If you have entered these settings in the Implementation Guide (IMG), you can use the Release Payment Item function to release the
relevant payment items.

PUBLIC Page 60 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Prerequisites
You have defined an amount over which the system is to run an authorization check and apply the principle of dual control in
Customizing for Bank Customer Accounts (BCA) by choosing Authorization Management → Amount-Dependent Authorization →
Maintain Amount Limit/Principle of Dual Control for Payment Item.
You need to have the necessary authorization to release items.

Procedure
1. Choose Account Management → Payment Item → Release.
2. Enter the required data.
You can restrict the payment items that are selected for release by choosing different criteria.
3. Choose Execute.
The system displays a list of the payment items to be released according to your selection.
4. Double-click on a payment item.
The system displays the payment item.
If checks were skipped when you created the payment item because you forced the posting, the system displays these checks on the Administration tab
page.
5. Check the available data for the payment item to be released.
¡ To release the payment item, select Release.
If the system recognizes errors during the check on the payment item to be released, it displays corresponding messages in a dialog
box.
¡ To reject the release of the payment item, choose Reject.
The payment item receives the status that it had before the action that led to the release. Payment items that flowed into the release
process from the posting receive the In Postprocessing status.
The list of payment items to be released is displayed again.
6. Repeat the previous steps for all payment items that you want to release.

Result
The payment items are released or reset to the old status.

1.3.3 Planned Item

Definition
Posting item with a posting date in the future.

Use
You can use "Planned items" to edit items with a posting date in the future that are forwarded to the current account system from a payment transaction system.
You can also edit items with a future posting date that were entered online.
Transactions with a posting date in the future are first saved temporarily in the current account system. Then, an executable program (report) compares the
posting date with the current date. If they match, the system makes the final posting.

Structure
Items with a future posting date are first saved in a table in the current account system and then checked by means of an executable program (report). The report
compares the posting date with the current posting date in the system. If they coincide, the system makes the final posting.

Restrictions
While temporarily saved in the table, the amount with the future posting date does not apply for any limit checks for current transactions. There is also no updating
on the general ledger or of the transaction figures.

Integration
From the time when the item is posted it is handled as a normal item.

1.3.3.1 Processing Planned Items

Purpose
You can use the function "Planned Items" in two scenarios.

To enable items to be processed in the current account system that have a posting date in the future and that were supplied by an
external payment transaction system.

PUBLIC Page 61 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 To enter a payment item online but then to post it after the current posting date.

Process Flow
Scenario a): Payment items supplied from an external payment transaction system
1. The item is supplied to the current account system by the payment transaction system.
2. The item is temporarily saved in a table and is given the status "Planned". It must not be a routing item.
3. You can display the saved item in an overview at any time. Choose Account Management → Planned Item → Display. This
overview lists all items whose posting date is in the future. By double-clicking on the item number you can display the details.
4. To post the item, an executable program (report RFBKTMP1) compares the posting date of each item with the current posting date.
If the posting date of the item is before or on the current posting date, the system posts the item in the current account system. The
"planned item" is now processed normally, meaning the following applies:
a. If there are no errors during the material check, the item is given the status "Posted".
b. If the material check fails, the item is given the status "Parked". Choose Account Management → Payment Item → Postprocess to
process the item, and then post it.
c. If the account to which the item is to be posted is "locked for Euros", the item is saved in a table, and then another report
(RFBKENQ1) reads the table and posts the item. You need to schedule the RFBKENQ1 report at least once daily. See also: Process
Flow of End-of-Day Processing

You need to schedule the RFBKTMP1 report daily (each morning).

Scenario b): Payment items entered online

1. You enter the item with posting date in the future by choosing Account management → Planned Item → Create.
2. The item is temporarily saved in a table and is given the status "Planned".
3. You can display the saved item in an overview at any time. Choose Account Management → Planned Item → Display. This
overview lists all items whose posting date is in the future. By double-clicking on the item number you can display the details.
4. To post the item, an executable program (report RFBKTMP1) compares the posting date of each item with the current posting date.
If it is on or before this posting date, the item is posted in the current account system. The "planned item" is now processed normally,
meaning the following applies:
a. If there are no errors during the material check, the item is given the status "Posted".
b. If the material check fails, the item is given the status "Parked". Choose Account Management → Payment Item → Postprocess to
process the item, and then post it.
c. If the account to which the item is to be posted is "locked for Euros", the item is saved in a table, and then another report
(RFBKENQ1) reads the table and posts the item. You need to schedule the RFBKENQ1 report at least once daily. See also: Process
Flow of End-of-Day Processing
5. You can delete items that were entered online. To do this, choose Account Management → Planned Item → Delete.

1.3.4 IHC Payment Order

Definition
This is used to enter a payment transaction. An IHC payment order documents a payment from a bank account to a recipient account
and contains a payer and a recipient position. The IHC payment order holds these payment items together but strictly speaking it does
not post anything.
There are various types of IHC payment orders:
· Internal IHC payment orders
IHC payment orders with a payment order recipient in the same group. In this case the system generates internal posting items.
· External IHC payment orders
IHC payment orders with a payment order recipient not in the same group. In this case the system passes the recipient items to the external system for
payment transactions which in turn forwards the postings to the relevant subledger.

Use
Create manually
You can use the following functions to manually process IHC payment orders:
· IHC Payment Order Browser
· Create IHC Payment Order
· Edit IHC Payment Order
· Display IHC Payment Order
Create automatically
In addition to manually created IHC payment orders, there are cases in which the system automatically creates IHC payment orders. An
automatically created payment order can result from the following:
· An incoming IDoc from a subsidiary system

PUBLIC Page 62 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 · An external bank statement
· Treasury Management
You can tell where the payment order originates from by looking at the Input Channel in the management data of the IHC payment
order.

For information on the different uses of payment orders and IHC payment orders, see IHC Payment Order Versus Payment Order.

Structure
An IHC payment order comprises the following tab pages:
· Overview
· Payer/Beneficiary
· Recipient/Payer
· Administration and Reference Documents
· Logs

Note the umbrella terms used in the documentation which refer to the following components of the IHC payment order:

Payment transaction Component of the IHC payment order

Bank transfer etc. Payer Payment recipient
Debit memo Payee Payer
Umbrella term Order initiator Order recipient

Integration
The input options available to you depend on the transaction type settings. You will find these settings in Customizing under Account
Management → Payment Processes in In-House Cash → Define Transaction Types.

IHC Payment Orders Versus Payment Orders

Definition
From a technical perspective, SAP In-House Cash uses two types of payment orders:
· IHC Payment Orders
Most of the SAP In-House Cash functions are based on IHC payment orders. For information on displaying IHC payment orders, see Displaying IHC
Payment Orders.
· Payment Orders
In the case of automatically generated objects, we are dealing in some cases with payment orders. For information on displaying payment orders, see
Displaying a Payment Order.

Note the different terms used in this documentation.

Use
When payment orders are created, one of the following constellations is possible:
· You create an IHC payment order. This is the case for all manual activities.
The IHC payment order also contains the functions for forward orders.
· The system creates a payment order.
This is the case if you carry out the following activities:
¡ Cash Concentration
¡ Closing Accounts
¡ Account Balancing
· The system creates a payment order and an IHC payment order at the same time.
This is the case if payment is made to an external recipient via a clearing partner. To this end, the system generates an external IHC payment order in
addition to the payment order as well as a payment item in the corresponding clearing account.
As a prerequisite, you must have made the relevant settings for generating additional IHC payment orders in the implementation guide (IMG), under Account

PUBLIC Page 63 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Management → Payment Processes in In-House Cash → Make Basic Settings for Payment Processes → External Payments.

The workflow only enters payment orders and not IHC payment orders.

1.3.4.2 IHC Payment Order Browser

Use
In the IHC payment order browser, you can search for IHC payment orders, create worklists, and process IHC payment orders in
groups or individually.

Integration
The functions you can use in the browser for several IHC payment orders are also available for individual processing. For more
information, see Editing IHC Payment Orders.

Prerequisites
You must have authorization to display the selected IHC payment orders.

After successful selection, you will receive a message informing you that the IHC payment orders displayed are:
§ All selected IHC payment orders
§ Only the IHC payment orders for which have authorization

Scope of Functions
The following functions are available:
· Select IHC payment orders
You can enter your selection criteria in a number of ways:
¡ By using the predefined selection fields.
¡ By arranging the selection fields individually. Select the arrow on the right of Select and click on Choose Selection Fields. You
can add or remove any fields from the structure of the IHC payment order for your selection. You can also enter values and intervals
here.
¡ By using the standard multiple selection.
¡ By using a selection variant.
You will find the options for processing selection variants by clicking on , to the right of Save Variant.

If a selection variant is user-dependent, other users cannot use it.

· Change the displayed list

The system shows a list of selected IHC payment orders in the lower area of the screen and hides double entries. The list contains IHC payment orders that
have already been posted, deleted or reversed.
You can change the list as follows:
¡ By grouping several selections in a list.
¡ By removing individual IHC payment orders from the list. Select the arrow on the right of Select and click on Restrict Selection.

If you deselect an IHC payment order which is not in the displayed list the system does not output an error message.
¡ By resetting the list.
· Edit IHC payment orders
From the list you can carry out the same activities for a number of IHC payment orders that you find under edit payment orders. However, the system always
proposes activities that can be carried out for all selected IHC payment orders. For more information on processing options, see Editing IHC Payment
Orders.

You cannot create and change IHC payment order data for a number of IHC payment orders.

· Create a worklist
You can save the list of selected IHC payment orders as a worklist. You will find the options for processing worklists by clicking on , to the right of Save
Worklist.

PUBLIC Page 64 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 · Change the layout of the worklist
You can change the layout of the worklist to suit your requirements. You will find the options for processing the layout by clicking on , to the right of with
quick info Select Layout….

Activities
Choose Account Management → IHC Payment Orders → Payment Order Browser.

Creating IHC Payment Orders

Use
The IHC Payment Order is used to enter a payment transaction. There are four types of payment orders:
· Internal bank transfers
· External bank transfers
· Internal debit memos
· External debit memos
They differ in the default values that you entered in Customizing for the transaction type, and in the input options. However, they are
created using the same procedure.

Procedure
1. Choose Account Management → IHC Payment Orders → Create Payment Order → Bank Transfer or Debit Memo → Internal
Payment Order orInternal Payment Order.
2. Enter the data. Note the following:
¡ The order initiator (in other words, the first position in the IHC payment order) must exist in the current account system.
¡ You can enter an IHC payment order with a transaction currency that differs from the account currency of the order initiator and the
account currency of the order recipient.
To do this, change the proposed transaction currency and enter the amount in the transaction currency. If the transaction currency is
different from the account currency, the system displays the conversion rates stored for the currency pair in Financial Accounting (FI)
on the Payer/Beneficiary tab page. The system shows two conversion rates. You can change these rates as necessary. In the case of
an external IHC payment order you can only change the conversion rate for the order initiator and not for the order recipient.
For further information on currency conversion rates, see Processing Foreign Currencies.
3. Once you have entered the data, select one of the following processing options:
¡ Post
¡ Park
4. The system runs the relevant checks.

Result
· If you choose park, the system does not yet post the IHC payment order but stores it with the status parked.
· If you select post, the system generates payment items and posts them to the accounts entered in the IHC payment order or to provisional accounts.
Depending on the settings you made in Customizing, the system flags the IHC payment order as either provisionally or finally posted.
· If you have activated the amount-dependent principle of dual control for entering IHC payment orders, the IHC payment order is initially entered with the status
transferred for posting. The payment order must be released by a different user who has the relevant authorization.
· This function is found under Account Management → IHC Payment Orders → Edit Payment Order.

When you create an IHC payment order, the system opens a log. Here you will find all messages that the system output while
processing the IHC payment order.

Editing IHC Payment Orders

Use
You can use this function to process an IHC payment order that has already been created.

PUBLIC Page 65 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Scope of Functions
Depending on the status of the IHC payment order, you can do the following:
· Change
You can change some of the data in IHC payment orders with the status parked, parked with clearing partner, or provisionally posted. The data that you can
change depends on the status, the input channel, and the transaction type.

Example 1: You can only change the clearing partner if the payment order has the status parked with clearing partner. However,
most of the other data can no longer be changed if the payment order has this status.

Example 2: Value dates can still be changed in a provisionally posted IHC payment order.

Example 3: The IDoc input channel only lets you change the execution date.

· Determine clearing partner

In parked status, you can determine possible clearing partners and select one of them before posting an external payment.
· Flag for posting
You can flag the IHC payment order for posting if it has the status parked or parked with clearing partner. IHC posting orders that are flagged for posting are
processed in the background and posted either provisionally or finally depending on the transaction type settings.
· Post
You can post the IHC payment order in dialog if it has the status parked or parked with clearing partner. The IHC posting order is posted either provisionally
or finally depending on the transaction type settings. In the case of provisional posting, the system forwards the payment order to a second user who checks
and releases it.
· Revaluate
You can revaluate provisionally posted IHC payment orders. The system resets the provisional postings and recalculates the values.

This is important if you have different currencies with a currency conversion and the conversion rates change.

· Release
If you have activated the principle of dual control, the system initially posts the IHC payment order provisionally. It forwards it to a different user who releases
the IHC payment order in a second step.
· Reset status
IHC payment orders with the status flagged for posting, parked with clearing partner, transferred for checking or provisionally posted can be reset to status
parked. This is equivalent to a refusal to pay in the principle of dual control, in status transferred for checking. In this case you can decide whether you want
to process the data or delete the IHC payment order.
· Delete
You can delete parked IHC payment orders. If the IHC payment order has already been posted, you can no longer delete it, only reverse it.
· Reverse
You can reverse finally posted IHC payment orders.

Activities
Choose In-House Cash → Account Management → IHC Payment Orders → Edit Payment Order.

1.3.4.5 Displaying IHC Payment Orders

1. To display an IHC payment order, choose Account Management → IHC Payment Orders → Display Payment Order.
2. Enter the payment order number.
This can also be the number of an IHC payment order that has already been posted, deleted, or reversed.

Result
The system displays the detailed data of the selected IHC payment order.

For information on how to display payment orders, see Displaying Payment Orders.

PUBLIC Page 66 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Displaying Payment Orders
1. To display a payment order, choose transaction F9I3.
2. Make a selection.
You can use the Ordering Party Data indicator to determine whether you display only the payment orders where the ordering party position matches the
selection criteria.
3. You receive an overview of all the selected payment orders. The overview also contains payment orders that have already been
posted, deleted, and reversed.
If you have set the Ordering Party Data indicator, the system displays only the ordering party position of the payment orders.
If you have not set the Ordering Party Data indicator, the first line of a payment order is the ordering party position, and the second line is the recipient
position.
4. Select a payment order number.

Result
The system displays the detailed data of the payment order. If the items of a payment order were transfer posted, the system displays
the Transfer Postings button in the toolbar.

For information on how to display IHC payment orders, see Displaying IHC Payment Orders.

Forwarding Instructions for the House Bank

Purpose
Instructions are supplementary information in addition to manual or automatic payment data.
Instructions can be forwarded by a subsidiary company in its role as payer or from head office in its role as internal house bank.
Instructions can affect the following payment data:
· List of payment methods to be considered
· Payment method supplement
· Company code
· Group of house bank accounts
· Short key for the house bank
· Short key for the account details
· Indicator: Are you authorized to debit account?
· Key for blocking payment
· Instruction key for data medium exchange
· Forward reporting data to the house bank

Define the selection of house bank and house bank account or the division of charges.

Prerequisites
If you forward instructions by data medium exchange in several steps, all affected systems must be able to correctly interpret the
instructions from the preceding systems. Note the following requirements:
· Use uniform, internal instruction codes for payments between subsidiaries and head office within your group.
This is necessary because subsidiaries do not always know which house bank is used for payment or the house bank instructions.
· Define instruction keys within your group for manual payments if necessary. Instruction keys are a combination of instruction codes that you use frequently.
For further information on Customizing settings, see Editing Instructions.

Process Flow
Instructions for the house bank pass through the following steps:
1. A subsidiary forwards a payment as a PAYEXT or DIRDEB IDoc to the internal house bank.
The subsidiary uses the internal group instruction codes.

PUBLIC Page 67 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 2. The internal house bank checks whether or not it recognizes the instruction codes.

You can deactivate this check.

3. The internal house bank forwards the payment unchanged to the executing Financial Accounting system (FI system).
The internal house bank uses the internal group instruction codes.
4. The executing FI system maps twofold:
a. It replaces the internal instruction codes with its own instruction codes.
b. It replaces its own instruction codes with instructions that can be recognized by the selected house bank.
5. The executing FI system forwards the payment to the house bank.
6. The house bank makes the payment, taking the instructions into account.

Example
The following graphic shows payments that have instructions for rapid payment:
· Subsidiary 1 → internal house bank → subsidiary 3 → external house bank ERBA
· Subsidiary 2 → internal house bank → subsidiary 4 → external house bank BAER

· Subsidiary 1
a. Subsidiary 1 wants to make a rapid payment.
b. It uses the instruction code QUICK in the IDoc sent to the in-house cash center.
Prerequisite: You must have defined the instruction code QUICK in the in-house cash center in SAP In-House Cash. All subsidiaries are
to use this code for rapid payments.
c. Using route processing, the in-house cash center determines that the FI system of subsidiary 3 should make the payment via house
bank ERBA.
d. The in-house cash center forwards the IDoc unchanged to the FI system of subsidiary 3.
e. Subsidiary 3's FI system maps the instruction codes. It replaces the internal group instruction code QUICK with its own instruction
code SOF and replaces SOF with the ERBA-specific instruction code EILT.
f. The FI system of subsidiary 3 forwards a data medium to external house bank ERBA which contains the instruction EILT.
· Subsidiary 2
Subsidiary 2’s payment follows the same logic. In this case, the payment is processed by the external house bank BAER which uses EXP to indicate rapid
payments. The executing FI system replaces the internal instruction code QUICK with the BAER-specific instruction EXP.

1.3.5.1 Editing Instructions

Use
If you forward instructions for processing a payment, all affected systems must be able to correctly interpret the instructions from
preceding systems. This section shows you the settings you need to make in the various systems.
For more information on instructions, see Forwarding Instructions for the House Bank.

Integration
The system automatically includes the instruction codes defined in Customizing of the FI systems when it effects a payment.
However, the instruction codes specified in the master data override the instruction codes in Customizing.
You can change the automatically proposed instruction codes when you enter an invoice.
You can enter the defined instruction codes or instruction keys in manual IHC payment orders on the Recipient/Payer tab page if the
payee is an external recipient.

Activities
SAP In-House Cash System

PUBLIC Page 68 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 · Instruction codes
Define instruction codes for up to four different instruction positions. You can define any number of instruction codes for each position:

Avoid using the same code for different positions.

In Customizing for SAP In-House Cash, choose Account Management → Payment Processes in In-House Cash → Outgoing Payment Orders →
Instructions for FI → Define Instruction Codes for FI.
· Instruction keys (optional)
You can define instruction keys for manual IHC payment orders to group a combination of instruction codes that you use frequently.
In Customizing for SAP In-House Cash, choose Account Management → Payment Processes in In-House Cash → Outgoing Payment Orders →
Instructions for FI → Define Instruction Keys.
· Checks for inbound IDoc
You can override checks that are run when an IDoc is received or on manual payment orders. This may make sense if, for example, the FI system of the
subsidiary is the same as the executing system.
In Customizing of SAP In-House Cash, choose Basic Settings → Message Control → Change Message Control for Inbound Idoc.
Financial Accounting Systems
· Instruction codes
Enter the instruction codes, which you defined in SAP In-House Cash, in the Financial Accounting systems (FI systems) of all affected subsidiary
companies.
In Customizing, choose Accounts Receivable and Accounts Payable → Business Transactions → Outgoing Payments → Automatic Outgoing Payments
→ Payment Media → Data Medium Exchange → Define Instructions for Payment Transactions.
Executing Financial Accounting Systems
· Customizing for SAP In-House Cash
Specify how internal group instruction codes are to be mapped to FI-specific instruction codes in all executing FI systems.
In Customizing, choose Integration with Other mySAP.com Components → In-House Cash → Setup Generation of Payment Requests for IDoc (Inbound)
in FI.

Example
The following tables contain examples Customizing settings in the various systems:
Customizing of instruction codes in the SAP In-House Cash system
Instruction Position Instruction Code Description
1 GB Use house bank BOENG
2 USD Use US$ account
2 EUR Use € account
3 + Charges are paid by payment initiator
3 – Charges are paid by payment recipient
3 0 Charges are split between payer and
payee
4 QUICK Rapid payment

Customizing of house bank details in executing FI system

Country House Bank ID: Account ID:
US BAER JPY
US BAER USD
GB BOENG GBP
GB BOENG EUR
DE ERBA EUR
DE ERBA USD

Customizing of instruction keys in the SAP In-House Cash system

Bank Area Instruction Instruction 1 Instruction 2 Instruction 3 Instruction 4
Key
IHC ENGEUR GB EUR 0

Customizing for SAP In-House Cash in the executing FI system

PUBLIC Page 69 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Table Field Table Entries
Clearing Partner 001 001 001
Currency EUR USD
Payment Method in IDoc J J X
Instruction 1 GB
Instruction 2 EUR
Instruction 3 + + 0
Instruction 4 QUICK QUICK
Payment Methods UI UI UI
Company Code 0001 0001 0001
House Bank ERBA BAER BOENG
Account EUR USD EUR
Instruction for House Bank SOF+ TOP+ SPLT

Example 1:
1. An subsidiary pays an invoice, the charges for which are to be paid by the payment recipient. The payment is to be made as soon
as possible. The subsidiary enters the instruction codes + and QUICK in instruction positions 3 and 4. The payment is made in EUR with
payment method J.
2. The SAP In-House Cash system determines clearing partner 001 on the basis of the payment data and forwards the payment
accordingly. Clearing partner 001 is the executing FI system.
3. The executing FI system determines house bank ERBA and account EUR. It replaces the internal group instruction code QUICK with
the FI-specific instruction code SOF+.
4. It determines the instructions recognized by the house bank on the basis of the instruction code SOF+ and forwards the payment
with these instructions to the house bank.

If the invoice had been in US dollar, the executing FI system would have determined the house bank BAER, account USD and
instruction code TOP+.
Example 2:
1. A subsidiary company pays an invoice in euro to a business partner in England.
2. Head office manually creates an IHC payment order. The instruction codes in positions 1, 2 and 3 are GB, EUR and 0. This means
that the IHC payment order is paid by house bank BOENG from account EUR and that the charges are split between payer and payee.
3. This combination of instructions is frequently used. Therefore, there is a corresponding instruction key ENGEUR.
4. The user enters instruction key ENGEUR when creating an IHC payment order. The system replaces these keys with the necessary
instruction codes and forwards them to the executing FI system.

The instruction key itself is not forwarded to the executing FI system.

5. The executing FI system selects house bank BOENG, account EUR and FI instruction code SPLT.

1.3.6 Processing Foreign Currencies

Use
You need to convert currencies if the transaction currency differs from the account currency of the affected current account when you
make or receive payments.

Prerequisites
You must have defined the currency-specific data.
In Customizing for SAP In-House Cash, choose Account Management → Payment Processes in In-House Cash → Make Basic
Settings for Payment Processes.

Scope of Functions
The currency conversion is based on payment items. The following functions are available:
· Provisional and final settlement
· Flexible determination of the exchange rate type
You can define separate rate types for buying and selling rates in order to calculate the credit or debit amounts.
· Primary and secondary exchange rates

PUBLIC Page 70 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 You can differentiate between rates that the in-house cash center uses on the money market and rates that are used internally.

1.3.7 Business Workflow

Purpose
Workflow management systems control processes according to a predefined model and are particularly suitable for structured organizations.
A workflow management system facilitates the electronic processing of structured processes that
cover a range of activities
always occur in similar or identical form
involve several people and departments
require a high degree of coordination
In the current account system, the editing of payment orders and payment items is organized using the workflow. During their life cycle, these two objects pass
through certain statuses. The workflow assumes the automatic transfer from one status to another, at the same time taking the different responsibilities of the
employees into consideration.
Using the workflow, the system determines if a status change has taken place for a payment order or payment item and assigns this payment order or payment
item to all possible employees in accordance with the specifications in Customizing. All employees who are possible candidates for editing this payment order or
payment item have a work item (task in the workflow) placed in their inbox.
To avoid several possible employees from editing the same payment order or payment item, decisive is who first edits it. If a payment order or payment item is
being edited, it no longer exists in the inboxes of the other employees.
However, before distributing the tasks to the employees, the system checks if the employees are authorized to execute the tasks.
Once the editing of the payment order or payment item is completed, it is saved on the database with the final status.
Prerequisites
You must have stored your organization in the Implementation Guide (IMG) by choosing Account management → Business workflow, and you must have carried
out task Customizing.

Tip:
Depict your organizational structure in the Implementation Guide (IMG), as in this way you achieve greater flexibility and no longer have to assign
every task individually to employees.

Process flow
As an example, following is an illustration of the process flow of workflow using the life cycle of a payment order.
01. A payment order is created.
However, the employee is not authorized to post it. Another employee must release this payment order. The payment order now has the status "ready for the
principle of dual control".
02. The system places the payment order in the inbox of those employees authorized to make the release in accordance with the principle of dual control.
03. One of the authorized employees looks in the inbox and releases the payment order.

Result
The payment order has been posted.
See also:
BC
Basis → Business Management → SAP Business Workflow

1.3.7.1 Executing Workflow for Payment Items

Use
You can use the SAP Business Workflow to
edit payment items
release payment items

Prerequisites
In the Implementation Guide (IMG) you must have assigned the tasks Edit or release payment items to your employees by choosing Account management →
Business workflow and you must have activated event linkage.

Procedure
In the SAP menu choose Office → Inbox.
Choose the pushbutton Workflow.

Result
All tasks to which you were assigned as editor in the Implementation Guide (IMG) are in your inbox and can be edited.
Background
Process flow
Once an employee has entered a payment item, this item has a certain status.
If the status at this time is (T1) "posted", further processing can only be done manually.
The process can be depicted by means of the workflow if the item has one of the following statuses:
In post processing

PUBLIC Page 71 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Principle of dual control
Those items that require editing in a certain way arrive automatically in your inbox.
Once you have edited them, the items receive a new status (T2).
If the items have one of the following statuses, the process starts again at the beginning, meaning they can be changed, deleted, posted or released.
In post processing
Principle of dual control
If the items have one of the following statuses, editing is either completed or must be done manually.
Posted
Deleted

1.3.8 Returns
Definition
In payment transactions it is possible to return items that are already posted to customer accounts or CpD (suspense) accounts. We differentiate here between
payment items that are to be returned and free returns that are not managed as payment items in the system.

Use
For a return, the system creates a payment order with the ordering party and recipient of the return. The system creates payment notes for this payment order from
the original payment notes and standard texts. Then the items of the payment order are updated and all other positions on the returned payment item (charges,
and so on) are reversed.

Structure
You need to make the following definitions for returns in the Implementation Guide (IMG) by choosing Account management → Returns.
For every transaction type you define the transaction types for the updating of the corresponding item on the customer account/CpD (suspense) account and for
the return posting.
You specify the recipient of any necessary notifications.
You define the composition of the payment notes for the return.
For check returns you define how any existing guaranteed amounts are to be debited (only applies to banks).

Integration
Returns are executed as part of payment transactions.

1.3.8.1 Returning a Payment Item

Use
You have the option of returning payment items already posted to customer accounts or CpD (suspense) accounts that you do not want
accepted (return debit, return check, (only applies for banks)).

Prerequisites
Only recipient items can be returned.
Before being able to return a payment item, you must first have predefined return reasons for the transaction type of the item in
Customizing.

Procedure
1. Choose Account Management → Payment Item → Edit (Special) → Return and make a selection.
2. You receive an overview of all items for which returning is possible.
Double clicking on an item or a position or detail brings you to the detailed display of the payment item. Here choose Return.
3. Specify the medium, payment method and value date for the return and choose one of the pre-defined return reasons.

Result
The system generates and updates a payment order with the ordering party and recipient of the return. Any existing guaranteed amount
(for check returns) is taken into consideration. If and how notification of the business partners involved is supported, depends on your
Customizing (in the Implementation Guide (IMG). Choose Account Management → Returns).
If you have activated the (amount-dependent) principle of dual control for the processing of payment items, the payment item can
initially be parked with the Returned Dual Control status. This must then be released by another user with appropriate authorization.
To do this, choose Account Management → Payment Item → Release. The system lists all the items that have not yet been released.
Go to the detail view of a payment item and choose Release.

PUBLIC Page 72 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.3.8.2 Free Returns
Y
ou use free returns if you wish to return an amount that you do not manage as an item in the current account system. This, for example, can involve one item of
several items from a collective bank transfer that you wish to return. However, since this item is not managed as a single item, you must first create an own
payment order for this.

Prerequisites
Before you can create a free return, you must first have pre-defined return reasons for the transaction type of the item in the Implementation Guide (IMG) by
choosing Account management → Returns.

Procedure
Choose Account management → Payment order → Create (special) → Return order.
Specify the original transaction type, the medium, the payment method and also the returning party's data and the amount in transaction currency.
This brings you to an input screen for the detailed information on the return. Make the necessary entries and choose a return reason.
This brings you to an input screen. Enter the necessary data.

Result
The system generates and updates a payment order with the ordering party and recipient of the return. If and how notification of the business partners involved is
supported, depends on your Customizing (in the Implementation Guide (IMG). Choose Account management → Returns).

Forcing Postings with the Feeder System

Prerequisites
Under certain circumstances it can be necessary to force ordering party postings by the feeder system. Such circumstances exist, for
example, if hurried orders are involved that must be urgently executed, even if the ordering party account does not show the necessary
coverage.
You can force such postings by setting an indicator that deactivates the posting control check on the interface for entering the ordering
party posting. In this case, the system does not run the checks for the business partner, the account, the value date check and the limit
check. Data consistency, however, remains unaffected.
The prerequisite for this is that the function module BAPI_PAYIT_POST_SENDER (or the obsolete BAPI_PAYM_ITEM_POST_SENDER
for data without a bank control key or SWIFT code) is included.
See also:
Interfaces in the Current Account System → RFC Interfaces → Overview of RFC Interfaces → Post Ordering Party Items.

On how to manually force postings for payment orders and payment items, read Postprocessing Payment Orders and
Postprocessing Payment Items.

1.4 Periodic Tasks

Functions that are to be run on a certain date in a defined time cycle are summarized under periodic tasks.
The periodic tasks include:
Setting the posting cut-off
· You postpone the posting date to the next posting day, either manually or automatically.
Cash concentration
· Account carryforwards are posted with the current date (system proposal) as the posting and value date.
Standing order run (banks only)
· Due standing orders are executed.
Planned items
· Planned items whose posting date matches the posting date in the system are posted. (See also Processing Planned Items).
Forward order
· Forward orders whose posting date matches the posting date in the system are posted (see also Processing Forward Orders).
Account balancing
· You can balance accounts either in a mass run or an individual run. If you have entered the corresponding settings, interest is also compensated during
account balancing.
Fixed-Term deposit
· The contract amount is collected on the collection date. Term agreements are fixed on the term start date. Correspondence for the prenotification of maturity is
initiated on the predefined date. Term agreements are called if the maturity date has been reached (see also: Fixed-Term Deposit Processing).
Account closure
· Accounts intended for closure on this date are closed.

PUBLIC Page 73 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Bank statements
· Bank statements are managed fully in the current account system. The data is provided by means of an interface.
Balance notification
· The system creates a balance notification with the posting date-based balance. You can specify how the balance is to be output and to whom it is addressed.
Tolerated overdraft
· The system determines the accounts whose holders need to be notified about being over the external limit (in accordance with the consumer credit law), and
creates the notification.
General ledger transfer
· Transfer of the summarized turnovers to the general ledger.
Currency changeover
· You can set the changeover date for a selection of accounts and run the changeover for selected accounts.
End-of-day processing
· You can start processing all periodic tasks in a group, which you can set up first in Customizing.

Special features:
· Mass processing can run in the background (batch).
· You can use parallel processing to improve system performance, whereby the accounts are divided into intervals and transferred to
different jobs. Customizing settings enable you to control the number and distribution of the jobs to different computers.
Application logs
· Prepared call-ups of the application log are available for the evaluation of all periodic tasks.

Process Flow of End-of-Day Processing

Purpose
End-of-day processing can be run daily or at longer intervals, depending on how current the data needs to be.
Before you start end-of-day processing, we recommend that you run certain programs (reports) several times during the day
(approximately every two hours) by using a job. The reports must run at least once, directly before the posting cut-off for payment
transactions and the other end-of-day processing steps.
These reports are as follows:
Report RFBKPOEX (Payment Order) (applies only to banks)
To process payment orders with at least one external recipient, the order is transferred to the upstream system to determine the
routing. If there are communication errors, the order is flagged with an error indicator. This report selects all these payment orders and
sends the information once again to the upstream system. If this corrects the error, the error indicator is removed and the payment
order is processed. If the error still exists, the error indicator remains and the payment order is selected again during the next run.
Report RFBKENQ1 (Payment Item)
This report enables the correct processing of payment items that were placed in a special table (totals records in queue) during daily
processing due to the following:
1. In the productive system, during a currency changeover, the affected accounts are locked for the EURO during a currency
conversion.
2. If the payment transaction system transfers a payment item to the current account system, the item undergoes the limit check on the
relevant account. Items that arrive simultaneously encounter a limit lock.
Report RFBKPRE1 (Process Parked Payment Items)
In productive operation, payment items can have the Parked status because the account did not have any coverage at the time of the
limit check. The report selects all the items for which the Parked status was caused exclusively by a lack of coverage. The system
checks if there is sufficient coverage on the account now. If this is the case, the item is posted.
You must also execute the Collect Deposit Amount for Fixed-Term Deposit report (RFBKTDEPOSITCOLLECTION) and the Fix Fixed-
Term Deposit Accounts report (RFBKTTERMCONTROL) before beginning the end-of-day processing.

The reports RFBKTMP1 and RFBKTMP1_PO for posting planned items or forward orders whose planned posting date has been
reached need to be scheduled for the start of the day, and must not be included in end-of-day processing.
End-of-day processing includes the following periodic tasks:
· Posting cut-off for payment transactions
You set the posting cut-off, whereby all subsequent payment transaction postings are entered with the subsequent date. The system can set the posting cut-
off (if you have defined this accordingly in the Customizing settings for the bank area) or schedule it in end-of-day processing. Complete the posting cut-off
before any other balancing tasks to ensure that no additional postings occur in the period to be balanced during the account balancing run (value dates in the
past are still possible). The posting date for the balancing postings remains unaffected and is normally (if run daily) on the last posting date for payment
transactions.
· Running cash concentration
In the cash concentration run, the system creates carryforwards for the accounts in account hierarchies. All root accounts are selected for which cash
concentration is due on the current posting date. (You determine this by your entries for the periodic account balancing in the account master data).
You can run cash concentration before or after account balancing. If you run the cash concentration before account balancing, then the balancing calculations
include the carryforward amounts.

PUBLIC Page 74 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 · Balancing accounts
Interest and charges for the accounts due for balancing are calculated and posted on each account accordingly. Interest compensation is triggered
automatically.
· Collecting Deposit Amount on Term Agreements(banks only)
The contract amount is collected for term agreements when the collection date is reached (depending on the Customizing settings).
· Fixing Term Agreements(banks only)
Term agreements whose term start date has been reached are fixed.
· Prenotifying Maturity of Term Agreements (banks only)
On the predefined date, the system initiates correspondence for the prenotification of maturity of term agreements.
· Calling Term Agreements(banks only)
If the maturity date has been reached (depending on the Customizing settings, either one working or one calendar day before the term end), the agreements
are called (see also: Fixed-Term Deposit Processing).
· Closing accounts
The time periods in which you close accounts depend on how current the information is to be and the number of accounts to be closed.
· Generating the bank statement
The bank statement data for all the accounts to go on the bank statement is printed or transferred to a suitable interface in a mass run.
· Updating the posting date to the next day for the balancing postings
Once the balancing tasks are complete, the system updates the posting date for balancing postings to the next day. The posting date must be updated
daily, even if no accounts were balanced.
If you have the same balancing and bank statement dates for all your accounts in the selected company codes (for example, end of the quarter), you do not
need to balance the accounts or generate the bank statements every day, but on this date only. If you do not balance the accounts daily but, for example,
monthly, note the following:
If the period end closing has not yet been completed for all accounts, the posting date must not be changed to a date after the last bank working day of this
period. To balance accounts on a day in the following period proceed as follows:
On the last day of the old period, set the posting date for the balancing postings and do not change it before the balancing is complete.
· Posting standing orders (banks only)
The system selects the standing orders due for the current posting date. Postings are created (with the current posting date for payment transactions) and
transferred to the payment transaction system.
(Note: If you use the processing sequence specified here for end-of-day processing, the standing orders due for the following day are generated, as the
posting cut-off has already been completed. This guarantees that the orders are placed in the external payment transaction system in good time).
· Calculating interest accrual/deferral
The accrual/deferral of the interest already incurred but not yet posted can be calculated separately from the other periodic tasks, particularly account
balancing.
· Preparing the balance sheet
During balance sheet preparation, data is divided into receivables and payables. It is advisable to run balance sheet preparation daily. You can use the
Balance Sheet Preparation report (RFBKGLBSPREP) by choosing Periodic Tasks → General Ledger → Balance Sheet Preparation from the SAP Easy
Access menu.
· General ledger transfer
The time intervals at which the data is transferred to the general ledger depend on how current the information on the general ledger is to be. Normally you
need to transfer the data to the general ledger each day.
You can run end-of-day processing with one of the following options:
· As event control. For more information, see: End-of-Day Processing as Event Control
· As job chain control in Bank Customer Accounts (BCA) whereby it is recommended that you automate these typical process flows by using jobs. For more
information, see: Setting Up a Job Chain

1.4.1.1 End-of-Day Processing as Event Control

Use
The following section describes how to use event control to organize end-of-day processing. You schedule the relevant reports as jobs
with the Job Definition transaction. This means that they run automatically.
Events have been defined for each function to control these jobs. These events inform the job administration when the function has run
successfully. Therefore, the next step is started only once the final event of the previous function has been reached. The previous job
must be defined in the subsequent jobs. You can do this with the Start After Event XY attribute. If this is a general step that applies to
more than one bank area, then it is triggered more than once. The parameter is the bank area.
The following table provides an overview of the report and the corresponding events (the events relating to standing orders and fixed-
term deposits apply only to banks):

PUBLIC Page 75 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Report name Event Description Description
SAP_BKK_…
RFBKCONA ACCRUAL_JOB_END End of job processing ‘interest
accrual/deferral’
RFBKACCL ACCNTCL_JOB_END End of job processing ‘account closure’
RFBKBSST BANKSTAT_JOB_END End of job processing ‘bank statement’
RFBKKC20 CASH_CONCENTR_JOB_END End of job processing ‘cash concentration’
RFBKCONC CLOSING_JOB_END End of job processing ‘account balancing’
RFBKCLEB CLOSPOSTDAT_JOB_END End of job processing ‘set balancing
posting date’
RFBKSOCR (obsolete from EA-FINSERV STANDORDER_JOB_END End of job processing ‘standing order’
200)
RFBKSOCRPAR (new from EA-FINSERV STANDORDER_JOB_END End of job processing ‘standing order’
200)
RFBKPDT2 PAYMPOSTDAT_JOB_END End of job processing ‘set payment
transactions posting date’
RFBKGLBSPREP BSPREB_JOB_END End of job processing ‘balance sheet
preparation’
RFBKGL01 GLTRANSFER_JOB_END End of job processing ‘general ledger
transfer’
RFBKTTERMCONTROL (changed for EA- TERMCONTROL_JOB_END End of job processing ‘fix fixed-term
FINSERV 500) deposit’
RFBKTTTERMMATURE (new for EA- TERMDEP_MATURE_JOB_END End of job processing ‘call fixed-term
FINSERV 500) deposit’
RFBKTDEPOSITCOLLECTION TERMDEP_COLLECT_JOB_END End of job processing ‘collect deposit
amount for fixed-term deposit’
RFBKTTERMPRENOTICE TERMPRENOT_JOB_END End of job processing ‘prenotification of
maturity for fixed-term deposit’
RFBKGL_VA_CALC_POST VALUE_ADJ_JOB_END End of job processing ‘value adjustment’

The final event of a function in a chain is triggered if:

· All accounts have been processed and
· Processing was successful.
On some accounts, errors may have occurred during processing, for example, because they were not active. These accounts are
locked for all further steps of the run. However, the event is triggered so that processing can continue for the remaining accounts.
If this is the case, proceed as follows to check the accounts:
1. In the overview of the mass runs, determine the mass runs where errors occurred. Note the key (program name, date, and
number) of each run. See also Displaying Overview of Mass Runs.
2. Use the overview of the locked accounts to find each locked account. See also Displaying an Overview of Locked Accounts.
3. In the application log, determine the run where an error occurred (marked red). The log provides you with more details of the
reason for account lock. You can call up specific application logs by choosing Periodic Tasks → End-of-Day Processing → Application
Logs from the SAP Easy Access menu.
4. Correct the error and start each mass run by choosing Restart, or Restart Individual Step. This removes the lock from the account.
See also Display Report Overview / Control End-of-Day Processing Chain. In some applications you can also restart the job by
choosing Periodic Tasks → <application> → Restart. In this case the status is also changed in the chain.
5. Start all the subsequent mass runs of the job by choosing Restart. These process the account accordingly. See also Displaying
Report Overview/Controlling End-of-Day Processing Chain.
The event is not triggered if a mass run was terminated (for example, due to a system error). If this is the case, the accounts of the
subsequent runs are not processed, and the batch processing is interrupted. The corresponding runs must also be started with Restart
or Restart Individual Step.

1.4.1.2 Establishing a Job Chain

Purpose
In end-of-day processing you can use one of the following:
· Event control (see: End-of-Day Processing as Event Control)
· Job chain control in the current account system.
You can use the job chain control to define the processing steps to be run automatically.

PUBLIC Page 76 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Prerequisites
You need to define the processing sequence that you require for the reports in the job chain, by choosing Periodic Tasks → Specify
Sequence of Mass Processing in the Implementation Guide (IMG). To use your own reports, choose Periodic Tasks → Include
Customer Reports for Mass Processing in the Implementation Guide (IMG).
Including your own reports for mass processing:
This lists all the reports that can be selected in a chain. You can specify both reports supplied by SAP as well as your own. Note that
inconsistencies can arise due to the Continue column, as there can be dependencies between the reports. It is recommended that you
only use the column for reports you have written.
Specifying the sequence of mass processing:
You can use this transaction to define any chains that you require. First you assign the chain ID and the corresponding chain name, then
you assign the corresponding reports.
You can include the following reports in mass processing (the reports for standing orders and fixed-term deposit accounts only apply to
banks):
Job name Description
RFBKPDT2 Set date for payment transactions
RFBKPDT4 Set date for payment transactions in test
RFBKKC20 Cash concentration
RFBKCONC Account balancing
RFBKBSST Bank statements
RFBKBANKSTATDUPL Creation of bank statement duplicates
RFBKBALNOT Balance notifications
RFBKCHACCUR Account changeover
RFBKCLEB Set posting date for balancing
RFBKSOCR (obsolete from EA-FINSERV 200) Standing order
RFBKSOCR (new from EA-FINSERV 200) Parallelized standing order
RFBKACCL Account closure
RFBKCONA Interest accrual/deferral
RFBKGL_VA_CALC_POST Individual value adjustment
RFBKGL01 General ledger transfer
RFBKGLBSPREP Balance sheet preparation
RFBKTMP1 Planned item
RFBKTMP1_PO Forward order
RFBKTTERMCONTROL (changed for EA-FINSERV 500) Fix fixed-term deposit accounts
RFBKTTTERMMATURE (new for EA-FINSERV 500) Call fixed-term deposit accounts
RFBKTDEPOSITCOLLECTION Collection of fixed-term deposit accounts
RFBKTTERMPRENOTICE Prenotification of maturity-term deposit accounts

The RFBKCHAINSTART report is provided to enable you to start a chain.

You need to enter a standard variant in these reports. You can also provide parameters and selection options of variants using
variables. On this subject, read the following documentation: Maintenance of Selection Variables in Table TVARV

Process Flow
1. The IMG activity Include Customer Reports for Mass Processing enables you to check whether all the reports exist. Since only the
jobs listed here are available in IMG activity Specify Sequence of Mass Processing, you can also control which jobs you want to
include in your job processing chains.
2. Define which reports are to run in a chain.
3. Define the variants belonging to the reports. This means that you need to maintain the parameters and selection options in the
TVARV table.
4. Use the IMG activity Specify Sequence of Mass Processing to define the chain, its reports, and the corresponding variants.
5. Use the RFBKCHAINSTART report to schedule a job.

Note:
Use the RFBKPDT4 report for testing and the RFBKDT2 report for production. The RFBKPDT2 report has a check that prevents you
setting the payment transaction date to a date in the future.

You can use the RFBCHAINSTART report to start the chain in online operation and in batch mode. For online operation, choose
Periodic Tasks → End-of-Day Processing → Start in the application.

For an example of how a job chain can be defined, see Proposal: Process Flow of End-of-Day Processing.

Result
End-of-day processing is triggered and carried out automatically.

Tip:

PUBLIC Page 77 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 To improve performance, you can use parallel processing in the system. You set up parallel processing in the Implementation Guide
(IMG) by choosing Periodic Tasks → Parallel Processing.You can set up the number of jobs to be processed in each application
type and in each target system. This distribution depends on the number of target systems and the available batch processes. Do
not distribute more jobs than there are batch processes available.

Proposal: Process Flow of End-of-Day Processing

We recommend the following process flow for end-of-day processing:
When you begin the end-of-day processing, the payment transaction date and the balancing posting date must be identical. This section
details the end-of-day processing for October 30.
1. Collect the contract amount for term agreements (RFBKTDEPOSITCOLLECTION)
The report selects accounts whose collection date is on or before the current posting date (October 30).
2. Fix term agreements (RFBKTTERMCONTROL)
The report selects accounts whose Term Start date is on or before the current posting date (October 30).
3. Set the posting cut-off for payment transactions (RFBKPDT2)
The payment transaction date changes to October 31. At this stage, the posting date for balancing postings is still October 30.
4. Write a report that supplies the date variables (for the old and new payment transaction dates) to the table TVARV.
The current payment transaction date (October 31) is used as the new date (date_new), while the payment transaction date before the posting date change
(October 30) is used as the old date (date_old). You must structure this report as per the sample report described in the Online Self Service (note 123217).
5. Execute cash concentration (RFBKKC20)
Account carryforwards are posted for all accounts in the hierarchy that are due for cash concentration on October 30.
6. Execute account balancing (RFBCONC)
Accounts whose next balancing date is on or before October 30 (date_old) are balanced.
7. Execute account closure (RFBKACCL)
Accounts whose closure date is on or before October 30 (date_old) are selected and closed.
8. Set the posting date for the balancing postings (RFBKLEB)
The posting date is set to October 31.
9. Initiate correspondence for prenotification of maturity (RFBKTTERMPRENOTICE)
Correspondence is initiated for term agreements whose predefined notification date is on or before October 30 (date_old).
10. Call term agreements (RFBKTTERMMATURE)
Term agreements whose maturity date is on or before October 30 (date_old) are called.
11. Generate bank statements (RFBKBSST)
Bank statements are generated for accounts whose next execution date (for bank statements) is on or before October 30 (date_old).
12. Execute account currency changeover (RFBKCHACCUR)
Accounts whose currency changeover date is on or before October 31 (date_new) are selected.
13. Execute accrual or deferral of interest and charges (RFBKCONA)
Interest and charges up to October 30 (date_old) are computed.
14. Execute balance sheet preparation (RFBKGLBSPREP)
Transactions up to October 30 (date_old) are selected.
15. Transfer postings to general ledger (RFBKGL01)
General ledger postings include transactions up to October 30 (date_old).

Maintenance of Selection Variables in the TVARV Table

Purpose
You need to specify variants with parameters for a report. This is required because the report is provided with these parameters while it
is running. However, parameters can change within a chain or at the start of different chains. An example of this is the selection date.
You cannot specify a fixed date because of the daily change.
Define the parameters or the variants as selection variables whose value is taken from the TVARV table. The value of a variable is
automatically read from the TVARV table if the Selection Variable attribute is set for the variable in the variant. Then choose the
selection option and specify which entry is to be used from the TVARV table to fill the variable value. You need to enter the data in this
table yourself.

Prerequisites
You can see if a variable is a parameter or a selection option when you save the settings as a variant. Each variable is based on a P

PUBLIC Page 78 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 (parameter) or an S (selection option). SAP recommends that you gain an overview of the variables to be created, and then create the
variables by using the SM32 transaction, and then using these in the variant. You need to enter date variables with the YYYYMMDD
format.
The following table lists the most important variables that are needed in the reports:
Job Name Field Name in the Report Variable Type
RFBKPDT2 Bank Area Parameter
RFBKPDT4 Bank Area Parameter
RFBKKC20 Bank Area Selection option
RFBKKC20 On Parameter
RFBKCONC Bank Area Selection option
RFBKCONC Balancing Selection Date Parameter
RFBKBSST Bank Area Selection option
RFBKBSST Statement Date Parameter
RFBKCLEB Bank Area Parameter
RFBKCLEB Balancing Posting Date Parameter
RFBKCHACCUR Bank Area Parameter
RFBKSOCR (obsolete from EA-FINSERV Bank Area Parameter
200)
RFBKSOCRPAR (new from EA-FINSERV Bank Area Parameter
200)
RFBKACCL Bank Area Parameter
RFBKACCL Closure Date Parameter
RFBKCONA Bank Area Parameter
RFBKCONA Accrual/Deferral Key Date Parameter
RFBKGLBSPREP Bank Area Selection option
RFBKGLBSPREP To-Date for GL Transfer Parameter
RFBKGL02 Bank Area Selection option
RFBKGL02 To-Date for Balance Sheet Preparation Parameter
RFBKGL_VA_CALC_POST Bank Area Selection option
RFBKGL_VA_CALC_POST Account Number Selection option
RFBKGL_VA_CALC_POST Posting Date Parameter
RFBKGL_VA_CALC_POST Valuation Date Parameter
RFBKTTERMCONTROL (changed for EA- Bank Area Selection option
FINSERV 500)
RFBKTTERMCONTROL (changed for EA- Product Selection option
FINSERV 500)
RFBKTTERMCONTROL (changed for EA- Account Number Selection option
FINSERV 500)
RFBKTTTERMMATURE (new for EA- Bank Area Selection option
FINSERV 500)
RFBKTTTERMMATURE (new for EA- Product Selection option
FINSERV 500)
RFBKTTTERMMATURE (new for EA- Account Number Selection option
FINSERV 500)
RFBKTMP1_PO Bank Area Parameter

Process Flow
In the most simple case (where there is one bank area only), the TVARV table requires only two variables:
· One parameter variable for the old payment transaction date.
· One parameter variable for the new payment transaction date.
You can specify all the other values directly in the variant. You need to enter the date variables daily.
There are two options:
1. The work preparation must adjust the variables on every working day.
2. You write a report that supplies the variables. Both date variables are in the BKK01D table. PDAT_ACT contains the current payment
transaction date and CDAT_ACT contains the current posting closing date. The values are exported from these variables and imported
to the TVARV table.
The report must be defined in such a way that it can be entered in a chain. The report uses the same logic as that from the reports
delivered by SAP. The general logic is in the Online Self Service in note no. 123217.
You then need to enter the report in the list of reports that are to be chained.

PUBLIC Page 79 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Displaying an Overview of Mass Runs
The overview of mass runs helps you with the analysis of the mass runs and also in identifying errors. You can display the following
mass runs:
● Current mass runs, meaning that the steps defined for the run are not yet completed. Also current are those mass runs whose processing runs in the
background (for example, for capital yield tax (CYT)).
● Incorrect mass runs, meaning that errors have occurred during the processing of the mass run (for example, database error) or on the accounts themselves
that have led to the accounts being blocked from the run.

Procedure
1. Choose Periodic Tasks → End-of-Day Processing → Mass Run Overview.
2. If you wish to limit the display, you have the following options:
a. Select the bank areas for which you wish to create the overview.
b. Select the application types (for example, account balancing).
3. Start the program.

Result
You receive a list of the current mass runs in accordance with your selection regarding bank area and application type.
This list contains:
● Application type
● Bank area
● Name of the user who started the mass run
● The mass run key
● Date/ time the mass run was last started
● In one column you see if a simulation or an update run is involved and also the current status of this mass run.

To find details of the individual accounts not processed during the run, check the corresponding runs in the overview of the blocked
accounts.

Displaying an Overview of Locked Accounts

The Overview of Locked Accounts function enables you to find locked accounts in mass or single runs, which cannot be processed
because they are locked.
This overview contains the accounts that were locked in mass runs (for example, cash concentration, account balancing, bank
statement) or in individual account balancing.

Procedure
1. Choose Periodic Tasks → End-of-Day Processing → Overview of Locked Accounts.
2. You have the following options for restricting the display:
a. If required, enter the bank area and, if necessary, the account number.
b. Select the application types to which the overview is to be restricted.
c. If necessary, restrict the period for starting the program. If you make no specification, the whole time period is selected.
3. Start the program.
The system provides a list for each selected balancing run of the locked accounts, their locking reason, and their lock category.

Tip:
You can find more detailed information as to why the account could not be processed in the respective application log.

1.4.2 Setting the Posting Date

In this section you increase the date on which the postings are executed in the system. This must always be done daily, even if no other balancing tasks are
performed. For information on the sequence for setting the dates, refer to
: Process Flow of End of Day Processing.

PUBLIC Page 80 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The user can set two posting dates:
Posting date of payment transactions:

The date used as posting date for all postings of internally and externally initiated payment transactions (you can individually control the value date in
payment transactions). Standing orders are also generated with this date. You set this date to the following day by executing a posting cut-off.
You have the following options for this:

You can set the posting cut-off manually. To do this, choose Periodic tasks → Posting date → Payment transactions or Balancing and specify the next
posting date for each bank area.
You can have the posting cut-off executed automatically by the system at a fixed time. You find the settings for this in the Implementation Guide (IMG) by
choosing Basic settings → Bank area → Define bank area.
Posting date for the balancing postings:

The postings generated by the system as part of cash concentration and account balancing are posted with this balancing date.
To set this date, proceed as follows:
Choose Periodic tasks → Posting date → Balancing and specify the bank area. The posting date for the balancing postings is then set to the current
posting date for payment transactions.

Both these posting dates can also be set in batch mode. For this, under Periodic tasks → Posting date → Payment transactions batch or
Balancing batch, reports are stored that can be included in jobs accordingly.

1.4.3 Account Balancing

Purpose
Accounts are balanced regularly as part of the periodic tasks in accounting. Account balancing is triggered periodically in accordance
with the entry in the account master. You can set the time periods on the account to determine the frequency.
During account balancing, the system does the following:
· It determines the balancing balances.
· It calculates the balancing interest and charges according to the conditions assigned to the account, and updates the respective account.
· It updates the balancing date defined in the account master to the next date.
· It transfers the interest to the module for the calculation of capital yield tax (CYT) for processing.
· If necessary, the system adjusts balancing from earlier periods if there are value dates in the past, backdated postings, or a retroactive condition change in
periods that have already been balanced.
Accounts can be balanced in a mass run or individually. It is possible to simulate a balancing directly on the account. To simulate
balancing runs, choose Periodic Tasks → Account Balancing → New Run → Single or Mass Run. In the process flow control on the
next screen, choose simulation on the next date. For more information on how to use account balancing in end-of-day processing, or
the connection with other periodic tasks, see Process Flow of End-of-Day Processing.
As an alternative to standard updating, you can enter balancing postings on another account, called the reference account. The
reference account can be in another bank area in the current account system as well as with another bank outside the current account
system. For more information, see Creation of a Reference Account for Balancing. When you enter these postings, the system fills the
payment notes. You can use the business transaction event 00010830 or 00010831 (see Filling Payment Notes for Balancing
Postings or Balancing Postings: Filling External Payment Notes).

Prerequisites
To balance an account, you need to maintain the account balancing data. For more information, see Maintaining Balancing Data.
Conditions must be assigned to every account that is to be balanced. You can assign standard or individual conditions to an account.
For more information, see Assigning A Condition Group to An Account or Creating Individual Conditions.
In addition you need to set the required transaction types the Implementation Guide (IMG) by choosing Account Management →
Assign Posting Categories to Transaction Types.
You enter balancing postings with the end date of the period to be balanced as the value date and the Posting Date - Balancing
Postings defined in the system as the posting date. (For more information on setting the posting date, see Setting the Posting Date)
In Bank Customer Accounts, the posting date of the payment transaction is different from the posting date of the balancing. Once the
date has been updated and the payment transaction postings entered, you can balance accounts. This means that the posting date of
the balancing is before the posting date of payment transactions.
Once the posting date for the balancing is set, an account has the following options:
· The posting date is within the period to be balanced. This is also possible if the posting date of payment transactions is already in the next period.
· The posting date is in the following period. One disadvantage of this is that adjustments to the balancing of the balanced period (for example, as a result of
value dates in the past) are not already included in the next period, but in the one following that. Adjustments are always made in the period in which the
posting date lies.

Process flow of interest and charge calculation

1. Selection of the accounts
Accounts are selected for the calculation of interest and charges according to bank area, balancing type, balancing (interest and
charges), and balancing date. In addition, you can restrict the selection by specifying a product. If you specify more than one bank area,
you cannot restrict the selection by specifying a product.
The following accounts are selected:

PUBLIC Page 81 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 · Due accounts, which have an account balancing date in the master data that is before or on the selection date for account balancing.
· Accounts to be balanced again, even if they are not yet due. These, are, for example, accounts whose conditions for CYT have changed. You need to trigger
this new calculation in the system. To recalculate balancing from past periods for individual accounts, choose Environment → Balancing → Recalculate in
the master data of that account.
· Accounts to be called, which are accounts whose maturity date in the term agreement is either on or before the selection date in the account balancing.
· Accounts that are to be closed, even if they have not yet matured.

Example
It is assumed that the balancing date of an account is June 30 and the account is to be closed on July 2. The date on which closure actually takes place is
July 5. This account is balanced until June 30 as normal. For the period between June 30 and July 2, you need to trigger a separate run for the account that
is to be closed. If the run is to take place on July 5, then you need to balance the account that is to be closed in a single run. If processing is not urgent, the
account can be balanced automatically on the next day in the mass run ( in this case, July 6).
2. Dispatching and parallel processing of the process flow
The accounts are divided into intervals and these account intervals are distributed to various processors or servers. You can set the
size of the intervals in the Implementation Guide by choosing Periodic Tasks → Parallel Processing. The account number is used as
the criterion for this.
3. Processing
The following processing steps for the different areas, for each “due” account:
· Account master: The system uses the balancing date defined in the account master data to find the periods that are to be balanced.
· Conditions: The conditions and limits stored in the system are used for the accounts to be balanced. If no individual conditions are stored, the standard
conditions always apply. With regard to limits, only the overdraft limit is used for balancing.
· The daily balances based on the value date are determined by the system.
· Item counter: The system reads the item counter to calculate the charges and dispatch expenses due. The system uses the counter value from the balancing
date to calculate the charges.
· Account balancing table: Calculation of interest and charges.
· Tax calculation: Transfer of the required data for tax calculation.
· Posting the account balancing: The interest and charges are posted, whereby the system creates a document containing several items (one for each
condition category). Separate documents are created for adjustment postings of old periods. The data is transferred to the general ledger and the account is
updated.

The balancing date and posting date of the transactions mean that there are nine options for calculating the interest and charges.

The following table shows the possible combination of value date and posting date, and how they are used during balancing. As an
example, February is the period to be balanced, January is the period already balanced and March is the following period.

The above graphic can be interpreted as follows:

PUBLIC Page 82 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Dates Interest calculation Charge calculation
1 No No
Posting date and value date are the same, The period is balanced and is not adjusted. The period is balanced and is not adjusted.
in this case Jan. 2.
2 Yes No
Posting date is Jan. 2 and value date is Interest occurs in the period to be Charges are levied when the item is
Feb. 5. (value date in the future at last balanced - February posted, in this case, January.
balancing)
3 No (Reason: Interest is calculated at the No (Reason: Charges already calculated
Posting date is Jan. 2 and value date is next balancing.) at the last balancing.)
Mar. 3.
4 Yes Yes
Posting date is Feb. 5 and value date is The period is recalculated. Charges are levied when the item is
Jan. 3. (Value date in the past) posted, in this case in the period to be
balanced - February.
5 Yes Yes
Posting date is Feb. 5 and value date is
Feb. 6. (Normal case)
6 No Yes
Posting date is Feb. 5 and value date is (Reason: Interest is calculated at the next Item charges incur that are levied in this
Mar. 4. (Value date in the future) balancing.) current period.
7 No (value dates in the past already known No (Reason: Charges are included in the
Posting date is Mar. 5 and value date is for the next balancing are not included, as next balancing)
Jan. 4. interest calculation then dependent on time
of balancing)
8 No No
Posting date is Mar. 5. and value date is
Feb. 7.
9 No No
Posting date is Mar. 5 and value date is
Mar. 5.

CYT:
CYT is calculated by a separate, customer module that you call by using an Event (Business Transaction Event). CYT can be calculated
in batch and online processing. Only the accounts with credit interest and/or the indicator Relevant for CYT on the account are
transferred.
If CYT is to be calculated for adjustment periods, the current account system transfers the total interest. In this case, total interest means
that all the interest from the adjusted period is transferred and not just the difference. The example below shows the full interest for the
amount of 12 USD. However, you need to enter the difference amount in the current account system for continued processing after the
CYT has been calculated by the CYT module.
CYT module in online mode
The processing of the interest for CYT in online mode with the user-defined CYT module is equivalent to a processing step between
different systems with no interruption. The following are the steps for each interval:
● Calculated interest is transferred to the CYT interface
● The CYT module calculates the CYT
● The CYT module transfers the calculated CYT back to the current account system
● The current account system further processes the data
Error Processing:
If an error occurs during online processing, the current account system terminates the processing. Once you have corrected the error,
you need to restart the account balancing. Choose Periodic Tasks → Account Balancing → Restart.

CYT module in batch mode

Processing interest in batch mode is different from online mode because it is done in independent systems. Each interval passes
through the following steps:
· Calculated interest is transferred to the CYT interface.
· The CYT module does not calculate the CYT at the same time as the current account system.
· The CYT module calls up the current account system at a later point in time and transfers the data (BAPI_COND_CALC_AFTER_WHTAX).
· The current account system continues processing the data.

Error Processing:
● Error in the current account system: If an error occurs in the current account system during batch processing, nothing is posted. Once you have corrected
the error, choose Periodic Tasks → Account Balancing → Restart to restart the balancing run.
● Error in the CYT module: If the CYT module has terminated processing, the CYT module must trigger the restart. It is not possible to restart the account
balancing from the current account system.
CYT and the Euro
After the changeover of the account, all items from balancing are posted in Euros - including those for periods ending before the
changeover key date (value dates in the past). For periods after the changeover key date, the amounts transferred back from the CYT

PUBLIC Page 83 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 interface are in euro currency. If, however, a period that lies before the currency changeover date is recalculated, CYT adjustments can
be transferred back to the current account system both in Euros and in USD.

If you are using SAP FI, the interest is transferred from the current account system to the CYT module in local currency, also. If your CYT
module only recognizes the local currency, you can define the company code in the bank area. If the currencies do not match, the
current account system converts the currencies, provided the currency involved is one participating in the Euro changeover. The Euro is
handled like a participating currency.

Adjustment postings from periods already calculated

Value dates in the past are postings from the current balancing period whose value date lies in a period that has already been
balanced. Value dates in the past can occur in any prior period. The entire period is recalculated, with the inclusion of the value dates in
the past. The result is compared with the interest of the last balancing. The difference is displayed in the current balancing as an
adjustment resulting from value dates in the past.
· Post
If there is a value date in the past on the last day of a previous period, this amount is not posted in the balancing balance of the previous
period. This day counts as the first day of a new period. Value dates on the last day of a period do not lead to the adjustment of a
period, as interest is calculated for the last day in the previous period.
· Balancing balance
In the case of value dates in the past, the balancing balance of the period to be adjusted depends on the posting date of the adjustment
period. There are three different situations:

If Then
Posting date in the adjustment period Adjustment posting in the balancing balance
Example: January is the adjustment period. If the posting date is
Jan. 23, the adjustment posting is contained in the balancing
balance for January. The adjustment of the balancing balance
takes place in the balancing for February.
Posting date after the adjustment period but before or on the next Adjustment posting in the next balancing
deadline Example: January is the adjustment period. If the posting date is
Feb. 5, the adjustment posting is NOT contained in the balancing
for January but for February.
Posting date is after the next deadline Adjustment posting in the next but one balancing
Example: January is the adjustment period. If the posting date is
Mar. 17, the adjustment posting is contained neither in January nor
in February. It is not contained in the balancing balance until
March, as soon as this is balanced.

Example: Current period - February, adjustment period - January

Interest adjustment for a period that has already been balanced

Value dating describes the key date-related value date of an account balance or of an item on a customer account. On the value date,
interest calculation starts for the changed balance resulting from an incoming or outgoing payment. If there is value dating to the past to a
balanced period, the credit and debit interest and the overdraft interest for the balanced period has to be recalculated.
Value dates in the past in periods already balanced lead to the following results:
Calculated credit interest was too high Minus credit interest (account is debited)
Calculated credit interest was too low Plus credit interest (account receives credit)
Calculated debit interest was too high Minus debit interest (account receives credit)
Calculated debit interest was too low Plus debit interest (account is debited)
Calculated overdraft interest was too high Minus overdraft interest (account receives credit)
Calculated overdraft interest was too low Plus overdraft interest (account is debited)
Calculated commitment interest was too high Minus commitment interest (account receives credit)
Calculated commitment interest was too low Plus commitment interest (account is debited)

The value date of the adjustment posting with the recalculated interest corresponds to the end date of the adjustment period.

Example:
Period 1 was balanced with credit interest amounting to 10 USD. A value dating in the past results in new credit interest of 12 USD.
The difference of 2 USD is not adjusted when the value date in the past is posted, but at the next balancing of period 2. This means
that period 1 is recalculated in period 2 and the customer receives 2 USD plus credit interest.

Result
If the balancing was successful, the account balancing is posted. You can take a look at the balance and also the turnovers, interest and
charges on the bank statement.
The balancing results are transferred to the general ledger. The customer account is updated.

PUBLIC Page 84 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.4.3.1 Balancing Accounts
You can balance accounts in two different ways.
Individual Account Balancing
This function is used to balance a single account outside of the normal mass run:
1. Choose Periodic Tasks → Bank Statement → New Run → Single Run.
2. Specify the bank area and the account number of the account to be balanced and also the selection date for the balancing.
If the balancing date specified in the account master data (or a possible closure date) is on or before the selection date, the system
balances an account.
You can also simulate the account balancing first, on the next balancing date. Choose the Simulation on Next Date field. In this field you
can choose between simulation including a check of the posting date of payment transactions and simulation excluding a check of the
posting date of payment transactions. During a simulation, no database tables are updated and no postings are made.
Mass Run
This function is used for balancing all accounts due, according to certain selection criteria:
1. Choose Periodic Tasks → Account Balancing → New Run → Mass Run.
2. Specify the bank area for which you wish to select the accounts and the selection date for the balancing. In addition, you can restrict
the selection for a bank area by entering a product.
The system balances every account in this bank area where the balancing date (or a possible closure date) that was specified in the
account master data is on or before the selection date. If you enter a product, the system also evaluates the product defined in the
account master data.
Simulation is also possible.
If errors occur during account balancing because individual accounts could not be processed, the system initially locks these accounts
for further processing in the balancing tasks (for example, bank statement).
It is possible to restart the run for these accounts, by proceeding as follows:

1. Correct the cause of the error.

2. Choose Periodic Tasks → Account Balancing → Restart → Single or Mass Run.
To simplify error correction, you can display the accounts that could not be processed by choosing Periodic Tasks → End-of-Day Processing→ Overview of
Locked Accounts.
Messages
Frequently output messages (for example, conditions, value date balances, calculation results) are stored in the spool output, which
enables you to decide what is to be output.
You can select from the following parameters that are in each account balance:
● Conditions
● Balances (calculation bases)
● Calculation results
● Total calculation results
● Capital yield tax (CYT) transfer
Procedure
1. Choose the following to display balancing reports under single and mass runs, where you selected the above parameters:
Periodic Tasks → Account Balancing →New Run
Periodic Tasks → Account Balancing → Restart
Periodic Tasks → Account Balancing→ Early Balancing
Periodic Tasks → General Ledger →Accrual/Deferral.
2. Choose one of the required balancing reports.
3. Choose one or more parameters.
The messages you want are now written to the spool. If you have not selected any parameters, you do not receive any messages.

Note
Messages that can be found in the application log are those recording something unusual (for example, old period must be
recalculated due to ‘backdated posting’ or ‘value dates in the past’). The system also records the errors.

1.4.3.2 Early Balancing

Use
Early balancing enables you to balance the account before the next balancing date specified in the account master. All postings in the
period between the early balancing and the actual posting date are flagged as backdated postings and recalculated during the next
balancing. This means that these postings are treated as if they belonged to periods that have already been balanced.
Early balancing may be necessary, for example, if balancing needs to be available a few days before the balancing date. You normally
use early balancing at the end of the year for year-end closing, if you require the balancing before 12/31.

Example:

PUBLIC Page 85 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 You want to balance your account for 12/31 on 12/28. The postings between 12/28 and 12/31 must be in the period up until 12/31. All
items posted in the period between 12/28 and 12/31 are included in the January balancing by means of recalculation of the original
balancing date (December balancing). The differences compared with the previous balancing are posted with the value date 12/31.

Activities
To prepare early balancing, enter the date of the early balancing and the period end date at least one day before the early balancing
run. You must do this for each bank area. The date of the early balancing must be on or before the posting date of payment
transactions. This enables items with a posting date between the two dates to be considered as backdated postings.
The account can be balanced early if you use the optional Product parameter for individual products of the bank area.
You can balance the account in a single or mass run.
You can also simulate early balancing, whereby you can start simulation before the run date has been reached. In a simulation, all the
program steps are processed as for a single run, but no data is updated on the database and no data is posted.

Procedure
Preparation
Periodic Tasks → Account Balancing → Early Balancing → Preparation.
Simulating the balancing
There are two options for the simulation:
1. The system compares the selection date for the balancing with the posting date of payment transactions. If the posting date of
payment transactions is before the selection date of the balancing, you cannot balance the account.
2. The system simulates the balancing without checking the posting date of payment transactions.

Choose the following settings, but at the earliest on the next day.
Executing a single run
Choose Periodic Tasks → Account Balancing → Early Balancing → Single Run.
Executing a mass run
Choose Periodic Tasks → Account Balancing → Early Balancing → Mass Run.

Interest Compensation

Purpose
Interest compensation is used to balance an account pool in a hierarchy, and is aimed at maximizing interest income and minimizing
interest to be paid to the bank. It also enables you to manage accounts for the same account holder for different purposes.
Interest compensation adds up the debit and credit balances of more than one account, and calculates the interest for the total balance
that has been compensated. Interest compensation is possible for the participating currencies in the EURO conversion, and in EURO
itself. Interest can be compensated across bank areas, but a hierarchy over more than one level is not supported.
The system periodically compensates interest as part of account balancing.
Enter the settings and activate the required checks in the Implementation Guide (IMG). You can run interest compensation as part of the
periodic account balancing as a mass run or as an individual balancing.

Value dates in the past and backdated postings are allowed. Conditions that applied at the time of the value date are valid, meaning
that if balanced periods are recalculated, the conditions of the hierarchy valid at that time are used. The account pool formation
applies also. If an account was a member of an account pool at the time of the last period but is no longer participating, the
conditions of the account pool apply.

An account can only belong to one account pool for a particular period, but this account can change to another pool in another

PUBLIC Page 86 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 period. If back postings and value dates in the past are for an earlier period in which the account belonged to another account pool,
then the conditions of this account pool apply.

Prerequisites
Before you can run interest compensation you need to create an account pool with a root account. The root account must be created in
the account pool and must be in the hierarchy, but it can refer to a reference account.
The root account is the leading account on which the interest conditions and limits are centrally defined for the account pool. The
balancing date for interest compensation is also defined on the root account. If conditions are defined for the subordinate accounts,
these are not included or are overridden by the conditions of the root account. The balancing date on each subaccount must be the
same as that on the root account.
A change or assignment to an account pool is only possible during the period if the accounts were created after the hierarchy start date
and have not yet received postings. You cannot assign an account to an account pool until account balancing has been completed.

Process Flow
1. The balances of the subordinate accounts are fictitiously summarized, value date-exact, and used as a calculation basis.
2. The interest for the accounts to be compensated is calculated on the basis of the total balance of the account pool, and
compensated or posted to the root account. This means that only the balancing result is posted but no account balances are carried
forward.
3. All accounts in the hierarchy are balanced without compensation for information purposes.

A business partner has three accounts and wants the interest and charges compensated on one of these accounts. The accounts for
compensation have the same debit and credit interest and the same limits. Interest is calculated for the compensated total balance.

Conditions:
Credit interest: 5%
Debit interest: 10%, overdraft limit = 1,000 USD
Result of interest compensation:
S Account balance (account 1, 2 and 3): 0 - 100 + 200 = 100 USD
Calculation of interest: 100 x 5%= 5 USD
Posting to root account: 5 USD credit interest
Result without interest compensation:
Account 1: 0 = 0 USD
Account 2: –100 x 10% = - 10 USD debit interest
Account 3: +200 x 5% = + 10 USD credit interest
Advantage of interest compensation: 5 USD (account 1 / root account)
The advantage of charge compensation is illustrated in the following two examples. Set the Charge Compensation indicator to take
advantage of this function.

PUBLIC Page 87 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Conditions of the root account Conditions for the account
Account maintenance charge 10 USD 10 USD
Free items: 1500 500
Item charge: 0.50 USD/Item 0.50 USD/Item

Result/posting to root account with charge compensation: Result/posting to root account with charge totaling:
Account maintenance charge: Account maintenance charge: 10 + 10 + 10 = 30 USD
10 + 10 + 10 = 30 USD Item charges:
Item charge (compensated): 700 - 500 = 200 x 0.50 USD
700 + 400 + 600 = 1700 -1500 = 200 items 400-500 = 0
600 - 500 = 100 x 0.50 USD
0.50 USD x 200 = 100 USD 100 +0 +50 = 150 USD

Result
The result is posted and can now be processed, for example, for capital yield tax (CYT).

1.4.3.3.1 Interest Compensation Process

Purpose
Interest compensation as used in the current account system is a one-level procedure with no relocation of the result. Interest and
charges can be compensated for the currencies participating in EURO conversion, in the EURO currency, and across more than one
bank area.

Implementation Considerations
You make the following settings in the implementation guide (IMG) to enable interest compensation in your bank:
1. By choosing Master Data → Limits → Define Limit Categories you define the limits that are needed for interest compensation. The
following limits are relevant for interest compensation:
· Interest compensation - overdraft limit: Used for calculating overdraft interest for interest compensation.
· Internal limit of interest compensation: Controls the coverage check of the payment transactions. The account pool for interest
compensation may be overdrawn up to this limit.
· External limit of interest compensation: The limit that is communicated to the customer (for information purposes).
2. Select the feature characteristics for interest compensation by choosing Master Data → Product Definition → Product → Create
Product.
3. Select the hierarchy type for interest compensation by choosing Master Data → Account → Maintain Account Relationship Types.
4. Define the interest compensation methods that you want to use for interest compensation by choosing Periodic Tasks → Interest
Compensation → Specify Interest Compensation Method. You can define more than one method for selection when you create a
hierarchy. Four methods are supplied, but you can also define your own methods. A method corresponds to a certain combination of
the seven indicators on the detail screen. Two of the seven indicators are dependent on each other, meaning that a total of 96 different
methods and not 128 methods are possible.

Integration
Interest compensation is run automatically during account balancing, whereby the balances of the accounts in an account pool are
fictitiously summarized. Then the interest and charges of the accounts to be compensated are calculated using the total balance of the
account pool and are posted to the root account. The balancing result is only posted, no account balances are carried forward.

Process Flow
1. Maintaining account master data for balancing
You can create accounts specifically for interest compensation or maintain existing accounts as required.
a) In the account master data, choose the “Balancing” screen, and specify the date of the next balancing, the period and the key date
for the following balancing or interest compensation.
Note:
Before you can add an account to an account pool, certain requirements must be met that depend on whether the account was created
specifically for interest compensation, or if an existing account has been maintained. Accounts in an account pool must always have the
same time periods and the same key date.
New accounts:
The time periods, the key date and the next balancing date must be identical. The accounts also need to have been opened on the
same date, but if the opening dates are not identical, the “Valid From” date must be the same as the opening date of the root account.

PUBLIC Page 88 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 same date, but if the opening dates are not identical, the “Valid From” date must be the same as the opening date of the root account.
The opening dates of the subordinate accounts may be on or after the opening date of the root account.
Existing accounts:
The time periods, the key date and one of the next balancing dates must be identical.
Example for the same date in the future:
Two accounts are to be included in an account hierarchy. The time periods of both accounts is three months, the balancing date of one
of the accounts is 03/31/2006 and that of the other account is 04/30/2006. Both are to be included in the account hierarchy on
07/01/2006, which is allowed, because a future balancing date coincides for both.
Example for a different date in the future:
Two accounts are to be included in an account hierarchy. The time periods of both accounts is three months, the balancing date of one
of the accounts is 03/31/2006 and that of the other account is 04/30/2006. Both accounts will never have the same balancing date and
cannot, therefore, be included in the same account hierarchy.
2. Creating an interest compensation hierarchy
Once you have prepared the accounts for interest compensation, you create these in an account pool, known as the interest
compensation hierarchy. For more information, see Creating Account Hierarchy for Interest Compensation.
To change a current interest compensation hierarchy, you need to end it, copy it and make the changes to the copy. For more
information, see Changing Account Hierarchy for Interest Compensation
3. Start of interest compensation
The calculation period of interest compensation starts with the “Valid From” date of the account hierarchy. From this date, the system
calculates the balancing result using the method that you specified, and posts the result to the root account.
4. Interest compensation log
· The result of interest compensation is displayed on the root account.
· You can also display the balancing result without interest compensation, whereby the system balances the account “normally” without
compensation and in an update run, without updating the result. This function is offered for documentation purposes only.
Interest compensation result on the root account:
1. Select the root account in display mode.
You are now in the account master data.
2. Choose Environment → Balancing → Display Balanced Periods.
The system displays the period list and the compensation result.
Balancing result without interest compensation:
Choose Information System → Interest Scale
The system displays the “Interest scale for normal account balancing”. This list shows the calculation without interest compensation.

Other notes:
¡ Every time you balance an account from anywhere in the current account system (for example, new run, restart, or early balancing),
the system also runs interest compensation.
¡ If an account changes the account pool, and if the period in which the account was a member of another account pool needs to be
recalculated, the system recalculates the whole account pool, not just the one account. The same applies for value dates in the past
and postings to prior periods.

Restrictions
It is not possible to balance one account individually in an account pool. If an account is part of a hierarchy, interest is always
compensated.

Tip:
To compensate interest for a single account hierarchy, choose one of the accounts in this hierarchy. You can choose any account of
the hierarchy, including subordinate accounts.

1.4.4 Bank Statements

The system enables you to create bank statements for the accounts managed in the system. The required data is made available by
means of interfaces or as a print order. The printing and the special layout of forms must be supported by upstream systems.
You can create a bank statement for an account in three different ways:
· Periodic output in a mass run
The system selects all accounts due for a bank statement generation run on a certain date (in accordance with the periodic dates defined in the master data
of the account). It then creates the corresponding bank statement and the data is transferred to an interface. The date for the next bank statement is updated
on the account.
Parallel processing is used for these tasks.
This means that this option is suitable for automatic runs during periodic task processing (depending on the product, daily, weekly, monthly, quarterly or
annually).
· On demand, for example, via a connection to a self-service bank statement printer
There is a BAPI that other systems, for example, the self-service bank statement printer, can use to call up the bank statement data via an interface. The
sequential number of the bank statement is updated, and the next bank statement lists only the items that have arisen since the bank statement was
requested. The due date for the next bank statement run is not updated.
You have the following choices for the bank statement output:
· Bank statement without turnovers

PUBLIC Page 89 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 This shows the account on which there has been no flow. Statements without turnovers are handled in the same way as statements with turnovers, meaning
the sequential number is updated. Bank statements without turnovers are balance notifications.
· Simulation
You can simulate the periodic bank statement and display it on the screen (using Bank Statement when you maintain the account master data). No periodic
counters are changed.
· Bank statements for back postings in the last year:
Statements for a balanced period before the start of the current year are created. This mainly concerns back postings to the previous year.
¡ Choose Periodic Tasks → Bank Statement → New Run → Single Run.
¡ Specify the bank area, the account number and the required statement date.
Using the statement date, the system checks if there are bank statements for the year required. If this is the case, the system creates a
new bank statement with a sequential number for the previous year. However, the items that have since arisen are not added on to the
original balance, so that the balances of the bank statements for the next following year remain in order. This applies in particular to
back postings. This item is also created for back postings on the bank statement for the previous year, but the balance remains
unchanged.
The system transfers a statement recipient address, the account, and the turnover data for the bank statement. This is determined as
follows:
· If only one business partner is entered in the role of the bank statement recipient, the address of this business partner applies.
· If an account has more than one bank statement recipient, the business partner indicated as the recipient of the original bank statement receives the original
and the others receive a bank statement marked “duplicate”.
· If no bank statement recipients have been created, the account holder and the standard address are transferred.
The system provides these customer fields in addition to the output on the bank statement for each item if you have maintained
customer fields for the bank area in Customizing, under Account Management →Basic Functions in Account Management → Maintain
Field Label for Customer Fields.
If you have set the corresponding indicator for a transaction type in Customizing under Account Management →Basic Functions in
Account Management →Maintain Transaction Types, the system does not display the reference account on the bank statement for
the items that were generated with this transaction type. This enables you to ensure that there is no information on the bank statement
that concerns internal interim accounts at the bank.

1.4.4.1 Executing a Bank Statement Run

When you execute a bank statement run, the system selects all the accounts due for a bank statement on a certain date and creates
the appropriate turnover and address data. The date for the next bank statement is updated on the account.
To execute a bank statement run, proceed as follows:
1. Choose Periodic Tasks → Bank Statement → New Run → Single Run or Mass Run.
2. Specify the date until which accounts due for a bank statement are to be selected (as per the periodic dates defined in the master
data of the accounts). To filter the selected accounts more finely, you can either specify a bank area range, or a product on which the
accounts are based, as well as a bank area.
3. Enter the Control Parameter.
You have the following options:
¡ Set the Simulation Run indicator to generate a bank statement without data (such as the counter reading for generated bank
statements) being written to the database as in an update run. The system thus does not change the counter reading for generated
bank statements, meaning that you can output the same data in an update run.
¡ Set the Statement Without Turnovers indicator to generate bank statements even if there have been no turnovers on the account.

To transfer the bank statements to a printer, in Customizing for Bank Customer Accounts (BCA) you need to activate an event
(00010510) that controls the output of the bank statements by choosing Basic Settings → Business Transaction Events/Event Control
→ Activate Function Modules (P/S) SAP Application. The output complies with your programming of the event. SAP supplies two
sample function modules that place the bank statements in the spool.
If errors occur during a bank statement run because individual accounts could not be processed, (for example, because the address
could not be found), these are locked for further processing. In this case, it is necessary to repeat the run for these accounts.
Proceed as follows:
1. Correct the cause of the error.
2. Choose Periodic Tasks → Bank Statement → Restart.
You can simulate the bank statement run, if required.

Generating Single Bank Statements

You can generate a bank statement for a single account. In this case, the next run date of the bank statement is not postponed.
1. Choose Periodic Tasks → Bank Statement → New Run → Single Run.
2. Specify the account data, and the required bank statement date.
Specify this date to determine the posting date until which turnovers are displayed on the bank statement. This date must be on or before the current posting
date.
3. Enter the Control Parameter.
You have the following options:

PUBLIC Page 90 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 ¡ Set the Simulation Run indicator to generate a bank statement without updating the database as in an update run (such as the counter
reading for generated bank statements). The system thus does not change the counter reading for generated bank statements, meaning
that you can output the same data in an update run.
¡ Set the Standard Output indicator to view the bank statement output on the screen. If you want to use your own output format
(meaning that event 00010510 is called), do not set this indicator.
¡ Set the Statement without Turnovers indicator to generate a bank statement even if there are no turnovers for the account.
¡ Set the With Address indicator if the address data is to be included on the bank statement.

1.4.4.1.1 Creating Bank Statement Duplicates

Use
This function enables you to create bank statement duplicates. You use the single run if a particular customer requires a duplicate, and
the mass run to generate bank statements for multiple accounts.

Creating a Duplicate Bank Statement for an Account

1. Choose Periodic Tasks → Bank Statement → Duplicate Creation → Single Run.
2. Enter the bank area and account number.
3. Specify the bank statement number to be duplicated.
4. Specify the year in which the statement was created.

Note on the control parameters:

You can levy a charge for the creation of a bank statement, which you define in the conditions for the account.

You can issue the duplicate in the standard format or your own format.

Creating Duplicate Bank Statements for More Than One Account

1. Choose Periodic Tasks → Bank Statement → Duplicate Creation → Mass Run.
2. Specify either a range of bank areas or a product and a bank area.
3. Enter the posting period in which the relevant bank statements were created.
4. Set the Restart Run indicator if the previous duplicate creation run is to be restarted.

Result
The system creates bank statement duplicates for all the accounts that meet your selection criteria.

1.4.4.2 Generating Balance Notifications

Use
As a rule, customers receive balance notification once a year showing the posting date-based balance. This balance notification is
legally binding, provided the customer raises no objections.

Prerequisites
You need to define the balancing type Balance Notification on the account by using the Balance Notification feature in the product.

Procedure
1. On the account, choose the Bank Statement tab page and then the Balance Notification group box.
2. Enter the time periods, and specify when the next run date is.
3. If required, set the indicator for interest information. If it is set, the system simulates the interest on the final day included for the
balance information and the customer is informed of the calculated interest. For performance reasons, only set the indicator regarding
interest information if really necessary.
4. When you want to create the balance notification, choose Periodic Tasks → Balance Notification. Now you have the following
options:
¡ If you choose Mass Run, the system generates the due balance notification for each account in the selected bank areas on the key

PUBLIC Page 91 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 date.
¡ If you choose Restart, the system selects all accounts with errors from the lock table and restarts them.
¡ If you choose Single Run, the system creates a balance notification for one single account, regardless of when it is due.

Example:
An account is due on May 25 of a year. On May 30 of the year a balance notification run is started on the key date May 25. The
system selects the account and determines the balance on May 25.

If the balance is determined on the current posting date, it can still change if items are posted later on this posting date.
You can determine the recipients of the balance notification by using a business transaction event. The sample function module
(Sample Interface_00012910) is programmed as follows: The balance notification is sent to the account holder's specified address. The
system checks whether this address is a P.O. box address. If it is, or if there is no balance notification address at all, the system selects
the address assigned as recipient of the original bank statement. If this is also a P.O. box address, the system selects the standard
address. If no bank statement recipient is stored, the account holder receives the balance notification. Here, again, the system checks if
a P.O. box address is involved. If this is the case, an error message is issued.
In addition to this business transaction event, SAP also provides you with an event that you can use to display balance notification data,
or to transfer the data to a suitable output interface. For a detailed description, see Transferring Balance Notification Data.
You can format the balance notification to suit your own requirements, in the same way as bank statements.

Note:
Choose the Balance Notifications button (on the Bank Statements tab page in the Balance Notification group box) to display an
overview of historic balance notifications.

Result
The balance notifications have been created on the specified date and can now be mailed.

1.4.5 General Ledger Integration

During general ledger integration, the items updated on the current accounts are transferred to the corresponding general ledger accounts (FI GL).
The following data and details are taken into consideration:
The updating of the items posted to the G/L accounts and the updating of interest and charge income and expense.
The distribution of the balances of the transferred current accounts to receivable or payable accounts, depending on the balance +/- sign.
The netting of the current accounts in balance sheet preparation in accordance with §10 RechKredV (German law).

Prerequisites
Additionally, you have the option of carrying out interest accrual/deferral for balance sheet preparation.

The general ledger accounts to which the transfer of the items is to be made must be set up in FI and specified accordingly in the Customizing settings. Learn how
to do this by reading the section on general ledger transfer in the Implementation Guide (IMG). Choose Periodic tasks → General ledger transfer.

In the current account system, a document type must be specified in the general ledger variant that is used in FI exclusively for postings from the current
account system.
For reconciliation, the reference document number (BKPF-XBLNR) is needed for the FI documents posted from the current account system. In the FI
Customizing settings you need to set that the reference document number is not changeable after posting.
Learn how to do this by reading the section on accounting (FI) in the Implementation Guide (IMG). Choose Financial Accounting → Basic settings: Accounting →
Document → Document header → Document change rules, document header.

Activities
General ledger transfer is divided into the following steps:
Balance sheet preparation:
In this step the current balances of the current accounts are prepared for the transfer posting to the receivable and payable accounts. Balances already existing
on the general ledger are taken into consideration. Totals formation takes place during the updating of the payment items according to the criteria specified in
Customizing (transaction types and account groups).
You can execute balance sheet preparation either for the current day’s date or for a past posting date.
Interest accrual/deferral
Receivables for debit interest or payables for credit interest must be accrued/deferred
already during balance sheet preparation if they are due but not yet updated on the current account. You can execute interest accrual/deferral for this. This means
that the system calculates all the interest that has arisen since the last account balancing and prepares it for transfer to the general ledger. The updating of the
documents in FI then takes place as part of general ledger transfer.
Transfer
In this step the system creates FI documents from the totals records prepared and posted to the general ledger in the previous step. Following are details of the
postings that are made:
First the payment items are posted to a clearing account, initially comprising both the debit and credit items jointly (in future called clearing account
receivables/payables). The offsetting posting is to a clearing account for payment transactions (in future called clearing account PT, for payment-affecting
items).
The interest and charge items posted in the current account system are also transferred to the clearing account receivables/payables. The corresponding
income or expense account serves as offsetting account.
Depending on whether a debit or credit balance is involved, the balance of a current account is transferred to a receivable or payable account. In another step,
the necessary transfer postings from the clearing account receivables/payables are then made to the respective accounts.

PUBLIC Page 92 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The totals from the interest accrual/deferral are posted to the respective income and expense accounts in accordance with the Customizing settings.
Normally, the sequence for the steps described above is as follows:
If an interest accrual/deferral is to be transferred to the general ledger, this must be executed before the general ledger transfer. Decide in what intervals this is
necessary (depending on when balance sheet preparations are created).
Balance sheet preparation is necessary for the transfer of the balances. This is split into a balance sheet preparation of postings executed in former account
(backdated) and a general balance sheet preparation.
You can randomly choose the sequence in which the interest accrual/deferral and balance sheet preparation are carried out. Only one function can be executed.
Subsequently, you must execute general ledger transfer to create the postings in FI.
Several reports exist to support the control of the general ledger transfer. Find these by choosing
Information system ® General ledger.
You can find more detailed information on this in the documentation for the respective reports. Find this on the initial screen of the report
by choosing Help → Extended help.

1.4.5.1 Executing Balance Sheet Preparation

Two types of balance sheet preparation are performed. Standard balance sheet preparation prepares postings made after the last standard balance sheet
preparation for division into payables and receivables.
Balance sheet preparation - backdated - prepares backdated postings, meaning with a posting date before or up to and including the last standard balance sheet
preparation for division into payables and receivables.

Prerequisite
It is advisable to have executed an account balancing so that any postings from the balancing can also be edited up-to-date.

Procedure
Choose Periodic tasks → General ledger → Balance sheet preparation.

Choose the program documentation icon for more information on this function.
Specify the bank areas for which the balance sheet preparation is to take place (note the comments on netting). You can also enter the posting date up until
when the transfer is to be executed.
It is advisable to execute a test run before the update run. To do this, select the field Simulation run.
Choose Execute.

Result
As a result, a log of the transfer postings is printed.

Executing Accrual/Deferral of Interest/Charges

Use
Normally, an account is settled and posted to accordingly on a monthly basis. If you manage accounts that are settled over longer
periods (for example, quarter yearly), with the help of the accrual/deferral function, you have the option of calculating the interest and/or
charges that would have occurred during a monthly settlement.
After accrual/deferral you can tell if, as a result of accrual/deferral, interest and/or charges were credited or debited on the general
ledger. The following principle statements apply:
● Transaction types for "Debit interest", "Plus debit interest" and "Minus debit interest" are all considered to be interest income, meaning that "Minus debit
interest" is not interest expense.
● Transaction types for "Credit interest", "Plus credit interest" and "Minus credit interest" are all considered to be interest expense, meaning that "Plus credit
interest" is not interest income.
● Display of the amounts is always in relation to a +/- sign, meaning the sign "-" is for credit postings and "+" is for debit postings.

Procedure for executing accrual/deferral

1. Choose Periodic tasks → General ledger → Accrual/deferral.
2. Specify the bank area for which the accrual/deferral is to take place and an accrual/deferral key date.
3. Select the accrual/deferral types to be executed.
4. It is advisable to execute a test run before the update run. To do this, select the appropriate selection field. The information
regarding conditions, balances (calculation basis), calculation results and their total, and also the capital yield tax (CYT) transfer are
stored in the spool output.
5. Choose Execute.

Result
The result of accrual/deferral is posted to a separate account on the general ledger (after general ledger transfer) and taken off the

PUBLIC Page 93 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The result of accrual/deferral is posted to a separate account on the general ledger (after general ledger transfer) and taken off the
books again on the next day. This takes place in one single run; you do not have to start the taking off the books separately.

There is a report for accrual/deferral that displays the detail data on the postings on the general ledger.

Procedure for viewing the accrual/deferral list

1. Choose Information system → General ledger transfer → Interest accrual/deferral: Detailed statement of the created interest
accrual/deferral.
2. Enter the bank area, account number, posting date of the accrual/deferral and the product.
The detail lists for interest income and expense as well as the charges income and expense are managed separately and totaled within a currency.
3. If required, you can choose a display currency and the amounts are then additionally converted into this currency.

Result
You now have an overview list. From a line in this list you can call up the next degree of detail, and from this degree of detail, a higher
degree of detail, right up to the transaction type.

Other notes
The interest rate is not output, since this can change during the period in question. You can find information on this if the spool list for
interest accrual/deferral is set accordingly.

The highest degree of detail shows the interest per account and transaction type, although it is not possible to tell which interest
incurred for which balances. However, this can also be seen in the spool list if the appropriate parameter is set.
Error handling:
In the case of an error you can restart accrual/deferral. Choose Periodic tasks → General ledger → accrual/deferral.
The program for accrual/deferral is completed even if there is an error in Customizing for general ledger transfer. You can review the
errors that have occurred here in the application log.

1.4.5.3 Transferring Postings to the General Ledger

Prerequisites
The postings from end of day processing are concluded.
The posting date for payment transactions and the posting date for balancing have been increased.
Balance sheet preparation has been executed.

Procedure
Choose Periodic tasks → General ledger → Transfer FI.

Choose the program documentation icon for more information on this function.
Specify the bank areas for which the transfer is to take place.
If necessary, swap the indicator for the data to be transferred:
current postings
if you only want information from current operation transferred
postings from legacy data transfer
if you only want information from legacy data transfer transferred
It is advisable to execute a test run before the update run. To do this, select the field Simulation run.
Choose Execute.

Result
As a result, a transfer journal is printed.

General Ledger Transfer After Currency Changeover

Purpose
During transfer to the general ledger, the items updated on the current account system accounts are transferred to the corresponding
general ledger accounts.
Until the currency changeover, the current accounts are managed in the account currency DEM and the documents are posted on the
general ledger in the document currency DEM. As a result of the currency changeover, the account currency is changed to euro. The

PUBLIC Page 94 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 changeover can take place daily, on any date. This changeover is taken into consideration during the transfer to the general ledger,
meaning that the accounts that have already been changed over to euro are transferred to the general ledger with the document
currency euro. Since general ledger transfer takes place daily after completion of all tasks, the changes to the accounts changed over
during the day are carried forward to the general ledger. The receivables and payables of the account are taken off the books in the
original account currency and put on the books on the relevant G/L account in euro. This is done automatically.
The possibility to transfer accounts that were already changed over to euro to the general ledger with the document currency euro
means that:
· Payables and receivables of the changed over accounts are no longer shown in the account currency before the changeover, but in
euro.
· The necessary transfer postings on the general ledger take place as part of general ledger transfer.

Process flow
1. Changeover of the current accounts to euro
2. Execution of the daily balancing tasks
3. General ledger transfer with automatic transfer postings on the general ledger
Possible currencies in the current account system and on the general ledger
The account currency in the current account system determines the document currency on the FI general ledger. It is irrelevant if euro, a
participating currency or some other currency is involved. The example below involves an account currency of French francs. This
account currency is adopted as document currency. This means that when the account currency changes to euro, the document
currency on the general ledger also changes. However, the local currency does not change. The local currency is independent of the
euro changeover for accounts and bank areas. This only changes after the changeover of the company code to euro.
What always applies is that current accounts managed in euro are transferred to the general ledger with the document currency euro.
The document currency change becomes apparent during the next general ledger transfer.

Posting logic on the general ledger

The following example serves to clarify the postings on the FI general ledger after currency changeover in the current account system:
The private account in the example is first still managed in DEM and receives a credit amounting to 1,000 DEM. Then the account is
changed over to EUR.
The credit is posted to the clearing account private customers (130.100) as payable (1). As part of balance sheet preparation, this
credit is taken off the books of the clearing account private customers and put on the books to the account payables, private customers
(160.100) as payable.
Following this, the account is changed over and during the first general ledger transfer after the changeover the DEM balance is taken off
the books by means of a special currency changeover account (198.010). The amount (3) is offset on the account clearing, payment
transactions (198.000). The amount in DEM is then taken off the books of account 130.100 clearing, private customers. The offsetting
posting (4) is to the account take currency changeover off books, (198.010).
Then the EUR amount offsets the DEM amount (5) on the clearing account, payment transactions. This is done by means of the account
put currency changeover on books, (198.020). It is identified as an amount put on the books. From this account, the EUR amount is put
on the books to the clearing account private customers (6).
In the next step the amount is transferred from the clearing account private customers to the account payables, private customers
(160.100). For this, the amount of 1,000 DEM is taken off the books of the payables account (4) and the payable of 1,000 DEM (2) is
updated on the clearing account private customers. The clearing account private customers is now balanced/cleared.
The amounts for balance sheet preparation are also taken off the books in DEM (7) and put back on the books in EUR (8). The taking off
the books takes place on account payables, private customers (160.100) to the clearing account.
From the clearing account private customers the EUR amount is posted to the payables account, private customers (8)

PUBLIC Page 95 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 By appropriate Customizing it is also possible to manage the accounts managed separately in the example for the taking off or
putting on the books of the currency changeover (198.010/198.020) as one account.

The offsetting account for currency changeover does not have to be the same as the payment transaction clearing account. For a
clearer overview, you can also set up a separate account for this purpose.

You can define different accounts for different currencies in Customizing. It is possible, for example, to set up separate clearing
accounts, payable accounts and receivable accounts for EUR and DEM. This division was not made in the above example.

1.4.5.5 Postings on the FI General Ledger

Following are some simple examples showing various sets of circumstances that arise during transfer to the FI general ledger. Only single payment items or FI
postings for single accounts managed in the current account system are illustrated.

The accounts managed in the current account system are called "BCA accounts" in these examples.

In FI, normally totals of postings for a general ledger group are posted. To clarify the posting logic, T-accounts are used for FI. A posting listed on a T-account
corresponds to the generation or update of a posting total in the current account system.

Posting a bank transfer

Assume a transfer from a BCA checking account is made to an account at the land central bank (LCB). The offsetting posting to the LCB account is normally
made in a total with all other payments. Assume the BCA checking account has the general ledger group "Corporate customer" and the LCB account belongs to
the "Bank customer" general ledger group. Alternatively, the LCB account can form its own general ledger group that is posted directly to a general ledger account
LCB (without clearing account and dividing payables/receivables). For balance sheet preparation it is assumed that before this posting the balance of the
accounts is zero.
Current account system:
BCA checking account BCA bank account LCB
(1) 1,000.—D 1,000.—C (2)

FI general ledger:
150200 (clear. 198000 (clear.
corporate customers) payment transactions)
(1) 1,000.-- 1,000.-- (3) (2) 1,000.-- 1,000.-- (1)

150300 (clear.
bank customers)
(4) 1,000.-- 1,000.-- (2)

PUBLIC Page 96 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 140200 (rec. 140300 (rec.
corporate customer) bank customers)
(3) 1,000.--

160300 (pay. corporate customer) 160300 (pay. bank customers)

1,000.-- (4)

(1) Posting of the payment item to the BCA checking account

(2) Posting of the payment item to the BCA bank account LCB
(3) Balance sheet preparation: Transfer posting daily balances corporate customers
(4) Balance sheet preparation: Transfer posting daily balances bank customers

Balance status change

Now we consider the case that after the above described posting, on the next posting day there is a credit to the BCA checking account that leads to a balance
status change (minus to plus).
Current account system:
BCA checking account BCA bank account LCB
(1) 1,000.—D 1,000.—C (2)
(5) 2,500.—C 2,500.—D (6)

FI general ledger:
150200 (clear. 198000 (clear.
corporate customers) payment transactions)
(1) 1,000.-- 1,000.-- (3) (2) 1,000.-- 1,000.-- (1)
(8) 2,500.-- 2,500.-- (5) (5) 2,500.-- 2,500.-- (6)

150300 (clear.
bank customers)
(4) 1,000.-- 1,000.-- (2)
(6) 2,500.-- 2,500.-- (10)

140200 (rec. 140300 (rec.

corporate customer) bank customers)
(3) 1,000.-- 1,000.-- (7) (10) 2,500.,-- 1,000.-- (9)

160200 (pay. corporate customer) 160300 (pay. bank customers)

(7) 1,000.-- 2,500.-- (8) (9) 1,000.-- 1,000.-- (4)

(1) Posting of the payment item to the BCA checking account (from bank transfer on previous day - see above)
(2) Posting of the payment item to the BCA bank account LCB (from bank transfer on previous day - see above)
(3) Balance sheet preparation: Transfer posting daily balances corporate customers (from bank transfer on previous day - see above)
(4) Balance sheet preparation: Transfer posting daily balances bank customers (from bank transfer on previous day - see above)
(5) Posting of the payment item to the BCA checking account
(6) Posting of the payment item to the BCA bank account LCB
(7) Balance sheet preparation: Transfer posting balances corporate customers
(8) Balance sheet preparation: Transfer posting daily balances corporate customers
(9) Balance sheet preparation: Transfer posting balances bank customers
(10) Balance sheet preparation: Transfer posting daily balances bank customers

Posting a charge
For a charge, contrary to payments in the current account system, there is a one-sided posting not offset by another amount. For balance sheet preparation the
amount is handled together with other postings on the BCA account as in the previous example.
Current account system:
BCA checking account
(1) 20.—D

FI general ledger:
150200 (clear. 850110 (charges income)
corporate customers)
(1) 20.-- 20.-- (1)

(1) Posting of the payment item to the BCA checking account

Posting and post processing

An amount of 2,500.00 from payments is posted to a BCA checking account. In addition, there is an amount of 1,000.00 from payments in post processing,
identified by ‘[ ]‘. To keep things simple, the offsetting postings to a bank account LCB (or another BCA account) are not listed.
Current account system:

PUBLIC Page 97 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 BCA checking account
(1) 2,500.—C
(2) [1,000.—D]

FI general ledger:
150200 (clear. 198000 (clear.
corporate customers) payment transactions)
(3) 2,500.-- 2,500.-- (1) (1) 2,500.-- 1,000.-- (2)

150210 (clear.
corporate - post proc.)
(2) 1,000.-- 1,000.-- (4)

140200 (rec. 140210 (rec.

corporate customer) corporate - post proc.)
(4) 1,000.--

160300 (pay. corporate customer) 160210 (pay. corporate post proc.)

2,500.-- (3)

(1) Posting of the payment item to the BCA checking account

(2) New payment item in post processing to the BCA checking account
(3) Balance sheet preparation: Transfer posting balances current accounts posted company customers
(4) Balance sheet preparation: Transfer posting balances current accounts post processing corporate customers

1.4.5.6 Handling the Netting of Accounts

According to §10 RechKredV (German law), the balances of current accounts must be offset against one another if they are handled "as one account", meaning if
they have the same conditions. In the current account system, you can depict this by using the netting group. This is then taken into consideration accordingly for
general ledger transfer.
The netting group is a field in the account master data that you can enter as you wish. For transfer to the general ledger, the balances of all accounts with the
same entry in this field are totaled and identified as a payable or receivable. It is also possible to change the netting group. The appropriate adjustment postings
are then executed during the next balance sheet preparation.
To ensure correct netting, consider the following:
Netting can also take place cross-bank area. Note that in this case you must select all bank areas across which netting takes place for balance sheet
preparation.
The accounts to be netted must be assigned to the same general ledger group.
A further prerequisite for correct netting is that the company codes in FI-GL in which the accounts are transferred are the same.

Tip
You can find a report as a statement of the balances of all accounts pending for netting on the current posting date and a simulation of the
corresponding netting by choosing Information system → General ledger transfer → Netting: Overview of BCA accounts for netting.

1.4.6 Cash Concentration

Use
Cash concentration means that payment orders are generated either to be credited to or debited to accounts within an account
hierarchy you have created. You can, for example, define that an account must always have a certain minimum balance or that the
remaining balance on an account is always to be transferred to another account (for example, an investment account) at the end of
every month.

Example for the creation of a cash concentration hierarchy:

At the end of each month you want to transfer the amount exceeding a balance of USD 2,000 from two salary accounts (of a married
couple, for example,) to a third account. This third account serves as joint investment account. To do this you create a hierarchy with
the investment account as root account and the two salary accounts as subordinate accounts. Enter a maximum balance of USD
2,000 for each of the subordinate accounts.

PUBLIC Page 98 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 Prerequisites
Cash concentration is based on a tree structure that you use to define the hierarchy of the participating accounts. You must create this
hierarchy with a special hierarchy type for cash concentration.
On this subject, see:
Creating Account Hierarchies.

Scope of Functions
When you use the hierarchy type for cash concentration, you can clear or fill account balances. To do this, in the hierarchy you define
the required data for:
Ø The minimum balance to which an account is filled.
Ø The maximum balance, amounts above which are transferred to a superior account.
Ø A trivial amount limit for the transfer of funds.
When you clear the accounts, you have the following options:
You can transfer the turnovers of an account by value date to a superior account, separated into debit and credit.
· An account is filled to reach a minimum balance. The amounts needed for this are transferred from the superior account. Amounts of subordinate accounts
already transferred are taken into consideration.
· Amounts that exceed a specified maximum amount are transferred to the superior account.
· You can specify a trivial amount (minimum transfer amount) for a transfer to a superior account above which the transfer takes place.
· Before transfer, the amounts can be rounded off. You decide on the point above which amounts are rounded off.
· If required, can define a maximum and minimum balance specifically for each cash concentration.
· You can simulate the clearing of the accounts.
You can choose from the following types of carryforward:
Value date exact
If you choose value date exact, every item is transferred with the exact value date with which it was posted to the account. This means you can clear all
accounts below the root account to a value date-based balance of zero.
By posting date-based account balance
If you choose posting date-based account balance, the carry forwards are based on the current posting balance.
By value date-based account balance
If you choose value date-based account balance, the carry forwards are based on the value date balance. It is also possible to restrict up until which value
date the turnovers are included.
Split credit/debit value date dependent
If you choose Split credit/debit value date dependent, the turnovers per value date amount are transferred separately as the total of all debit postings and the
total of all credit postings for this day.
A base amount that is to remain on an account is first created by a corresponding posting during the first cash concentration run of this type. This base
amount is changeable and can be set during the next cash concentration run of the assigned hierarchy by an adjustment posting on the account.

In the Implementation Guide (IMG), you can restrict the above-mentioned selection by choosing Master Data → Account → Maintain
Account Relationship Types → Set Type of Cash Concentration Carryforward.

When you start a single run, you can define individual amounts that overwrite the settings from the account hierarchy for this run.

Process Flow of Cash Concentration

Cash concentration takes place as follows:
The system begins with an account on the highest (numerically speaking) hierarchy level, and processes all the accounts on this
hierarchy level. It then processes the account on the next hierarchy level, which means that the root account is processed last.
Amounts are transferred from the superior account to the next account below in the structure, if the balance falls below the minimum
amount. Amounts in excess of the maximum balance are transferred from an account to the next account above in the structure.
Account-specific overdraft/credit limits are not taken into consideration. If you want such a limit to be taken into consideration, you must
specify it as minimum balance in the hierarchy.
For the transfer to a superior account, only those amounts are included that exceed the minimum transfer amount. For amounts
transferred from superior to subordinate accounts, only the minimum transfer amount of the subordinate accounts are taken into
consideration.
Once a hierarchy level has been worked through, the superior hierarchy level is processed.
Minimum and maximum balances (with the exception of the root account) are allowed to differ from the minimum and maximum
amounts in the following cases only:
· If you round off the carry forward amounts (which you can set up) the minimum and maximum amounts do not need to be matched.
· If a minimum transfer amount is specified, it is possible that a minimum balance is not reached or that a maximum balance remains exceeded. The system
only checks the defined minimum transfer amount after rounding off.
As a result of a cash concentration run, the system increases the date for the next due cash concentration run in the account master

PUBLIC Page 99 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 record.
Example for Cash Concentration

1.4.6.1.1 Cash Concentration (Example)

The carryforwards for cash concentration are as follows:

Account submitting Account receiving Transfer amount
1101 1107 1000.00
1100 1101 1000.00

After cash concentration, these accounts show the following balances:

Account Balance
1100 -500.00
1101 2,000.00 (= minimum balance)
1107 2,000.00 (= minimum balance)
1106 1,002.00 (> minimum balance due to minimum transfer amount)

1.4.6.1.2 Cash Concentration / Clearing Accounts

Prerequisites
Before you can run cash concentration (clearing accounts), you must define these accounts in a hierarchy of the hierarchy type Cash
Concentration (Creating Account Hierarchies).

Note that during the cash concentration run, the limit check for subordinate accounts is deactivated.

Procedure
1. Choose Periodic Tasks → Cash Concentration → New Run. To clear one account hierarchy, choose Single Run. To clear all
hierarchies in one or more bank areas, choose Mass Run.
The system displays a screen on which you can specify the selection criteria for the account hierarchies that are to be processed.
2. If you have chosen the mass run, you can select the hierarchies according to bank area and currency.
3. If you have chosen the single run, you can also specify the root account of the account hierarchy that is to be balanced. Using the
F4 help you can display all the root accounts for which a valid hierarchy exists.

Note:
To identify a hierarchy as due, the balancing posting date is always used as reference.
4. Specify the value date until which account movements on the subordinate accounts are to be included.
5. If you so wish, you can round off the carryforward amounts (rounding off point). Enter the point to which the rounding is to take place
from the right. The currency-specific number of digits after the decimal point applies.

Rounding to the 3rd place:

PUBLIC Page 100 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 USD 521.45 ® USD 521.00

USD 521.50 ® USD 522.00

USD 0.49 ® USD 0.00

ITL 123478 ® ITL 123500

6. You can overwrite the cash concentration amounts for the minimum and maximum balance, and the minimum transfer amount
specified in the hierarchy tree, as well as the base amount for an individual cash concentration run.
To do this, choose Amount Definitions and define the cash concentration amounts for the required accounts of the hierarchy tree.
You can choose Display Hierarchy to display the standard cash concentration amounts defined in the hierarchy.

If you wish to specify cash concentration amounts in a currency for which no places after the decimal point are defined, the system
may add two zeros to the amount. To avoid this, choose Enter as soon as you have specified the account number. The system then
interprets the amount in accordance with the account currency and processes the subsequently entered amounts correctly.
7. Choose Execute.

Result
The system displays a log indicating which carryforwards have been created. (Note: The log is set in the print spool. Depending on
whether or not the log is to be printed immediately, you must maintain the corresponding values in the user fixed values first).
If errors occur during a run, meaning that individual accounts have not been balanced, then you can balance these again (restart).

Creating a Cash Concentration Hierarchy (Example)

Following is an example to explain the functions of cash concentration.

Creating a hierarchy
· At the end of each month you wish to transfer the amount exceeding a balance of USD 2,000 from two salary accounts (of a married
couple, for example) to a third investment account.
¡ To do this you create a hierarchy with the investment account as root account and the two salary accounts as subordinate accounts.
Enter a maximum balance of 2,000 for each of the subordinate accounts.
· On certain key dates you wish to completely transfer the balance of an account A to another account B.
¡ To do this you create a hierarchy with account B as root account and account A as subordinate account. Specify a maximum balance
of 0 for the subordinate account A.

Process flow and result of a cash concentration run

The carryforwards for cash concentration are as follows:

Account submitting Account receiving Transfer amount
1101 1107 1,000
1100 1101 1,000

After cash concentration, these accounts show the following balances:

Account Balance
1100 -500,
1101 2,000 (= minimum balance)
1107 2,000 (= minimum balance)
1106 1,002 (> minimum balance due to minimum transfer amount)

PUBLIC Page 101 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.4.6.1.3 Simulating Cash Concentration
Choose Periodic tasks
® Cash concentration ® New run ® Single run or mass run.
Specify the account hierarchy and the other settings as for a cash concentration run (see
Cash Concentration / Clearing Accounts).
Activate the selection field Simulation run.
Choose Execute.

Result
You receive a list showing the carry forwards that would have been created. You can call up the application log by choosing Periodic tasks → Application log →
Cash concentration.

1.4.6.1.4 Cash Concentration: Restarting a Run

Use
If errors occur during a cash concentration mass run because individual accounts could not be cleared, (for example, because they
were not active), these are initially locked for further processing within the balancing tasks (for example, account balancing).
In this case you can repeat the run for these accounts.

Procedure
1. Correct the cause of the error.
2. Choose Periodic Tasks → Cash Concentration → Restart. The system then selects the unprocessed accounts from the terminated
run. You can change only the amount definitions and the simulation indicator of the run.
It is also possible to restart simulation runs.

1.4.7 Tolerated Overdraft

Use
This function supports you in fulfilling banks' notification obligation regarding tolerated overdraft in accordance with the German
consumer credit law (§4 and §5). This law requires you, for example, to inform a customer if an account overdraft has been tolerated
for more than three months and the customer is a natural person.
If a bank tolerates the overdraft of a current account of a natural person and the account has been overdrawn for more than a certain
time period, in accordance with the consumer credit law the bank is required to inform the customer of the annual interest, incurred
costs and any other changes.
The current account system offers you the option of periodically monitoring accounts for which an overdraft of the external limit is
tolerated and which are, therefore, affected by this law.
If an external limit has been exceeded for a certain time period and if other criteria apply, (for example, the account involved belongs to
a natural person), it is possible to initiate notification of the customer. The system supplies the necessary data for notification by means
of an interface. The actual printing and special formatting of the letter is performed by a notification module that you create yourself.

Prerequisites
In the Implementation Guide (IMG) you must have activated Business Transaction Event "Tolerated Overdraft" for the notification by
choosing Basic settings ® Business Transaction Events / Event control → Activate function modules (P/S) SAP application.

Scope of Functions
On the current posting date for payment transactions the system checks if the external limit has been exceeded. This check produces
those accounts whose limit has been exceeded for a time period that you have specified. These are saved in a table and transferred to
the above-mentioned business transaction event. This business transaction event transfers the address data and other data relating to
the overdraft to a function module. You can format the transferred data to suit your requirements, much the same as for the bank
statement.

PUBLIC Page 102 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 During a run you can either notify your customers immediately or have them flagged for notification.
You can also have all affected accounts displayed.

Restrictions
Only limits and reference limits existing in the current account currency are included. Note this particularly for accounts affected by
currency changeover.
IHC payment orders with the status Posted Temporarily are not included. (Applies only to SAP In-House Cash.)

1.4.7.1 Executing a Monitoring Run

Use
You use the monitoring run (report RFBKOVR_CNTRL) to filter out accounts whose holders need to be notified of an overdrawn external limit in accordance with the
consumer credit law.
Typically you schedule a monitoring run as background job. Suggestion: When defining the job, choose event SAP_BKK_ENDOFCHAIN as start date. Event
SAP_BKK_ENDOFCHAIN is an event supplied by SAP that the system triggers when end of day processing has been successfully completed.

Procedure
Choose Periodic tasks → Tolerated overdraft → New run.
Enter a bank area or an interval of different bank areas.
Specify a business partner category.
If required, enter details on 'Special business partner selections'.
Specify an overdraft period (generally 3 months).
The length of the overdraft period results from the total of the number of months and days you have specified. If the start of an overdraft period is not on a working
day, it is extended to the previous working day. The date of the last posting date-based end of day balance is set as end of the overdraft period, meaning the date
directly before the current posting date for payment transactions.
Specify checks per account for the period:
No payment items with process

Here you can exclude accounts with turnovers resulting from a certain process. In the current account system, a process corresponds to a technical
operation that leads to the creation of payment items and payment orders. The process specified in the item or order represents the origin (for
example, the item was created by an account closure). If you do not enter any details here, all accounts on which at least one payment item of any
kind was posted in the overdraft period will be excluded from notification.

No change of the external limit

Here you can switch on or off whether the system is to perform a check regarding the change of the external limit. If you set the indicator, the system
removes all accounts from the monitoring run whose external limit has not only been exceeded, but whose limit has also changed during the
specified period.

01. Specify whether you wish to create a notification for the determined accounts or if you wish to flag them for notification.
For more information on these two notification options, read
Executing Notification.
Start the run.

Example
You want to check the accounts of all bank areas whose account holder is a natural person and whose external limit, based on the respective current posting date
for payment transactions, has been overdrawn at least three months.
An account is only to be flagged if the external limit has not been changed within the last three months and no payment item has been posted except the item
created by account balancing.
01. Do not enter a bank area, because if these fields remain blank, the system performs the run across all bank areas.
02. As business partner category, specify 'Natural person'.
03. As overdraft period, specify '3 months’.
04. You specify the check that ensures that no payment items other than balancing items have been posted to the account during the overdraft period by means of
the process of a payment item. You have two options for specifying the check.
Option 1: You individually list all processes in the dialog box 'Multiple selection' (except the processes 'Account balancing' (0090) and 'Account balancing
reference account' (0092).
Option 2: You indirectly list the processes by excluding the individual values 'Account balancing (0090) and 'Account balancing reference account' (0092)
using the pushbutton 'Complex selections' (F7) in the dialog box 'Multiple selection'. (You must specify these two individual values in the window section '....but
not').
You define the same check with both options: The accounts of natural persons that have been overdrawn for three months but on which payment items have
been posted in those three months that were not balancing items are not flagged for notification.
05. Specify that the external limit for an account may not have changed during the overdraft period.
06. Specify that accounts are to be flagged for notification.
07. Start the run.

Result
If the run was successful, using the menu option Periodic tasks → Tolerated overdraft → Notification, you can create a list of the flagged accounts and choose
those for which you want to have the system initiate notification and forward information to the notification module.

PUBLIC Page 103 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 1.4.7.2 Executing Notification
Use
You have two different options for executing notification.
01. You perform notification at the end of the monitoring run, meaning that in your specifications for the monitoring run you selected the option 'Execute notification'.
After a successful run, all accounts are then given the notification status 'notified'.
02. You have the accounts to be notified flagged for notification during the monitoring run, meaning that in your specifications for the monitoring run you selected the
option 'Flag for notification'. After a successful run, all accounts are then given the notification status 'flagged for notification'. Then you can analyze the flagged
accounts by choosing Periodic tasks → Tolerated overdraft → Notification, and execute notification as necessary. Only then are the selected accounts given
the notification status 'notified'.

Prerequisites
In the Implementation Guide (IMG) you must have activated Business Transaction Event
"Tolerated Overdraft" for the notification by choosing Basic settings ® Business Transaction Events / Event control ® Activate function modules (P/S) SAP
application.

Procedure
If you chose option A, notification has already been completed as part of the monitoring run. Nothing else needs to be done.
If you chose option B, the overdrawn accounts have only been flagged for notification during the monitoring run and you still have to do the following:
01. Choose Periodic tasks → Tolerated overdraft → Notification.
This gives you a list of accounts to be notified in accordance with your specifications.
02. Choose Notify, to transfer the selected accounts to the business transaction event.

In the list of accounts to be notified, the processing status is displayed by a traffic-light symbol.

Notification possible.
Indication that you were already in the detail display.
Accounts not notified, as the business transaction event recorded an error.
No traffic-light
Notification has been executed.

1.4.7.3 Displaying Tolerated Overdrafts

Use
The overview provides you with information on the accounts whose external limit has been exceeded during a certain time period.

Procedure
1. Choose Information System → Tolerated Overdrafts.
2. Enter the number of the tolerated overdraft monitoring run.
3. Specify the bank area and the monitoring status.
4. If required, enter the start and end dates of the overdraft.
5. Choose Execute.

Result
The system displays the overview list of all accounts in accordance with your selection criteria.

1.4.8 Changing Business Partners

Use
You can replace account maintenance officers, bank statement recipients, or business partners in user-defined roles by one or more
different business partners in the same roles for selected accounts.

Prerequisites
The selected accounts must have the Active status, and the new business partners must already be created in the roles

Procedure
1. Choose Periodic Tasks → Master Data Changes → Change Business Partner.

PUBLIC Page 104 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 2. Limit the accounts for which you want to change business partners. You can do this using bank area, account currency, account
number and/or product.
3. To replace the business partner with the same other business partner in all selected accounts, enter the business partner role, the
previous business partner and the new business partner in this role on the Simple Conversion tab page, then choose Execute.
4. To replace the previous business partner with different, new business partners in the selected accounts, enter only the business
partner roles and the previous business partner in this role on the Extended Conversion tab page, and choose Execute.
5. All accounts of the previous business partner in this role are displayed in a list. To limit the accounts for the first new business
partner in this role, select Set Filter and enter the filter criteria.
The list is limited in accordance with the filter criteria entered.
6. Select Replace Business Partner and enter the new business partner for these selected accounts.
7. Repeat these steps for all new business partners.

Result
You have replaced the previous business partner with one or more new business partners in all accounts.

Example
If account maintenance officer A leaves the company, or if the company is restructured, the account balance has to be distributed to
one or more other account maintenance officers. You can do so with this function without having to change each account separately.

1.5 Information System

Purpose
The information system is used to evaluate the extensive data basis online and to display the information in manageable units on the
screen. If, for example, you require an overview of the balances of a certain bank area for your statistics or strategic planning, you can
use the Information System to obtain this overview.
The main data basis of the information system comprises the accounts and their turnovers and administration. To display or evaluate
the data from the database you use special ABAP programs known as reports. For more information on reports, see the documentation
Working with Reports.
In the current account system, the Information System provides an effective, wide range of reports for the following areas:
· History of the individual conditions, standard conditions, and condition assignment
· Balance list and balance list by key date
· Overdraft list
· Account locks
· Check locks (only applies for banks)
· Interest scale
· Limit overview
· Individual conditions
· Tolerated overdrafts
· Account overview for the currency changeover
· Accounts for review
· Holds
· Reference accounts
· General ledger transfer
The following describes the basic characteristics of the Information System with regard to the current account system. The special
report features are explained in each document on the respective report. For more information, choose the Program Documentation
button when you call up the report.
You can analyze each area as often as required. However, note that under normal circumstances, it is advisable to only create the lists
in certain situations (for example, end-of-day balancing is complete). Typically, their creation is planned for each batch job. These lists
are created to enable the evaluation of the data created in this component. This supports repetitive standard evaluations and also
reports with a specific purpose.

Integration
The Information System was created with the SAP List Viewer. The SAP List Viewer standardizes and simplifies the use of lists in the
SAP System. A uniform interface and list formatting is available for all lists. It offers convenient options for the dynamic creation of your
own layouts.
See also:
SAP List Viewer (ALV): Classic

Scope of Functions

PUBLIC Page 105 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The most important functions of the SAP List Viewer include showing/hiding fields, resorting, and displaying totals as you require. You
can save your settings for the field selections, which means that the lists are predefined next time you call them up. You can also use
the List Viewer to create your own reports and lists, with standard formatting of all lists.
A few of the important functions of the SAP List Viewer follow as examples:
· Setting up layouts
Layouts enable you to change the display form of your lists. You can, for example, select the fields you want displayed or change the sequence of the fields
as required. You can also adjust the width of the columns to suit your requirements.
· Sorting
You can sort the report lines according to one or more report columns either in ascending or descending order.
· Set filter
You can only display the lines that fulfill certain criteria in one or more columns.
· Calculating totals and subtotals.
You can display totals or subtotals in the list for one or more selected columns..

Note on dynamic selections:

This release does not include dynamic selections for the definition of a variant. However, regardless of the variant, the last dynamic
selections are saved per report and user until the next entry of new dynamic selections. This applies both for the field selection and
for the field contents.

Restrictions
These specifications do not apply to the Information System for the general ledger transfer. In this case, the selection criteria and
evaluation options are different, as their format has technical differences.

1.5.1 Creating Condition Histories

Use
You need a complete statement of the condition changes for auditing purposes. These reports enter and display conditions even if they
have been deleted or have not yet been used. This enables you to create a complete condition history for auditing purposes, which
does not omit any details.

Procedure
The reports document the history for the standard and individual conditions, as well as for the condition assignments. In addition, the
reports evaluate the document file. You can generate the histories in the variant with the SAP List Viewer to archive the data.
1. Choose the report you require under Information System -> Condition History:
¡ Individual Condition History
¡ Standard Condition History
¡ Condition Assignment History.
2. To extend the condition changes (to be checked) to a date in the past, overwrite the defaulted current date and enter an earlier
date.
The system evaluates all change documents from the specified time.
3. You can restrict the selection as follows:
¡ Individual conditions: To a bank area, to a user who made a change, or to a document number
¡ Standard conditions: To a condition area, to a user who made a change, or to a document number
¡ Condition assignment: to condition area, condition group category and condition group, to a user who made a change, or to a
document number.
4. Choose Execute.
The system displays an overview of all changes from the selected time and the additional restrictions.
5. Choose Display Document.
The system displays a formatted change, which is recorded in this change document.
To archive the change history, you can choose the more compact Display in List Viewer.

1.5.2 Displaying the Balance List

You can use the balance list to create an overview of the clearing results of selected accounts. You can use the balance list to plan the
strategy across bank areas, or for checking the balancing of individual accounts.

PUBLIC Page 106 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.
 The SAP list viewer enables you to design the list layout of the balance list to suit your own requirements.

Prerequisites
Choose Information System →Balance List to display the balance list.

Procedure
1. Specify one or more bank areas.
2. Specify one or more account currencies.
3. Specify one or more account numbers.
4. Select a business partner category.
5. Enter the name of the account maintenance officer or the account holder.
6. Enter the business partner key.
7. Set the indicator that specifies that the balance list is to contain no accounts whose balance is zero.
8. Set the indicator that specifies whether the turnovers on the credit side during the last month are to be displayed for each account.
9. Enter a balance, or a balance interval and specify the currency.
The system displays only accounts whose balance meets this selection requirement.
10. Specify the display variant.
11. Choose Execute.

If you use Dynamic Selections you can also design the account selection to suit your own requirements. For more information, see
Information System.

Result
The system displays the balance list of the selected accounts.

1.5.3 Balance List by Key Date

Use
You can use the report Balance List by Key Date (RFBKBAL1_VAL) to create an overview of the balances for selected accounts. You
can use the balance list, for example, for strategy planning within your bank area or to check individual account balances.

Scope of Functions
This report contains all functions that are available in the report Balance List (RFBKBAL1). However, with this report you can also enter
a key date for the selection.
For more information about the Balance List report, see Displaying Balance Lists.
.

PUBLIC Page 107 of 107

© 2013 SAP AG or an SAP affiliate company. All rights reserved.