Dates and repetitions in financial forecast transactions

Documentation •
In this article

The Date column

The value contained in the Date column is the one that will validate the forecast.

  • If there is no date, the transaction will be taken into account at the beginning of the planning.
    If you require a forecast indicating a period, the amounts will be taken into account in the balance value at the beginning of the period.
    Due to the fact that it does not fall within the period, no amount will be displayed in the Total column.
  • Dates in the accounting period set in the file properties.
    These are the ones commonly used. The total amount will be indicated in the Total column, taking into account repetitive movements, within the accounting period.
  • Dates prior to the period.
    You can enter movements that precede the forecast period. However, you must be careful that they do not conflict with the opening balances entered in the account table.
    Due to the fact that it is not within the period, no amount will be displayed in the Total column.
  • Dates after the period.
    If you make forecasts over several years, they allow you to indicate transactions for the years to come.
    Due to the fact that it is not within the period, no amount will be displayed in the Total column.

The End date

This is used in combination with repetition, to indicate the last date beyond which there is to be no repeat.

  • Must generally be left empty.
    If you enter a date when it is not necessary (for example the end of the accounting period) the forecasts for the following years will not include this operation.
  • For leasing transactions.
    Indicate the date on which the payment of the last installment will be made as the end date.
  • For loan repayment.
    Indicate the last expected payment date.
  • For changes in the amount at set deadlines.
    In the case, for instance, that the amount of a recurring transaction is adapted at certain deadlines (salary increase).
    • Create a transaction row with repeat "M" and End date as per the last payment before the increase.
      Create transaction rows with Dates when the increase begins.
    • If the increase follows a precise and regular automation, this can also be programmed with formulas.

Repetitions

For recurring expenses or income, the repetition code is recommended (refer to Documentation on the columns).

  • When calculating the forecast, the program creates copies of the operation and progressively increases the date, taking into account the indicated frequency.
  • If there is no end date, the program will generate internal copies of the records for the entire period of the forecast indicated at the time of the report when calculating the forecast.
    • If the start date is January, the frequency is monthly
      • If the forecast period is the year, it will generate rows from February, 1 original row and 11 automatic rows, for a total of 12.
      • If the forecast period is 10 years, it will generate rows starting from February, 1 original row and 119 automatic lines (11 the first year + 12 * 9 for the following ones), for a total of 120 lines.
  • If you want the program to automatically calculate forecasts for subsequent years.
    • For recurring operations, indicate the relative repetition code.
    • For transactions that occur only once a year (for example depreciation at the end of the year), indicate the repetition code "Y", so that the depreciation is also calculated in the following years.
    • Don't use the repetition only if the operation will not occur in the following year.

Total column of the Budget table

The Total column is calculated automatically and represents the sum of the amounts of the current row and the repetition amounts that fall within the accounting period. The Total column is empty if the transactions have an earlier date or extend beyond the accounting period.

Schedule with precise date and monthly logic

Forecast movements are entered in the Budget table indicating the date on which these are expected to occur.

However, it is not always possible to predict all revenues and expenses with a daily precision. When making a forecast it is therefore useful, in some cases, to use approximations, generally reasoning on a monthly basis. In any case, it is useful to always follow a specific logic so that reliable liquidity forecasts can also be obtained in the short term:

  • Punctual operations (capital payment, investments) are indicated with the date on which they are expected to occur.
    If there is no precise date, it is useful to indicate them on the 15th day of the month in which they are expected to occur. 
  • Recurring charges that have a precise payment date are to be set with the expected payment date and the relative repetition code:
    • Bank charges, interest, amortization are to be indicated at the end of the month, quarter or year that they will take place.
    • Rentals on the due expected date of payment.
    • Salaries and social security charges
      • For the calculation and monthly payment on the day that wages are paid.
      • For thirteenths, bonuses or whatever at the moment they are paid.
      • Payments for advances and adjustments of social security charges on the expected payment date.
    • Payments and VAT adjustments on the typical payment due day.
  • Revenue Forecasting.
    The preparation of the forecasts depends on the type of activity.
    If you do not know the exact day, but you will know that it will happen in a certain month, it is recommended to indicate the 15th of the month
    • Punctual revenue.
      They are to be indicated on the date on which it is expected to take place or mid-month.
    • Recurring revenue.
      To be indicated on the date of entry or mid-month.
    • In many cases a monthly forecast is well suited. The revenue can be indicated on the 15th of the month.
      • If the revenues are recurring, the revenue can be entered with the monthly repetition. Using formulas you can predict growth.
      • If there are seasonal differences, it is helpful to have a sales forecast row for each month.
    • Forecast of projects or major works.
      If there is a calendar with receipts, a transaction row is to be indicated for each expected entry. It can be approximated by indicating the 15th of the month.
    • Forecast for customers.
      For a consultant or commercial advisor, who works both with budgets and projects, it can prove very useful to set up a detailed revenue forecast for each client, with the expected payment dates. This forecast will also be very useful to check if the customer has actually paid.
  • Variable costs.
    • Constant expenses linked to the turnover (a restaurant for example ), are indicated with the same date as the turnover. With a formula you can also calculate as a percentage value of the turnover.
    • Costs can also be linked to other elements, such as the number of employees, rented premises or other.

Forecasting with the cash principle

Planning for small business and cash activities (such as shops, restaurants) it is useful to proceed with the cash principle, then indicate the revenues with the date on which they will be collected and the costs when paid.

For important operations, such as the purchase of a machine whose payment is deferred over time, it is however useful to insert forecast movements with precise details:

  • Purchase of machinery (asset registration with suppliers) with date of purchase.
  • Payment of the machinery, with the date(s) on which payment is expected.

Forecasts with the accrual method

In this case, the insertion of the operations takes into account when the payment will be made.

  • Cash transactions.
    They are obviously registered normally.
  • Transactions expected to be settled in the near future.
    For simplicity, the operations that fall within the forecast month or the one immediately following, it can be useful to use the cash principle.
  • Deferred payments.
    If the dates are not known with precision, you can use the 15th of the month.
    • Transactions with precise payment terms.
      • One movement indicates the purchase date with the counterpart in the supplier account.
      • One of the other movements indicates payment on the scheduled dates.
  • Deferred collections.
    • With precise payment terms, as is the case with a project:
      • A movement indicates the billing date and the customer account with the counterpart.
      • One of the other movements indicates payment on the scheduled dates.
    • Late payment.
      This is the case when a part of the revenues is collected in the short term, a percentage is collected later. It can be done like this:
      • Enter the revenue as cash collection.
      • With the same date, a movement is created that moves a part of the collection to the customer account.
      • At a later date, the cash collection is indicated with the client account of the counterpart.
  • Use of variables for deferred collections and payments( see Example use of variables)
    When the same value must be reused at the time of payment, it can prove very useful to use the formula column and variables.
    • In the billing transaction, the amount is assigned to a variable.
    • In the payment movement, the variable is inserted so that the amount is automatically taken over.
    • Variables can also be used to define the percentage of the amount that will be deferred, for example.
Tell us how we can help you better
If the information on this page is not what you're looking for, is not clear enough, or is not up-to-date, let us know.

Share this article: Twitter | Facebook | LinkedIn | Email