For non-life insurers and reserving actuaries in the GCC evaluating IFRS 17 software before a 2026 buying decision, this guide names the vendor warning signs that surface after the contract is signed.
TL;DR
Picking IFRS17 software for a non-life book fails most often on things a demo hides. This guide names the red flags that show up after go-live: thin audit trails, PAA eligibility that isn’t tested every period, claims data that won’t reconcile, and scenario testing bolted on as an afterthought. You’ll learn what to check against non life reserving vendor criteria, why audit ready reserving platforms matter for SAMA and CBUAE, and how to run a proof-of-concept that exposes weak IFRS17 solutions. Read it before you shortlist.
Why IFRS17 Software Choices Break After the Demo
Most non-life insurers don’t discover their vendor problem during evaluation. They discover it in the second reporting cycle, when the auditor asks how a number was calculated and nobody can show the trail.
The global IFRS 17 insurance software market reached USD 1.41 billion in 2024, and the shortlists keep growing. More vendors, more decks, more claims of “full compliance.” Fewer platforms that actually hold up under a P&C audit.
Here’s the part that catches teams off guard. A tool built for a global life insurer with long-duration contracts can be the wrong tool for a mid-sized motor and property book. You might think more features means safer. Often it means more surface area to misconfigure.
Non-life reserving under IFRS 17 leans heavily on the premium allocation approach. The EIOPA study of first-year adopters found non-life contracts were mostly valued using PAA, around 90% of them. So your software has to do PAA properly, not treat it as a simplified checkbox.
What this article covers:
- The audit trail gaps that fail P&C reviews
- How to test non life reserving vendor criteria before signing
- Why scenario testing and claims data integration expose weak vendors
Our advisory team has sat on both sides of these evaluations, running proofs-of-concept for insurers across Saudi Arabia and the UAE. The patterns repeat.
What Are the Biggest IFRS17 Software Red Flags for Non-Life?
The biggest red flags in IFRS17 software for non-life reserving are missing audit trails, PAA eligibility that isn’t re-tested each period, claims data that can’t reconcile to the ledger, and scenario testing added as a manual step. Each one passes a demo. Each one fails an audit.
Let’s break them down, because the order matters.
Red Flag One: The Audit Trail Stops at the Output
Ask a vendor to show you the audit trail. Watch what they point to.
Weak platforms show you the final journal entry and call it traceability. That’s not an audit trail. That’s a result.
A real audit ready reserving platform lets you walk backward from any figure in the disclosure to the raw claims record that fed it. Every assumption change, every user, every timestamp. When the external auditor picks a liability for incurred claims number and asks “where did this come from,” you should be able to reconstruct it in minutes, not days.
The Actuaries Institute post-implementation survey found that fewer than three in every twenty-two insurers had a fully automated solution. Nearly half still relied on heavy manual intervention across inputs, disclosures, and bespoke calculations. Manual steps are where audit trails go to die.
So when a vendor’s “audit trail” needs a spreadsheet export to make sense, that’s your signal.

Red Flag Two: PAA Eligibility Isn’t Tested Every Period
PAA is not permanent. A contract group that qualifies for the premium allocation approach this year can fail the eligibility test next year if coverage duration or measurement expectations shift.
Plenty of IFRS17 solutions run the PAA eligibility test once, at setup, and never again. That’s a compliance gap waiting to be found. KPMG flagged periodic assessment of PAA eligibility as one of the common challenges for Saudi insurers preparing SAMA submissions.
Ask the vendor directly: does the platform re-run PAA eligibility automatically each reporting period, and does it log the result?
If the answer involves a consultant or a manual review, you’ve found a red flag.
Red Flag Three: Claims Data Integration That Only Works in the Demo
Claims data integration is where most non-life implementations stall. The demo uses clean sample data. Your production data is messy, split across a policy admin system, a claims system, and an actuarial model that speak different formats.
A vendor whose platform couldn’t handle real policy volumes, lacked proper audit trails, or needed months of IT effort to connect to the ERP is a common story. Insurers found this out after signing, not before.
Test it with your own data extract during the proof-of-concept. Not their sample set. Yours.
If they resist, ask why.
How Do You Test Non-Life Reserving Vendors Before Signing?
You test a non-life reserving vendor by running a proof-of-concept on your own claims data, forcing a PAA eligibility re-test, tracing one number end-to-end through the audit trail, and running a scenario test the vendor didn’t pre-configure. If any step needs manual help, note it.
Quick self-check before you even shortlist. Score your current evaluation on these:
- Can you trace one disclosed figure back to a raw claims record without a spreadsheet?
- Does the platform re-run PAA eligibility each period on its own?
- Did the vendor demo on your data or theirs?
- Can you run an ad-hoc scenario without calling support?
Three or more “no” answers means you’re being sold a demo, not a platform.
The teams that get this right narrow 15 to 20 vendors down to three to five real candidates before deep evaluation. A tight shortlist saves months. Our own shortlist questions for IFRS 17 walk through the specific questions that expose weak solutions during an RFP.
Scenario Testing Separates Real Platforms From Slideware
Scenario testing is where enterprise claims meet reality. Non-life reserving needs stress runs: what happens to the liability for incurred claims if inflation on bodily injury claims runs hotter than assumed? What if a catastrophe reshapes the tail?
Weak vendors pre-load one or two scenarios for the demo and freeze there. You can’t build your own without a support ticket.
That’s the tell. A platform built for non-life reserving lets your actuaries define, run, and audit their own scenarios. On their own. In minutes.
And it logs every run, because scenario history is part of the audit trail too.

IFRS Tech
Want to see how Delta IFRS 17 handles PAA eligibility and your own claims data? Book a free product demo.
No obligation · Live walkthrough · GCC, Europe & APAC
Which Audit-Ready Reserving Platforms Fit GCC Non-Life Insurers?
GCC non-life insurers need reserving platforms that handle PAA at scale, log every assumption for SAMA and CBUAE review, reconcile claims data to the ledger, and support Arabic-language and multi-entity reporting. The fit question matters more than the feature count.
Regulators in the region have been specific. KPMG’s insurance pulse noted Saudi insurers wrestling with LIC surplus classification, VAT treatment on premium receivables under PAA, and expense allocation, all under SAMA dry-run scrutiny. Software that ignores these local realities looks fine in a European demo and fails in Riyadh.
This is where portfolio fit beats brand name. A short-tail motor and property writer applying PAA doesn’t need the stochastic modeling depth a life insurer pays for. Paying for VFA machinery you’ll never run is its own kind of waste.
For a deeper look at how measurement models map to product mix, our breakdown of IFRS 17 actuarial tools in insurance compares end-to-end platforms, best-of-breed tools, and in-house builds.
One honest limit here. I don’t have clean long-term cost data across every GCC deployment yet, because the standard is still young and few insurers publish their total cost of ownership. What I can say is that the platforms reconciling claims data cleanly in year one are the ones auditors stopped flagging in year two.
That pattern held across the non-life implementations our team supported through 2025.
Who we are
Purpose-built IFRS software. 50+ years of combined expertise behind it.
IFRS Tech is the technology division of Prima Consulting, delivering Delta IFRS 17, Rust IFRS 9, IAS 19, and ROU 360 IFRS 16 software to banks, insurers, and corporates across the GCC, Europe, and Asia-Pacific.
The Build-vs-Buy Trap for Reserving Teams
Some insurers still ask whether an in-house IFRS 17 reserving build makes sense. For most non-life teams, it rarely does.
The hidden cost isn’t the initial build. It’s the regulatory update dependency. Every time the IASB or SAMA shifts a requirement, your internal developers own the fix, and there’s no external validation of the calculation logic. Total cost of ownership tends to overtake vendor solutions within about three years.
That said, a thin vendor with no audit trail can be worse than a disciplined internal build. The point isn’t buy-at-all-costs. It’s that you need auditable reserving logic someone else validates.
If you’re weighing the two, our note on IFRS 17 non-life solutions covers contract grouping risks and the GMM-versus-PAA decision that shapes the whole build-or-buy call.
What Questions Expose a Weak IFRS17 Vendor Fastest?
The fastest questions to expose a weak IFRS17 vendor are: show me PAA eligibility re-running automatically; trace this disclosed number to source; run a scenario I define right now; and reconcile this claims extract to the ledger live. Vague answers to specific questions are the clearest red flag of all.
Notice the pattern. Every question forces a live demonstration, not a slide. Vendors who claim “full support” for every standard but go vague on specifics, like how they handle liability adequacy or PAA reassessment triggers, are telling you something.
Ask about SAMA and CBUAE reporting formats by name, who owns the regulatory update after go-live, what the audit trail looks like for a scenario run, not just a journal entry.
Then watch whether they show you, or tell you.
What would it cost your team to find the answer to these questions eighteen months in, mid-audit, instead of now?
What you now know:
- Audit trails must trace every disclosed figure back to raw claims, or they aren’t audit trails
- PAA eligibility, claims data integration, and self-service scenario testing are the three checks that expose weak non-life vendors
- Fit to your portfolio and your regulator beats raw feature count every time
Choosing IFRS17 Software You Won’t Regret
The non-life insurers who avoid regret aren’t the ones who bought the biggest platform. They’re the ones who tested IFRS17 software against their own claims data, forced a PAA eligibility re-test, and traced a real number end-to-end before signing anything.
Red flags don’t hide in feature lists. They hide in what happens after the demo ends, when the auditor arrives and the manual workarounds show. Fewer than three in twenty-two insurers reached full automation. Don’t join the manual half by picking on slideware alone.
Bring your data. Force the live tests. Ask who owns the regulatory update. That’s the whole game.
If you want a second set of eyes on your shortlist, IFRS TECH’s advisory team assesses whether Delta IFRS 17 fits your insurance lines, data volumes, and non-life reserving needs, on your data, in a free walkthrough.
Free Product Demo
See Delta IFRS 17 handle your non-life reserving, on your data.
IFRS Tech’s advisors walk you through PAA eligibility, audit trails, and claims reconciliation live. First demo is always free, no pitch, just the product.
Frequently Asked Questions
What is the most common IFRS17 software red flag for non-life insurers?
The most common red flag is an audit trail that stops at the output. Weak IFRS17 solutions show the final journal entry but can’t trace it back to raw claims data. Real audit ready reserving platforms let you reconstruct any disclosed number from source, with every assumption and timestamp logged.
How often should IFRS17 software re-test PAA eligibility?
PAA eligibility should be re-tested every reporting period, automatically. A contract group qualifying this year can fail next year if coverage duration shifts. Many IFRS17 solutions test only at setup, which creates a compliance gap. Regulators like SAMA flag periodic PAA assessment as a known challenge area.
Why does claims data integration matter in non-life reserving vendor criteria?
Claims data integration matters because production data is messy and split across policy, claims, and actuarial systems. Vendors that demo on clean sample data often need months of IT work to connect real feeds. Test any platform on your own claims extract before signing, not the vendor’s sample set.
Do GCC insurers need different IFRS17 solutions than European ones?
GCC non-life insurers need platforms that support SAMA and CBUAE reporting formats, handle LIC and VAT treatment under PAA, and often require Arabic-language and multi-entity reporting. Software that performs well in a European demo can fail local regulatory review, so fit to your regulator matters as much as features.
Is building an in-house non-life reserving system cheaper than buying?
Building in-house rarely stays cheaper for non-life teams. The hidden cost is regulatory update dependency: your developers own every IASB or SAMA change, with no external validation of calculation logic. Total cost of ownership usually overtakes audit ready reserving platforms within about three years.
Author
-
Ibrahim Ahmed Zahidie, FCA, is a Fellow Chartered Accountant with 18+ years of experience in IFRS financial reporting, banking transformation, regulatory compliance, and financial strategy. Having held leadership roles at KPMG, A&H Actuaries, and UBL, he specializes in IFRS implementation, financial planning and analysis (FP&A), risk management, ERP implementation, and digital finance transformation. He has successfully led IFRS compliance projects in Saudi Arabia and Pakistan and advises organizations on strengthening financial reporting, regulatory compliance, and finance modernization.





