T24 Accounting Introduction R16

T24 Accounting Introduction
T24 Financial Accounting - R15 1




The general ledger is the main accounting record of a business.

Accounting entries are generated for all the transactions and the account balances
are updated.
During COB, the balances are replicated to the General Ledger (GL) heads.
Characteristics of the traditional GL are:
1) Multiple GL Account heads
2) All desired combination of accounts to be opened whether required or not.
3) Any further classification very difficult.
Under the traditional way of maintaining General ledger accounts, an account needs
to be opened in every currency, for every product, and for every further sub-
classification.
Assume that a Bank deals in 5 currencies, has 10 products, maintains them by
industry wise (say 30 industries), it needs 1500 accounts (5 X 10 X 30).
Further sub-classifications like Sector or Dealing officer, etc would increase the
number of accounts.

T24 follows the virtual account system with flexibility for GL groupings. Instead of
providing one standard General Ledger design, T24 allows User definable groupings
purely driven by reporting requirements of the Bank. It may be based on the
countries specification and Central Bank requirements. T24 creates Keys or
groupings as and when needed. Static element like Industry, Residence, Sector, etc
are selected from Customer Table and Currency, Product, Maturity etc are selected
from respective applications. Any change in the value of these data results in
automatic regrouping under respective GL heads/GL Keys.
Regrouping is done automatically by the system during COB. Reports can be
generated using any combination of elements available in GL Key.

The importance of financial accounting to banks need not be over emphasized.

Banks are usually subject to very rigorous regulatory norms for reporting and their
disclosure requirements vary from country to country.
In keeping with its general design for maximum flexibility, the financial accounting
and reporting in T24 is very flexible and has a very unique design. It does not have
any predefined chart of accounts. This enables the banks to construct their General
Ledger in any manner they desire.
One of the important aspects of T24 is that all dealings with customers are classified
either as ‘Accounts’ or ‘Contracts’. There are also Profit and Loss headings (All
these products are Categories in T24).

Accounting entries generated under these three broad headings can be consolidated
into user definable AL and PL groupings called as Keys. The design of keys is
driven by reporting requirements. They are called Central reporting Files. From
these, any user defined report could be generated – closing balance type or
movement type; showing residual maturity or without; profit and loss in currency in
which earned or in local currency etc.
In Accounting, choice is available to choose Trade dated or value dated accounting
and Category codes. In consolidation, key design is done with reporting
requirements in view and is unique to every implementation site. The keys have
some parts of a standard structure. Information under a key is also standard.
Reports are fully user defined with in-built flexibilities.

The Core Parameter Tables are very important to build of the system and should be
completed during initial stage of the analysis.
The tables colour coded as CORE can be viewed as static data, data that are crucial
across the system.
The tables colour coded as FINANCIAL STATIC has been distinguished from
others because of the operational impact of the information. They will be addressed
to the treasury area, as they will maintain information relating to currency markets,
dealer desks, interest rates etc.
The tables colour coded as CUSTOMER assist in identification of data required to
adequately record customer details. They form an important part in deciding on
customer related consolidation of information like Industry, Sector, Residence,
Nationality etc.

The currency market functionality enables the client to define different sources of
exchange rates – a different currency market could be used for the cash market and
another for treasury market. Like this, up to 99 markets can be defined. However,
consolidation is designed to be done for the markets with Ids 1 to 9. Hence, the
markets could be set as 9 main markets and 90 linked markets so that markets 1, 10,
11, 12, 13, 14, 15, 16, 17, 18 and 19 could be consolidated together under Market 1.
A typical example is Belgium where foreign currencies are quoted on the
Convertible/Regular market and also on the Financial/Free market. Different sets of
exchange rates will exist according to these two markets.
CURRENCY.MARKET Field can also be used within the concept of notional
market, i.e. where you would like to define different sets of exchange rates
according to the type of products handled. One set of exchange rates, for example,
could be defined to identify the exchange rates applicable to your Notes
transactions, set of rates for Traveller Cheques, another set of rates for your transfer
transactions, etc.

Up to 9999 records can be created in INDUSTRY and SECTOR. It is very likely

that a Bank may wish to make changes from time to time in Industry and / or Sector
classification. New industries may emerge. It is also likely that a Customer
engaged in a particular industry may change his line of activity. In these cases, the
new reports have to reflect the current picture.T24 automatically takes care of these
changes incorporated in respective CUSTOMER records. The Sector codes must be
defined carefully because they can be used to create CUSTOMER.DEFAULT
records to simplify opening of new Customer records by reducing amount of
necessary input. ACCOUNT.CLASS records also use Sector codes to indicate Class
type – Example Banks. This value determines a customer should receive MT202
message rather than MT 100/103. The DEPT.ACCT.OFFICER table indicates the
entire hierarchy of a bank. This identifies a Department or an Account Officer. A
DEPT.ACCT.OFFICER attached to each Customer to link the relationship manager
for him. This value defaulted from Customer while inputting transactions. Can be
modified at transaction level. Useful for consolidation to get branch wise /
department wise / officer wise performance data.

The Sector is one of the main elements for classifying customers. It is purely
descriptive and it is user definable in SECTOR table. It is however, very significant
in that in many grouping/classification definitions, such as for consolidation,
preferential groupings and special purposes such as NOSTRO, Bank, etc.
Mention of Department Account Officer is used to determine the departmental profit
and loss.
Industry identifies the Industry in which the Customer is trading and can be used for
several purposes including checking commodity limits.
For determining Nationality and Residence, Country table is used.
Customer status indicates the status of the customer like for example, sound,
bankrupt, deceased etc.


Booking date: Otherwise called as Transaction date. Date on which the transaction
is booked in the system. System date on which the Entry was generated that is
Today Field in the DATES record for the Company being processed. The booking
date is normally, but not necessarily the actual date at the time the Entry is
generated, e.g. if the previous day's business is still being processed after midnight,
the actual date changes, but the run date is still the previous day.
Value date: The date on which the entry is to be given value for interest purposes. If
the Value Date is not entered in the originating transaction, a default date may be
generated by the system depending on rules specified in the application.
Exposure Date: The date on which Account’s cleared balance will be credited. Date
can be present in Credit Entries or Debit Entries which are reversals of Credit
Entries. If this field is blank, the Exposure Date is assumed to be the same as the
Booking Date but cannot be less than the value date. Please note that this date does
not affect the Value Date on which the Entry updates the Balance for interest
purposes.
Processing Date – The date on which transaction is to be processed. This can be
current or future date but cannot be back dated.

In T24, FUNDS.TRANSFER, TELLER, DATA.CAPTURE are Account based

applications.
These applications can be used to move money between accounts on one side and
Accounts or Profit and Loss head on the other. However, PL to PL is possible in
DC. The accounts could be Customer type of accounts or Internal accounts.
These applications cannot be used to move money into or from a contract. A loan
contract cannot be repaid directly by using TELLER application. Instead, the
repayment amount should be placed in liquidation account and the Contract will
directly pick the amount from the account due on the due dates.
Contract applications can generate new contracts and draw and settle through
Accounts on other side. They can also move money into Profit and Loss heads. A
Loan contract will place the proceeds directly into an account. Likewise, it will
collect loan handling charges from account and credit it directly into Profit and Loss
head.

In T24, Accounting entries are automatically generated for authorised transactions.

But system provides with a certain amount of flexibility in defining broad rules for
a desired accounting set-up.
All contract based applications except Securities follow Value Dated system by
default and all account based applications including securities follow Trade Dated
system by default.
From R15, a new accounting system called as “Trade Dated GL” has been
introduced.
All account Based transactions including Securities have the option of following
Value Dated System / Trade Dated GL System, though Trade dated accounting is
used by system in default.
When transaction date and value date are same, all accounting systems behave in
the same way, i.e. from day 1, Assets and Liabilities are considered as non
contingents. The treatment differs only when there are future value dated
transactions and explained in the next slide.

Accounts and contract balances could be consolidated and presented as desired by a Bank. A
Bank sets rules as to how these balances are to be consolidated. Hence T24 does not come
with a pre-designed General ledger. Similarly, the profit and loss entries could be
consolidated as desired. T24 does not have a pre-designed Profit and Loss account set-up
either.
Every Bank reports Assets and Liabilities and Profit and Loss figures differently for different
users. Statutory reports, Management reports, Shareholders reports, Departmental reports are
not same in contents although all of them report only figures of Assets and Liabilities and
Profit and Loss.
Hence T24 gives flexibility to decide upon consolidation based on reporting requirements.

Under Trade dated accounting all the transactions from the cash based applications such as
Data. Capture, Funds Transfer, Teller, Securities, Derivatives update the Customer’s balance
and Bank’s positions immediately, i.e. on the trade date, irrespective of whether they are
processed with a future value date.
Under Value Dated accounting, transactions that are processed with a forward value date are
treated as forward movements until the value date. Contingent entries are passed on Trade
date and maintained till value date. On value date, the contingent entries are reversed and
non-contingent entries are passed.
Under Trade Dated GL accounting, future valued account and securities transactions will
update the Customer’s balance only on value date but they are immediately reflected in
Balance sheet as “Receivable/Payable” . Here, the entries are not contingent but Special
entries are processed on Trade Date with Non-contingent asset types “PAY” and
“RECEIVE”. On Value date, these special entries are reversed and replaced by Non-
contingent account entries , thereby hitting the account statement. The main benefit of this
system is to include the future dated movements also in the Balance sheet rather than
showing them as Contingent ( Off Balance sheet ) items outside the Balance sheet. Foreign
currency positions updated by foreign movements are updated with the trade date and are
revalued as the current Asset & Liability Positions.

Under TDGL set-up, future dated P&L movements are treated the same way as under Value
Dated accounting, i.e the movements are booked as contingent between the trade date and the
value date.
Please remember that only account based applications like FT,TT,DC and IC and Securities
have the option of following TDGL system. Contracts other than securities will always follow
Value Dated system and hence in case of future valued contracts, system generates contingent
entries on Trade date/Transaction date. They get reversed on value date and Non-Contingent
entries are passed on Value date.

Initially, All account based and securities transactions can switch over from Trade Dated
accounting to Value Dated Accounting. But once switched over to Value Dated System, they
can never switch back to Trade Dated Accounting.
From R15, with the introduction of Trade Dated GL System, there is a flexibility to switch
from one accounting system to another, but only for account based applications and
Securities.However this will apply to new transactions only; the existing cash based
transactions with a future date will still follow the existing set-up under which the entries
were raised until the value date. Existing transactions will be still under the original set-up
until the value date.

VALUE.DATED.ACCTNG:
If a value dated accounting system is required in general, then this Field in

ACCOUNT.PARAMETER Table should be set to 'Y'.
For Trade dated accounting, this field should be set to ‘N’.
For Trade Dated GL system, this field should be set as “Tdgl”
VAL.DATE.SYS.ID:
Any of the account based applications and SC could be selected if you require
application specific accounting system, by using multi value fields. ( Eg:SC)
VAL.DATE.BY.SYS:
For the above selected application, the accounting system can be mentioned. For eg,
Tdgl option to be selected for Trade Dated GL System.
VD.CAT.SYS.ID:

Any of the sub-product for the above mentioned application/product (Eg:SCSCP )
VAL.DATE.BY.CAT.SYS:
For the above selected sub-product, the accounting system can be mentioned. For Eg, “Y”
option for Value dated Accounting system.
VAL.DATE.BY.CAT:
For selecting a range of products at system level by giving the starting range in the field
“VD.CAT.START “and ending range in “VD.CAT.END “ and option could be selected as
“Tdgl” or “Y” or “N”
CASH.FLOW.DAYS Field determine the no. of days to update the Available Balances ladder
in Accounts from forward dated STMT entries (F entries). If the value is Null, default value is
10 days for NOSTRO ACCOUNTS. However, forward value-dated STMT entries in value-
dated accounting system will update the Available Balances ladder in Accounts based on the
value-dates, irrespective of the setting in this field.
Whenever changes are made to ACCOUNT.PARAMETER table, sign-off and then sign-in
again.

TXN.JOURNAL is a work file, which contains particulars of transaction entries

passed during a day. It contains particulars like Transaction Reference, Account
Id/Contract Id/PL category code, Amount in Local Currency and Foreign Currency,
Value date, Category code and Customer number. Using this file,
TXN.JOURNAL.PRINT report is generated during COB.
EB.JOURNAL.SUMMARY file is also a work file, which contains currency wise,
company wise and application wise summary of debit and credit transaction entries.
It is used to generate JOURNAL.SUMMARY report during COB.
BYPASS.TXN.JOURNAL and BYPASS.JOURNAL.SUM fields in
ACCOUNT.PARAMETER are used to by pass updates to TXN.JOURNAL and
EB.JOURNAL.SUMMARY. So, when the above fields are set to YES,
TXN.JOURNAL.PRINT and JOURNAL.SUMMARY reports are not generated.
When the fields are set to NO, TXN.JOURNAL.PRINT and
JOURNAL.SUMMARY reports are generated




Assets and Liabilities are balances from Customer accounts, Internal accounts and
Contracts.
Entries affecting non contingent Account balances are stored in STMT.ENTRY file
for Customer accounts and Internal accounts. These entries are used to produce
Statements for Customers and for internal accounts.
All other entries affecting Assets and Liabilities are stored in
RE.CONSOL.SPEC.ENTRY file.
T24 does not open accounts for Profit and Loss items. Straight from Category codes,
the balances are consolidated.
Entries affecting Profit and Loss heads, both contingent and non-contingent, are
stored in CATEG.ENTRY file. These entries update consolidation straight from
Category codes without any intermittent accounts. Instead, during close of business,
they go and directly update the consolidation for PL heads.

STMT.ENTRY generated for non contingent balance of Accountns and

RE.CONSOL.SPEC.ENTRY generated for all other assets and liabilities are
consolidated into GL heads called Asset and Liabilities Keys.
Contingent and non-contingent entries generated for updating PL heads are
consolidated into GL Heads called PL Keys

The entries in T24 are system generated files and cannot be user initiated/edited.
User can only list, view and print the account entries. Entries contain essential
details like deal record number, transaction currency, amounts in local and foreign
currencies, exchange rate, Customer, Category, Transaction code, Transaction
reference, Overrides if any, Booking Date. Value Date and Exposure date.
User can add Local Reference fields to be populated in Accounting entries.
All records in CATEG.ENTRY file contain essential details like PL Category,

Product Category, amounts in local and foreign currencies, exchange rate,
Customer, Transaction code, Transaction reference, Booking date. In case any more
information is required, local reference fields of CATEG.ENTRY can be populated
through generic accounting interface.
A Bank may transfer money from a Customer account to another person having
account in a foreign country by using Nostro account channels. It may debit
customer’s account with bank charges in addition to the transfer amount. These
charges are then credited on line to a Profit and Loss heading by way of an entry in
CATEG.ENTRY. During the end of the month, the Bank may like to debit interest
and credit the customer’s account with monthly interest for maintaining credit
balance in the account. Debit to interest head is by way of CATEG.ENTRY record
and this is part of close of business job during the month end.

Accounting entry has the unique Id format for all three types of accounting entry.
Id comprises of first 5 digits for number of days since 31.12.1967, second five digit to
denote user number, third 5 digit to express transaction time in seconds since 0 hrs of the
day followed by ‘.’ and decimal seconds in two digits and ends with four digit sequence
number.
Note that, Time at which the transaction is input - Time in hundredths of a second since
midnight, consisting of 5 integers and (usually) 2 decimals. If the time is an exact number
of seconds since midnight, the decimals are omitted.
A sequence number. - If a transaction generates several Entries, all the Entries have parts (a)
(b) and (c) the same and are distinguished from each other by their Sequence numbers.
Transaction that generates the entry captures the accounting entry Id and the sequence
number.
If a transaction generates several entries, last part – Sequence number, distinguishes them
In case a STMT.ENTRY is consolidated, Id of the STMT.ENTRY.DETAIL will be attached

to the transaction.
If a transaction generates both CATEG.ENTRY and STMT.ENTRY , both could have
same sequence number also.
Id of CATEG.ENTRY are captured in the application like FT which produces CATEG
entries.
Multi value Field STMT.NO / STMT.NOS hold the Id of the entry, sequence number per set
of movement for STMT.ENTRY and then CATEG.ENTRY.

The Transaction codes contain and identify important processing conditions which
will be defaulted by the Applications if no other input has been entered at the
transaction level.
STMT.ENTRY and CATEG.ENTRY records use codes that are defined in
TRANSACTION table to narrate the transaction creating them.
Transaction code ranges have been assigned to some of the applications in T24. For
instance, LD application uses transaction code range of 400-499.
These transaction codes defined in transaction table are linked to applications
through their respective parameter tables like LD.TXN.CODES and
LC.PARAMETERS.
It is possible to define default values for exposure and value dates only when the
field DATA.CAPTURE is set to Y. The default values would be automatically
updated only in TELLER and DC transactions using those Transaction codes.
From R17, Transaction codes can be 4 digits, erstwhile it was only 3 digit
transaction codes. . EB.OBJECT Transaction record can further increase the length
of transaction upto 10 digits based on client requirement.
RE.TXN.CODE table : TRANSACTION.CODE of RE.CONSOL.SPEC.ENTRY
updated with RE.TXN.CODE IDs
RE.TXN.CODEs are hard coded .

Reflect stages in life of contracts and other events LNW, NEW, INC, DEC, ACC,

LIQ, MAT, SPT, REV etc CUS, APP SGN

From R15, two new RE.TXN.CODEs are added for TDGL Special entries. NPR for creating a
new entry and OPR for offsetting that entry. To reverse a special entry, REV can be used.

Transaction code: COMBINE.PROD.CAT, COMBINE.SYSTEM.ID and

COMBINE.TXN Fields are used to define the way that T24 combines accounting
entries together, at a transaction level.For instance, the User can specify that all
STMT.ENTRYs from a LD input with Category Code: 21052 be combined. In this
case, since the LD Category 21052 is used for Loan contracts, in case of a Loan
contract with this category, for a draw-down account the credit entry will be
combined with other debit entries, if any, on the same account for charges. Thus,
there will a single STMT.ENTRY for the net amount. This feature is currently
available only for LD application. Remember, this combination of entries is at a
transaction level, which is different from daily consolidation of entries, which is at
an Account or a Category level over a day, about which you will be learning later.
You can assign transaction-based charges in CHARGE.KEY Field of
TRANSACTION table. Such Charges should be defined in the
TRANSACTION.CHARGE table. These charges will be collected along with other
account maintenance charges, as per the frequency set in the COMPANY table. The
IMMEDIATE.CHARGE field does not have any effect on such charges. For
example, you can set a charge for any cash withdrawal from ATM based on specific
transaction codes used for ATM transactions.
It is also possible to charge based on transaction turnover or no. of transactions for a
specific transaction type. The parameters for such charges will be defined at
Account application level. However, to enable calculation of such turnover-based
charges, you have to set the field TURNOVER.CHARGE to Y in TRANSACTION

table.
RE.TXN.CODE carries only description and reversal marker for the code.

Account Module caters to creation and maintenance of all types of accounts handled
by T24. In T24, Accounts can be classified as two types, namely Customer accounts
or Internal type of accounts. Customer accounts are accounts opened for and owned
by external customers. External customers in the sense that it should be a valid
counter party. Internal accounts are accounts maintained by the bank for its own
purpose, like cash account, Travellers Cheque etc.
Accounts module provides for calculation, accrual and application of interest on
customers' accounts. Interest could be either a Fixed or a Floating rate. Further it can
be level or banded. In addition, it is used for calculation of charges relating to
maintenance and servicing of accounts. Rules for interest and charges can be set for
a individual account or for a group of accounts.
Account Balances can change from positive to negative balances and vice versa.
The balances of Account is held in the file EB.CONTRACT.BALANCES and the
Account application holds the static details of customer.
EB.CONTRACT.BALANCES is the balance look-up file for consolidation and is
updated online.

T24 Financial Accounting Features
In this demo, we would open a savings account with mnemonic SS1. We can open
an internal account.
Also open two current accounts in USD with mnemonic CA1 and CA2
T24 Financial Accounting - R15

Go to User Menu, Retail operations, Account and open savings account - local
The Savings account is opened here

Go to User Menu, Retail operations, Account and open Internal account
The internal account is opened here.

Go to User Menu, Retail operations, Account and open current account
The current account in USD is opened here

Entries in STMT.ENTRY file are generated to affect non contingent balances in

Accounts. For example, when one customer’s account is debited and money
transferred to another customer’s account, two entries in STMT.ENTRY file are
generated, one as a debit entry and another as a credit entry. During a month end,
when T24 debits interest/ interest payable and credits it to customer’s account, the
credit entry is in STMT.ENTRY file. This is generated as part of batch job. As
entries are System generated, they can only be seen and printed. Not possible to
delete or amend them. Concat files like ACCT.ENT.TODAY can be used to view
STMT.ENTRY affecting an account.
In Trade Dated accounting, the entries raised on non-contingent entries only on the
trade date. Value date is used only for interest purpose. Balances are updated
immediately either online or COB.
In Value Dated Accounting, for future value transaction, contingent entries appears
as Future value dated entries or Forward dated entries in STMT.ENTRY table.
These are replaced with actual non-contingent STMT.ENTRY on the value date.
Remember, only non-contingent entries that appear in account statement are
STMT.ENTRY.

In Trade Dated GL accounting, for future value transaction, special entries are raised
under RE.CONSOL.SPEC.ENTRY table, but with Non-contingent asset types called
as “PAY” and “RECEIVE”. These are reversed and replaced with actual non-
contingent STMT.ENTRY on the value date.

For Future value dated transactions, Forward valued STMT.ENTRY records are prepared on the
transaction date.The PROCESSING.DATE Field of STMT.ENTRY is updated with the value-date.
The Id of STMT.ENTRY will be updated in the live file ACCT.ENT.TODAY.
The cash-flow ladder AVAILABLE.BAL will be updated online as per the VALUE.DATE for debit
transactions. For credit transactions it will be updated as per EXPOSURE.DATE/VALUE.DATE
depending upon EXPOSURE.DATED.AF of ACCOUNT.PARAMETER is set to Y or not.
Generated for systems that has moved to Value dated accounting from Trade dated accounting
through ACCOUNT.PARAMETER setting namely FT,TT,DC,IC & SC
F entries are generated by only FI (Fixed Type) Standing Orders and contracts generate F entries for
future events like Principal/Interest Payments.
When a loan is given to a Customer, the repayment of principal and payment of interest is agreed
upon and scheduled accordingly. These are termed as future events in a contract.
Likewise, when a Standing order is accepted to debit an account on the fifth of every month and
transfer a specific amount to another account for the next two years, then there are scheduled
activities in future.
For such events, T24 prepares Forward dated entries if they are going to affect the non contingent
balance in an account. These entries are also stored in STMT.ENTRY file. Their id is however
different. Id comprises of F to denote that they are future dated entries. This is followed by the date
on which these F entries will be converted into a normal accounting entry.
Remember for local clearing, T24 OFS clearing accepts incoming transactions with value date
greater than the current date as “F” entries by setting up AC.ENTRY.PARAM. On the value date “F”
entries are dropped and real entries are generated by use of the relevant AC.ENTRY.PARAM
records through local development.

For Future value dated transactions, Forward valued STMT.ENTRY records are prepared on the
transaction date.The PROCESSING.DATE Field of STMT.ENTRY is updated with the value-date.
The Id of STMT.ENTRY will be updated in the live file ACCT.ENT.TODAY.
The cash-flow ladder AVAILABLE.BAL will be updated online as per the VALUE.DATE for debit
transactions. For credit transactions it will be updated as per EXPOSURE.DATE/VALUE.DATE
depending upon EXPOSURE.DATED.AF of ACCOUNT.PARAMETER is set to Y or not.
Generated for systems that has moved to Value dated accounting from Trade dated accounting
through ACCOUNT.PARAMETER setting namely FT,TT,DC,IC & SC
F entries are generated by only FI (Fixed Type) Standing Orders and contracts generate F entries for
future events like Principal/Interest Payments.
When a loan is given to a Customer, the repayment of principal and payment of interest is agreed
upon and scheduled accordingly. These are termed as future events in a contract.
Likewise, when a Standing order is accepted to debit an account on the fifth of every month and
transfer a specific amount to another account for the next two years, then there are scheduled
activities in future.
For such events, T24 prepares Forward dated entries if they are going to affect the non contingent
balance in an account. These entries are also stored in STMT.ENTRY file. Their id is however
different. Id comprises of F to denote that they are future dated entries. This is followed by the date
on which these F entries will be converted into a normal accounting entry.
Remember for local clearing, T24 OFS clearing accepts incoming transactions with value date
greater than the current date as “F” entries by setting up AC.ENTRY.PARAM. On the value date “F”
entries are dropped and real entries are generated by use of the relevant AC.ENTRY.PARAM
records through local development.

As long as the value date is the same date as trade date or date prior to trade date, there is no
difference between Trade dated, Value dated and Trade Dated GL accounting.
Under Value dated Accounting, if the value date is in future, the balance to be updated immediately
is the contingent balance. The non contingent balance will be updated only on the value date. But the
entries will be reported in account statement only after value date.
RE.CONSOL.SPEC.ENTRY is passed to update the contingent balance. Cash flow ladder in the
underlying Account is also suitably updated. The contingent balance in the account is reversed on the
value date by the reversal entry in the form of RE.CONSOL.SPEC.ENTRY. Both the entries,
contingent and its reversal are created online though the reversal entry is used only on the value date
to reverse the contingent.
Though the non contingent balance is required to be updated only on the future value date, a
STMT.ENTRY is passed on the trade date itself, but its processing date is set as the future value date
and not the trade date. On the value date, this entry takes effect and updates the on line balance of
the underlying account.
Any value dated transactions (e.g. Data Capture, Funds Transfer and Teller) with exposure date or
value date beyond the window will cause the window to expand for that account.
As a consequence of this, any forward dated transactions (e.g. Money Market, Loans) with a value
date beyond the window will automatically be included in the available funds ladder.
Under Trade dated GL Accounting, the balances immediately reflect in GL on Trade date as Non-
contingent balance with Asset Types “PAY” and “RECEIVE”, for a future value dated entry.

In this screenshot we can find the sample files of forward entries. We see
TRANS.FWD and ACCT.ENT.FWD files here.
Account wise forward dated entries are stored in an internal file ACCT.ENT.FWD.
These are also reflected in another way, where they are grouped contract wise and
stored in TRANS.FWD file.
Even if the value-date of a contract is before the PERIOD.END of DATES i.e. on or
before the next working day, only F entries will be generated for the account and
contingent entries generated for the account.
Under Future value dated transactions:
For split value dated transactions where the debit value date and credit value date
are different, system parks one part of the transaction in Suspense accounts and
reverses the same on second value date.
In case, the future value-date is before the PERIOD.END in DATES i.e. on or
before the next working day, the accounting entries and update of balances will be
similar to trade dated accounting.
For forward entries, the F STMT entry generated would trigger the actual entries on
the value date

In this workshop, let us transfer USD12345 from CA2 to CA1 for value today using
FT application.
Let us have a look at the entries generated.

Go to User Menu, Retail operations, LCY Draft Issue/Acct Trfr, Transfer between
Accounts
The amount 12345 is transferred from CA2 to CA1 value today

Go to User Menu, Finance, Journal Facility, Accounting Entries Enquiry, List of

Unauthorised transaction Entries
The entries related to the FT transaction are listed here.

The STMT.ENTRY is seen here

In this workshop, let us book a FT with a back dated value for an amount of USD
15000
Let us have a look at the accounting entries generated

The FT transaction is booked for a back value date as seen in this workshop

This enquiry shows the accounting entries generated

We can find the statement entry generated with back value date and current
exposure date.

In this workshop, we will input a transfer of USD 2500 from CA1 to SSS using the
Data Capture application.
We can find the impact on balances of account to identify that the balances were
updated immediately as DC is a trade dated application.

The account transfer is input for future value date through DC application

The future value dated DC transaction is updated in ECB as a Non-contingent entry

since it follows Trade Dated Accounting and the debit movement in account is
updated on Today’s date.

The balance updates and entries can be seen from the enquiry seen in the
screenshot.

In this workshop, we would transfer USD 2000 from CA1 to SS1 using FT
application with debit value after 1 month and credit value after 15 days and get the
entry authorised.
We would check on the update in the balances of the account.

Go to User Menu, Retail Operations, LCY Draft Issue/Acct Trfr, Transfer between
Accounts
Please recollect that FT system was already moved to Trade Dated GL accounting in
Workshop 1.
We have now input a future value dated FT transaction between CA1 and SS1.

Let us have a look at the accounting entries.

We find the value date of the STMT.ENTRY is the future value date.

The balances updated in ECB are seen here. Since FT follows Trade Dated GL
system, the debit of $2000 is entered with a non-contingent asset type “RECEIVE”.
From R15, to know the future value dated movements, two new fields are added to
hold the future dated movements called as AUTH.PAY.MVMT and
AUTH.REEIVE.MVNT.
Also, a new balance field called as TRADE.DATED.GL.BAL will be added in

EB.CONTRACT.BALANCES to hold a Trade dated GL Balance
(Online.Actual.Bal + AUTH.PAY.MVMT + AUTH.RECEIVE.MVMT)

The balances updated in ECB are seen here. Since FT follows Trade Dated GL
system, the debit of $2000 is entered with a non-contingent asset type “RECEIVE”.
From R15, to know the future value dated movements, two new fields are added to
hold the future dated movements called as AUTH.PAY.MVMT and
AUTH.REEIVE.MVNT.
Also, a new balance field called as TRADE.DATED.GL.BAL will be added in

EB.CONTRACT.BALANCES to hold a Trade dated GL Balance
(Online.Actual.Bal + AUTH.PAY.MVMT + AUTH.RECEIVE.MVMT)

ACCT.ACTIVITY, STMT.PRINTED, STMT2.PRINTED and

CONSOL.UPDATE.WORK updates happen online from R6 release.
In ACCT.ACTIVITY table, for each account and month, history of Value Dated
Balances, Book dated balances and statistics about all entries processed are
maintained. Balances update by booking date happen from R6 release. The
booking-date balance for the current day will be equal to the current
ONLINE.ACTUAL.BAL and the balance for a prior processing day will be equal to
that day’s closing ONLINE.ACTUAL.BAL. ACCT.ACTIVITY file will be feeding
statement information uploaded from STMT.ENTRY files
The Id of CONSOL.UPDATE.WORK is Consol Key’Asset Type’Processing Date’.
Processing Date in case of future value-dated entries in a value-dated accounting
system will be equal to the value-date. The Asset Type will be the Asset Type under
which the account’s balances have been consolidated in the previous day. In case of
new accounts, its value will be “NILOPEN-Account No.”. The Field
OPEN.ASSET.TYPE in an Account holds the opening Asset Type for the Account,
which will be updated with the value NILOPEN when the first transaction in a new
account is input. This field will be updated with appropriate asset type of the
account balance during COB.
ACCT.ENT.TODAY file is cleared during COB and copied to
ACCT.ENT.LWORK.DAY file.


We can find the ACCT.ACTIVITY record being created for an account month wise.
CONSOL.UPDATE.WORK holds the debit and credit movements for a

combination of Consol Key, asset type, session no and Booking date.

The following STMT.ENTRY related enquiries are available in T24.

1.STMT.ENT.BOOK for an account shows booking period movements and
balances with value date, posting date etc.
2. .STMT.ENT.TODAY for an account shows movements and balances
for the system date which is same as posting date.
3.%ACCT.ENTRY.FWD is an enquiry for an account to show forward
dated entries.

We have seen that accounting under Trade dated accounting is quite simple. On the
Trade date, what ever be the value date, accounting entry is passed and on line
balance of an account is updated. This is updated as non contingent balance. The
entry is stored in STMT.ENTRY file and details thereof are kept at
ACCT.ENT.TODAY file. This choice is available only for Account based
applications and Securities.
Under value dated accounting, till the value date, the Assets and Liabilities are
considered as contingents. On reaching the value date, they are considered as non
contingents.
If this choice has been opted for Account based applications and Securities, then
RE.CONSOL.SPEC.ENTRY is passed on the transaction date and balance in the
account is contingent balance. STMT.ENTRY is also prepared but with a future
processing date. On the value date, STMT.ENTRY is processed and contingent
balance is reversed and non contingent balance is updated.
Under Trade Dated GL accounting, for account based applications and securities,
RE.CONSOL.SPEC.ENTRY is passed on the transaction date but balance in the
account is non-contingent balance. STMT.ENTRY is also prepared but with a future
processing date. On the value date, STMT.ENTRY is processed and
RE.CONSOL.SPEC.ENTRY is reversed and account balance is updated.

Contracts uniformly follow value dated accounting. They also produce Forward dated entries.
Forward dated entries of STMT.ENTRY generated by contracts and Standing orders will
move from ACCT.ENT.FWD to ACCT.ENT.TODAY on the relevant value date. Actual
STMT.ENTRY will be generated and online balance affected only then.

1)Ans: True. In T24, account statements for customer type as well as internal
accounts are produced using entries in STMT.ENTRY
2)Ans: True. The difference comes because of a future value date. As long as the
value date is same or prior to transaction date, there is no difference in accounting.
3) Ans: False. Accruals do not affect the balance in an account. Hence this will not
be a STMT.ENTRY. (It will be an entry on RE.CONSOL.SPEC.ENTRY on one
side and CATEG.ENTRY on the other). Only on the day of capitalisation,
account balance is affected. Hence, only for capitalisation, it will be a
STMT.ENTRY
4) Ans: False. For capitalisation, contract maturity etc., balances in accounts will be
affected during COB. Hence these entries can also be passed during batch run
5) Ans: False. Only non contingent balances are updated by STMT.ENTRY.
Contingent balance will be updated by RE.CONSOL.SPEC.ENTRY
6) Ans: False. They are produced by Standing orders also
7)Ans: False. Cash flow is calculated and overrides displayed only for the period set
in ACCOUNT.PARAMETER

CATEG.ENTRY: In case of Trade dated accounting, the accounting entry is

consolidated on the Booking Date in the form of a PL (non-contingent profit) key.
Consolidation key value is updated on-line in the entry. Work-file
PL.CONSOL.UPDATE.WORK is updated online. This file holds the consolidation
key-wise movements for the day, which is used to update the CRF base during COB.
We have seen that a value date in accounts and contracts is associated with interest
calculation. Then how is it relevant in a Profit and Loss item? Contracts do not pass
any future dated Profit and Loss accounting entry, though they uniformly follow
Value dated accounting. Do not count your chicken till your eggs are hatched. T24
follows this conservatism principle for Profit and Loss items. Only Account based
applications with value dated accounting options can produce a forward valued
Profit and Loss accounting entry. This is then considered as a contingent Profit and
Loss item till the value date is reached. There upon this is considered as a non
contingent or regular Profit and Loss item. The difference thus lies in consolidating
these items as CP items till value date and as PL items thereafter. Hence on the trade
date, a debit and credit entry with CP consolidation is generated one with a value
date of the transaction and the other with value date in future. Along with them a
normal entry is also passed with future value date. All these are stored in
CATEG.ENTRY file. While the first two entries go to create a contingent today and
reverse it on the value date, the third entry is used to create a non contingent or a
normal consolidation on the value date. With the introduction of IFRS module in
R10, to ensure compliance with IFRS, you will find CAL records with position
types as TR and also IF to reflect IFRS entries. Similarly, CPL records will reflect

the position type as either IF or TR. For example, you may find records containing CPTR
which means contingent profit with position type as TR. PLTR will mean regular profit and
loss with position type as TR and so on.
From R15, Trade Dated GL accounting, follows the same method as that of Value dated
accounting for P&L movements, i.e. treated as contingent between the trade date and the
value date.

CATEG.ENT.TODAY file is cleared during close of business and its contents are
copied into another internal file CATEG.ENT.LWORK.DAY.
In addition, during close of business, CATEG.ENT.ACTIVITY file is also built
from out of details available in CATEG.ENT.TODAY. This is useful to maintain
daily activity for every Profit and loss head.
GET.CATEG.MONTH.ENTRIES routine can fetch the list of CATEG.ENTRY IDs
from CATEG.ENT.ACTIVITY for a given CATEGORY and period.
CATEG.ENT.FWD which was updated by forward value-dated transactions in a
value-dated system is no longer updated. Instead only CATEG.ENT.TODAY is
updated by CATEG.ENTRY.
There is a work file PL.CONSOL.UPDATE.WORK which is updated online. This is
used to update Profit and Loss consolidation keys during COB. The consolidation
keys are decided online and their Ids are available in the respective CATEG.ENTRY
. But the balances in the keys are updated only during COB.

The following enquiries are available for CATEG.ENTRY.

1. CATEG.ENT.BOOK.STD. for a PL Category head for any given period shows
movements and balances for PL category with Value Date , posting date etc.
2. CATEG.ENT.FWD shows details of category wise value date wise
details of future dated entries.

In this workshop, we can input a transfer of USD 10000 from staff salary PL code to
Special savings account (SS1)
The transaction is a future value dated transaction booked using FT application.

We can find the funds transfer being booking between the PL head and customer
account with future value date.
Please recollect FT system is moved to Trade dated GL accounting

The accounting entries are generated as contingent entries and booked as non
contingent entries on value date




In this workshop, we can input a transfer of USD 5000 from staff salary PL code to
Special savings account (SS1)
The transaction is a future value dated transaction booked using DC application
which is in trade dated system.

The transfer is booked in the DC application as Debit and Credit legs.

In this enquiry, we can find the accounting entries generated for this transaction

The entries generated are seen here.


The CATEG.ENT.ACTIVITY and CATEG.ENT.MONTH records are updated here.


The PL.CONSOL.UPDATE.WORK file is updated as seen here.

The PL.CONSOL.UPDATE.WORK file is updated as seen here.

Under Trade dated accounting, accounting entries affecting Profit and Loss heads
are stored in CATEG.ENTRY file on the transaction date. Internal file
CATEG.ENT.TODAY holds details of entries for the day. During close of business,
these entries update non contingent or normal Profit and Loss consolidation keys.
Under value dated accounting and Trade Dated GL accounting for account based
applications, it is possible to create a future value dated Profit and Loss accounting
entry. While this has no effect on any interest calculation, it goes to update the
contingent balance of a Profit and Loss head. On the value date, this is reversed and
a regular consolidation takes place. For this purpose, another entry is also stored in
CATEG.ENTRY file on the transaction date itself, but with a future value date.
Contracts do not generate any Forward dated entries in CATEG.ENTRY file.

1) True. CATEG.ENTRY records do not update any accounts as there is no concept

of Profit and Loss accounts in T24. Profit and Loss items are maintained only at
consolidation level and updated by CATEG.ENTRY
2) False. Only Securities and Account based applications of FT, DC and TELLER
can create accounting entries with future value date for Profit and Loss headings
3) False. It is possible to debit or credit a Profit and Loss item using Account based
applications. If value dated accounting or TDGL has been opted, then there would
be a contingent item for future dated PL transaction.
4) True. When interest is accrued, one side of the accounting entry will affect a
Profit and Loss heading and the other side will affect Assets and Liabilities. Hence,
CATEG.ENTRY will be produced for PL side of accrual activity.
5) False. Accruals are done only during COB, besides other jobs affecting Profit and
Loss heading. Hence these entries will happen during COB also

7) False. Contracts cannot produce any forward dated Profit and Loss entries
8) False ,T24 does not produce any forward dated CATEG.ENTRY. Cash flow is
calculated only for Customer type of accounts

All entries other than those affecting non contingent balances in Accounts and
contingent and non contingent balances of Profit and Loss heads are grouped
together in RE.CONSOL.SPEC.ENTRY file.
The nature of entries in this file is quite varied.
All accounting entries raised for generating contracts, contingents as well as non
contingents are all in this file. When a loan transaction is input on the value date, it
generates non contingent loan. When it is input before its value date, it generates a
contingent loan. When a letter of credit or a guarantee is issued, they remain as
contingents till the Bank meets its obligation. Likewise, in the case of a three
months forward contract, till delivery, the obligation is contingent.
In a value dated accounting set up for Accounts, contingent entries raised are in the
nature of RE.CONSOL.SPEC.ENTRY.
All other entries affect contracts or accounts uniformly, like the entries for accruals
or capitalisation that affect the Assets and Liabilities side.
When positions are revalued, one side affects profit and loss while on the other side,
the Assets and Liabilities are revalued. The change in values of Assets and
Liabilities is done through entries in RE.CONSOL.SPEC.ENTRY .

The movement entries for updating transfer of balances between consolidation keys
are stored here. These are special entries and are unique to T24 set up of
consolidation keys.
Let us assume that a Bank does consolidation of loans based on the nature of loans
and industry of the Customer availing the loan. One element of consolidation is
from the business application and that is nature of loan. The second element is from
the industry of Customer.
Let us assume that a Customer engaged in Shipping industry has availed a Corporate
loan of USD 1 million.
While disbursing the loan, one RE.CONSOL.SPEC.ENTRY is passed to debit loan
and give money to the Customer’s account (by way of a STMT.ENTRY). At the end
of the day, this loan balance is consolidated as Corporate loan in USD to Shipping
industry.
After some time, the Customer decides to change his industry as Ship breaking.
Now there is no change in anything else, except that the loan should now be re
classified as Corporate loan of USD 1 million to Ship breaking industry in its
reports. In T24, a simple change in industry classification in CUSTOMER record is
enough to make this change system wide, for any number of loans and accounts of
the Customer.
T24 automatically passes an entry to reverse the earlier classification and another
entry to debit the new classification. Both these entries remain in

RE.CONSOL.SPEC.ENTRY file.

Here we see the effect due to a change in overdue status.

A customer has taken a loan which is repayable in installments. After some time, the
first installment has fallen due. It alone moves to Past due while the rest of the
instalments are still current.
The bank consolidates its loan balances based on status of loans also (besides other
choices). It has also opted that the worst status of any part of the loan should be
applicable to the loan in full, though some parts of the loan may not even be due for
repayment.
The part of the loan that is now over due then affects the status of the other parts of
the loan which are still not even due for payment.
How will this change in one part of the over dues affect the loan balance
consolidation ?
Depending on the changes happening in PD.PAYMENT.DUE record of the
overdues, the underlying status of loan also changes to PDO. The outstanding
current Principal parts are credited back to the old key with overdue status as Nil
and debited to another key with overdue status as PDO.
Similar treatment is done for interest accrued on the loan.

RE.TXN.CODEs are hard coded. This file defines CRB codes with descriptions
for enrichment. They indicate the nature of transactions say
LNW for Live New Principal; NEW for new contracts; INC for any increase in an
existing contract; ACC for accrual; SPT for Spot; REV for Revaluation;
DEC for decrease in an existing contract; LIQ is for liquidating; MAT is for
contract maturity.
CUS and APP used in Consolidation key movements for Customer level and
Application level static changes affecting key. Example: When Category code of an
account changes and if consolidation done Category code wise.
SGN: RE.CONSOL.SPEC.ENTRY record generated to move the Account
consolidation balances from Debit to Credit Asset types, when the sign of account
balances change.
New contracts in all applications except FOREX generate
RE.CONSOL.SPEC.ENTRY online. They all update
EB.CONTRACT.BALANCES online . Though RE.CONSOL.SPEC.entry is raised
during COB for FOREX, it updates EB.CONTRACT.BALANCES online with
Forward STMT.ENTRY Id.
New FOREX contracts and Commitment transactions in
LD.LOANS.AND.DEPOSITS generate RE.CONSOL.SPEC.ENTRY during close
of business. As the nature of these entries is contingent, Commitments update
EB.CONTRACT.BALANCES during COB.

Entry Contains essential details like Deal Number, Product Category, amounts in local and
foreign currencies, exchange rate, Customer, Transaction code, Booking and Value dates,
Consolidation key details.

Contracts other than Securities uniformly follow value dated accounting. The
concept behind this is to differentiate them as contingents or non contingents in the
books of Banks.
In case of loans, if value date is a date in future, until the value date is reached,
contract is considered contingent. On value date, contract turns non contingent. T24
passes suitable entries for generating contingent entry, reversing it and passing a
new entry for making the asset a non contingent one. All these entries are stored in
RE.CONSOL.SPEC.ENTRY file. T24 has different hard coded Asset types to
differentiate the contingents from non contingents like FORWARDDB and
LIVEDB, FORWARDCR and LIVECR. Contingent RE.CONSOL.SPEC.ENTRY
records are consolidated under asset types like FORWARDDB, FORWARDCR, etc.
Some modules like LD, MM and SW create F entries in STMT.ENTRY file without
any underlying account number. These entries are used to generate reversal entries
in RE.CONSOL.SPEC.ENTRY on the value date.

Banks generally accrue interest on loans and deposits. A bank may opt to accrue
interest daily, with the facility to reverse and repost the daily accruals. Generally
the, the transactions codes used for interest and commission either on accrual or at
capitalisation are same. If opted for reverse and repost, the transaction code “ACC”
is used for all the accruals done and transaction code “RAC” is used for the reversal
of accruals for the RE.CONSOL.SPEC.ENTRY generated.
In some instances it is necessary for a bank to separate the accruals on
capitalisation date and to identify them differently, separate transaction code viz.,
CAS is used in RE.CONSOL.SPEC.ENTRY record.
If separate transaction codes are needed for CATEG.ENTRYs as well, it can be

coded through fields APP.CASH.TXN.CO and CASH.TXN.CODE in
ACCR.REV.PARAM table.
The field CASH.TXN.CODE is a default catch all application. Separate

Transactions codes, application wise, can be opted through APP.CASH.TXN.CO
field.

In this workshop, let us book a loan for fixed interest with start date as a future date
and maturity 3 months after start date.
We can have a look at the forward entries generated and the related enquires.

Go to User Menu , Treasury Operations , Forex & Money Market Trader , Front
Office , Money Market Trader , MM Placements/Loans , Input Fixed Maturity
Contracts
Input a loan value T+15 and with maturity 3 months after that.
To authorize the above deal, please go to User Menu-Treasury Operations- Forex &
Money Market Trader-Back Office – Authorise/Delete MM Transactions.

The forward entries generated for this loan are displayed here

The F Stmt entry generated for this transaction are listed here.

We can find the Fstmt entry for the account leg has the account number displayed
and the contract leg doesn’t have the account number displayed

In this workshop, we have input a loan for value today and maturity 3 months from
then.
Let us have a look at the accounting entry generated in the related tables.

Go to User menu, Treasury Operations, Forex & Money Market Trader, Front
Office, Money Market Trader, MM placements/Loans, Fixed Maturity contracts
Input the contract as desired.

The accounting entries can be seen in the enquiry as displayed here.

The non contingent entries are generated directly for the start date

The F STMT entries for the maturity leg are generated as forward entries

We can find the F STMT entry for the principal and interest legs of account here.

When the transaction date is equal to or less than value date (i.e. value date is
reached), the asset type of the entry is non contingent and consolidated into AL key
as Non Contingent. Examples of such asset type are LIVEDB or LIVECR.
When the value date is future, the entries for transaction date show suitable
Contingent Asset type and the same are consolidated under Contingent Asset or
Liability. Examples of such asset type are FORWARDDB or FORWARDCR. On
the value date, contingent entries are passed to reverse the Contingent Asset or
Liability created on transaction date; and non contingent entries are passed to update
non contingent balances and are consolidated under non contingent asset type.
In case of forward dated contracts, some modules like LD, MM and SW create
entries in STMT.ENTRY file on the booking date without any underlying account
number. These entries are used to generate reversal entries in
RE.CONSOL.SPEC.ENTRY on the value date.
TRANS.FWD file has details of future valued entries and on the value date, they are
moved out and Non Contingent entry in RE.CONSOL.SPEC.ENTRY becomes
effective and these entries update the Non Contingent Assets and Liabilities key.

All Applications, except FX, generates RE.CONSOL.SPEC.ENTRY online and also

update EB.CONTRACT.BALANCES online.
For FOREX application, since delivery is taking place generally after two working
days for SPOT deals and after SPOT date for forward deals,
RE.CONSOL.SPEC.ENTRY is generated during COB.

Of all the Contract Applications in T24, SECURITIES is the only application with
the option of Trade dated accounting or Value dated accounting.
Under Trade dated accounting, irrespective of value date, Non Contingent
accounting entries are passed online on the transaction date itself and consolidated
into non contingent AL balance during COB.
Under Value dated accounting, if the value date is in future, Contingent entry, its
reversal entry and Non Contingent entry are prepared on the transaction date itself
and stored in RE.CONSOL.SPEC.ENTRY file with different value and processing
dates. On Transaction date, Contingent consolidation takes place through the first
Contingent entry. On the Value date, the Contingent consolidation is reversed
through the reversal Contingent entry. Through the third entry which is Non
Contingent, Non Contingent balance/consolidation is updated on the value date.
Under Trade Dated GL Accounting, for future value dated transactions, special
entries are raised with non contingent asset types and are stored in
RE.CONSOL.SPEC.ENTRY. On value date, these entries are reversed and replaced
with non contingent entries hitting STMT.ENTRY.

Entries for accruals, capitalisation and contract maturity are generated during COB
.
A Bank may like to prepare its Profit and Loss accounts on a daily basis. Hence,
every day it would accrue interest. These accruals are not passed on to Customer
accounts if the Bank wants to settle the interest on a different frequency. For
accruals in a loan, Interest receivable is debited and Profit and Loss is credited.
In T24, Interest Accruals are stored in ASSET.TYPEs (details of ASSET.TYPE are
discussed in the later part of this course) and so there is no need to open any account
head for Interest Receivable. If the loan is consolidated as Corporate Loan to
Shipping industry, then the interest due on these loans will also be consolidated
under the same heading but as a different Asset type – Interest receivable.
For debiting this Asset type, a RE.CONSOL.SPEC.ENTRY is generated and to
credit the PL, a CATEG.ENTRY is generated.
When the bank settles the accrued interest, accruals till the date are reversed through
a RE.CONSOL.SPEC.ENTRY and to settle it to the customer account,
STMT.ENTRY is generated

1) False. These entries are used for updating balances in contracts, consolidations
and accruals, etc. and also for movement of balances between CAL keys.
2) False. Entries are always generated irrespective of the value date.
3) True , When interest is accrued, one side of the accounting entry will affect a
Profit and Loss heading and the other side will affect Assets and Liabilities. As the
non contingent balance in the account does not undergo any change, the entry will
not be a STMT.ENTRY, but RE.CONSOL.SPEC.ENTRY to affect the Assets and
Liabilities.
4) False, RE.CONSOL.SPEC.ENTRYs are generated both online and during COB
5) True. Contingent balances even in accounts are produced only by
RE.CONSOL.SPEC.ENTRY

The EB.CONTRACT.BALANCES file records the information held in the

CENTRAL.REPORTING FILE '(CRF)' down at contract level.
The purpose of this file is to :
Allow the user to see the online effect of a transaction to the CRF
Provide drill down information from a reporting line
Be used as the basis for the CRB rebuild
Be used as the basis for CRB static changes.
Information is held on this file includes:

Currency of the balance
Multi-valued set of fields detailing CRB asset types and associated value date,
maturity date, and amount of outstanding CRB balance.
Consol key

In this workshop,
Let us create a LD deposit with start date as future date but within the cashflow
ladder and maturity date beyond the cash flow ladder.
Have a look at the balance updates and the accounting entries generated.
Let us input a FT with value date after the maturity date of the LD and have a look
at the balance updates.
Let us also have a look at the contingent spec entries generated for the future value
dated FT transaction.

Account.parameter has a setup of cash flow days as 5 Days

New Account is created and a loan is released with value date T+2 and maturity date
after T+5 .

The balance update and accounting entries are seen here.

Only the entry that falls inside the account parameter ladder updates available
balance.
That is, the maturity amount is not seen as available balance in ECB.

The Fstmt entries are seen here for the loan creation and maturity. These are trigger
entries and are single leg entries.

The contingent entry for creation of contract is seen in RE.CONSOL.SPEC.ENTRY

The FT is input with a value date beyond the maturity date of LD.

STMT.ENTRY raised for both debit and credit legs on Trade date itself

The ECB record shows USD 100 from 7th May 2015

The ACCT.ACTVITY table is used for the Interest calculation as it records the Balances
based on the Value date. The VALUE.DATE on an entry determines when the balance for an
entry is used for interest calculation. The value date can be backdated or future dated. The
Interest calculation on an account uses the Value dated balance as recorded In
ACCT.ACTIVITY record for that account.
From R16, Interest can be calculated based on cleared balance. Cleared balance is values of
all authorized entries over the Account, except any credit or reversal debit entries with
future exposure dates
For Interest Calculation on cleared balance, balances are being considered from
ACCT.ACTIVITY record. So ACCT.ACTIVITY can be built based on the Exposure Date
rather than the value date and there is a set up done at ACCOUNT.PARAMETER level. It
can either be at application level or a category level choice is possible
The statement entries which are raised after the Exposure Date setup is turned on, will have
the value EXPOSURE.DATE in the field TDGL.DETAILS for calculation of interest only
for credit transactions. If the setup in turned off, then the field will be having the value
VALUE.DATE
Note that the possibility to adjust the exposure date of one or more transactions is possible
with AC.REBUILD.EXPOSURE. AC.REBUILD.EXPOSURE is discussed in detail on

Account courseware Features learning unit. While using AC.REBUILD.EXPOSURE if

ACCT.ACTIVITY based on the exposure date it will also be modified accordingly. Also
consolidate entries for rebuild exposure cannot be set to yes.

In this workshop,
Let us setup Account activity update for specific category code for calculating
interest on cleared interest.
Now the FT has to be input with future exposure date
The results are to be observed

ECB and ACCT.ACTIVITY balances of the accounts are observed

Account parameter of that category is set up as Exposure dated category

FT is input for future exposure date

The accounting entry has the TDGL.DETAIL.8 updated as EXPOSURE.DATE to

indicate account parameter choice for the account.

Acct activity is for the credit entry for 38.08 USD effectively.
Can you identify why the debit is for 22nd itself while credit is for 30th in Acct
Activity
Yes – As Exposure date is for credit entries only.


CATEGORY, AC.CONSOLIDATE.COND and ACCOUNT.CLASS are some of the

important parameter tables to be set up for Accounting.
Please note that local currency accounts should be opened for all the category codes
defined in ACCOUNT.CLASS Account type records. This will enable system to do
automatic processing of transactions in foreign currencies by opening accounts in
that currency.

In T24 all dealings are classified either under Accounts or Contracts. Customers have
different types of Accounts such as, Current Accounts, Savings Accounts, and so on.
To reflect the balances in T24 Banks’ Nostro Accounts with other Banks, T24 Banks
open mirror accounts as Nostro Accounts in their books. There are internal accounts,
which are bank’s own accounts, e.g. Cash, Capital & Reserves, Premises & Furniture,
Departmental and other Suspense Accounts, Tax awaiting Payment to Authorities etc.
All in one product and AA modules use accounts. The main difference between an
Account and a Contract is that Account permits the balance to be debit or credit from
time to time, whereas in any particular contract, while the balance may change from
time to time, its sign will not change from the original. At the period end, the balance
only becomes NIL. Customers may have Contracts such as Money Market deals,
Securities contracts, Loan contracts, and so on. It may be observed that in all these
contracts, the initial sign never changes to the other sign. Loan is always a loan and it
does not become a deposit and a deposit contract can never become a loan contract.
This also means, Loan is always a loan and it does not become a deposit if the
Customer pays more than his dues and a deposit contract can never become a loan
contract.
T24 does not use “Accounts” for Profit and Loss heads. Then how does it manage
Profit and Loss? Here comes the Category codes to differentiate one PL heading from
another and then rules for consolidating PL accounting entries. Interest, Discount,
Salaries, Commission are examples of PL headings. Unique Category codes are
assigned to these headings to differentiate one from the other. Then by proper
consolidation, PL heads are grouped. For example, Interest income from Corporate
Loans given to US residents engaged in Software industry, Commission on Letters of

Credit opened on behalf of UK residents engaged in Iron and Steel Industry etc. PL heads are
broadly classified as Product related heads and Overheads. Product related income or expense
result out of banking products. For example, Interest on Loans, Commission on LC, Charges
on Current Account etc.

The category table is one of the most important tables for accounting.
In T24 you will not be able to create an account without having a category linked to,
or you will not be able to input a contract based transaction without link to a
category which indicates which product or sub-product the transaction belongs to.
Every product, be it an account or contract or Profit and Loss head, should be
suitably defined in CATEGORY table.
A Category code is a 5 digit number. The first two numbers are meant for the
highest level of classification and are hard coded. The other three digits are user
definable.
For example, in a Category code of 1001, it should be considered as 01-001 to make
it as a five digit number. The first two digits of 01 are part of hard coded range for
Customer type Account products (01 to 09).
Hence, a user can configure a Current account as 01-001 or 01-002 or 01-345 or 01-
999…
Likewise, a product to use LD.LOANS.AND.DEPOSITS can use only codes
beginning with 21, which is the top level grouping. A user can define deposit and
loan products within this broad hard coded range. In this case, there are further sub-
classifications, which we shall see later.

Accounts use 1000 to 19999 range. Accounts are classified into 2 broad ranges as
Customer Accounts and Internal Accounts. Customer Accounts are allocated the
range of 1000 to 9999, whereas Internal Accounts are allocated the range of 10000
to 19999. It is possible to accrue Interest for Customer Accounts, whereas it is not
possible to accrue interest for internal accounts. Within Customer Accounts,
product wise ranges are also suggested by Temenos.

Contracts use 20000 to 49999 range. Under this broad range, each application has its
own allocated range.
FOREX application can use only 20000 to 20999 range while
MM.MONEY.MARKET and LD.LOANS.AND.DEPOSITS applications share the
same range of 21000 to 21999, as their business is similar.
However, as these handle deposits as well as loans, and as accounting is automatic,
there are sub ranges for deposits and loans. If a loan business product is made to use
the range meant for a deposit product, accounting entries will be passed as though it
were a deposit. Hence, we should be careful in using the correct range for the
correct business product.
While Securities have a range of 22000 to 22999, they use only one single defaulted
category code of 22999.
Similarly for every other Contracts application, there is a particular range to be
used, all of them falling within 20000 to 49999 range.
These ranges and sub-ranges within facilitate automatic accounting.

The Profit and Loss items are broadly classified as Product related items and Non
product related items or overheads.
Accordingly, 50000 to 59999 is used for product related Profit and Loss items and
60000 to 69999 is used for overhead items.
Product related income or expenditure arise from Bank’s operations like Loans,
Deposits , Letters of Credit ,Overdrafts , Savings accounts etc.
Overheads cannot be linked to any specific banking product and are mostly internal
expenses and income resulting from day to day operations.
The Closing category specified in FX.POS.TYPE table (69999) is used during
annual closing to transfer balances from all Profit and Loss items. This is finally
transferred to Internal Account specified in ACCOUNT.CLASS table with Id of
PLCLOSE.

It is also possible to default category codes through appropriate versions.

Wherever, category codes are not parameterised, user need to input category codes.
Ex. Input of LD contract. Category codes in versions can also be amended.
The use of these codes, together with selection criteria defined in the
“CONSOLIDATE.COND” table, e.g. Residence, Status, Industry and Sector codes
etc., enable the Bank to produce balance sheets and returns reflecting a coordinated
and structured view of its operations, by directing business transactions to their
appropriate place on the report.
(1) Loans by Industry (Criteria - Industry) segment
(2) Geographical distribution (Criteria - Residence) of Loans & Deposits
(3) Sectoral (Criteria - Sector) distribution of Loans & Deposits
A Category table is delivered with every T24 implementation to save time creating
thousands of records from scratch. Clients can decide to use the delivered
categories, add new ones within specific ranges, modify those that need changes and
mark as `Reserved for future use’ those categories that they do not use immediately.
Examples of reports using category codes.
Housing loan in USD for residents of USA engaged in software industry
Housing loan in USD for residents of UK engaged in iron and steel industry
Vehicle loan in USD for residents of USA engaged in software industry

The first two digits of Category code represent the highest level of classification
and next three digits represent a sub-classification. Description is for naming the
product and short name for enrichment.
System Id is to fix category to particular application. MNEMONIC Field is for
alternate identification of category code.
If entries are to be consolidated, CONSOLIDATE.ENT Field should contain Id to
the AC.CONSOLIDATE.COND record that describes rules for consolidation.








Asset types replaces the usage of GL heads for payables and recievables and
principal balances in T24 virtual accounting.
Asset types help us to know whether the balance under a key is contingent or non-
contingent or accrued income or expenditure in nature.
Contingent and Non contingent Asset types are hard coded.
Accrued income and expenditure Asset types (other than for Account interest
accruals) take value from respective application level parameter tables. These will
use the underlying Profit and Loss category codes and not any alpha values.
FORWARDCR is an asset type for credit contracts prior to Value Date.
FORWARDDB is an asset type for debit contracts prior to Value Date.
CREDIT and DEBIT are the asset types for Credit and Debit balances in Accounts.
LIVECR and LIVEDB are asset types for Credit and Debit Contracts from Value to
Maturity date.
50000 (interest payable) and 51000 (interest receivable) are the asset types for
accrual balances.
These asset types are hard coded. It is not parameterised anywhere.
The first transaction posted to an Account will update the Balance.Type
‘NILOPEN’. The COB will then move it under the correct Balance.Type according
to the sign of the Account(DEBIT or CREDIT).

ACCOUNT.CLASS table has three types of records.

This first type (Account) provides the Category Code portion when building an
Internal Account Number (such as Suspense Account).
Normal requirement is to open local currency internal account for suspense. System
opens in foreign currencies for automatic debit /credit when customers have not
specified or do not have accounts for transaction in foreign currencies.
The second type (Class) provides the parameters required to identify say sector and
category for NOSTRO accounts, sector required for Banks as customers, category
code for Savings Accounts with Pass Book facility etc.
The third (P&L) is for profit and loss items used in DX application.
Id of the record is hard coded. If the user wants to create a new record, they should
use Id in the form of ‘U-Code ’.
These records are used by wide range of applications in T24.

When the record type is ACCOUNT then the category code must be valid and in the
range 10000 to 19999.
SUSPENSE: To be used when the DATA.CAPTURE system generates suspense
entries at the end of day for those entries which have not been authorised.
DIFFERENCE: To be used when the DATA.CAPTURE system has to raise an entry
to balance a batch as part of the end of day processing.
SUSPCREDIT/ SUSPDEBIT: To be used when the end of day accounting module
raises a credit/debit suspense entry as original entry can not be posted due to
account not being present or override condition has been met.
SUSPLMMCR/ SUSPLMMDR: To be used by the Loans and Money Market
systems when the true account is not yet known for the payment entry.
SUSPFXCR/ SUSPFXDR: To be used by the Foreign Exchange system when the
true account is not yet known for the payment entry.
Changes to Category codes mentioned here for Account Classifications
RESFWDCR, RESFWDDR, RESSWAPCR and RESSWAPDR must be done by
using the application FX.REVAL.PARAMETERS. These four records are used to
indicate internal account used in Revaluation of FX and SWAP applications.

When the record type is CLASS, the category and sector code fields are treated as
multi value associated fields and atleast one of them should be defined.
Duplications are not allowed within a record.
BANK : To identify counterparty as Bank, so that suitable swift message could be
sent
SAVINGS: To identify class of accounts for which instead of statements, pass books
could be issued. Though the code word is SAVINGS, pass book facility could be
extended to any type of account which fulfills the Category or Sector defined in this
record.

When the record type is P&L, the Category codes to be used should be that of Profit
and Loss. Sector code cannot be used
If the RECORD TYPE is P&L then this field contains the category code to which
corresponding PL entries will be booked.
Used by DX module for debiting and crediting a PL head for commissions.
Used by applications for debiting and crediting a PL head for marketing exchange
profit and loss of the Marketing Department (Due to difference in exchange rate
from Treasury rate).
Here, only one Category code per record is allowed.



When the AC.CONSOLIDATE.COND is attached to an Account, the

STMT.ENTRY records generated for the Account will be cumulatively totaled and
consolidated . Similarly when AC.CONSOLIDATE.COND is attached to a PL
CATEGORY, the CATEG.ENTRY records for the Category will be cumulatively
totaled and consolidated. There could be more than one consolidated entry at any
time for an Account or for a PL Category, since consolidation is based on both fixed
criteria and user-definable criteria.
.

Only the consolidated entry is stored in STMT.ENTRY. Concat table

STMT.ENTRY.DETAIL.XREF, stores Ids of underlying individual entries.
Individual entries are held in STMT.ENTRY.DETAIL
STMT.ENTRY file contain debit/credit entries that are passed in any accounts. Ids
of all statement entries are stored in a table called STMT.ENTRY.DETAIL.XREF.
STMT.ENTRY.DETAIL is an internal file which contains details of all the
consolidated entries in STMT.ENTRY.
All contingent and non contingent entries of Contracts and contingent entries of
Accounts, Accrual/revaluation, reclassification entries are stored in
RE.CONSOL.SPEC.ENTRY file. File RE.SPEC.ENTRY.XREF stores Ids of
underlying individual entries. Individual entries with details are held in
RE.SPEC.ENTRY.DETAIL file.
The IC (Interest & Charges) Module creates the PL entries for accrual of Accounts
interest and charges. CATEG.ENTRY.DETAIL.XREF table stores all ids of
individual entries. CATEG.ENTRY.DETAIL table stores information of individual
entries.

Entries are consolidated based on the following criteria:

Entry Type - S, F, C or R (Statement, Forward dated,Category or Special entries), CRF
Key (for Category and Special entries only), Account Number or Product Category, CR or
DR, Currency, System ID, Transaction Code, Value Date, Exposure Date, Reversal Marker,
Currency Market, Suspense Category, Terminal Number (not updated), Booking Date,
Account Officer (P&L only), Product Category (for Category and Special entries only).
Besides the above, additional elements defined in ADD.CONSOL.FLD Field.
RE.CONSOL.SPEC.ENTRY consolidates based on criteria like entry type, CRF key
appended with Asset type CR or DR , Currency system ID, RE.TXN.CODE, Value Date,
Exposure Date , Reversal Marker, Currency Market, Suspense Category, Terminal
Number(Not updated), Booking Date, Account Officer and Product Category.
AC.CONSOLIDATE.COND application define rules for consolidation of entries for either
an Account or Category record. A valid record Id to AC.CONSOLIDATE.COND should be
set in the Account or Category record for which consolidated entries should be raised.
Consolidation of statement entries is carried out as per conditions set in the application.
This is done entry by entry progressively online.This application provides for consolidation
of RE.CONSOL.SPEC.ENTRY with reference to Account application. By default,
consolidation is provided for non-contingent special entries raised from account, Interest and
charges applications.Id of a statement entry consists of several parts. They are 1. S/F
(STMT/Forward) 2. Account Number 3. CR/DR indicator4.Currency5.System Id.6.
Transaction Code 7. Value Date 8. Exposure Date 9. Reversal Maker10. Currency
Market11. Suspense Category 12.Terminal Number 13.Booking Date + additional details if
any. Each part is separated by a delimiter !.

Id for the table is alphanumeric and can be between 3 and 20 characters. Id attached to Accounts /
Categories (for P & L)
Type of Entries to consolidate can be specified through ENTRY.TYPE Field.
S , F, C or R (Non-Forward dated Statement, Forward dated Statement, Category, Special
entries)
When S option is chosen, non-F entries are consolidated value-date wise. F Statement entries will not
be consolidated.
To consolidate F Statement entries also, the option F should be specified in addition to S.
Selected EB.SYSTEM, TRANSACTION and CATEGORY codes and/or Routines can be excluded
from consolidation.
ADD.CONSOL.FLD Field can have values of additional STMT / CATEG.ENTRY data fields to be
used in consolidation of entries.
There could be multiple consolidated STMT.ENTRY records during a day for an Account
depending on the system enforced/user defined consolidation criteria. Similarly, there could be
multiple consolidated CATEG.ENTRY records for a PL Category during a day.
In AC.CONSOLIDATE.COND, the field NO.ENTRIES.START specifies number of entries after
which the consolidation will happen. Also Useful to stop consolidation, when number of entries is
less in a day
NO.DETAIL.APP field will be used to mention the applications for which the details of the
consolidated entries will not be maintained.
The record Id created in AC.CONSOLIDATE.COND has to be attached to the field
CONSOLIDATE.ENT of an account or a Pl category. Please note, if attached to an account, its
STMT.ENTRY records will be consolidated. If attached to a Pl category, its CATEG.ENTRY
records will be consolidated. For RE.CONSOL.SPEC.ENTRY, only one record with
Id:REDEFAULT is allowed, this is not to be attached to any category.
Consolidation of CATEG.ENTRY and RE.CONSOL.SPEC.ENTRY is covered later during the
course.
Please note: Filter system id and Transaction id are not used for consolidation. It is used to suppress
STMT.ENTRY record ids being updated in ECB.

The default AC.CONSOLIDATE.COND record with Id: DEFAULT has been

introduced in R6 for the purpose of consolidation of STMT.ENTRY records of
NOSTRO and internal accounts.
NO.ENTRIES.START Field in DEFAULT record in AC.CONSOLIDATE.COND
table can be set to 0.
A new default record CLDEFAULT is introduced for the consolidation process of
entries on Customer accounts. The purpose is to start consolidating entries by
default after the 50th statement entry raised for the day.
The AC.CONSOLIDATE.COND record with Id: REDEFAULT is used to
consolidate non-contingent RE.CONSOL.SPEC.ENTRY records in AC module like
accruals and capitalisation. This functionality has been extended to consolidate
RE.CONSOLIDATE.SPEC.ENTRY generated in LD, MM, PD modules as well.
The AC.CONSOLIDATE.COND record with Id:VDSUSPRE is used to consolidate
contingent RE.CONSOL.SPEC.ENTRY records created in account module under
value dated accounting system.
This record is not used for consolidation of CATEG.ENTRY records.
The default record with Id PLDEFAULT. Consolidates PL entries generated by IC
module. No need to attach this record to P&L Categories

In this workshop, we will create a new current account for the customer.
Create two AC.CONSOLIDATE.COND records one for customer account and other
for category codes
And attach them to the respective ones.

Create a new current account for the customer

A new record is created in AC.CONSOLIDATE.COND

This record is attached to the new account created.

The new AC.CONSOLIDATE.COND record is created for the category code and
attached to the record.

In this workshop, let us book a transaction between the account in which account
consolidation conditions are attached and another customer account.
Let us view the impact on the accounting entry generated.

FT transaction is booked between the new customer account and the customer
account with consolidation conditions.

The accounting entries are displayed here

We can find the STMT.ENTRY generated for one leg of the transaction
But other leg for the new account has a STMT.ENTRY.DETAIL generated.

The internal account has only STMT.ENTRY.DETAIL (consolidated entry)

generated

In this workshop, let us book a funds transfer between customer account SS1 and
the category code with consolidation conditions.
Let us have a look at the entries generated.

The FT transaction is booked here

The accounting entries are generated as displayed here

The STMT.ENTRY is generated for account but category code has

CATEG.ENTRY.DETAIL generated.

We can find the CATEG.ENTRY generated using the PLCategory code search

The CATEG.ENTRY is displayed here.

The CATEG.ENTRY.DETAIL.XREF entry is also identified


We have now come to the end of this course. We hope that you have attained a high level
understanding of T24 and would like to welcome you to join us in our subsequent courses.
Thank you!


T24 Accounting Introduction R16

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

T24 Accounting Introduction R16

Caricato da

Copyright:

Formati disponibili

T24 Accounting Introduction

T24 Financial Accounting - R15 1

T24 Financial Accounting - R15 2

T24 Financial Accounting - R15 3

T24 Financial Accounting - R15 4

The general ledger is the main accounting record of a business.

T24 Financial Accounting - R15 5

T24 Financial Accounting - R15 6

The importance of financial accounting to banks need not be over emphasized.

T24 Financial Accounting - R15 7

T24 Financial Accounting - R15 8

T24 Financial Accounting - R15 9

T24 Financial Accounting - R15 10

Up to 9999 records can be created in INDUSTRY and SECTOR. It is very likely

T24 Financial Accounting - R15 11

T24 Financial Accounting - R15 12

T24 Financial Accounting - R15 13

T24 Financial Accounting - R15 14

In T24, FUNDS.TRANSFER, TELLER, DATA.CAPTURE are Account based

T24 Financial Accounting - R15 15

In T24, Accounting entries are automatically generated for authorised transactions.

T24 Financial Accounting - R15 16

T24 Financial Accounting - R15 16

T24 Financial Accounting - R15 17

T24 Financial Accounting - R15 17

T24 Financial Accounting - R15 18

If a value dated accounting system is required in general, then this Field in

T24 Financial Accounting - R15 19

Any of the sub-product for the above mentioned application/product (Eg:SCSCP )

T24 Financial Accounting - R15 19

TXN.JOURNAL is a work file, which contains particulars of transaction entries

T24 Financial Accounting - R15 20

T24 Financial Accounting - R15 21

T24 Financial Accounting - R15 22

T24 Financial Accounting - R15 23

T24 Financial Accounting - R15 24

STMT.ENTRY generated for non contingent balance of Accountns and

T24 Financial Accounting - R15 25

All records in CATEG.ENTRY file contain essential details like PL Category,

T24 Financial Accounting - R15 26

In case a STMT.ENTRY is consolidated, Id of the STMT.ENTRY.DETAIL will be attached

T24 Financial Accounting - R15 27

RE.TXN.CODEs are hard coded .

T24 Financial Accounting - R15 28

LIQ, MAT, SPT, REV etc CUS, APP SGN

T24 Financial Accounting - R15 28

Transaction code: COMBINE.PROD.CAT, COMBINE.SYSTEM.ID and

T24 Financial Accounting - R15 29

T24 Financial Accounting - R15 29

T24 Financial Accounting - R15 30

T24 Financial Accounting - R15

T24 Financial Accounting - R15

Go to User Menu, Retail operations, Account and open Internal account

The internal account is opened here.

T24 Financial Accounting - R15

Go to User Menu, Retail operations, Account and open current account

The current account in USD is opened here

T24 Financial Accounting - R15

Entries in STMT.ENTRY file are generated to affect non contingent balances in

T24 Financial Accounting - R15 35

T24 Financial Accounting - R15 36

T24 Financial Accounting - R15 37