## What is the basis of the method of C2BII? Part 6: CashFlows that will take place only if a predetermined criterion has been met

Most of the “Calculated Incidents” are conditional in nature, and will take place, only if a predetermined criterion has been met. In the C2BII program, those incidents are called “Calculated CashFlows” or CCF for short. Examples are:

• “Payment of VAT”, will take place only if there is a credit balance in the relevant account, on the relevant date.
• Calculation of “Interest Income”, will take place only if there is a debit balance in the relevant account, on the relevant date.
• Calculation of “Interest Expense”, will take place only if there is a credit balance in the relevant account, on the relevant date.
• Etc

So, first of all, we must be able to create simulations of relevant accounts, on a daily basis. In previous articles, we have seen how from a forecasted incident (for example: “Forecasted Sales with 19% VAT and 60 Days of Credit to the Customer”) we have created the daily “Analytical Lines” that will populate the simulation of relevant accounts.

For the purposes of this article, we are going to focus on the simulation of the company’s “VAT Account” that has already been created thru the C2BII program. All Accountants know that the “VAT Account” is being debited by the values of “VAT of Purchases” and is being credited with the values of the “VAT of Sales”. On the last day of each calculation period (usually a month), in order to determine if a payment will take place, we see if the balance is a credit, and if it is, that balance gets paid to the Government on the appropriate date. In Greece, that appropriate date is the 25th of the next month.

In the C2BII program, the set-up screen of the VAT looks like this:

In order to understand the chain of thoughts that are pictured, we must ask ourselves the following 6 questions:

Question 1: The simulation of company’s Accounting books has many Accounts. Which is the one that is relevant to the task at hand (Payment of VAT)?

Answer 1: That information can be found in the “Data Source for Calculation”, and in this case it is the “Calculated CashFlow” Ledger. The fact that the field “Other Calculated CashFlow” is left blank, means that the source of information is itself, and not the ledger of another CCF code.

Question 2: Now that we know where to look, for data to process, we would like to know the purpose of this quest.

Answer 2: That information can be found in the “Purpose of the Calculated CashFlow”, and in this case it is to take an “Action on Credit Balance”. In other words, we will make a “VAT Payment” only if the VAT ledger satisfies the criterion of having a Credit Balance.

Question 3: Now that we know, where to look for data to process, and what characteristic to look for, we would like to know the value of the “Calculation Basis” for the calculation that we are going to perform.

Answer 3: That information can be found in the “Basis for its Calculation”, and in this case, it is the “Balance of the Breakpoint Date”. In Question 5, we are going to discuss the nature of the “Breakpoint Date”

Question 4: Now that we have established the value of the result of the calculation, what shall we do with it?

Answer 4: That information can be found in the “Event that will be used for Entry of Purpose”. It is the “Event Type” that the program will use to automatically create a new entry for the value that has been calculated. That new entry will be automatically fed into the workflow and will be processed (i.e. analyzed into relevant “Analytical Lines” that will populate the simulations of the relevant ledgers).

After that, the simulation of the VAT ledger will look like that:

Question 5: What is the date, on which the program must automatically check if the above mentioned criterion is being met, and if it is, to create the relevant new entry?

Answer 5: That information in C2BII is called a “CCF Calculation Breakpoint” and it is being defined in another menu. On the date, on which we want that automatic check to take place, we assign a “Priority Number” to the relevant CCF. In our example, we assign “Priority Number” 10, on Jan 31 of 2008. The logic behind the creation of the “Priority Numbers” is that, if on a specific date there are more than one CCFs that need to be processed, the one with the smallest gets processed first, and the one with the largest gets processed last. In other words, this is how we make sure that actions that must take place before this calculation (prerequisites), take place in the appropriate sequence.

Question 6: In some types of calculations (examples: “Interest Income”, “Interest Expense”, “Income Tax” etc) a calculation rate is being involved. How do we define that?

Answer 6: That information in C2BII is called a “CCF Rate” and it is being defined in another menu.

Stick around, as we are about to find out about the mechanism that will enable us to easily and accurately process “What if” scenarios.

## What is the basis of the method of C2BII? Part 5: Forecasted and Calculated figures – Curing Inaccuracies and Inconsistencies

In an “Annual Budget”, or in an “Investment Plan Evaluation”, some incidents (and the CashFlows that result from them) are subject to a forecast. Examples are sales, ads, rent, salaries (only under specific circumstances) etc. Some other incidents should never be subject to a forecast, but should always be a product of a verifiable calculation. Examples are “VAT Payment”, “Interest Income”, “Interest Expense”, purchases (raw materials, packaging materials, merchandise etc), “Income Tax”, other Taxes, “Direct Labor Salaries”, “Social Security” etc.

Let me explain this a little more. In an oversimplified example, let us say that someone has made the following forecasts:

• Forecasted Sales with 19% VAT = 1,000,000€
• Forecasted Purchases with 19% VAT = 800,000€
• Forecasted Payment of VAT to Government = 40,000€

Creating a forecast for the “VAT Payment”, to begin with, is redundant and (almost always) dangerous and misleading. The thing is that when someone has said that sales are going to be 1,000,000€ and purchases are going to be 800,000€, then (for all practical reasons and purposes) that person has already said the equivalent of:

So, we have a person that says 40,000 while at the same time, his/hers data say 38,000. This is not simply an inaccuracy. It is much worse. This is an inconsistency, which is one of the most lethal sins in science.

An inexperienced person might think that this is the sort of mistake that nobody with a decent IQ could ever make in a million years. If life (and conducting business) was as simple as the above oversimplified example, then I would have agreed too.

However, a sample of the real life list of steps that are needed to create that “VAT Payment” calculation, and the issues that need to be factored in, might look like this:

1. The volume of forecasted Sales, needs to be broken down among the days of the forecasting period (week or month or Fiscal Year)
2. Each daily volume of sales must be backtracked to a date of production, using the company’s policy for “levels (i.e. days) of stocks of finished goods”.
3. Each volume of daily production must be backtracked to a date of purchase of raw materials and packaging materials, using the company’s policy for “levels (i.e. days) of stocks of raw materials and packaging materials”.
4. A volume of daily purchased raw materials and packaging materials should be established, on the basis of the “Bill of Materials” of the Item for which we have created the above mentioned Sales forecasts.
5. The volume of daily purchases of raw materials and packaging materials must be increased by a factor that reflects the “production waste” and the “quality control rejections of finished goods”.
6. The sum of each specific month’s “VAT Payment”, is the difference between that specific month’s “VAT of Sales” minus that specific month’s “VAT of Purchases”.
7. If a month’s calculated “finishing balance” of the VAT account is a debit value (which results in “non payment of VAT” for that specific month), then that debit balance must be incorporated into the next month’s VAT calculation.

And this is just a sample list of the many issues in the calculation of “VAT Payment” of the “Annual Budget” or of an “Investment Plan”. Please note that in all the above mentioned calculations, the key issue is “daily calculation” of values. Now that you have seen part of the real picture, that “VAT Payment” calculation doesn’t seem that simple anymore, does it?

And if you think that calculating the “VAT Payment” is complicated, wait till you see the list of issues that must be addressed for the calculation of “Interest Income” and “Interest Expense”. Hint: among other things, we must establish “Calculated Daily Balances” of the Bank Account (not a “Monthly Average” balance) and we must also take into consideration the “Days of Valeur” of each individual transaction. And after all these calculation issues have been correctly factored in, only then we can start talking about the issues of the “Income Tax” calculation (an even more demanding and complicated process).

I have seen way too many incidents of people creating forecasts for “VAT Payments”, “Interest Income”, “Interest Expense”, “Income Tax” etc, as a means of taking a shortcut. In their defense, I understand that correctly conducting all the calculations that are relevant, by using a spreadsheet, is an unimaginably difficult, time consuming and prone to casual error endeavor, up to the limit that in most of the cases, it is impractical to perform. However, this understanding cannot be used as vindication and justification for not creating a calculation whose results can stand up to scrutiny and verification.

A few weeks ago, in a private conversation that I had with a Venture Capitalist, I heard him say that he is sick and tired of seeing MBA holders who create Business Plans that have little to no proximity to an accurate calculation of profitability, due to inaccurate (or even entirely omitted) calculations of miscellaneous values, such as the VAT Payment etc. I felt no hesitation to reply to the effect that I also shared his resentment.

So, bottom line, any accurate method of conducting Financial Analysis must have provisions and mechanisms for the creation of “Calculated Values” from “Forecasted Values”. Stick around and we are going to see how C2BII addresses this issue in an accurate and easy to understand and implement way.

## What is the basis of the method of C2BII? Part 4: Analytical Lines

An “Impact Group” represents incidents within a period of time. In this example we will use the weekly budgeted sales of a super market. All the days within the week do not yield the same volume of sales. So, if we go to the company’s ERP system and run a query for the last 2 or 3 years, we can find the seasonality within the week. This hypothetical break down says that for every 100 EUR sold on Saturday, on average 20 EUR are sold on Monday etc.

Since we must distribute 100,000.00 EUR within the days of the week, these distribution factors that the query showed us, are the basis for performing the break down. Monday’s sum is calculated in the following manner:

100,000.00 * 20 / 320 = 6,250.00

So, the end result is that for sales of week “Jan 14 of 2008” to “Jan 20 of 2008”, the following “Analytical Lines” will be created, with their respective dates and sums.

These “Analytical Lines” will populate the simulations of the company’s Accounting ledgers. Here is the simulation of the Bank account (the aspect by Accounting Balance – not the Balance by Valeur).  In the diagram it is being mentioned as “Impact Group 1”. In the upper grid we see the daily totals, and in the lower grid we see the analytical movements that have created that daily total. In this example we can also see other numbers that are not included in the list, but were created automatically by the system to represent other incidents (VAT payment, Interest Income, Interest Expense etc). The mechanism that creates them automatically (Calculated CashFlows – CCF) will be discussed in later articles.

Stick around, as we are going to see the tool that handles CashFlows that will happen only if a predetermined condition has been met.