5 Questions Every Insurance CFO Should Ask Before Investing in a New Financial Management System

Choosing a financial management system used to be a relatively “tame” decision. You evaluated functionality, negotiated licensing, and managed the implementation. The compliance landscape was stable enough that a competent general-purpose system could handle most of your finance team’s needs.

The keyword to emphasise here is “stable landscape”.

IFRS 17 has raised the floor on what an insurance financial management system must do, as well as the stakes for getting the choice wrong. As we explored in our previous article, How Infor SunSystems Enables IFRS 17 Compliance for Insurance Companies, compliance is not a one-time project. It is an ongoing operational discipline. The system you choose either supports that discipline structurally or it creates friction that your finance team absorbs manually, month after month.

If your team and business are considering digitally transforming the finance function, these 5 questions can help cut through vendor demonstrations and get to what actually matters.

Further reading:

Question 1: Does it eliminate the need for separate reconciliation?

Consider asking the vendor to explain how their system eliminates the need for reconciliation across accounts, business units, and different systems.

If the answer involves automation, scheduling, or improved matching logic, you are looking at a system that has sped up reconciliation. Every interface between separate ledger environments, between the GL and a sub-ledger, between the finance system, spreadsheet apps, and a reporting layer, and between local entity/group accounts and a consolidation tool is a point where data can diverge, where timing differences introduce misstatements, and where the audit trail breaks.

A true unified, single-ledger architecture posts every transaction to all relevant accounts simultaneously. As a result, there is no reconciliation between ledgers as there are no separate environments.

Consider asking your solution provider this question:“Show me where the reconciliation happens between the GL and management reporting. What are the manual steps involved, and how frequently does data need to be synchronised between environments?”

If the vendor cannot provide a demonstration that does not require exports or manual reconciliation steps, the system is not a single-ledger architecture.

Question 2: How does it handle IFRS 17 data granularity, monthly recalculations, and CSM tracking?

This question distinguishes systems that have been configured for IFRS 17 from those designed for it.

IFRS 17’s Contractual Service Margin (CSM) is the most operationally demanding concept introduced by the standard. The CSM must be tracked from initial recognition, adjusted each period for changes in estimates of future cash flows, released systematically as services are delivered, and reported with full disclosure of the movements.

This calculation requires contract-group-level data, embedded dimensional tagging, and a direct connection to actuarial model outputs.

The right system stores transaction data with its full analysis dimensions (such as policy type, contract group, measurement model, business unit) from the point of entry, so that CSM tracking draws on consistently tagged source data rather than on downstream reclassification. Monthly recalculations should be a controlled, system-driven process, not a finance team exercise in reconciling actuarial exports against GL balances.

Consider asking your solution provider this question:“Show me how the CSM roll-forward is produced. Where does the actuarial data come from, how does it enter the system, and what manual steps are involved between actuarial model lock and the production of the IFRS 17 disclosures?”

The answer to this question will tell you more about a system’s true IFRS 17 readiness.

Question 3: Can it consolidate across multiple entities, currencies, and regulatory frameworks in real time?

For insurance groups operating across APAC, this question is where many vendor claims fall apart under scrutiny.

APAC insurers face a compounding regulatory burden: IFRS 17 requirements alongside risk-based capital standards; IFRS S1 and S2 sustainability reporting, which are incoming across multiple jurisdictions; and country-specific adaptations, such as Indonesia’s PSAK 74 and China‘s rollout for non-listed entities from 2026.

A subsidiary in Vietnam must comply with Vietnamese Accounting Standards for local regulators while providing IFRS 17-compliant numbers to the group’s consolidated statements. These are not the same numbers, and the system managing that subsidiary must hold both frameworks simultaneously, not as a workaround but by design.

Currency translation adds further complexity specific to IFRS 17. A system that applies currency conversion at the ledger level rather than at the transaction level will undermine IFRS 17’s purposes and outputs, posing additional challenges for insurers during audits.

Consider asking your solution provider this question:“Can you show me a group consolidation across two entities with different functional currencies and different local reporting requirements. How does the system hold both local statutory frameworks, such as Vietnamese Accounting Standards or Indonesian PSAK 74, alongside IFRS 17 group reporting? At what point does currency translation occur? At the transaction level or period-end ledger level?”

Ask also whether the multi-entity consolidation requires any data exports or manual aggregation steps outside the system. If the answer involves spreadsheets at any stage, the consolidation is not genuinely real-time. It is a periodic extraction presented as one.

Question 4: What is the true total cost of ownership, including the cost of your current system’s inefficiency?

Most technology evaluations compare the cost of the new system against its licensing fee. The more honest comparison is the total cost of the new system against the total cost of the current one.

Your current system has a cost that does not appear in any invoice. It is embedded in the hours your finance team spends each month on manual reconciliation, spreadsheet-based consolidation, and rekeying actuarial data.

It shows up in the talent equation, a.k.a., you, the experienced finance professional who has to spend their time on administrative tasks rather than deep analysis and producing meaningful, audit-ready reports.

Compared with on-premises solutions, Infor SunSystems Cloud runs on AWS infrastructure, eliminating hardware investment, reducing IT maintenance overhead, and removing manual upgrade cycles.

Every six months, Infor delivers a new release of SunSystems Cloud at no additional licensing cost. For instance, the latest April 2026 release announced the delivery of enhanced reporting capabilities through the Query & Analysis Report Scheduler, live Accounts Payable dashboard widgets for real-time cash flow visibility, and an expanded language library. These enhancements are rolled out automatically, without involving your IT team or causing downtime.

The calculation your CFO should run:

Staff hours per month consumed by manual reconciliation and data transfer × loaded cost
Estimated cost of a material audit finding or regulatory restatement
IT infrastructure and maintenance costs of on-premise deployment
Opportunity cost of the finance team capacity absorbed by administration rather than analysis

The total cost of the status quo is rarely made visible in a technology evaluation. It should be the baseline against which any new investment is measured.

Check out this case study:From Legacy to Cloud: How Global Insurance Corporation Mitigates End-of-Life Systems Challenge

Question 5: Who is implementing it, and do they have insurance-sector expertise in your region?

This is a question about the implementation partner, not the product. A generic system provider who has read the IFRS 17 documentation is not the same as a team that has configured an industry-specific financial management system for an insurer operating under both Vietnamese Accounting Standards and IFRS 17. The difference is between a go-live that delivers a compliant first close and one that requires months of post-implementation remediation.

Consider asking your solution provider this question:“How many insurance clients have you implemented successfully? Can you provide a reference from an organisation of comparable size and structure? What is your methodology for configuring the system for local statutory reporting alongside IFRS 17? How do you handle the integration between the financial management system and other platforms?”

Look specifically for evidence of regional regulatory knowledge in addition to just product knowledge. An implementation partner who understands PSAK 74 in Indonesia, VAS in Vietnam, or the specific IFRS 17 rollout timeline in the Philippines is not the same as one who knows the standard in the abstract. The regulatory context determines how the system must be configured, and that knowledge cannot be improvised during an implementation.

Bonus: What does the vendor’s release cycle look like?

A financial management system implemented today will need to keep pace with an evolving compliance environment as well as the business’ growth. Insurers have to keep in mind that IFRS 17 is not the only regulatory standard reshaping the finance function in the insurance sector, especially in APAC. IFRS S1 and S2, the ISSB’s standards for sustainability-related and climate-related financial disclosures, are moving from voluntary to mandatory across APAC in staggered timelines.

On the other hand, RBC frameworks require insurers to hold minimum capital proportional to their actual risk profile. The critical point for finance leaders is that RBC reporting draws on the same contract- and portfolio-level data as IFRS 17.

Therefore, TRG believes that the system requirements regarding disclosure quality and granularity are likely to increase rather than stabilise. The regulatory landscape your system must support in 3 years will not look identical to the one it must support today.

Infor SunSystems Cloud delivers regular system updates, with enhancements focused mainly on efficiency, reporting, visibility, and compliance. For insurance organisations, this cadence means the system is continuously developed in response to the evolving regulatory and operational environment, all of which is done by the software developer and provider.

Ask any vendor you are evaluating when their last product release was, what it delivered, and when the next one is scheduled. The answer will tell you whether product development is a genuine ongoing commitment or a marketing claim.

All in all, the financial management system that you choose today is not just a technology decision. It is the infrastructure on which every IFRS 17 reporting cycle, every regulatory submission, every board-level financial insight, and every audit response will be built for the next several years.

The six questions above are designed not to identify a perfect system (please note that no system is perfect for every organisation). These questions are designed to help you and your business surface the structural realities that might be overlooked during the demo phase.

A system that cannot eliminate manual intervention for CSM tracking or currency conversion, or that is implemented by a team without regional insurance expertise, will create ongoing friction that your finance team quietly absorbs until it cannot.

Speak to TRG International’s insurance finance specialists to understand how Infor SunSystems Cloud addresses each of these questions in your specific regulatory environment.