T24 Accounting Set-Up - Additional Features R16
T24 Accounting Set-Up - Additional Features R16
When a Money Market contract is first captured onto the system, for example a Taking,
then it generates a consolidation credit entry of a FORWARDCR Contingent Liability
position for the contract principal.
When the Money market Taking deal starts the following entries are generated:
(1) a consolidation entry to debit (reverse) the FORWARDCR Contingent Liability position
for the principal (2) a consolidation entry to credit the LIVECR liability type (3) a statement
entry to debit the Customer account supplying the funds for the deal.
The daily accrual process will generate
(1) a Profit and Loss entry to debit P/L Interest Expense for the daily interest (2) a
consolidation entry to credit IENP (interest expense not paid) for the daily interest
The contract maturity will generate the following entries
(1) a consolidation entry to debit (reverse) the LIVECR liability type for the principal (2) a
consolidation entry to debit the IENP (interest expense not paid) for the total interest (3) a
statement entry to credit the Customer account returning the deposit principal and total
interest.
Contingent entries will be raised in the COB process for any contract which has been
created with a value date greater than the System date. These contingent entries will be
raised for both the amount bought and the amount sold. All contingent entries are of the
type `Special Consolidation Entries’ and will use the Transaction codes and CRF Asset Types
described earlier in accordance with the contract type.
It is now possible to opt for self balancing of contingent entries except contingent PL by
moving contingent accounting and value dated suspense processing online.
The Balances files are updated online. They are used to accrue interest and charges.
Their structure is application dependent.
Id of Balance file is Account-YYYY-MM / Contract Number. Each time interest /
commission is accrued on a contract, the balance file fields are updated (e.g.
OUTS ACCRUED INT Field is debited on a placement contract) and an entry is
posted to Profit and Loss (e.g. INTEREST RECEIVED is credited on a placement
contract). The keys to the Category entry records produced in this accrual process
are stored in this file.
It should be noted that it is only the Category entry numbers that relate to the
current interest period that are held in this field. Because one accrual period can
have many Category Entries then this field will also accept sub values.
The key to the Category Entry file is made up of 2 parts, Statement Number and
Sequence Number. If a transaction generates several Entries, all the entries have
the same Statement Number, the Entries on the same file are distinguished from
each other by their Sequence Number.
The Sequence Number is a 6 digit number out of which first two digits can be
viewed here and balance numbers are from 0001 to 9999.
Statement Number which is first part of the key for all the Category Entries is
shown separately and the range of Sequence Numbers used for category Entries is
shown separately.
In addition to generating online entries, quite a lot of accounting entries are generated
during COB.
Main among them are entries for accruals, capitalisation, contract maturity and premature
closing.
Interest on a contract may be due on 15th of every month. A Bank may like to prepare its
Profit and Loss accounts on a daily basis. Hence, every day it would accrue interest, but not
debit or credit Customer accounts. If it were a loan contract, every day Interest receivable
will be debited and Profit and Loss credited. This is accrual process in short. In T24, there is
no need to open any account head for this 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 and Liability head, a debit entry is passed and stored in
RE.CONSOL.SPEC.ENTRY. Corresponding credit entry would be in CATEG.ENTRY.
On 15th, Customer’s account would be debited by way of STMT.ENTRY record and credited
through another entry in RE.CONSOL.SPEC.ENTRY. This is capitalisation. Here the reversal of
accruals takes place by Debit or Credit by RE.CONSOL.SPEC.ENTRY.
Contract maturities are handled during COB. Depending on applications, premature closing
can be handled online as well as during COB.
FOREX module provides daily revaluation of Foreign Exchange position, producing daily
profit / loss for each dealer in each foreign currency against local currency. Contract wise
revaluation can be seen in POS.TRANSACTION application
SPOT contracts are uniformly revalued as mark to market, while the FORWARD deals have
choices as rebate method and Straight line method. Under REBATE method the deals are
revalued on cost to cover deal today. In the case of straight line method the deals are
revalued on amortisation of exchange profit or loss over the life of the deal. In the case of
SWAPs exchange profit may also be treated and accrued as interest.
Different revaluation methods are available in T24 which are pre defined in FX.REVAL.TYPE.
Application handles the following methods namely:
IN = Interest method RB = Rebate method SL = Straight line IH = Interest hedged SF =
Straight line funding which is used only for swap.
If SF is defined, then PM.PARAMETER table will need changing to include the new position
class - FXFSF.
FX and SWAP contracts till maturity will be revalued as per the applicable parameters in
REVALUATION.PARAMETER. One side will be a STMT.ENTRY to an internal account and
other side will be a CATEG.ENTRY. Details are held in POS.TRANSACTION. POSITION records
will not be updated.
In FOREX revaluation under close to cover method has two types of revaluation they are
SPOT and REBATE.
In the case of SPOT method, the latest available Reval rate is used and in its absence Mid
Reval rate of a currency will be used. REBATE method for forwards uses only the Mid reval
rate and adds the applicable forward premium or discount available in the forward rates
table. Under these methods the daily revaluation profit or loss is posted to Profit and loss
on one side and internal accounts on the other side which are defined in
REVALUATION.PARAMETER and ACCOUNT.CLASS as EXCHADJ internal account
FX and SWAP are held in contingent asset types in CAL. When they are revalued in CAL
(optionally if set in CONSOLIDATE.COND), RE.CONSOL.SPEC.ENTRY will be generated and
LCY amount of the contingent position will be updated.
After maturity they will be revalued as per the parameters for AL.
AL revaluation is done at a ‘bucket level’. Here, balance in each Asset Type in a key is re-
valued (System Wide 5 – EOD.CRF.REVAL) and a debit/credit RE.CONSOL.SPEC.ENTRY record
is raised in LCY. This value is also reckoned while posting the debit/credit movements to the
LCY component to the respective Asset Type.
When an interest accrual is done to a FCY account, a foreign currency position is created,
since the categ.entry is generated in LCY and accrual is held in FCY.
Following is the workflow for A & L revaluation.
ie. A/L asset type figures in each CAL record are re-valued and RE.CONSOL.SPEC.ENTRY is
raised.
Totals of A/L asset type balances are written to a work file, and the difference amount
between CAL and POSITION is adjusted in the Post routine.
The forward asset types are re-valued if the setting in CONSOLIDATE.COND says the asset
type should be revalued .
Regarding revaluation of contingent Assets and Liabilities, it is carried out only in respect
of Contingent Asset types indicated in CONSOLIDATE.COND record. Revaluation is similar
to non-contingent assets .
Revaluation entry to P&L (System Wide 5 – REVALUATION.AL) is based on the net Position
for the currency for a dealer desk. One CATEG.ENTRY for each currency for each dealer
desk is raised .
Forex and SWAP position revaluations create CATEG.ENTRY records and the contra to the
Profit and Loss. Deals involving two currencies create currency Positions in POSITION table
Id: Company code, Currency Market, Position type (TR), Dealer Desk, Bought and
sold currencies, Value date
System provides daily revaluation of net Foreign Exchange positions, producing daily profit
/ loss for each currency market, Dealer desk wise and in each foreign currency against local
currency
The POSITION file is updated only when a specific transaction actually impacts the position
of a particular currency i.e. when because of that specific transaction, the position of a
particular currency increases or decreases. In other words, if a transaction involves the
same foreign currency on the debit and credit side with the same amount on both sides.
No position updates will be raised. There are no real accounting entries behind the
POSITION file.
If there is a requirement in some instances that real physical accounting entries are to be
maintained in addition to the POSITION file updation, T24 can be parameterised through
POSITION.ENTRY Field in CONSOLIDATE.COND application to generate balanced entries for
internal position accounts. This is made possible by the creation of internal position
accounts.
The account number format for these will be determined by the type of environment, single
company, multi company or multi-book.
For a multi-book environment, the format of the account will be CCYCCYCCCCCDDSSBBBB.
The first CCY is the currency code of the account
The second CCY is the other currency of the position relationship
CCCCC is a category code in the range 10000 – 19999
DD is the DEALER.DESK code
SS is sequence number, which will allow the user access to sub account processing BBBB is the
branch sub division in a multi book area.
These position accounts use similar functionality to other internal accounts i.e. statement
frequency, opening balance, closing balance, movements as of any date and between any dates.
Each of these currency position accounts will have a corresponding account in local currency which
will contain the local currency counter value of the foreign currency position. For example if there
is an account GBPUSD1055000010001 and local currency is USD, there will be a corresponding
USDGBP1055000010001 account.
The accounts are populated with real accounting entries each time a transaction raises a position in
a particular currency. These accounting entries will be included in the STMT.ENTRY file where all
T24 account entries are kept.
Each of these currency position accounts will have a corresponding account in local currency which
will contain the local currency counter value of the foreign currency position. For example if there
is an account GBPUSD1055000010001 and local currency is USD, there will be a corresponding
USDGBP1055000010001 account.
The benefits of position accounting are:
On the overall balance sheet i.e. all currencies converted to local currency equivalent, the net
impact of all the position accounts will be exactly ‘NIL’ as the net balance of all these position
accounts will be exactly equal to zero.
The system will be able to balance each currency ledger.
The EB.POSITION.PARAMETER record has the @Id to this record is the COMPANY Id. In a
multi-book environment it will be necessary to create a separate record for each lead
company in existence.
It is necessary to clearly separate the On Balance Sheet position accounts from the Off
Balance Sheet position accounts. This will be managed by the use of CONTINGENT or
NON-CONTINGENT accounts. The Off Balance sheet position accounts will be furthermore
subdivided between the spot, forward and al forward position accounts.
In order to set up position accounting, 4 new CATEGORY codes must be created. One for
each of the following:
AL (Non contingent)
ALFWD (Contingent)
FXSP (Contingent)
FXFWD (Contingent)
The category codes created for ALFWD, FXSP and FXFWD need to be made contingent. This
is done by entering the category codes into the ACCOUNT.PARAMETER record, using the
Fields CONT.DESC, CONT.CAT.STR and CONT.CAT.END.
We need to log out of the system, so that the changes in the ACCOUNT.PARAMETER can
take effect. 4 new transaction codes must be created. One for each of the following:
IN.CR.TXN.CODE,
IN.DR.TXN.CODE,
MAT.CR.TXN.CODE,
MAR.DR.TXN.CODE
The use of ENT.TYPE Field in the EB.POSITION.PARAMETER is to allow for the accrual
transactions to be posted to a different dealer desk for position accounts thus we can enter
ACC which is an overall request and then we can enter ACC-MM which means that for MM
we wish to do something different. The field is used in conjunction with Fields CHANGE.DD
and DEALER.DESK.
Now that the structure has been input, the functionality is activated by setting the field
value of POSITION.ENTRY in CONSOLIDATE.COND – ASSET & LIAB record to “ACCOUNT”.
Before the functionality becomes live, it is necessary to exit the system. Upon signing in
the functionality will be active. We have to create an internal account for each of the new
category codes. The currency of the account must be the same as the first currency in the
@Id. For example in internal account USDCHF1055100010001 the currency must be USD.
The system will then use this as a template to open further accounts as and when required.
When opening the first position account for a currency the DDSS part of the account
number should be input as 00 which is for dealer desk 00 followed by sequence 01 as in
the above example account record. This is so that sub accounts can be used and the
maximum number of sub accounts allowed for a position account is 98 meaning that
sequence number can have values 01 to 99 with 01 the master/main and 02 to 99 the sub
accounts.
Refer to the workshop-9, wherein we transferred USD 15,000 from Internal Account for
Computer software to our customer’s GBP account with today’s value date at exchange
rate of 1.7
The accounting entries including the position accounting entries generated can be
observed and understood.
Notable point to observe that as GBP position has increased by virtue of a credit of GBP
8,823.53 to the customer’s account, an internal position accounting entry related to
GBPUSD140160001 is generated with GBP -8,823.53 (which is equal to USD -17,430).
Simultaneously a credit entry for USD 17,430 (equivalent of GBP 8823.53 at Treasury Rate)
related to the local currency position in USDGBP140160001 is also generated. Thus, it can
be observed that overall the net position will be equal to zero.
From R13, POS.EXP.DATE field holds the value date of position exposure in STMT.ENTRY.
In EB.ACCOUNTING, this field is populated only for Position Accounting entries whose
category matches with those specified in EB.POSITION.PARAMETER. This field is uniformly
updated for all position entries raised for a currency pair, for a contract or transaction.
ENQUIRY POS.STMT.ENT has been introduced to show the currency exposure or
movements for a specific currency pair and category code for a range of dates which may
be either of VALUE.DATE or Position exposure date (POS.EXP.DATE).
ENQUIRY POS.STMT.ENT has been introduced from R13, to show the currency exposure or
movements for a specific currency pair and category code for a range of dates which may
be either of VALUE.DATE or Position exposure date (POS.EXP.DATE).
ENQUIRY POS.STMT.ENT shows the currency exposure or movements for a specific
currency pair and category code for a range of dates
which may be either of VALUE.DATE or Position exposure date (POS.EXP.DATE).
The Selection criteria will be:
o Currency Pair (E.g. EURUSD)
o Category (Category define in EB.POSITION.PARAMETER)
o Dealer Desk (Optional)
o At least one of the Value.Date or Processing.Date
o Application Drill down (Optional)
Enquiry Lay out design for selection and output is seen here
To revalue FCY A/L positions, balances will be converted using mid rate and compared
with that of LCY position account. When there is a difference,
A STMT.ENTRY to the LCY position account for the difference amount will be raised.
A CATEG.ENTRY for the opposite sign for the P&L for the amount will be raised.
The FCY position accounts total will be checked so that it has to be zero for each currency.
The LCY position accounts total will be checked that it also nets to zero, if not a set of
adjustment entries will be raised for the last LCY position account processed.
A fiscal year is a financial year (sometimes a budget year) is a period used for calculating
annual ("yearly") financial statements in businesses and other organizations.
In many jurisdictions, regulatory laws regarding accounting and taxation require such
reports once per twelve months, but do not require that the period reported on constitutes
a calendar year (that is, 1 January to 31 December).
Fiscal years vary between businesses and countries. The "fiscal year" may also refer to the
year used for income tax reporting.
Quarter end reporting and Half year end reporting are in place for the same purpose for
every quarter of the fiscal year.
PL.CLOSE.PARAMETER table is the parameter table required to be set up for year end
transferring of Profit and Loss balances to A & L. It consists of 5 important sections viz.,
Reports, Year End, Excluded Types, Grouping and Halt Process. The settings made through
these sections help the system to control the reports that are produced during the close
out process, specify the period end, exclude certain PL categories from close out, Group
the entries at the time of close out as per the customised user definition and can help halt
the cob process just before the close out process is run, if required.
Reports section is used to parameterise to control the reports that are produced during
the close out process. It has 3 related fields, which are REPORT.TYPE, REPORT and
REPORT.DATA
REPORT.TYPE Field is used to specify which type of reports to be produced. The reports to
be produced can be ENQUIRY, REPGEN.CREATE or program driven.
REPORT Field contains the key to REPGEN.CREATE, ENQUIRY, REPORT, RE.STAT.REQUEST or
a valid complied program name.
REPORT.DATA Field is used to pass a parameter to program driven routines
CLOSE.FREQ.DATE Field should contain the year end and subsequent cycle frequency for
this particular company. When this is set the field FINANCIAL.YEAR.END on the COMPANY
record is changed to match this date.
This field is in two parts, for example 31JAN2002 M1231.
1) Next Financial Year End: 1-9 Date characters. Default value calculated by the system from
the Frequency. Must be a month end date. The day in the date and the day in the
frequency (last two digits) must be the same.
2) Frequency: 2-5 type FQU (standard frequency format). Frequency must be Monthly,
Quarterly, Half-yearly or Yearly. The frequency cycle must start with M12.
TYPES.TO.EXCLUDE Field contains the types which should not be included in the PL
Closeout process.
Valid types are PL, CP, CI & CL
PL - Non-Contingent P&L item.
CP - Contingent
CI - IAS P&L
CL - Local Gap P&L
As a default we exclude the types
CP …. Contingent
CI …. IAS and P&L
CL …. Local Gap P & L
AL.GROUPING can be set to group the entries based on the user configured elements
selected from CONSOLIDATE.COND record PROFIT & LOSS. By default the entries produced
will be based on the CATEGORY/CURRENCY and one entry will be passed to the internal
account (as defined by the ACCOUNT.CLASS record PLCLOSE). Each of these entries will be
the sum of all the CONSOLIDATE.PRFT.LOSS records matching the combination of
CATEGORY & CURRENCY. To produce entries summed at different group levels, we may
add the additional elements from the PROFIT & LOSS key so that the entries are summed
for all records matching the same settings, for example
PLCATEGORY/CURRENCY/NATIONAL/SECTOR/INDUSTRY or whatever settings we have
defined. So it will be possible to group the entries with the same key elements (such as
NATIONALITY, SECTOR, INDUSTRY etc) but in doing so the number of accounting entries will
increase.
The most essential parts of the PL close out are the accounting and the backup to how
accounting has been created from the system. During the financial year the PL Category
items will become used and contain both credit and debit balances. Let us assume a
simple PL item head which has a balance of USD 5,000 over a period and has a credit of
USD 100 on the final day of the financial period. The accountant of the bank will expect to
see a closing balance of USD 5,100 for the old year and a new fresh balance of USD 0.00 for
the New year. This is because of the transfer of the balance to an internal Asset & Liability
account. In the examples in the slides to follow you can see the progression of a single
CONSOLIDATE.PRFT.LOSS record from a populated start point to the ‘virtual year end day’
and then the new financial year based on the record, whose PL category code is 50010 and
Currency is USD. If more than one record satisfies the grouping criteria, then the system
will produce grouped accounting entries.
The processing of the PL close out effectively creates a second day for the year end. This
‘virtual day’ is used to segregate the accounting entries and record updates to enable the
year end process audit to be as clear as possible. Some of the system files will have
system dates with ‘CL’ appended to indicate these are unique to the close out process.