Post to IBA or Process Direct Payment

From Wiki
Jump to: navigation, search

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


Posting Claims

In the CLMMEN program this option is used to post the claim to pending IBA or process direct payment.

NOVUS checks if the Policy Type (GID 1) maps to a Processing Group (GID 14) has the Transaction route set as 'T' for treaty. If so then the Claim Post to IBA will display ‘Prop Treaty’ and the user will be chained through to the Treaty IBA Poster to complete the transaction. Where the Transaction route is set as ‘N’ (non-treaty), the transaction will be processed by Claim Post to IBA as usual.


CLMMEN post to IBA.PNG


Post to IBA (or Process Direct Payment)

For each record to settle:

Field name Description
Claim Ref Claim Reference number

The section, market version number, order per cent and accounting date are automatically displayed.

Cat Code Displayed automatically
Section Displayed automatically
MVN Displayed automatically
Order % Displayed automatically
Details Details referring to this occasion of posting. You may use any free format text in this area.
Accounting Date Defaults to the current system date.
Instalment Date Defaults to the current system date.
Payable by This is the payable by date. Normally there are no terms of credit with a claim.
Currency Enter the required currency. As claims may have been recorded in different currencies, the system needs to know which currency to process. Two currencies are required. 1. The currency of the claim and 2. The intended settlement currency. The settlement currency must be a banking currency.
Type This field and the next are automatically displayed showing the type of transaction and any relevant third party account.
Account Displayed automatically.
Now Due The system computes the amount due (for this currency).
Settle Y/N
Amount State amount to be posted – this can be different from the amount outstanding for part settlements.

HELIX only

Field name Description
Details Incurred period from claim entry and details referring to this occasion of Posting. You may use any free format text in this second details field.
Instalment Date Defaults to the current system date.
Payable by This is the payable by date. Normally there are no terms of credit with a claim.
Currency Enter the required currency. As claims may have been recorded in different currencies, the system needs to know which currency to process. Two currencies are required. 1. The currency of the claim and 2. The intended settlement currency. The settlement currency must be a banking currency.
Type This field and the next are automatically displayed showing the type of transaction and any relevant third party account.
Account Displayed automatically.
Short Name Displayed automatically.
Now Due The system computes the amount due (for this currency).
Settle Y (yes)/N (no)/P (part settlement)
Amount State amount to be posted – this can be different from the amount outstanding for Part settlements.

Once the list is complete [COMMIT] using f10 to proceed.

Field name Description
Direct Payment

(only if system flag set)

Enter ‘Y’ to settle if the insurer is to settle this transaction directly with the claimant. If ‘Y’ is selected the transaction is posted to the direct ledger and will not appear in any company account. Accept the default of ‘N’ to settle the transaction with the claimant.
Aggregate:

HELIX only

If the claim entry carries a catastrophe code you can enter ‘Y’ to aggregate this current settlement into a previously aggregated total for this catastrophe code. The LOV will show aggregated amounts (exclusive of the present settlement) for this catastrophe code. To clear down the aggregated amount and consolidate into the current settlement enter ‘D’ to disaggregate. If disaggregation has already taken place the program will advise and set the field to ‘R’ for a re-disaggregation.
Split Client Y/N

Navigate to the ‘[COMMIT] to proceed. On pressing [COMMIT] the program will make a single transaction into the IBA ledger apportioned over the insurers concerned and including any fees, third party liabilities and recoveries.


Aggregate Outward Claims HELIX only:

Inward aggregation can be applied for IBA postings based on a given catastrophe code

A simple worked example will help to explain how aggregates work. This example Assumes an aggregate excess loss policy with a 1,000 excess in the aggregate. All postings are for the same catastrophe code

Entry Amount Aggregate IBA entry Retained Amount Ceded Amount
1
3,000
N(*)
3,000
1,000
2,000
2
4,000
Y
4,000
N/A
N/A
3
2,000
Y
2,000
N/A
N/A
4
1,050
N(*)
1,050
1,000
50
5
2,500
D
2,500
1,000
7,500
6
3,300
Y
3,300
N/A
N/A
7
4,000
D(**)
4,000
0
7,300

(*) In the circumstance, these entries are likely to be incorrect – they should have been entered as aggregates. They are shown here for illustration purposes only.

(**) Entered as ‘D’. The system will re-label this entry as ‘R’ as a repeat de-aggregation.

The IBA columns show that aggregation has no impact on the IBA entries.

Claims poster fails when only one reinstatement cycle due for settlement is selected.


Version History

v6.4.0 – Updated to the latest version
v4.2.0 – Updated to the latest version
v72K - Accounting date added to screen. Notes button disabled
v70K - i_iba_all failed for TPL with index clash. ac_ref was not being written to iba.reference