IFRS 17: Introduction to Subledger System
By Tze Ping Chng, Steve Cheung, Terrance Lee and Stephanie Chong
International News, May 2021
After a very long journey, the International Accounting Standards Board (IASB) issued IFRS 17 “Insurance Contracts” (IFRS 17) in May 2017. IFRS 17 replaces IFRS 4 that was issued in 2004. The overall objective is to provide a more transparent and consistent accounting model for insurance contracts among entities issuing insurance contracts globally. Three years after the release of the IFRS 17 Standard, the IASB published the amended version of IFRS 17 on June 25, 2020. The revised effective date of IFRS 17 has been deferred to annual reporting periods beginning on or after Jan. 1, 2023.[1]
IFRS 17 introduces a fundamental change to the financial reporting requirements for insurers, including the accounting standard interpretation, actuarial valuation methodology, insurance contracts valuation, and the corresponding financial statement presentation & disclosure. In order to achieve the above objectives, insurers will need to take note of the requirements on its overall system architecture, end-to-end data flow, data granularity, and the linkage between system components (administrative system, actuarial model, finance system, etc.) when implementing IFRS 17.
This article provides an overview of one of the most budget-, resource- and time-consuming components in an insurers’ IFRS 17 implementation journey in Asia—the subledger implementation. This article covers the key functionalities of a subledger system, as well as the important lessons learned during the implementation processes.
High Level Introduction of the Subledger System
The subledger, in general, provides a detailed breakdown of the entries behind the general ledger used for financial reporting. In particular, for IFRS 17, the subledger is used to produce the additional entries required under the IFRS 17 presentation & disclosure framework. These additional entries are posted to the general ledger for the preparation of the respective financial statements.
IFRS 17 does not only require changes to a finance system, it also poses a profound impact on the entire business and reporting processes. While a subledger is positioned in between the administrative system, extract, transform and load (“ETL”) tools, actuarial models and general ledger, it is aimed to minimize the changes or additional developments on the existing system components when fulfilling the IFRS 17 requirements. The diagram below shows an example of how a subledger system fits into a typical financial reporting process for insurers.
Figure 1
Interaction Between the Subledger and Other System Components for Financial Reporting
Key Processes within the Subledger System
In general, there are at least three core components within the subledger system, namely the Data Management Process, Calculation Process and Accounting, Posting and Reporting Process (Accounting Process).
The diagram in Figure 2 illustrates the key processes within the subledger system:
Figure 2
Key Processes within the Subledger System
1. Data Management Process
Typically, the subledger journey starts with a standardized data staging area in which certain source data is input from various upstream system components (for instance, administrative, claim, expense, reinsurance system, actuarial model and finance system, etc.). The Data Management Process will (i) capture the relevant input data, (ii) convert the data into a certain system-specific format, and (iii) convert the data into the required level of granularity and currency to fulfill the subsequent calculation and accounting requirements.
Some common input data includes actual and expected cashflows, coverage unit, discount rate, FX rate, and the linkage between underlying contracts and the reinsurance contracts held. The input data required will also be dependent on the overall design of the end-to-end process—for instance, whether the discounting of future projected cash flows is done within or before the subledger system.
2. Calculation Process
During the Calculation Process, the subledger will perform the necessary calculations under IFRS 17 and prepare the outputs required for the downstream posting and reporting. These calculations will rely on the upstream data gathered during the Data Management Process.
Some common calculations include (i) CSM roll forward calculation (CSM interest accretion for GMM, CSM adjustment due to experience variance & assumption change, CSM amortization, etc.), (ii) recovery of insurance acquisition cash flows, (iii) systematic allocation of the loss component, (iv) CSM adjustment on the reinsurance contract held due to the underlying contract, and (v) loss recovery component calculation, etc. The Calculation Process may need to cover the related disclosure requirements including sensitivity analysis and the CSM run-off pattern, depending on the system and business requirements.
3. Accounting Process
The Accounting Process handles the final step in the subledger system including accounting event posting and the corresponding IFRS 17 specific reports generation. It provides the final linkage from the IFRS 17 outputs into the general ledger.
With the significant change in the overall presentation & disclosure requirements, the IFRS 17 posting framework should be defined properly within the subledger to link the outputs from the upstream Data Management and Calculation processes to the IFRS 17 posting. The posting granularity and chart of account design in the subledger should provide sufficient information for both financial and management reporting. Typically, the subledger will have controls embedded throughout in order to reconcile the data flows and processes to ensure the accuracy and consistency of the relevant accounts.
Subledger System Implementation
Subledger implementation is one of the major tasks during the IFRS 17 implementation journey. It requires a multi-disciplinary team including accountants, actuaries and IT experts with a well-defined project plan and project management office (PMO). From actual implementation experience, an agile delivery model was adopted for the subledger development, in which the project was separated into multiple sprints with some sprints overlapping with each other. This was to accommodate the tight development timeline, re-deliberation process from the IASB, and the evolving IFRS 17 Standard before the final Standard was issued in June 2020.
Project Team Structure: Key Workstreams
The implementation team is structured with various workstreams according to the typical components of a subledger system. In general, Data Management Process is led by IT, Calculation Process is led by actuarial while Accounting Process is led by accounting. The PMO will overlook the overall project timeline, progress, budget, and resource allocation. It is also important for insurers to consider the cross-workstream interactions, consistent interpretation of business requirements, and the data linkage between the Data Management, Calculation and Accounting processes.
Figure 3
Typical Work-Stream for Subledger System Implementation
Before the Implementation Phase
Before the subledger system implementation, it is important for insurers to understand what needs to be built in the subledger. Hence, during the design phase, insurers should prepare (i) accounting policies with the overall interpretation of the IFRS 17 requirements and accounting policy decisions, and (ii) business requirement documents to articulate the business logic on the relevant actuarial and accounting items. Some insurers start with the posting framework development by including all posting items required under IFRS 17, to ensure that all the necessary posting entries are covered in the business requirements during the design phase.
Key Milestones during the Implementation Phase
During the implementation phase, it is important for insurers to take note on the following key milestones
- Technical design: illustrate how the business requirements are reflected in the subledger system, in particular the end-to-end data flow from the upstream source system through to the subledger posting.
- Data linkage: ensure that the data inputs to the subledger are fit for purpose and at the right granularity.
- Configuration vs customization: configure your requirements leveraging the standardized system setting and coding logic, and further customize to reflect the calculation and posting logic based on the insurer’s own specific requirements.
- Report generation: define the IFRS 17 presentation & disclosure reports within the subledger system.
- Posting to general ledger: prepare the interface files that can be used for the general ledger posting.
- Control & reconciliation: understand the overall control & reconciliation functionalities of the subledger system.
- Deployment: deploy the solution in production environment after the subledger system is built and tested.
Subledger System Testing
Before the subledger can be deployed for production, testing should be conducted to ensure that the system performs according to the designed business requirements. There are various types of testing that an insurer can consider (noting that the testing required will be dependent on the maturity of the system solution and the insurer’s understanding of the system). With limited time and resources for IFRS 17 implementation, it is important for insurers to design the overall testing strategy and focus on meaningful test cases. Insurers should also prepare independent test tools to validate that the subledger system outputs are as expected.
Different types of testing for subledger system:
- Unit test / component test: the test case is designed to test the individual business requirement or individual system component. For instance, whether the CSM amortization amount is calculated properly according to the coverage unit release pattern in the Calculation Process, or whether the posting is done correctly for the “insurance revenue” in the Accounting Process. This test can be combined with the integration test depending on the maturity of the system solution.
- Integration test: the test case is designed to test the end-to-end subledger system including all Data Management, Calculation and Accounting processes. Test data will be entered into the data staging area at the beginning of the Data Management process; the same data will be processed end-to-end within the subledger system up through reporting to mimic a production process. Corresponding workstreams will validate if the system outputs are same as the expected value. Normally this test is conducted using mock-up data, and it may not test the interaction between the subledger and the existing system architecture completely.
- User acceptance test (UAT): after the integration test done by developers, business users should conduct the UAT based on the actual production data or modified production data to ensure that the subledger system is behaving as expected, and to ensure proper linkages between all system architecture components from policy administrative system through the general ledger.
- Parallel run test: before the system goes live, a parallel run test is conducted to simulate the future reporting process, and to analyze the financial results.
- Others: there are also other types of tests that insurers can consider, including the performance test, stress test, etc. A regression test is also conducted when part of the system solution is updated after certain testing above has been conducted. The extent of the regression test will depend on the degree of changes that have been applied in the subledger system.
Conclusion
This article provides an overview of the key components of a subledger solution, and the common approach adopted by insurers when deploying such a solution to its IFRS 17 program. Similar to other large scale financial reporting system implementation initiatives, insurers will need to consider proper implementation and testing approaches. The related design considerations, implementation details, and testing evidences should be properly documented and approved within the entity’s governance structure, as well as agreed with the entity’s auditor. Insurers should get familiar with the new subledger system functionalities during the testing phase, and deploy the subledger outputs for the future financial and management information reporting purposes.
Statements of fact and opinions expressed herein are those of the individual authors and are not necessarily those of the Society of Actuaries, the editors, or the global EY organization or its member firms.
Tze Ping Chng, FSA, FASHK, MAAA, is a partner at Ernst & Young Advisory Services Limited in Hong Kong (EY HK). He can be contacted at tze-ping.chng@hk.ey.com.
Steve Cheung, FSA, FASHK, is an associate partner at EY HK. He can be contacted at steve.cheung@hk.ey.com.
Terrance Lee, FSA, is a consulting actuary at EY HK. He can be contacted at terrance.lee@hk.ey.com.
Stephanie Chong is a senior associate at EY HK. She can be contacted at stephanie.chong@hk.ey.com.