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
entry#1:
Future Cash Flow 40
Risk Adjustment 10
Contract Service Margin 50
Insurance liability 100
Here lie these challenges:
- Which collection slip is the data source for entry #1? If an IT staff doesn't have the answer, once the original receipt is modified, the IT staff will not be able to know that entry #1 should be modified accordingly!
- Entry #1 is for which policy numbers? If you don't know, IT staff can't program to read accounting journal entries, classify them by policy type (group), and generate various aggregation reports such as profit and loss, amortization, and reserves!
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:
- Policy #1: 2nd installment full premium $100, 3rd installment prepaid $90
- Policy #2: 5th installment full premium of $200, late payment fee of $20, 6th prepaid premium of $200, 7th prepaid premium of $200
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.
- After the ERP passively receives the bank payment notification, or actively polls the bank API to learn the payment information, how should the ERP immediately create an accounting journal entry?
- How does your ERP compare (reconcile) accounting journal entries with bank receipt data?
- Can your ERP derive these data by tracing back the aforementioned data entered by salesperson #9 from accounting journal entries: policy #1, policy #2, payment period and amount? If your ERP can't do it, how can insurers manage collection operations, accurately write off installments, partially write off advance receipts, receivables, and where to read data to calculate salesperson bonuses?
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.
- Because the ERP is complex, even if its accounting data contains hidden errors, all stakeholders, including independent auditors, misunderstand that insurers meet the requirements of IFRS 17, but they actually are not. Such ERP is like an unexploded bomb, no one has the ability to dig it, let alone dismantle it.
- The accounting module becomes an "information island". The accounting module is completely unaware of the monetary data that is added, modified, and deleted at any time in each business module. In order to do their jobs, accountants are forced to transfer datasets from various business modules, download files, import them into worksheets, and even manually input report data, and then process and input entries to the accounting module in the next month. It is a huge pile of chaotic code created as temporary workarounds by countless generations of programmers. It is difficult for senior IT staff to control, and IT novices cannot undertake maintenance. Users like accountants and actuaries are not satisfied with the ERP.
- The quality of the information service is not good because accounting information is not real-time. Most of the accounting information is unavailable to information users until the monthly batch runs are successfully completed.
- The ERP often has hidden discrepencies between business modules and accounting module. Inconsistent information confuses information users from insurer staff, salespersons, government taxation agencies, etc. Not knowing which data should be trusted, the customer service staff are too busy to answer the phone, the IT staff and the accounting staff work overtime without any credit. The whole company is in chaos.
- Attempting to fix the ERP problems, the company expands the size of IT departments by recruiting large number of personnel. The same phenomenon also occurs to almost all other department in addition to IT due to the poor quality of information services.
- Due to the difficulty of information integration, the pace of launching new information services is slow.
- IT staff tend to modify OLTP code in business modules but forget to also modify the corresponding code for batch processing, resulting in batch runs to output wrong data or to encounter exception in the middle of execution.
- Because the data is scattered in various business modules, the productivity of the IT department is low, and it is difficult to provide high-quality information services. For example, actuaries and accountants need statistical data, and IT personnel must fully understand the structure of the database tables of each business module, so as to be able to start writing complex programs to read a large amount of raw data, which takes a long time to complete.
- Batch job runs may be interrupted by exceptions, most of which are beyond operators' capability to debug. As a result, account closure is delayed.
- Because the data is scattered in various business modules, the execution of batch operations consumes a large amount of server resources and slows down the speed of ERP responding to other information users. Therefore, batch runs must be arranged to be executed during off-peak hours. This means that the insurer ought to recruit IT operators who will work night shifts.
- Insurance companies are forced to resort to this quick-and-dirty workaround: increase hardware expenses (eg. TWD 7 billion for a server) to make up for ERP software deficiency.
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-house personnel could not develop a better quality system than outsourced accounting module
- managing an outsourced accounting module is easier than making one
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:
- The first System Analyst responsible for user computing of a giant life insurer. See article "Information System Flaws Running on Mainframes".。
- Contracted and completed the complete information system of the Taiwan branch of the British Commercial Union reinsurance company.
