manual LP - inglês.pdf

12
Robert Bieber (Developer ERP FIN) Direct Cash Flow with the SAP Liquidity Planner March 03, 2007 Attachment to SAP note 412605 Copyright 2007 SAP AG. All Rights reserved

Transcript of manual LP - inglês.pdf

Page 1: manual LP - inglês.pdf

Robert Bieber(Developer ERP FIN)

Direct Cash Flow with theSAP Liquidity Planner

March 03, 2007

Attachment to SAP note 412605

Copyright 2007 SAP AG. All Rights reserved

Page 2: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 2

Contents

1 The Statement of Cash Flows 3

1.1 Structuring Cash in and out 3

1.2 Operating Cash Flow: Indirect vs. Direct 3

1.3 Cash Flow Statement vs. Cash Position 4

2 The Liquidity Planner Approach 4

2.1 Individual vs. Summarized Information 5

2.2 Online vs. Offline 5

3 Document Chains and Clusters 5

3.1 How LP acquires information 6

3.1.1 Document Chains 6

3.1.2 Actual GL Accounts 7

3.1.3 Info GL Accounts 8

3.1.4 An Example 9

3.2 The N:M Problem 9

3.3 How to build Pyramids 10

4 Summary 12

Page 3: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 3

1 The Statement of Cash FlowsCash is King. The value of an enterprise is the total of discounted cash flows that it is going to return to itsowners. Whenever investors, creditors and other stakeholders want to judge a company, they need to knowhow much cash it generates now and make an estimate for the future. The information about past andcurrent cash generation can be obtained from a statement, that is called the ‘Statement of Uses and Sourcesof Funds’ or ‘Statement of Cash Flows’. Sometimes there are legal or regulatory requirements thatdetermine the form of that statement. The typical structure is:

Cash balance at the beginning of the PeriodCash in and out during the Period

Cash balance at the end of the Period

Periods may be years, quarters, months or (typically for internal purposes only) even weeks or days. ‘Cash’in the sense of this statement is the money that’s on the bank current accounts of the enterprise. Often oneincludes cash equivalents: Short time highly liquid investments that are readily (say within a couple of days)converted into cash.

1.1 Structuring Cash in and out

To asses a company’s health it is not quite enough to know that it had a positive net cash flow during theperiod; this might come from the sale af assets that need to be leased back later. Rather, one needs to getmore detail information on the uses and sources of cash. The highest level consists of three classes. Cashreceipts and payments resulting from:

Operating activities

Investing activities

Financing activities

Each class is split into items to give more details and thus better information. Operating activities relate to thenormal business of a company; typical items are cash inflows from sales of goods or services and cashoutflows to suppliers for inventory. Investing activities are there to safeguard and expand operations, withtypical items: Cash outflows to purchase property, plants and equipment and cash inflows from sellingunused equipment. Financing activities provide the money for the other two areas, e.g. with an item for cashinflow from taking loans.

The detail structure for investing and financing activities is usually ‘direct’: We have items that tell us theuses and sources of cash by name and in a direct manner. In contrast, for the operating activities there aretwo general patterns:

1.2 Operating Cash Flow: Indirect vs. Direct

There are two main methods to report cash flows from operating activities: In the quite popular indirectmethod (or reconciliation method) one starts with the net income (as reported in the Profit and Lossstatement) and lists the adjustments (e.g. increase in accounts receivable) that comprise the difference ofnet income and operating cash flow:

Net Income (P&L)

Adjustment 1, e.g. changes in A/R

Adjustment 2, e.g. changes in A/P

Operating Cash FlowFrom the structure it is obvious, that this method explains the difference between net income and net cashflow from operating activities, rather than operating cash receipts and payments themselves. This is stilluseful information for investors, as it might show them that the company achieved to generate a reasonablenet income only by accumulating huge inventories, resulting in a small or even negative cash flow.

Page 4: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 4

Cash flow information proper is rather provided by the direct method. This shows the cash receipts andpayments 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 donot collect information in such a manner as to support a straightforward creation of a direct cash flowstatement. The classical SAP Financials is no exception. In this paper we show, how we can use the actualdata part (sometimes called Liquidity Analysis or Liquidity Calculation) of the SAP Liquidity Planner to obtainsuch direct operating cash flow information.

1.3 Cash Flow Statement vs. Cash Position

To repeat; the cash flow statement for a period has the structure:

Cash balance at the beginning of the period

Cash in and out during the period

Cash balance at the end of the period

At a first glance, this looks almost like the Cash Position report in Treasury, that is prepared every morningafter today’s bank statements have been imported:

Cash balance at the beginning of today

Cash in and out today (expected)

Cash balance at the end of today (expected)The main difference is, that the cash flow statement is about actual cash only, whereas cash positioncombines actual and expectation. Moreover, the cash position has to be reported for every single bankaccount, in order to support cash concentration or balancing of gaps and surplus. Such a reporting by bankaccount is not required for the cash flow statement.

2 The Liquidity Planner ApproachThe SAP Liquidity Planner (LP) is a collection of products to support Liquidity Planning (e.g. on a rollingmonthly basis) in an enterprise:

Page 5: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 5

The LP functionality is spread over several systems:

Planning and reporting in the Business Warehouse

Functions to determine actuals (cash already received or spent) and forecast, structured by uses andsources in the enterprise core system.

The items that describe those uses and sources are called Liquidity Items (LI). In this paper we focus onthe actual part of LP.

2.1 Individual vs. Summarized Information

In the statement of cash flows, we see summarized data, e.g. the sum of cash out to suppliers for thepurchase of raw material in the period. In case those data are questioned and have to be verified, it is usefulto have them on an individual level:

For every single cash movement (in or out) that is stored in the system, one would like to know the LiquidityItem that describes the source (incoming) or use (outgoing) of that movement. The relationship is typicallynot 1:1 but 1:N, i.e. one cash movement is split into parts that have different Liquidity Items. You know thissplit from your monthly credit card statement: There is a total amount deducted from your current accountthat is split into a variety of uses, e.g. for accommodation, flight tickets and a pair of new shoes.

The Liquidity Planner is designed to show such individual information; it splits and classifies every singlecash movement.

2.2 Online vs. Offline

A cash movement is posted in Financials. When do we see its uses and sources information? Most peoplewould prefer immediately, i.e. an online assignment of Liquidity Items. For performance reasons, this wouldrequire some kind of preparation in the system: Split and assignment information waiting to be attached tothe cash movement when this is posted. This approach is feasible; it was e.g. used in the late Cash BudgetManagement (TR-CB) application of SAP.

Liquidity Planner takes another approach: It does record cash movements online, but on ‘dummy’ LiquidityItems taken from customizing (transaction FLQC2: Global settings):

Every actual (cash movement) line item in an accounting document creates (online) an LP line item that hasexactly one of those four ‘dummy’ Liquidity Items. The first two of them are used for normal incoming andoutgoing movements. The last two are used for the exceptional case where all line items in a document areactual. These movements balance, they do not describe real cash flow but rather shifting of funds from onebucket into another. A summarized report over those LP line items would thus be quite boring, thus showingtwo totals for cash in and out. To get the desired report, the initial dummy (in/out) items have to be replacedby other Liquidity Items that really tell us uses and sources. For this task, there exist many assignmentprograms that run (offline) over the LP line items and exploit different sources of information to automaticallyfind and assign proper Liquidity Items.

3 Document Chains and ClustersMost customers use the automatic assignment mechanisms given by transactions FLQAC and FLQAD. Theyevaluate document chains and in this paper we focus exclusively on them.

Page 6: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 6

3.1 How LP acquires information

3.1.1 Document Chains

The LP assignment mechanisms FLQAC and FLQAD evaluate FI document chains. What is a documentchain? Here is the picture: An FI document with two line items is an object with two small handles (one foreach line item) and a link (for the document itself). If just one of both line items is actual (represents cash),we draw the document with the actual handle pointing upward, the other one downward:

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 aglue that binds the objects of the individual documents into a bigger chain. Below you see an example thatconsists of four documents with two line items each. One contains an actual line item (e.g. it is Bank – BankClearing), 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 thatlooks like the one for a single document: The cleared items are used for gluing and disappear, the otheritems 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. Inthe 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 7: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 7

Both assignment mechanisms FLQAD and FLQAC exploit the fact that those low end line items of thechains (e.g. Vendor, Customer, Revenue, Expense) contain some information that allows to determine theLiquidity Items of the actual line item that is at the top of the chain - for which we have a line item in the LPdata base. Typically the chain gets broader towards the bottom (like in the figures), therefore we get a splitassignment with several Liquidity Items (1:N) rather than a unique assignment (1:1). One outgoing actualitem of 1000- might e.g. be split into 200- for material and 800- for services. The next figure summarizes theprinciple behind FLQAD/C:

To get the Liquidity Items (split) for the top actual, the mechanism goes down the chain and collects the LIinformation found in the low ends.What tells the mechanism whether a line item in an accounting documentis 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 accountsthat 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 thispaper, we won’t discuss those derivation rules but rather concentrate on the actual/info GL definitions.

3.1.2 Actual GL Accounts

In SAP Financials, there is transaction FI12 to maintain the house bank accounts:

Each external house bank account of the company is maintained here and gets a GL (no. 113100 in thisfigure). LP regards those GL accounts (table T012K) automatically as actual; no further settings are requiredfor them. Other GL accounts that represent cash but are not linked to an external bank account, have to beentered 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. Oftenthey are sufficiently close to real cash to justify this (remember that cash flow is supposed to cover cash andcash equivalents). And this setting has technical advantages, see section 3.3 below.

Page 8: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 8

3.1.3 Info GL Accounts

We start our discussion with the chain assignment FLQAC, which has one step and only one set of infoaccounts (FLQAD has two). As described in note 614240, all GL accounts that fall into one of the followingclasses are considered info:

Reconciliation accounts for Vendor/Customer

Profit and Loss accounts (no balance sheet sign in GL master data)

Accounts that are defined ‘info’ in LP customizing (FLQC7) or settings (FLQINFACC)

Whether the LP info account maintenance is in customizing or settings depends on a flag set in theassignment customizing (FLQC13). In this info account maintenance one can also attach default LiquidityItems. This is the simplest rule for LI derivation. For this reason, even ‘automatic’ (e.g. P&L) info accountsare often maintained in FLQC7/FLQINFACC, with default LI.

In case a GL has been defined both actual and info, we have the rule: Actual beats info. Therefore, all GLaccounts in the company code fall into one of the three classes:

Actual = top end of FLQAC cash chains

Others = in between or not at all touched by cash chains

Info = low end of FLQAC cash chainsNote that clearing on line items with actual accounts (top end) and line items with info accounts (low end)does not enhance the chains; we have absolute end points. The following figure shows two examples forsuch FLQAC chains:

Historically, transaction FLQAC was the first assignment mechanism to evaluate document chains. It stops atthe 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 cashflow statement: E.g. FLQAC would show all payments to vendors on a common vendor Liquidity Item, butoften we’d 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 infoaccounts: They are divided in intermediate and final info (details in note 614240). FLQAD performs a twostep assignment: The first step is exactly like FLQAC, where the chain (starting with the actual item) isfollowed downward until an info account is reached. The corresponding line item is then evaluated and aLiquidity 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 asecond set of rules. If this evaluation produces a new Liquidity Item, the buffer item from the first step isreplaced. If however that 2nd part of the chain does not come to an end, or the LI evaluation does not give aresult, the assignment is to the buffer LI. The buffer LI has its name from the fact that it covers the remainingamount in case the 2nd step is only partially successful.

Page 9: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 9

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 itreaches the vendor line item in the (F110) payment document. This is evaluated with a first set of rules. Letus 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, theprogram proceeds downward in the chain until it reaches the expense line items in the invoice. They areevaluated with a second set of rules. If this evaluation is successful, i.e. if new Liquidity Items are found, theoutgoing 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.

3.2 The N:M problem

In the example above we saw how FLQAD evaluates a straight chain that spans from actual to final infowithout any side branches. There are other patterns, too. Consider two bank statement documents (one in,one out), linked via bank clearing. This represents Cash Transfer between two different bank accounts and isshown in the following figure:

Here we do not reach any information GL. What Liquidity Items are assigned to both actuals? Themechanisms (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 lineitems.

This N:M pattern does not fit into LP’s principle of individual assignment. There is nothing to tell themechanisms which part of the information belongs to the first actual, which one to the second and third. Thisambiguity is resolved by making the assignment not individually for each of the N (three) connected actualline items, but rather for the whole group together. For performance reasons, the program does thistechnically by picking the actual with the biggest amount as the representative item of the group. This

Page 10: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 10

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. Thesecond copy gets a delta amount so that the sum of both copies is the original amount. This delta copy isconnected to the other actuals only. Thus, in the second branch we have a connection of N actuals w/o anyinfo, 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 possibilityto maintain special technical transfer Liquidity Items in transaction FLQC13. The next figure illustrates thisartificial 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 massclearing activities in the intermediate region between actuals and first information. If those mass clearingsare sufficiently regular (e.g. sometimes one has document pairs with same amount and opposite sign) thereis the possibility to use exit functions to cut them down into more digestible pieces. If successful, this candramatically 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 haveseveral vendor items which are cleared by different payments. Consider the example of two flows connectedat the invoice level:

This does not lead to an assignment on the default cash transfer items; rather the total LI information fromexpense is shared proportionally between both cash flows: Both get a split assignment with all three LiquidityItems L1, L2, L3. In general, such ‘sharing’ produces assignment results that are hard to explain.

3.3 How to build Pyramids

When the actual data part of an LP project is started in an enterprise, one normally has two things given:

A catalogue of Liquidity Items, for the desired structure and granularity of direct cash flow.

Posting patterns and habits in the SAP accounting system

Typically, people in the company have used SAP financials for years, and have developed certain ways ofmapping business processes into documents and clearings. Sometimes, this is standardized across thecompany. Sometimes each user has his or her own preferred habits of doing things. This is made possibleby the many degrees of freedom that the SAP financials system offers: With transactions FB01 and FB05you can create all kinds of documents and clearings; with balance zero being almost the sole restriction.

The problem for LP is, that this freedom can lead to patterns that look quite different from a straightforwardchain. The ideal pattern for LP is the pyramid, i.e. one actual item linked to one or more intermediate infoand each of them again linked to one or more final info:

Page 11: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 11

And without any side branches and connections to other pyramids: It is no problem, if in the end severalthousand final info items are linked to one actual. But all occurrences of N:M patterns, both in the first andsecond 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 andconsistent manner, the resulting data are well suited to give further information. If however the initial mappingis 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 businessprocess, the only exception being information drawn from individual line items, e.g. for Cash Managementforecast or Controlling. For those line item based applications, the structure of documents and clearings isnot important. Thus it was e.g. no problem if several logically independent documents were posted as onephysical document. For LP, such glued documents are normally disastrous, as they lead to a mingling ofcash flow chains:

Therefore, one task in an LP project is to make the accounting people aware of the fact that their postingsare 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 oneoften has to take posting habits as given and try to make the best out of them. If their quality does not directlymatch 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 andpyramids. This is not always possible – one needs certain regular patterns which the exits can exploit. Thisrequires much skill and understanding. Moreover the more elaborate and complex the exit functions are, themore unstable they might become.

The second option is to shorten the LP chains by narrowing the intermediate layers: This should reduce thenumber of side connections and result in neatly isolated pyramids. One should be aware of the side effect: Itmight change the scope of LP (what are cash equivalents) and reduce the granularity of Liquidity Items.

Page 12: manual LP - inglês.pdf

SAP Liquidity Planner

2007 SAP AG. All rights reserved Page 12

We discuss the two intermediate layers separately:

Other intermediate GL accounts

The typical troublemakers in this group are the bank clearing accounts. In exceptional cases it may makesense to define them info accounts, but normally it is preferable to move them into the top layer, i.e. definethem actual accounts (FLQC4). Why? Consider a typical mass clearing of many bank statement items on abank clearing account:

If the bank clearing account is intermediate, we have a complex N:M situation. If it is however actual, thisbundle falls apart, and we have N simple actual transfers (the documents: bank – bank clearing). They getdummy transfer items (FLQC2) on both sides (LP update should be by posting date to make sure that bothsides have the same date and thus balance). Besides, there remains a straightforward 1:M situation.

Intermediate info accounts

Here the action of choice is to make them final. Normally this cuts dramatically the amount of data to beprocessed and evaluated:

Thus this is a boost for performance. The drawback is a loss of information. Thus, unless the information canbe recovered with the help of cleverly designed exit functions, such a change has to be accompanied by achange in the structure of Liquidity Items for direct cash flow: Less granularity, less details. A typical examplefor this is wages for employees: Instead of detailed information on various wage types, one just gets wageoutflows 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 ofcash flows (direct method). The LP approach is heuristical: The challenge is to make best use of the databuried in the accounting documents and clearing. Depending on the quality of those raw data, one issometimes forced to make concessions; and choose the granularity of the items for the direct cash flowstatement less detailed than originally anticipated. Sometimes one can use exit functions to improve rawdata so that one gets a better LI structure.