Professional Documents
Culture Documents
Direct Cash Flow With The SAP Liquidity Planner: Robert Bieber (Developer ERP FIN)
Direct Cash Flow With The SAP Liquidity Planner: Robert Bieber (Developer ERP FIN)
Direct Cash Flow With The SAP Liquidity Planner: Robert Bieber (Developer ERP FIN)
Contents
1 The Statement of Cash Flows
3.1.4 An Example
10
4 Summary
12
Page
Page
Cash flow information proper is rather provided by the direct method. This shows the cash receipts and
payments by uses and sources:
Cash inflows
From sales of goods
From sales of services
Cash outflows
To suppliers for raw material, services,..
To employees (wages etc)
To government for taxes
For other expenses
Operating Cash Flow
An often quoted disadvantage of the direct method is difficult data collection: Many accounting systems do
not collect information in such a manner as to support a straightforward creation of a direct cash flow
statement. The classical SAP Financials is no exception. In this paper we show, how we can use the actual
data part (sometimes called Liquidity Analysis or Liquidity Calculation) of the SAP Liquidity Planner to obtain
such direct operating cash flow information.
Page
Every actual (cash movement) line item in an accounting document creates (online) an LP line item that has
exactly one of those four dummy Liquidity Items. The first two of them are used for normal incoming and
outgoing movements. The last two are used for the exceptional case where all line items in a document are
actual. These movements balance, they do not describe real cash flow but rather shifting of funds from one
bucket into another. A summarized report over those LP line items would thus be quite boring, thus showing
two totals for cash in and out. To get the desired report, the initial dummy (in/out) items have to be replaced
by other Liquidity Items that really tell us uses and sources. For this task, there exist many assignment
programs that run (offline) over the LP line items and exploit different sources of information to automatically
find and assign proper Liquidity Items.
Page
If there is more than one non-actual line item, the picture is similar, with all of them pointing downwards:
If the low end line items are cleared with line items in other documents, this clearing information acts as a
glue that binds the objects of the individual documents into a bigger chain. Below you see an example that
consists of four documents with two line items each. One contains an actual line item (e.g. it is Bank Bank
Clearing), the three others lead further downward (e.g. they are Bank Clearing vendor).
Clearing (on the bank clearing account) glues the objects for the individual documents into a new object that
looks like the one for a single document: The cleared items are used for gluing and disappear, the other
items remain. In the example, the glued object corresponds to a single document with one actual line item,
three Vendor line items; the glue is still visible in the middle but otherwise has no effect any more.
Other line items in the attached documents might again be cleared and so the chain continues downward. In
the figure below we see the effects of further glueing with three invoice documents:
The resulting chain connects one actual line item with a couple of expense and tax line items.
Page
Both assignment mechanisms FLQAD and FLQAC exploit the fact that those low end line items of the
chains (e.g. Vendor, Customer, Revenue, Expense) contain some information that allows to determine the
Liquidity Items of the actual line item that is at the top of the chain - for which we have a line item in the LP
data base. Typically the chain gets broader towards the bottom (like in the figures), therefore we get a split
assignment with several Liquidity Items (1:N) rather than a unique assignment (1:1). One outgoing actual
item of 1000- might e.g. be split into 200- for material and 800- for services. The next figure summarizes the
principle behind FLQAD/C:
To get the Liquidity Items (split) for the top actual, the mechanism goes down the chain and collects the LI
information found in the low ends.What tells the mechanism whether a line item in an accounting document
is actual (top end) or to be evaluated for Liquidity Item (LI) assignment? - This depends on the GL account
(BSEG-HKONT) of that item: The most important set of rules for LP are thus the definitions of GL accounts
that are:
Actual (Top end)
Info (Low end for LI evaluation)
A second set of rules tells the mechanism how to derive Liquidity Items from the info line items. In this
paper, we wont discuss those derivation rules but rather concentrate on the actual/info GL definitions.
Each external house bank account of the company is maintained here and gets a GL (no. 113100 in this
figure). LP regards those GL accounts (table T012K) automatically as actual; no further settings are required
for them. Other GL accounts that represent cash but are not linked to an external bank account, have to be
entered in a special LP customizing transaction (FLQC4). This defines them as actual:
In some cases, it may even make sense to define the classical bank clearing accounts as actual. Often
they are sufficiently close to real cash to justify this (remember that cash flow is supposed to cover cash and
cash equivalents). And this setting has technical advantages, see section 3.3 below.
Page
Historically, transaction FLQAC was the first assignment mechanism to evaluate document chains. It stops at
the customer and vendor line items in payment documents. Thus it is unable to see the original invoices.
However, expense and revenue items in invoices usually contain crucial information for a detailed direct cash
flow statement: E.g. FLQAC would show all payments to vendors on a common vendor Liquidity Item, but
often wed rather like to distinguish between payments for services and for raw material.
Therefore SAP created FLQAD. This mechanism extends FLQAC and needs a refined classification of info
accounts: They are divided in intermediate and final info (details in note 614240). FLQAD performs a two
step assignment: The first step is exactly like FLQAC, where the chain (starting with the actual item) is
followed downward until an info account is reached. The corresponding line item is then evaluated and a
Liquidity Item is derived from it. Only if three conditions are met:
GL account in the line item is intermediate info
The line item is cleared
The Liquidity Item derived here is a buffer LI (select-option)
Then the chain continues downwards until a final info account is reached. This is then evaluated with a
second set of rules. If this evaluation produces a new Liquidity Item, the buffer item from the first step is
replaced. If however that 2nd part of the chain does not come to an end, or the LI evaluation does not give a
result, the assignment is to the buffer LI. The buffer LI has its name from the fact that it covers the remaining
amount in case the 2nd step is only partially successful.
Page
3.1.4 An Example
Consider the process where the vendor sends us an invoice, we post it and pay it with the payment program
(F110). On the next day, our bank sends us the bank statement and thus confirms our payment:
The FLQAD program starts at the actual (bank) line item and follows the chain (via bank clearing) until it
reaches the vendor line item in the (F110) payment document. This is evaluated with a first set of rules. Let
us suppose this gives us the Liquidity Item VENDOR and let us further suppose that this is a buffer item.
Vendor reconciliation accounts (except down payment) are natural intermediate info accounts. Therefore, the
program proceeds downward in the chain until it reaches the expense line items in the invoice. They are
evaluated with a second set of rules. If this evaluation is successful, i.e. if new Liquidity Items are found, the
outgoing cash amount is assigned to them. If only part of those expense line items give new Liquidity Items,
the final assignment is split between the buffer LI VENDOR and the new ones.
Here we do not reach any information GL. What Liquidity Items are assigned to both actuals? The
mechanisms (FLQAC and FLQAD) handle this like a direct cash transfer posted in one single document
(bank bank) and assign the default items for cash transfer from global data (FLQC2).
Now consider the case where several (N > 1) actual line items have a common link to several (M) info line
items.
This N:M pattern does not fit into LPs principle of individual assignment. There is nothing to tell the
mechanisms which part of the information belongs to the first actual, which one to the second and third. This
ambiguity is resolved by making the assignment not individually for each of the N (three) connected actual
line items, but rather for the whole group together. For performance reasons, the program does this
technically by picking the actual with the biggest amount as the representative item of the group. This
Page
representative is then virtually duplicated: One copy gets the group amount (sum of all actuals in the group)
and is connected to the info line items. This gives a normal 1:M chain that can be evaluated as usual. The
second copy gets a delta amount so that the sum of both copies is the original amount. This delta copy is
connected to the other actuals only. Thus, in the second branch we have a connection of N actuals w/o any
info, and the program assigns the cash transfer liquidity items to all of them. To distinguish this artificial,
technical cash transfer from the natural one discussed at the beginning of this section, there is the possibility
to maintain special technical transfer Liquidity Items in transaction FLQC13. The next figure illustrates this
artificial split of N:M into 1:M and an N transfer branch:
The N:M problem discussed here affects FLQAC and the first FLQAD assignment step; it is due to mass
clearing activities in the intermediate region between actuals and first information. If those mass clearings
are sufficiently regular (e.g. sometimes one has document pairs with same amount and opposite sign) there
is the possibility to use exit functions to cut them down into more digestible pieces. If successful, this can
dramatically improve LP performance and data quality.
N:M effects may also occur in the second FLQAD assignment step, e.g. if there are invoices that have
several vendor items which are cleared by different payments. Consider the example of two flows connected
at the invoice level:
This does not lead to an assignment on the default cash transfer items; rather the total LI information from
expense is shared proportionally between both cash flows: Both get a split assignment with all three Liquidity
Items L1, L2, L3. In general, such sharing produces assignment results that are hard to explain.
Page
10
And without any side branches and connections to other pyramids: It is no problem, if in the end several
thousand final info items are linked to one actual. But all occurrences of N:M patterns, both in the first and
second assignment step, cause a decline in performance and in quality of Liquidity Item assignment.
This relationship of original data quality and LP results is a special case of the universal garbage in
garbage out problem in IT: If the original business processes are mapped into the system in a clear and
consistent manner, the resulting data are well suited to give further information. If however the initial mapping
is kind of messy, we cannot expect to get real value out of it.
Before the introduction of LP in an enterprise, the posting in an FI system was the final step in a business
process, the only exception being information drawn from individual line items, e.g. for Cash Management
forecast or Controlling. For those line item based applications, the structure of documents and clearings is
not important. Thus it was e.g. no problem if several logically independent documents were posted as one
physical document. For LP, such glued documents are normally disastrous, as they lead to a mingling of
cash flow chains:
Therefore, one task in an LP project is to make the accounting people aware of the fact that their postings
are not the very last step of a business process: Rather, LP comes behind and wants to derive information.
As a matter of experience, it is quite difficult to change posting patterns and habits in an enterprise. Thus one
often has to take posting habits as given and try to make the best out of them. If their quality does not directly
match the original expectations for LP, there are two options:
The first is to use plastic surgery in the form of exit functions to cut the messy bundles into neat chains and
pyramids. This is not always possible one needs certain regular patterns which the exits can exploit. This
requires much skill and understanding. Moreover the more elaborate and complex the exit functions are, the
more unstable they might become.
The second option is to shorten the LP chains by narrowing the intermediate layers: This should reduce the
number of side connections and result in neatly isolated pyramids. One should be aware of the side effect: It
might change the scope of LP (what are cash equivalents) and reduce the granularity of Liquidity Items.
Page
11
If the bank clearing account is intermediate, we have a complex N:M situation. If it is however actual, this
bundle falls apart, and we have N simple actual transfers (the documents: bank bank clearing). They get
dummy transfer items (FLQC2) on both sides (LP update should be by posting date to make sure that both
sides have the same date and thus balance). Besides, there remains a straightforward 1:M situation.
Thus this is a boost for performance. The drawback is a loss of information. Thus, unless the information can
be recovered with the help of cleverly designed exit functions, such a change has to be accompanied by a
change in the structure of Liquidity Items for direct cash flow: Less granularity, less details. A typical example
for this is wages for employees: Instead of detailed information on various wage types, one just gets wage
outflows to employees in one LI.
4 Summary:
In this paper we showed how Liquidity Planner (LP) can be used to obtain the data for a statement of
cash flows (direct method). The LP approach is heuristical: The challenge is to make best use of the data
buried in the accounting documents and clearing. Depending on the quality of those raw data, one is
sometimes forced to make concessions; and choose the granularity of the items for the direct cash flow
statement less detailed than originally anticipated. Sometimes one can use exit functions to improve raw
data so that one gets a better LI structure.
Page
12