A true story about SAP, its CashFlow module and its inability to process “What if” scenarios, or even get the work done Part 1

A few months ago, I witnessed the following incident. I happened to be present, when SAP consultants, twenty days before the scheduled first live run of a new SAP installation in a major Greek company, were delivering to the users the CashFlow module, and were scheduled to train them in its use. We all know that SAP AG is the global leader in ERPs.

That company generates a sizeable percentage of its income from sales to super market chains. In Greece, super market chains practically almost never pay their vendors on time. When the agreed payment day arrives, they tell you that they are going to pay you after X number of days, only the Y% part of the debt, and it remains to be seen what is going to be done about the rest of the amount. And since they are such huge and important customers, they get away with it. This is not a treatment that they have in store only for that specific company. This is what they do to everyone. Actually, if we look at the whole picture, we will see that there are reasons (most of them valid) behind that behavior, and that super markets are not the villains they might seem at first glance. However, the fact remains that their payment patterns are highly erratic. The company wanted to create 4 categories of payments and collections in its CashFlow.

  • “Collection Class 1″: These are collections that are expected to happen more or less on time.
  • “Collection Class 2″: These are collections from super market chains, that follow erratic patterns.
  • “Payment Class 1″: These are the payments that must be done on time, or else there is a danger for business interruption. Examples are: Salaries, VAT, income Tax, other Taxes, payments to Government agencies, payments to key suppliers etc.
  • “Payment Class 2″: These are the payments that can be delayed, if such a need arises, without fear for business interruption.

The company has a constant need to run every week the following “What if” scenario:

  • If super market chain A delays its payments to us by XA days and pays only YA% of the amount owed, and
  • If super market chain B delays its payments to us by XB days and pays only YB% of the amount owed, and
  • If … If … If …

then

  • what is our CashFlow going to look like, on a present day plus six months (or more) horizon?
  • what will be our new Bank loan situation, on a present day plus six months (or more) horizon?
  • what kind of payment delay, are we might be forced to impose on vendors of “Payment Class 2”?

In the years before SAP, the job was being done thru spreadsheet, and the process had all the inevitable shortcomings that are associated with performing CashFlow on a spreadsheet. The company wanted to automate that process, and achieve accuracy and time efficiency.

Stick around, as we are going to see why this turned into a complete fiasco.

This entry was posted in CashFlow, Financial Analysis, Financial Analysis Method, Investment Plan Evaluation and tagged , , , , . Bookmark the permalink.

One Response to A true story about SAP, its CashFlow module and its inability to process “What if” scenarios, or even get the work done Part 1

  1. Pingback: A true story about SAP, its CashFlow module and its inability to process “What if” scenarios, or even get the work done Part 2 | CEO on Financial Analysis

Leave a Reply