IBA User Guide

From Wiki
Jump to: navigation, search

See the NOVUS Walkthrough Guide for general information about the system.

Related programs

Transaction entry - ETRAN

Transaction entry overview for maintenance - ETRANH

Period summary totals enquiry -EPERIOD

Account matching history - EMATCH

IBA tasks can be grouped as follows:




Cash matching
Currency conversion including change of destination currency
End of period
Rates of exchange maintenance
Change mnemonic


Account listings
Aged analysis
Cross analysis etc.

Basic Concepts


The NOVUS IBA (insurance brokerage account) ledger does not differentiate between client, insurer or any other type of account. Notwithstanding an entry against a given IBA account may be seen to be ‘client’, ‘insurer’, ‘consultant’ etc. from the suffix and tax-code. This feature enables a manageable set of account codes to be defined for those parties with whom business is mostly transacted.

This is particularly useful in a reinsurance environment where the same business partner can adopt different roles. More importantly, it enables the business position between brokers and a given partner to be determined, irrespective of the role(s) that partner has played.

The NOVUS IBA ledger is symmetrical with regard to clients and (re)insurers.

A transaction can have multiple clients, as well as multiple insurers. The small claims transaction entry program can create transactions with duplicate clients differentiated by splitter.

The convention for the suffix is

Suffix Value
* client
null brokerage
other insurer
. period

This is usually a period (full stop) '.' but can also be an uppercase alpha character to accommodate ‘facilities’.


The splitter has two functions: instalments. The first instalment carries a splitter of ‘A’, the second will be assigned ‘B’, the third ‘C’ and so one. The allocation of splitters is directly linked to instalments – not necessarily the instalment dates. Hence if the initial instalment is a ‘double dose’ because of the delay in writing the transaction to the ledger, then a double set of records will be written with the same instalment date half with a null splitter and half with an ‘A’ splitter.

This provides greater clarity in the IBA and enables soft currency transactions to be converted by instalment rather than by instalment date. The splitter is also used in the claims system where the ‘split client’ option is taken, a client line is written for each insurer line allowing each underwriter line to be converted at a different exchange rate.

Tax Code

A technical entry can include any combination of taxes and fees. These appear as separate IBA lines identified by a characteristic tax-code in the range ‘a’ through ‘z’ (upper and lower case). The system is pre-configured with a number of types of taxes – the User can set up other types of taxes if required. For example:-

code Value
p policy fee
d discount (tax)
x client tax (e.g. IPT (insurance premium tax))

Depending on how the particular fee or tax has been configured, the associated IBA accounts can be market participants, third parties, or other internal revenue accounts (such as the XBK brokerage account).


In the technical entry section, it states that a transaction is entered in a specified source currency whilst specifying the destination currency into which that transaction is expected to be converted. The destination currency must be a banking currency.

If both currencies are the same, the system pre-converts the transaction on entry, i.e. it does not need to be converted before matching. Conversely, if the source and destination currencies differ, then the transaction will be a convertible currency transaction even if both currencies are banking currencies.

Instalments start off in a common currency but each instalment can be in a different currency when converted.

Original amounts are in source currency. Unconverted outstanding amounts are expressed in source currency and converted outstandings are in destination currency. Funding is always in destination currency – as funding only arises as a result of cash matching.

On conversion, the amounts outstanding in source currency are set to zero and the amounts outstanding in destination currency are computed from the original amounts at the specified rate of exchange. The same rate of exchange must be used for converting all lines on an instalment.

Exchange rates stored in the ledger are source/destination - not necessarily source/GBP. Prevailing exchange rates stored in the currency table are with respect to the base currency as set up in the system parameters (not necessarily GBP).


The IBA ledger has been designed to support technical entries based upon the policy and market configuration. Cash is account based rather than policy based, and is posted to a pseudo policy number ‘000000’ (no year or section). The CASHENTRY cash entry program is designed to accept either IBA or nominal ledger based cash. This section deals with IBA based cash.

If the nominal ledger (NL) module has been installed, then please refer to the nominal ledger overview page on this wiki for details of posting NL cash though the cashbook. If your system does not include the nominal ledger module, this program can only be used for IBA based cash.

Cash must be allocated to a division - however, the cash matching program can be tuned to allow cross division matching if required. Similarly IBA account codes can be created up for specified divisions, or ‘ALL’.

End of Period Totals

There are three monthly summary totals for all entries into the IBA ledger in banking currency or when converted from convertible currencies: Transactions, cash, transfers journals, and zombie extract cash (bank element) brokerage

Totals are stored for each banking currency and division analysed by client or company.

The system automatically generates the additional period totals when any of the following occurs:

  • A bank account is set up with a new banking currency.
  • A new division is created.
  • The calendar is extended.

The end of period process involves closing the current period and bringing forward balances into the next period. Periods are created in the CALENDAR program.

If the nominal ledger module has been installed then the end of period process will write period totals to the debtors, creditors, bank, brokerage and revenue accounts in the NL.

It is part of the IBA function to regulate postings into the IBA ledger. Periods are designated as open, blocked or posted. The division between open and blocked is the earliest open period which is the period indicated in the calendar with a greater than symbol ‘>’, and is also specified in the system parameters table.

The calendar maintenance program should be used to set the earliest open period.

Postings cannot be made to periods prior to this earliest open period. Blocked periods are sometimes referred to as ‘closed’ - however, a blocked period can be re-opened.

Once a period has been blocked in the CALENDAR program, it may then be subjected to the end of period process. This posts that period (to the NL if applicable) and sets its status to 'posted'. A posted period cannot be re-opened.

For example, at period (month) end, the IBA personnel might wish to prevent any further records entering the IBA ledger for this period, e.g. January. (Periods do not have to be calendar months – up to 99 periods can be set up within the ‘year’ which does not necessarily have to be January – December.) The CALENDAR program should be used to display the appropriate year. A ‘>’ should be displayed against the January line. Use the cursor keys to move the symbol to February. The status of the periods are then: January - blocked, February - open (first open period) March etc. - open.

This now provides an opportunity to reconcile January. If certain journals are required for January, or other entries are required, the ‘earliest open period’ can be reset back to January. This will need to be done under controlled conditions, as technical entries could be back-dated into January whilst this period is open.

To run the end of period for January, the earliest open period must first be advanced to February or later. Furthermore, periods can only be processed in sequence, therefore January cannot be processed without first having closed December etc.

The end of period processing writes carried forward balances into the January summary totals and brought forward balances into the February summary totals and the status of the periods will then be:

  • January - posted
  • February - open (first open period)
  • March - open


The funding algorithms automatically computes the funding on all lines on a transaction caused by cash matching. There is widespread misunderstanding of ‘funding’ so it may be useful to clarify what is meant by this term.

Funding occurs when cash is paid/received on one side and not settled on the opposite side. By ‘opposite’ this means with regards to sign. Cash received against a debit would imply all other lines (including brokerage) are credit items.

For example: funding occurs when a credit line is cash matched before corresponding debit items. This is the more common usage of the term ‘funding’ because it is considered that the broker has funded the transaction, i.e. is out of pocket. To differentiate between the two situations, this situation is regarded as funding, and receipt of premium before settlement to the opposite side as negative funding.

NOVUS computes new funding on the matched line and the proportional share of that funding on the opposite side lines. Cash matching on one side changes the funding situation of both sides. For example, receipt of a client premium (debit) before the insurers (credits) can be matched, creates negative funding on the client line (the amount received), and negative funding proportioned over the insurer lines. Funding is reduced to zero by fully settling all the insurers or paying back the client.

The NOVUS funding algorithm handles part payments, over payments, and incomplete transactions subject to certain conditions(*).

(*) NOVUS allows lines to be archived using the clear down process, provided the outstanding amount and funding is zero. The funding algorithm can be adjusted to work with data which has been cleared down incorrectly as might be encountered in a data take-on situation.

Version History

v4.2.0 – Updated to latest version