Insurers Digitally Transform Businesses This Way to Comply with IFRS 17

Posted: 2022-03-16 Edited: 2022-03-26

IFRS 17 is effective for annual reporting periods beginning on or after 1 January 2023 with earlier application permitted as long as IFRS 9 is also applied.

Here is one of the key requirements of the standard: The income expected to occur in the future shall be realized in the future period by period; The loss occurred at the time shall be realized immediately.

This article examines the challenges and to-do task for life insurers, property and casualty insurers, and reinsurers that bear the brunt.

The accounting journal entries of the insurer should record all necessary detailed information!

One may translate this assignment requiring the chairman, general manager, chief information officer, chief financial officer, and staff of the actuarial department to submit within a time limit into this true-false test of information system software (referred to as ERP) curriculum:

Does your insurance ERP seamlessly and instantly integrate business modules and accounting module and is in line with the characteristics of OLTP?

You are invited to review as early as possible your own ERP with a magnifying glass.

These two requirements, seamless and instant, highlight the significant shortcomings of many insurance industry ERPs.

First of all, your ERP should have this capability: in addition to providing the common features of general ledger, accounting journal entries must also provide sub-ledger capabilities.

Your ERP should conform to the characteristics of OLTP: All transactions related to money in each business module will generate accounting journal entries. Those ERPs in which the accounting module is temporarily or even permanently, partially or even completely, disconnected from business modules are far from what we call the ERP.
All currency-related transactions in each business module immediately generate accounting journal entries. We are not talking about those ERPs that run batch jobs at midnight daily, monthly and yearly to extract datasets from various business modules (perhaps even from different databases via layered software interfaces), transform, and then generate in one go thousands of accounting journal entries (if the batch job run completes successfully).

The following hypothetical examples are given to illustrate the degree of influence of sub-ledger capabilities on the quality of insurance ERP.

Example 1: When premiums are received

Future Cash Flow	40
Risk Adjustment	10
Contract Service Margin	50
		Insurance liability	100

Here lie these challenges:

Example 2: Insurer Business Digital Transformation

How do you as an IT personnel design a website for salesmen to remotely enter information about premium collection?

1. Salesman #9 collects the following money and enters the ERP, but has not transferred the money to the bank account of the insurer:

How will your ERP create accounting journal entries for above data entries?

2. The salesman #9 will transfer the entire amount to the company's bank account three days later.

If you can't overcome barriers 1 or 2, it means that there is a gap between cash flow and accounting. Even if your website design skill is superb, your work should not be launched for salesmen to use, so as to avoid creating an uncontrollable mess.

An ERP that fails to fulfill any of the preceding questions does not meet the OLTP characteristics and does not seamlessly integrate business and finance.

An insurance ERP that decouples its accounting module from its business modules and lacks OLTP features has the following main defects that cannot be completely improved.

The worst arrangement is: outsourcing and plugging in an accounting module "with sub-ledger capability and pre-made statistical reports".

Such hybrid software systems will cause the following undesirable side effects:

It is not easy to integrate outsourced accounting module with business modules.
The programming language and database used by the outsourced accounting module may not be the same as those used by business modules. Even if they are the same, it is still not easy to seamlessly and instantly integrate the outsourced accounting module with business modules. It brings unnecessary painful burdens and technical tests to MIS personnel: lossless and real-time, one-way or even two-way, synchronization of two or more (even different brands) databases.
The outsourced account module may be a black box.
The following problems occur if the software does not come with source code.
  • MIS personnel cannot optimize the module by themselves.
  • MIS personnel have no chance to learn from it and improve their professionalism.
  • The company is like being kidnapped by the software supplier.

Decision makers made such decision due to these misconception:

In fact, the in-house personnel may not be unable to take on the responsibility. The ideal strategy is: professional managers themselves or external lecturers train subordinates to enhance their professional capabilities, so that subordinates can develop accounting modules with better quality than those sold in the market, and perpetually optimize accounting modules independently.

to-do task: building an insurance ERP that seamlessly integrates business and finance modules with the following characteristics:

Fully IFRS 17 compliant.
There are no hidden errors in accounting information.
Accounting information is consistent, timely and complete with each business module.
All kinds of statistical data, including salesperson bonuses, are all taken from accounting journal entries. There is absolutely no inconsistency between business data and accounting data that would confuse users of the information.
The accounting journal entry information is detailed , can be traced back , and can be linked to the original transaction records.
Installment payment, prepayment reversal object, prepayment, accounts receivable party, bank account number, bills receivable number, payment order number, claim settlement number, surrender order number, fixed asset number, account due date.
The number of batch jobs is minimized.
Batch processing is limited to aggregate calculations (for example: adding up the amounts of a certain category, then calculating the amortization amount and generating accounting journal entries in batches, or calculating salesperson bonuses).
The structure of the accounting data table is simple, and the ERP is Low code development platform.
Not only IT personnel, but also actuaries and accountants who know their own business best have the opportunity to participate in ERP development to quickly satisfy information needs and realize the ideal of citizen ERP development.

I Help Insurers Build IFRS 17 Compliant Information Systems.

Low code development platform PostERP accounting module has been supporting general ledger and sub-ledger since 2006 and seamlessly integrating various business modules with accounting module by generating colludable accounting journal entries in real time.

The key factors to the success of an insurer’s digital transformation are not limited to the IFRS 17 challenges and solutions described in this article. Here are some more articles exploring decent ERP architecture:

The author of this article C.N. Liou has these insurance industry ERP experiences:

❮ PostERP Is Simple PostERP Fits All Enterprise Sizes ❯