IFRS 17 Post-Implementation Challenges: 6 Operational Issues and How to Address Them
Most IFRS 17 implementations produce six recurring operational challenges after go-live — from manual processes embedded in the close cycle to institutional knowledge fading as teams rotate. These are not implementation failures. They are patterns that emerge once the standard moves from project to production.
For most insurers, the go-live milestone marks the beginning of a different and often harder problem: making the standard run reliably month after month. Across engagements in multiple jurisdictions, these six challenges come up with enough regularity that they are worth naming directly.
flowchart LR
A[Data Extraction] --> B[Actuarial Engine]
B --> C[Post-Engine Adjustments]
C --> D[Disclosure Templates]
D --> E[Financial Reporting]
E --> F[Management MI]
style A fill:#1E2538,stroke:#00C2CB,color:#F0F0F0
style B fill:#1E2538,stroke:#00C2CB,color:#F0F0F0
style C fill:#1E2538,stroke:#00C2CB,color:#F0F0F0
style D fill:#1E2538,stroke:#00C2CB,color:#F0F0F0
style E fill:#1E2538,stroke:#00C2CB,color:#F0F0F0
style F fill:#1E2538,stroke:#00C2CB,color:#F0F0F01. Manual processes embedded in the close cycle
After go-live, it is common to find that several key valuation or disclosure steps still rely on manual data transformations — spreadsheets bridging gaps between source systems and the actuarial engine, post-engine adjustments applied outside any controlled environment, and workarounds that made sense under implementation time pressure but were never decommissioned.
The risk is not just efficiency. Manual steps introduce version control problems, create single points of failure, and make audit trails harder to maintain. When reviewers ask why a number moved, the answer sometimes involves a spreadsheet that three people have edited in different directions.
How to address it: The goal is not to eliminate all spreadsheets immediately — that creates its own project risk. A more durable approach is to map every manual intervention in the close process, classify each by materiality and frequency, and embed controlled automation incrementally. Priority goes to steps that are both high-frequency and prone to error.
2. Errors surfacing late in the cycle
Without preventative controls built into the reporting calendar, issues tend to appear at the worst possible moment — during final reconciliation, when there is no time to investigate root causes properly. The result is either a delayed close or a decision to accept a number that has not been fully understood.
This pattern is particularly common in the first year or two of production, when teams are still learning where the sensitivities in their implementation lie. A model that behaves predictably in most periods will occasionally produce a result that requires explanation — and discovering that in week four of a four-week close is a structural problem.
How to address it: A structured reporting calendar with detective and preventative controls built in at earlier stages changes this dynamic. Detective controls — reasonableness checks, period-on-period movement analysis, CSM roll-forward variance flags — should run before the final numbers are locked, not after. Preventative controls address the upstream data quality issues that feed through to valuation.
3. Budgeting and forecasting still operating in pre-IFRS 17 logic
Forward-looking planning processes are often the last to catch up. Finance teams producing budgets and forecasts may still be projecting revenue and profit using pre-IFRS 17 concepts, while the statutory reporting function operates under the new standard. The gap creates real problems when board packs present plan versus actual comparisons that are not calculated on a consistent basis.
This is not a failure of implementation — it reflects where the urgency was focused. Getting the historical balance sheet right and the first production close completed was the correct priority. But the misalignment does not fix itself.
How to address it: Extending fulfilment cash flow mechanics into the planning process is the substantive fix. Projections of the liability for remaining coverage, the liability for incurred claims, loss components, and risk adjustment release need to be consistent with production. Running two parallel logics indefinitely is the alternative, and it compounds.
4. Management reporting not connected to IFRS 17 drivers
Boards and senior management need to understand what is driving the insurance service result. In many cases, IFRS 17 metrics have not been fully integrated into the dashboards and commentary templates that leadership actually uses. The statutory numbers are produced correctly, but the narrative connecting those numbers to business decisions is underdeveloped.
This is partly a translation problem. IFRS 17 introduces new line items — CSM amortisation, risk adjustment release, insurance finance income — that do not map cleanly onto the intuitions built under the previous standard. Without structured support for that translation, reporting tends to default to prior-period comparatives and high-level commentary that does not surface the underlying drivers.
How to address it: Structured movement analysis and KPI bridges are the practical tools here. A well-designed CSM roll-forward, presented consistently period over period, gives management a stable framework for understanding how new business, experience variances, and assumption changes flow through the result — making IFRS 17 output legible to people whose primary job is not technical accounting.
5. Close cycle dependency on a small number of people
In many teams, the ability to produce a complete and accurate IFRS 17 close sits with two or three individuals who were central to the implementation. That concentration of knowledge is a business continuity risk and also a practical constraint on how quickly the process can be improved.
When those individuals are occupied with production, there is limited capacity for the process improvements, documentation, and cross-training that would reduce the dependency over time. The problem is self-reinforcing.
How to address it: External technical support that runs alongside the existing team — rather than replacing it — can interrupt this cycle. The objective is to handle heavier analytical and documentation work during the close period, freeing internal resources for the judgement calls that require institutional context. Progressive automation of mechanical steps reduces the overall volume that needs to be distributed.
6. Institutional knowledge eroding as teams change
Implementation teams are rarely the same as the teams running production eighteen months later. Staff move, roles change, and the people who built the model and made the early judgement calls are no longer available to explain why certain decisions were made. New team members inherit outputs they cannot fully interrogate.
This matters because IFRS 17 models encode significant judgements — grouping boundaries, coverage unit definitions, risk adjustment methodology — that are not always visible in the numbers. When those judgements are not documented in a way that survives team transitions, the risk of misapplication increases.
How to address it: A continuous technical resource who understands the specific implementation — not IFRS 17 in the abstract, but this entity’s model, this grouping structure, these data flows — provides the institutional memory that documentation alone cannot fully replace. The goal is not permanent dependence on external support; it is ensuring that knowledge transfer happens actively rather than by accident.
These are patterns, not certainties. Some teams manage the transition from implementation to steady-state operations more smoothly than others — usually those where internal capability was built deliberately during the project, where process documentation kept pace with build, and where leadership treated go-live as the start of an operational improvement programme rather than the finish line. The challenges above are common, but they are also addressable, and most teams make real progress once the specific friction points are identified.
If your team is working through similar challenges, I would welcome the conversation. Get in touch.