Aptitude Software describes the importance of using an accounting hub and subledger to achieve successful IFRS 17 compliance
While it feels like IFRS 17 has been a part of the insurance conversation for quite some time, it was just over 18 months ago that FWD Group ("FWD") became one of the world's first insurers to select a technology solution to address the new standard. Since then, the insurance industry, vendor community, and the standard itself have evolved quite a bit.
After welcoming FWD as the first IFRS 17 client in early 2018, Aptitude Software is now implementing its IFRS 17 Solution in 46 countries – and working with FWD as they become one of the first global insurers to enter UAT [user acceptance testing] under the new standard. Over the last 18 months, our global IFRS 17 implementations have informed our approach and reinforced our ability to help insurers navigate the challenges and seize the opportunities inherent in the Standard.
For our clients and prospects - some of whom have now come back to Aptitude after failed solution implementations - the use of an accounting hub and subledger to achieve IFRS 17 compliance has been the single most important differentiator for a successful IFRS 17 implementation.
What is an accounting hub?
An Accounting Hub can be made up of multiple components including standardized APIs, a financial data store, configurable posting engine, rich subledger and a reporting/extract layer. Together they provide a configurable, IP-rich solution.
An accounting subledger, typically included in an accounting hub, is a database or book of accounts used to store a detailed subset of double entry accounting transactions. A subledger allows companies to maintain data at lower levels of granularity, which can then feed the general ledger(s) – either in the cloud or on premise - at a more consolidated level for accounting and reporting.
The subledger integrates and allows retention of transactional and event level detail, providing a linkage point between the source systems where the data originated and the target systems (GL, Analytics & BI solutions, AI tooling, etc.) that can turn that data into reporting and insights.
Subledgers are garnering a renewed interest as organizations grapple with complex compliance efforts like IFRS 17, in addition to typical finance challenges like systems consolidation, data proliferation, cloud migration requirements and an expanded CFO role. In response to this interest, Gartner has added Accounting Hubs to their financial management applications landscape.
This work will also help establish a baseline of functional capabilities that should be included in a subledger such as handling multiple GAAPs, foreign currency calculations, period-end processing and more.
Accounting subledgers drive strategic compliance
Compliance remains one of those things that can take up a lot of time and resources for a CFO, and IFRS 17 is certainly no exception. However, many CFOs are taking a smart compliance approach to IFRS 17. This entails addressing the data, systems and process changes required in a way that achieves additional business benefits. As a result, this can position the finance department to offer corporate strategic guidance rather than just governance and react to future regulatory changes with agility.
For many insurers, this has meant investing in a subledger to drive business benefits in the areas of strategic foresight, financial control and operational intelligence. CFOs are finding ways to harness the increase in granular data required by IFRS 17 to make more informed business decisions. They are also using IFRS 17 budgets to make improvements to finance architectures and launch finance transformations that will take their organizations into the digital future.
For example, a large European Insurer is using IFRS 17 compliance to enable a finance transformation. In addition to gaining the ability to "walk" between IFRS 17, Solvency 2, and the new capital standard reporting, they are expecting to automate over 70% of finance reporting while also driving a productivity increase of 40%.
"A (zero balancing) subledger provides a solid foundation for using transaction, contract and reference data at the most granular level of detail – providing agility and robustness. It enables a clean separation of accounting and actuarial elements and helps to simplify processes, hand-offs, and actuarial models." Grant Robinson, Senior Actuary – Head of Actuarial, Projects & Support, AMP Life
Similarly, Swiss Re Corporate Solutions is a good example of a global company that has come to realize the benefits of a subledger as they scale their global footprint. The currently installed subledger, included within the Aptitude Accounting Hub, has allowed them to centralize accounting data and address requirements for multi-GAAP reporting.
The resulting end-to-end data lineage offers multiple benefits, such as a faster close process, a consolidated view of financial data and full control over all accounting calculations and reporting in one place.
Along with being able to handle the complex requirements of IFRS 17, a subledger can also provide the following;
- a single-view of financial information across the entire organization including real, forecast, transactional and customer data
- support for a cloud general ledger migration
- real-time access to granular data for advanced analytics & business decision making
- an efficient and future-ready finance department with fully automated, low maintenance, faster systems which deliver better TCO and allow the business to more easily address change
Subledgers have been driving increased efficiencies in finance departments for many years, but the complexities of IFRS 17 and the shift to digital are now making subledgers a necessity for any finance department wishing to modernize and remain relevant.
Subledgers provide an accounting-driven approach to IFRS 17 compliance
While initially there was a general perception that the IFRS 17 insurance standard could be handled within the actuarial systems, the complexities of IFRS 17 have crystalized and now the focus is on determining where the handoff point is between the actuarial and accounting departments.
"The standard is going to create a world where you can no longer be a good accountant if you don't understand actuarial matters and where you can no longer be a good actuary without understanding financial reporting and capital management." Ferdia Byrne, Global Insurance Actuarial Lead Partner, KPMG UK
Solvency II was very much an actuarial driven approach where the SCR calculation and risk margin were primarily based on discounted future liabilities. However, under IFRS 17, revenues and profitability are predominantly driven by releases of actuarial reserves (release of Risk Adjustment and release of CSM) which will require additional data, such as historical policy data, and an increased number of calculations.
Most actuarial vendors are providing modelling templates and libraries for IFRS 17 which can be customized to produce the specific cash flows and the expected CSM and RA numbers – but these do not address the conversion of actuarial data to accounting events and transactions that are essential for the IFRS 17 disclosures. Many insurers are looking to meet these needs with a subledger and accounting engine to store the IFRS 17 data at sufficient levels of granularity to support the generation of the disclosures.
In addition to supporting the granularity and data volume requirements of IFRS 17, an accounting engine and subledger can address the many complexities inherent in these types of accounting transactions. Namely around multi-currency/FX, complex entity structures, consolidations, allocations, reconciliations, reinsurance and multi-GAAP reporting.
Furthermore, IFRS 17 requires measurement and re-measurement of the performance of contracts over the life of that contract. This requires the intrinsic capability to store the results of the calculation at each measurement period and provide a fully auditable process as the calculation changes over time. A subledger provides the capability to manage this process with full transparency, providing an audit trail of changes which can be accessed simply and easily and where required can be tracked back to the transaction level.
The accounting and actuarial worlds will now have to work in unison to a much greater degree than ever before, particularly as the adoption of IFRS 17, and therefore a successful IFRS 17 implementation, will have a marked impact on insurers' future profitability profiles and therefore share price. For now, we are seeing many insurers adopt an accounting driven approach to IFRS 17 reporting while at the same time enhancing their actuarial capabilities.
Subledgers take pressure off the general ledger
IFRS 17 makes the sole use of a General Ledger for accounting virtually unsustainable. The standard requires a massive increase in data sets and calculations that cannot be managed by a general ledger at the level of detail required. Add in the audit scrutiny that insurers will undergo following the switch to IFRS 17 reporting and it's clear a General Ledger, with its aggregated balances and lack of source to post linkages, is not a long-term solution.
And it's not just IFRS 17 that's responsible for today's overburdened GLs. Too many functions within the business are making changes directly in the GL with no record of why or how and often there are multiple GLs across the business – some still siloed – because of multiple acquisitions.
An overburdened GL can create issues for an organization. Inefficient core processes with clunky workaround solutions can open a company up to operational risk and higher cost and resource requirements. A lack of linkage between balances and source system transactions can also mean a lack of understanding about business drivers which will be critical in the post IFRS 17 world.
Using a subledger can ease the data pressures on a General Ledger. By freeing up the General Ledger to support basic reporting requirements, you can significantly extend its life and ensure you get the maximum value from your investment. When the time comes to upgrade the GL, a subledger provides the ideal platform for a seamless switch to a more modern solution such as a cloud GL.
For example, one of the largest banks in the UK chose the Aptitude Accounting Hub (AAH) to support the move to a cloud GL and the rationalization of multiple ledgers towards a thin Group GL structure. They continue to expand the number of applications that feed into AAH and are planning for an additional 20 key applications to be incorporated into the primary subledger in the next two years.
In addition to providing a single version of detailed data and an important mechanism in maintaining a thin, standardized GL, they are finding that the UK regulators like the fact that AAH stores key reporting data on-premise, in the event of a failure along the Cloud chain of data.
Stay the course
Even the most basic approach to complying with IFRS 17 will take a significant amount of effort and budget. The standard does an excellent job of highlighting the manual-heavy, disparate and siloed systems and processes that are currently in place in many organizations. So much time, energy and cost are being poured into maintaining the status quo and it is more obvious than ever before that this cannot continue. IFRS 17 is demanding positive change.
The one-year delay in the standard effective date has given Insurers the chance to be more strategic in their approach to IFRS 17 compliance. A recent white paper from Deloitte identifies IFRS 17 as "a unique opportunity to invest not only in compliance, but in a modern accounting approach.'' This is the chance for insurers to invest available budget dollars to create the finance infrastructure that will take them into the future.
Seven reasons an IFRS 17 project may fail
While the selection of an IFRS 17 solution vendor may seem like the end of a long and detailed internal project, the reality is that the start of solution implementation is just the beginning.
Hopefully, you have secured a solution with all the 'must have' functionality required by the new standard, but many insurers don't have a complete understanding of these necessities at the outset of their projects – and it may not become apparent until quite late.
The challenge for many insurers is that they have initially focused their projects on the need to determine the calculations for IFRS 17, assuming that the process to then integrate into their financial landscape can be achieved with the bolt-ons being developed by their calculation engine vendor.
However, for many, the complexities in the accounting are only just being realized, resulting in some clear systems issues that are preventing them from delivering an operational solution. Here are seven common IFRS 17 solution issues that may arise during IFRS 17 projects.
Lack of persistence and audit trail for calculated data
If data is held in a table and not a database, it may impact the solution's ability to provide a necessary audit trail and manage reconciliations. In addition, IFRS 17 requires measurement and re-measurement of the performance of contracts over the life of those contracts. This requires the intrinsic capability to store the results of the calculation at each measurement period and provide a full audit trail to explain the results movement as the calculation changes over time. Without a subledger, the process cannot be efficiently managed and there is no audit trail to show changes that can be assessed and tracked to the transaction level.
No version control for accounting rules and no audit trail of the rules used, which impacts controls and reconciliations
Version control of accounting rules is very important and can have a significant impact, especially when accounting policies or chart of accounts change. There is an expectation for finance to keep the detail of how balances are derived for tax authorities, financial reporting, and regulatory inspection – in many cases this detail must be stored for many years after the cutover to the new standard. It is also important to understand and show what rules were applied and when, and to be able explain period to period differences as a result of core accounting policy changes.
When an IFRS 17 solution lacks persistence and transparency around data, accounting rule versioning, and accounting rule use, it can lead to issues. Other issues can arise when an IFRS 17 solution is IT centric and requires the involvement of IT for key finance aspects like audit. Rather than traceability through the subledger, these IT-based solutions are known to produce Binary files which then require a complex mechanism through which you can interrogate files to deliver the audit trail required.
Inability to support reversals and interim versus external reporting
There is a practical finance issue that arises when evaluating interim vs external reporting. This is particularly apparent when subsidiaries perform annual reporting whereas the parent reports quarterly. This situation requires that at least two sets of books with two separate CSM figures are held, depending on the frequency of reporting and the year end of the subsidiaries. This kind of parallel processing would typically overburden a General Ledger, significantly impacting its performance and time to close. A subledger capability is necessary to meet this important requirement.
Limited accounting templates and business event rules, resulting in the need for customizations and an explosion of custom rules
Any comprehensive IFRS 17 solution will need to convert actuarial data and actual cash flow data into accounting transactions. The inbound insurance data should be processed by the accounting engine and posted to a granular subledger.
It is very easy for the number of accounting rules to explode as IFRS 17 requires the application of a significant change to the mechanism an insurance firm uses to create their books and records. When accounting rules are written on a contract-by contract basis, there is often a massive duplication of logic, leading to inconsistencies between developers as well as a maintenance nightmare once the solution goes live. An IFRS 17 solution needs to have built-in business logic and templates that are highly configurable and reusable rather than being a customized solution.
Limited internal controls for areas such as FX, zero balancing journals, and period control
If these features are not included as part of the solution, the onus is on the General Ledger (GL) or custom processes to ensure the validity of the journals and complete the operational accounting process. Given the level of scrutiny expected on the part of auditors, shareholders and the ratings agencies, having a fully functional subledger with capabilities like zero balancing and automated reconciliations, operating at the journal level is essential. Auditors will check for quality of input data, calculations, accounting transactions and processes and thus the ability to drill down to a highly granular level is critical.
IFRS 17 also requires a number of complex currency translations for multi-currency denominated contracts and aggregations up through legal entity structures. It is important this is maintained at the correct level of granularity within the IFRS 17 solution to explain the impact on the CSM and ensure that the business is managing its currency positions.
Any IFRS 17 solution should provide full, multi-currency accounting including FX translation, FX revaluation functionality and management of multi-currency CSM.
Incomplete chart of accounts (CoA) with no flexibility to edit, requiring CoA mapping to happen in a custom layer
In an operational process, the disclosures should always be generated from the CoA balances to maintain auditability and traceability. An incomplete CoA will result in missing information for disclosures and requires unpicking the numbers externally.
This places a needless burden on the finance team, requiring them to fill in the blanks – a nightmare during year-end preparation of disclosures for the annual report. In such a situation, the period-end reporting processes will increase in duration, complexity and stress.
Disclosures generated from calculated numbers, not posted journals
Big 4 Insurance Advisory firms have noted a trend over the last six months. Insurers who selected an IFRS 17 calculation engine are now realizing that they need an accounting rules engine and subledger to satisfy the requirements of the standard. Many of these insurers that selected a pure IFRS 17/CSM engine have now gone out for a second wave of RFPs specifically for an accounting rules engine and subledger.
Finance teams are demanding an underlying data repository to plug the existing solution gaps that prevent them from accurately accounting, reconciling, and producing their disclosure reporting requirements. While some actuarial based solutions can undoubtedly calculate the expected CSM and RA numbers, it is the translation of these numbers into accounting inputs (debits/credits) and the associated postings that, when missing, pose a major challenge to insurers.
Avoid these 7 issues – and gain business value beyond compliance
The Aptitude IFRS 17 Solution meets the many requirements of the Standard by including all three necessary components for compliance: an IFRS 17 Calculation Engine, an accounting rules engine and a subledger with underlying rich data repository that can be traced from source to disclosure report. It provides an audit trail of changes which can be easily assessed and tracked to the transaction level as needed. It also enables the persistence of the balances – balances are not just calculated on the fly - at each layer to retain the auditability.
The solution can be owned by finance, reducing the dependence on IT and putting the control in the user's hands. It has significant built-in IP with templated rules for more than 160 insurance lifecycle business events which are used to generate IFRS 17 accounting transactions. These events are re-usable every time a new product is launched and hence help to manage the rules and ease the risk to the GL from storing an explosion of rules or data. A simple example is often shown during our POC playbacks, where the "ACID" business event (Assumption Change Increment Decrement) is re-used across policies and policy types whenever this type of data is discovered. The elegant 3-step accounting process used by Aptitude, ensures there is a minimal number of Business Events, Accounting Events and Posting Patterns to maintain, meaning a smaller, simpler and easier to audit set of accounting logic is in the hands of the Finance team.