Skip to content

Accounting models

An accounting model represents a collection of events the combination and sequence of which generate precise accrual / accounting / collection or payment curves.

Tagetik has already defined a number of pre-set and system-generated accounting models internally; however, when particular needs arise, there is nothing stopping the user from creating new models, provided he or she pays significant attention during the set up of the accounts subject to accounting records.

The accounting model is therefore based on a series of events and all of the accounts that the model handles.

The management of accounting models can be accessed from the administrator-user’s web interface, by following the path Setup & Admin > Data Processing > Cash Flow Planning > Financial rules > Accounting models.

Navbar > Data Processing > Cash Flow Planning > Financial rules > Accounting models.

An accounting model is identified by:

  • a model type. The following types are available:
  • Sales
  • Purchases
  • Credits
  • Debits
  • Asset. The user can NOT insert a model of this type manually; these models are created automatically by the system while saving a new assets class
  • FX hedging
  • Stock
  • Work order
  • Financial assets
  • Financial liabilities

The model type ensures that the system behaves differently according to whether the model has been associated with a cost rather than revenue, a payable rather than a receivable, and so on. The same model of accrual, accounting with credit terms and VAT subordinate once to the “Purchases” type and once to the “Sale” type, creates the same curves but reversed in sign precisely because they have been defined as different types.

  • a code. This identifies the accounting model. In cases of $ entities this must always begin with the character “$” in order to avoid overlapping with models inserted by individual entities;

  • a description

  • an entity code. This identifies the entity. It is possible to select either the value $ in order to specify that the accounting model is common to the group: it can be used by all Entities of the group or the actual Entity code in order to specify that the rule can only be used by that Entity.

Once the accounting model header and type have been defined, it is necessary to define the events, namely the accounting events that are of interest to the model that we are creating. For example, supposing the user wants to define a model of Accrual, Accounting with Credit terms and VAT, there will be three events to be managed: accrual, accounting and collection / payment (my means of credit terms or manually).

The definition of the events that make up an accounting model can be accessed from an accounting model’s actions / detail menu.

Once the events and the order in which the events are linked together have been defined, it is necessary to define, for each of them, the generic default accounts, which essentially specify the double entry that every event should create. The accounting models make use of default accounts (identified by the prefix $) since the same model could be valid for several accounts and therefore if we were to specify the actual accounts to be affected in the model immediately, then that model will no longer be valid for other accounts.

For example, if we want to create the “Accrual” entry for a “Packaging Purchase”, the general record that we must create is:

the record for the “Accounting” event is:

and the record for the financial event is:

Thus, only when the accounting model is associated with the actual account does the system replace the Original Account with the account in question and all the entries that we specified earlier per event are computed on the Credit accrual variation, Debit variation, and Liquidity variation accounts that we have associated with the effective account on the list. For example, given the Packaging Purchase Account, if it is decided in the chart of accounts that the “Debt variation Account: Debit” is “Various Payables-Dim” and the “Debt variation Account: credit” is “Various Payables-Incr.”, then the system associates the aforementioned model with the Standard “Packaging Purchase” account that the variation accounts already contain and generates the accounting record on the “Various Payables-Incr.” account.

The aforementioned default accounts are defined by defining entering values for the following fields:

  • debit account. This is the account used by the system to generate the accounting entry based on the event in the debit section. It can be:

  • a balance sheet account of the variation type present in the chart of accounts

  • a P&L account of standard type present in the chart of accounts

  • a generic default account (with code starting with the character $) chosen from:

  • $NULL which means “Do not make the entry"

  • $ACCOUNT which represents the event account
  • $ACCRUAL_DR or $ACCRUAL_CR which represent the accrual accounts (debit or credit) included in the accounts list for the event account
  • $VARIATION_DR or $VARIATION_CR which represent the variation accounts (debit or credit) included in the accounts list for the event account
  • $ARAPVARIATION_DR or $ARAPVARIATION_CR which represent the credit/debit variation accounts (debit or credit) included in the accounts list for the event account
  • $CASH_DR or $CASH_CR which represent the liquidity variation accounts (debit or credit) included in the accounts list for the event account
  • $ADDL_DR or $ADDL_CR which represent the “other accounts” (debit or credit) defined in the accounts list for the event account
  • $ACCRUAL2_DR or $ACCRUAL2_CR which represent the other accrual accounts (debit or credit) included in the accounts list for the event account

  • $SETUP which indicates that it is possible to directly enter an account code included in the list

  • credit account. This is the account used by the system to generate the accounting entry based on the event in the credit section.

  • reference account for cash flows. The account with which the system generates cash flows. It only needs to be defined on records related to liquidity entries. It can be:
  • a balance sheet account of the variation type present in the chart of accounts
  • a P&L account of standard type present in the chart of accounts

  • a generic default account (with code starting with the character $) chosen from:

  • $NULL which means “Not involved in the cash flows calculation”

  • $ACCOUNT which represents the entry account (used for the P&L and for balance sheet variation accounts into which data is input directly)
  • $ACCRUAL_DR or $ACCRUAL_CR which represents the accrual accounts (debit or credit) included in the accounts list for the event account (generally not used)
  • $VARIATION_DR or $VARIATION_CR which represent the variation accounts (debit or credit) included in the accounts list for the event account (generally not used for the initial balance sheet disinvestment)
  • $ARAPVARIATION_DR or $ARAPVARIATION_CR which represent the variations of the credit / debit account linked to the entry account (generally not used)
  • $ADDL_DR or $ADDL_CR which represent the “other accounts” (debit or credit) included in the accounts list for the event account (generally used in L/T financing- and stocks-type objects)
  • $ACCRUAL2_DR or $ACCRUAL2_CR which represent the other accrual accounts (debit or credit) included in the accounts list for the event account (generally not used)
  • $SETUP which indicates that it is possible to directly enter an account code included in the list

For every event indicated within the model it is also possible to specify:

  • whether the event in question allows:
  • credit terms. It should be noted that the credit terms rule is not specified in this phase, but only that the model in question allows credit terms for the selected event
  • indirect tax
  • the second indirect tax (can be used for excise, withholding taxes)

For collection and payment events, it is also possible to specify:

  • whether the amount of the event entries must not be changed as a result of the indirect tax deriving from previous events (Manual Collection/payment including VAT option active). This option is useful for entering payment events already inclusive of indirect tax

  • whether the amount of the entries needs to be generated in the entity currency (Collection/Payment in Entity currency option active)

In cases of an Accrual, Accounting with Credit terms and VAT model, the user has decided that it is the accounting event that permits credit terms and VAT because those two events typically arise from the accounting event. However, nothing would stop the user from creating ad hoc models where, for example, the intention is not to transit from the accounting event but to make a payment / collection directly based on accrual. In the latter case, our model would have had an “Accrual” event which allows credit terms.

It is possible to change the description of generic accounts (those starting with a $) by following the path Setup & Admin > Data Processing > Cash Flow Planning > Advanced financial rules > Financial planning accounts.

Navbar > Data Processing > Cash Flow Planning > Advanced financial rules > Financial planning accounts.

Utilities

Clone accounting model

An accounting model can be defined manually or using the clone utility. This utility can be accessed from the administrator-user’s web interface, by following the path Setup & Admin > Data Processing > Cash Flow Planning > Financial rules > Accounting models > Actions > Clone accounting model.

Navbar > Data Processing > Cash Flow Planning > Financial rules > Accounting models > Actions > Clone accounting model..

The user must indicate:

  • the code, which for entity codes must always start with the character $
  • the description
  • the entity code

Once this section is complete, if the user clicks on the OK button the system creates the new accounting model by copying it from the one selected in the models list.