Insurers Digitally Transform Businesses This Way to Comply with IFRS 17

Posted: 2022-03-16 Edited: 2023-06-01

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!

As the chairman, general manager, chief information officer, chief financial officer or staff of the actuarial department, you are invited to review as early as possible your existing information system software (referred to as ERP) with a magnifying glass and ask yourself these questions: curriculum:

Does the accounting module seamlessly integrate all other business modules?
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.
Does the accounting module instantly reflect all moneytary related transactions occurring in all other bussiness modules?
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).
Can auditors trace from accounting data back to the original transactions that posted moneytary transactions to accounting module?
For example, auditors can find out the payment# or claim# by looking up the data recorded in accounting module.

If your answers to these questions are all "yes", your ERP system literally is already IFR-17 compliant and you don't need any third-party accounting reporting module at all. If you have a "no" answer to any of these questions, I can help you get there quickly.

The following hypothetical examples are given to illustrate the quality of your ERP system.

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 "that is IFRS-17 compliant".

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 can seamlessly integrats its accounting module with all business modulessince 2006. PostERP generates 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 Very Simple to Use