Overview 
C2BII Method Outline The new method to conduct Financial Analysis (C2BII) has practically nothing in common with the stateoftheart before it (Net Present Value). For the purpose of understanding it, please: 1) Forget about discounting the forecasted cash flows into a Net Present Value. The new methodology does not work that way. The first step of the evaluation of an investment plan is the collection from relevant managers of the forecasts of what we expect to take place (sales, purchases, salaries, ads etc). So far nothing has changed from the previous state of the art. From that point on, everything will be handled differently. How we are going to work. The actions we will take are fundamentally close to what is being performed by basic accounting. For ease of understanding, imagine that we are evaluating a Business plan that has only one forecasted incident. Let’s say that it is a sale of a service. We are asked to calculate the “Profit or Loss” at Fiscal yearend. In the above scenario, we can easily create a simulation of the company’s accounting books (thru a spreadsheet) with the entries that will result from the forecasted sale. The Bank account’s simulation will have two entries. The first entry will represent the payment to the government for the sale’s VAT (outflow), and the second entry represents the collection from the customer (inflow). On that basis it is easy to establish a daily balance for the bank account, and accurately calculate the resulting “Interest Income” or/and “Interest Expense”. Those figures (Interest) will be moved to the simulation of the “Profit & Loss”, along with the impact from the forecasted sale, and thus we will have a fiscal yearend result that is 100% accurate and whose accuracy cannot be put into doubt, since what we have done so far is basically “good old fashion accounting”. The forecast creation process, by its nature, yields a result that has some (small or large) deviation from the figure that will actually materialize. Let’s say that our forecasts are ±X% accurate. If we process the forecasts, in order to determine the resulting profitability, with a method that is ±Y% accurate, the calculated profitability result will be ±(X+Y)% accurate. Or to put it in another way, one level of inaccuracy gets piled up on the other. So far, what we have done is, we have taken a forecast, and we have analyzed it into the incidents that will result from it, and thus have calculated thru basic accounting a result that is as accurate as the forecast it is based on. In other words, the ±Y% of the used methodology used to determine the final result (Fiscal Year End profit) is 0%. Now lets try to add more forecasts, and use the same method (simulation of accounting books) to determine the resulting profit or loss. The first problem that we will encounter is that after the addition of only a few forecasts, the Bank account simulation will have so many numbers, that we will practically get overwhelmed. And you can totally forget about being flexible enough to calculate “what if” scenarios, based on the work performed so far. But the main problem is that forecasts are always provided in a concentrated form (i.e. Sales of March) and not on a daily basis. So, even though so far we have seen how we can (in principle) have a calculation of profitability that is 100 % accurate, in practice there are huge obstacles to overcome. This is where the C2BII methodology comes in, to provide tools, so that we can calculate a result that is meaningful, dependable and 100% accurate. What we will achieve. What we are going to do (on the basis of the supplied forecasts) thru the new methodology is: 1) Analyze each forecasted number into a plurality of values that simulate the daily accounting impact (not accounting entries) that is expected to take place, should the forecasts actually get realized. Every one of these numbers is characterized by the specific date on which it is expected to occur, and by what aspect of the accounting books it is going to affect. 3) Calculate accurately each day’s “Interest Expense” or “Interest Income”, with applicable (different) rates, and incorporate those figures into the simulation of the company’s accounting books (Profit & Loss). 4) Calculate (and incorporate into the simulation) each “Fiscal Year’s” financial result (profit or loss), “Income Tax”, “Reserve Funds”, “Dividends Payable” and “Retained Earnings”. 5) In the end, and after all the needed results are calculated, we will isolate two groups of very specific numbers. They are the ones that portray (on the basis of the specific date that they are expected to happen), How we will achieve that. To begin with, we will not create accounting books and accounting entries. At least not in the way you might already be familiar with them, thru your company’s ERP. The following is a first (basic) listing of some of the tools that we are going to use. a) Impact Targets Impact Targets In the C2BII methodology, there are 5 basic simulations that describe what is expected to happen in the company’s accounting books. They are:
If you are familiar with what an accounting ledger looks like (columns for date, sum of debit, sum of credit, balance), then you are very close to understanding the nature and the workings of an “Impact Target”. However, be aware that these also have additional information that traditional accounting ledgers don’t have. Primary Entries Let us have a look at one of the forecasts that was supplied to us by the Sales Manager. It was based on a specific length of time, and it names an expected value of sales. In many cases, a forecast’s length of time is a month (i.e. forecasted sales of March 2009). In other cases it is another length of time, depending on the nature of the specific business. For example, in supermarkets, sales are budgeted on a weekly basis, because it is the buying period of the main customer (the housewife). In order that the example to be easily viewable, we will use the following forecast: “Sales for the week starting Monday Jan 12 of 2009 and ending Sunday Jan 18 of 2009 for Item code “700001 = Milk” are going to be 100,000.00 EUR (VAT 19% not included). Terms of sale are 60 days of credit to the customer”. The “Primary Entry” is the tool we use in order to enter into the system a forecast. In order to enter into the system the above mentioned forecast we associate it with a date (within the limits of the mentioned period) and an “Event Type” code. In the above case, the “Event Type” code is named “Sales with 19% VAT and 60 Days of Credit to the Customer”. Event Type – Impact Groups – Analytical Lines If we were accountants, and we were booking an invoice of an actual sale with the above mentioned characteristics, we would have done the following:
Eventually (after 60 days), after the customer has given us the money, we would have done the following new entry:
Lines 1 and 5 eventually and over time cancel each other. For the purposes of conducting Financial Analysis thru C2BII, we will not consider them. In line 4, we see that the incident has impact on the company’s Bank account. That effect is going to be portrayed in C2BII thru entries in the “Targets of Impact” “Bank by Accounting” and “Bank by Valeur”. The difference between those two is that the first records the incidents on the date that they happen, and the second on the Interest bearing date, that is calculated after we add the “Days of Valeur” that our Bank adds. The effect of line 3 will be recorded in C2BII thru entries in the “Target of Impact” “Calculated Cash Flows”, or to be more accurate, in the proper subdivision of it. The effects of line 2 will be recorded in C2BII thru entries in the “Targets of Impact” “Item” and “Profit & Loss”. So the “Event Type” code “Sales with 19% VAT and 60 Days of Credit to the Customer” should have associated with it the following 5 “Impact Groups” that handle the corresponding sums. Bank by Accounting = 119,000.00 EUR
Every “Impact Group” represents a collection of individual days (Analytical lines), on which the described action will take place for a specific “Impact Target”. In our example it is a week. Now, every day of the week does not deliver the same volume of sales. Let us assume that we have determined that the following breakdown within the week takes place.
Keep in mind that these numbers are distribution factors and not distribution percentages. So, Monday’s sum is: 100,000.00 X 20 / 320 = 6,250.00
So, after the appropriate days have been added (i.e. +60 days, +2 days of Valeur or Same Date) to the starting days, which are the days of the week for which the sales forecast was initiated, we come up with the following Analytical Lines breakdown. Keep in mind that weekends and non working days for the company or/and the Bank have been factored in.
These Analytical Lines will populate their relevant simulations (Targets of Impact). For example, in the “Bank by Accounting” we have the following result.
In the upper grid we see the daily movements as a total, and the daily cumulative balances. Since we have clicked March 16 of 2009, we see in the lower grid the three entries that create the daily movement total of 44,625.00. In the same manner, all forecasts are entered thru suitably created “Event Type” codes. The result is that in the end we have accurately calculated daily balances of the Bank account, on the basis of which (Bank by Valeur) we can accurately calculate the sum of “Interest Expense” and “Interest Income”. Then we will move those numbers to the “Profit & Loss” simulation (Target of Impact), which has been populated in the same manner. After that, we have an accurate “Fiscal Year end” result (Profit or Loss), on which we will calculate Income Tax, Reserve Funds, Dividends and Retained Earnings (expressed as “Calculated Cash Flows”), and enter them appropriately in the system. Calculated Cash Flows The purpose of the Calculated Cash Flows (CCF) is to portray the cashflows that will take place only if a predetermined condition has been met. For example: On the basis of the above mentioned example, the VAT simulation ledger will look like this.
On the left grid we see the daily cumulative balance, and the total of the day’s movements. On the right grid we see (since on the left grid we have chosen January 14 of 2009) the entry that created the day’s total. The functionality of the Calculated Cash Flows is basically determined by the following supplied information: More on the working of the “Calculated Cash Flows” can be found on the program’s manual. Variation Factors Let us assume that we want to implement a quick change to many numbers, in a very brief timeframe, and calculate the effect of the new edited scenario. This is the realm of the “Variation Factors”. A simplified explanation of what they look like is that they consist of a number and a method of impact. Their creation is mostly dependant on one’s creative imagination and on one’s ability to foresee what might be useful in the future. An example of a number might be “100” and an example of a method of impact might be “Multiplication with Percentage”. At data entry time, any number has the nonmandatory capability to be associated with a “Variation Factor”. Let us assume that we are handling our company’s Annual Budget. The CEO has set same high sales targets in order to pressure the sales people. On the basis of those targets, the Finance Director has calculated thru C2BII the expected Yearend profitability. After the Sales Director has left the room, the CEO asks the Finance Director to calculate the result of the Annual Budget on a more realistic level. Specifically, he believes that the sales people will eventually deliver 93% of their target. In order for the change to take place, we enter the “Variation Factor” setup, and on the code with which those sales have been associated with, we change the number from 100 to 93. All forecasted numbers associated with that specific “Variation Factor” code will be changed into 93% of their value. Of course all other information remains the same. Then we press calculate, and we note the change between the previous result and the new one. More on the working of the “Variation Factors” can be found on the program’s manual.
