Overview of the C2BII concept

Under the C2BII methodology, we will create several “simulations” (in the program mentioned as “Targets of Impact”) of values that affect the Investment plan under examination. If you know what an accounting ledger looks like, and what information it contains (lines of data, each with data for date, sum of debit, sum of credit and balance) then you already are very close to what a “simulation” is all about. However keep in mind that, even though solid understanding of accounting principles is required (at least for the set-up process - not really required in the data entering phase), this is not an accounting program, and we will not create accounting entries. At least not in the form you know them so far.

Step 1

Let us consider the evaluation of an investment plan. We are asked to invest a sum of money to create a new company. Our job is to calculate if the return of the investment is going to be greater than the amount invested, or not, and to what level. To that end, the first step is the collection of forecasted events (sales, purchases, expenses etc) from relevant sources. Up to this point there is no difference with what is being done so far, for the purposes of implementing NPV.

Picture that those forecasts are entered in C2BII, thru the help of two types of codes. The first one we will call it “Event Type”. An example of such a code could be: “Sales with 19% VAT and 60 Days of Credit to the Customer”. Thru that code relevant forecasts are entered into the system.

Now picture that the above “Event Type” is associated with several other codes, which we will call them “Analytical Lines”. One “Analytical Line” represents the money that the company will take out of its Banking account on the 25th day of the month after the month of the sale, in order to pay to the Government the VAT of the sale. That line (on its specific date and with its specific sum) populates the table that is the simulation of the company’s Bank account. Another “Analytical Line” represents the money that the company will receive from its customer 60 days after the issuing of the invoice. Again that line (on its specific date and with its specific sum) populates the table that is the simulation of the company’s Bank account.

In that way we see how after the forecasts are entered in the system, we end up with a simulation of the Bank account, in which we can determine a daily balance. If the daily balance is in our favor we will calculate Interest Income (for example at 0.5%), and if it is against us we will calculate Interest Expense (for example at 6.0%).

Actually, there are going to be two Bank account simulations. One that represents the accounting balance and another that describes the movements, after taking into consideration each one’s banking value days (valeur). Interest is going to be calculated on the latter’s balance.

Other “Analytical Lines”, associated with the same “Event Type” code will represent the impact that this entry has on other aspects. These other aspects are represented in the system by relevant “simulations”. Examples are: “Profit & Loss”, “Item ledger”, “VAT” etc. In the same manner the entry thru that “Event Type” will populate the “Profit & Loss” simulation with data from all purchases, sales, salaries, ads, expenses etc. Then the data from the calculation of interest are going to be transferred to the “Profit & Loss” simulation. Now we have in the latter simulation the company’s result, without the inaccuracies associated with the “Net Present Value” methodology.

The above is a simplified version of the actual methodology and the employed codes, whose purpose is ease of understanding of the basic principle. Important elements, such as the “Impact Groups”, CCF’s, “Variation Factors”, “Distribution Factors” etc have been intentionally omitted.

Step 2

One can notice that there is a specific business plan that, every company, in every line of business, always needs to examine on a specific and recurring time frame. That is the annual budget. The only difference between it and the new machine scenario, mentioned in step 1, is that the budget is examined on a one year length time basis, while the new machine on the basis of whatever is the expected useful life of the machine (such as 5, or 7, or 12 years etc).

Presently the budget function is conducted in two stages.

The first stage is the entering of the forecasts of the primary incidents (sales, expenses etc) in the ERP. This is where the usefulness of these data ends. They are going to be used again next year for the creation of statistical reports such as “Sales: budget vs. actual” or “Expenses: budget vs. actual”.

In the second stage, the financial analysis department, in order to calculate the final forecast, which is the interest, takes all the entered data in the ERP and enters them for a second time in a spreadsheet of gargantuan size and unimaginable complexity. Let us not stand for long on the fact that in the 21st century the same job in performed twice instead of once, which we all know that it is contrary to all the practices that Information Technology stands for. Let us not even go long into the fact that we are not able to verify the calculated result, because of the unbelievable complexity of the spreadsheet, and the ease that a mistake can occur.

The most bothering part is the huge inaccuracy of the result. What is being done is that the total number of monthly payments and receipts are calculated thru a hugely inaccurate and full of assumptions methodology, and on the basis of that information the Budget Dept. establishes the average monthly balance of the bank account. Then on the basis of that average balance they calculate interest. In other words, they assume that on average everything happens on the 15th day of the month. We all know that this has nothing to do with reality (VAT on the 25th, salaries on the 30th, social security on the 31st etc).

Even if instead of entering the data for a second time in a spreadsheet, we enter them into C2BII, the process will be in a much shorter time frame, absolutely precise and easily verifiable. But of course the obvious move would be to export the data from the ERP in a TXT file or XML, which C2BII will read and import the data from it, thus materially shrinking the time needed to complete the job.

Step 3

The solution to the “Marketing problem” is the following:

The Marketer takes delivery of the file that contains the company’s annual budget. After the entry for the forecasted sales of the product in question is located, one changes the entry’s “Event Type” code from “Sales with 19% VAT and 60 Days of Credit to the Customer” to the new code “Sales with 19% VAT and 30 Days of Credit to the Customer” (which has already been created at program set-up). Also a change is done in the unit price from 4.40€ to 4.20€, and then one hits the calculate button.

Already pictured in the annual budget, one can find every product, from every Business unit, with its seasonality and planned promotions, as well as all planned expenses. The difference between the previously calculated result and the new one is the impact of the new proposed policy.

The new methodology does not create new workload. On the contrary, it speeds up existing tasks, and on the basis of the already performed work provides answers to new questions.

Along the same line of actions comes the solution to the “Treasury problem”.

Actually, the above mentioned solution (even though fundamentally correct) even though it is very fast and requires no knowledge and understanding of Accounting and/or Finance issues, it is not the fastest way to arrive at the result, and thus is not the suggested method of solving the problem. It is presented only for the purpose of understanding the mentality of the methodology. The suggested method of solving the problem involves the use of “Variation Factor” codes.

Suggested usage of the software

To better understand the suggested method of work, imagine that you are working in a spreadsheet or a word processor. After some time you save your work as “file1”. You continue working on the same file and after some time you save as “file2”. Again you continue working on the same file and after some time you save as “file3”. You put the “file3” on a diskette and you give it to a colleague. He saves it as “file4”. He continues further work on it, and after some time he saves it as “file5”. He continues work, and does some major changes which at some point he realizes that they have created unsolvable problems. He exits without saving and loads again “file5” or “file4” and continues working anew.

After the installation and activation of the software, someone with sound knowledge of Accounting and Tax issues (such a person can usually be found in the Accounting or the Financial Analysis Departments) creates the set-up files. When the set-up is completed, then that file is saved with a new name, and it is distributed to other persons in the company. Each recipient opens that file from the program installed on his PC, adds his work (entries etc) and saves it under a different name.