The European insurance sector generated over €1.3 trillion in gross written premiums in 2024, with total assets under management exceeding €10 trillion (Insurance Europe, Key Facts 2024). Behind these volumes lies an operational reality that IT directors in insurance know well: the information systems of an insurance company or mutual insurer resemble those of no other industry.
A generic ERP handles sales, procurement, and accounting. In insurance, these functions are secondary. What truly structures the information system is policy management, claims processing, technical provisions, and the production of prudential reporting compliant with Solvency II. No standard ERP covers these needs without significant customisation.
This guide is aimed at CIOs and CFOs of life and non-life insurance companies, health mutuals, provident institutions, and wholesale brokers looking to evaluate, modernise, or replace their core management system.
Why Insurers Need a Different ERP
The Insurance Value Chain and Its Information Flows
The value chain of an insurer follows a fundamentally different cycle from that of a manufacturer or service provider. It begins with underwriting: a contract is issued, a premium is collected. Then comes the life of the contract: endorsements, cancellations, renewals, updates to coverage. Then the claim arises: declaration, investigation, assessment, settlement, and sometimes subrogation against a liable third party. Finally, technical accounting aggregates these flows to calculate provisions and produce the prudential balance sheet.
Each step generates highly specific business data: an insurance contract is not a customer order, a premium collected is not revenue in the traditional accounting sense, and a provision for outstanding claims is not an accounts payable entry. The ERP must understand these business objects natively, or interface with a specialist management system that carries them.
Most mid-sized insurers operate with a layered architecture: a Policy Administration System (PAS), a general ledger system, and a prudential reporting system. The ERP typically occupies the financial middle office and general accounting, while the PAS remains separate. The real question is therefore not “which ERP covers everything?” but “how well does the ERP integrate with the PAS and actuarial tools?”
What a Standard ERP Does Not Cover Natively
A well-implemented generic ERP (SAP, Oracle, Sage X3, Microsoft Dynamics) covers general accounting, procurement, supplier management, treasury, and fixed assets. In insurance, these functions represent only a fraction of the need.
What is systematically missing from a standard ERP:
- Management of technical provisions (unearned premium reserve, claims outstanding reserve, IBNR, mathematical reserves for life) in line with national supervisory requirements
- Processing of reinsurance flows and cedant accounts
- Production of Solvency II QRTs (Quantitative Reporting Templates) in XBRL format for submission to the national competent authority (NCA) and EIOPA
- Feeding the ORSA (Own Risk and Solvency Assessment) process
- Management of multi-year contracts with automatic premium revision
- Accounting for financial instruments under insurance rules (market value, unrealised losses)
These gaps explain why, in many organisations, the finance ERP coexists with dedicated business tools, Excel consolidation spreadsheets, and manual processing chains whose audit trail leaves much to be desired during supervisory reviews.
The Essential Modules of an Insurance ERP
Policy Management and Underwriting
The heart of the insurance information system is the contract database. Each policy must be identified with its coverages, deductibles, beneficiaries, effective and expiry dates, and pricing conditions. A robust policy management module also handles endorsements (mid-term modifications), automatic renewals with tariff revision, and portfolio segmentation by risk and line of business.
In P&C (property and casualty) insurance, policy management is transactional and high-volume. A motor insurer manages hundreds of thousands of contracts with frequent events. In life and protection insurance, contracts are fewer but more complex: mortality tables are applied, profit participation calculated, and surrender values determined each financial year.
For health mutuals and supplemental health insurers, complexity comes from reimbursement claims management. Third-party payment means the insurer settles directly with the healthcare provider; the ERP must process normalised electronic transmission flows and reconcile thousands of reimbursement lines per day.
Claims Management (Declaration, Investigation, Settlement, Subrogation)
The claims process is the most critical in terms of customer experience and financial risk. A P&C claim goes through several stages that the ERP or management system must orchestrate: declaration (telephone, web, or broker channel), case opening with initial reserve estimate, investigation (collection of supporting documents, expert assessment), settlement decision, payment, and archiving.
In liability or construction insurance, claims can remain open for several years. The reserve must be reassessed at each accounting close, and the traceability of decisions is an audit challenge. In health insurance, timescales are shorter but volumes very high: a mid-sized mutual processes tens of thousands of reimbursement claims per month.
Subrogation management (recovery against the party liable for the claim) represents a recurring financial flow that must be reconciled with the general ledger. This item is often poorly managed in generic ERPs, ending up in catch-all accounts that are difficult to reconcile.
Technical Accounting vs. General Accounting, Mathematical Reserves
The distinction between technical accounting and general accounting is fundamental in insurance, and often underestimated in ERP projects.
General accounting records actual flows: premiums collected, claims paid, management expenses, investment income. This is what any ERP handles.
Technical accounting calculates and tracks provisions: unearned premium reserve (the portion of premium corresponding to the future period of the contract), outstanding claims reserve (estimate of the final cost of reported but unsettled claims), IBNR (incurred but not reported), and in life insurance, mathematical reserves (actuarial present value of the insurer’s future commitments to policyholders).
These provisions are calculated according to rules defined by the Insurance Code and national supervisory authorities. They directly impact the prudential balance sheet and the calculation of the SCR (Solvency Capital Requirement) under Solvency II. An ERP that cannot trace the setting up and release of these provisions in an auditable manner is insufficient for this sector.
In life insurance, mathematical reserves are calculated by actuaries using mortality tables, discount rates, and contract characteristics. These calculations are performed in dedicated actuarial tools (Prophet, MOSES, ResQ) and the results are then integrated into the ERP for accounting purposes. This ERP-to-actuarial flow is a critical integration point.
Solvency II Prudential Reporting (QRTs, ORSA)
Solvency II is the European directive governing the solvency of insurance companies since 1 January 2016. Its impact on information systems is considerable. It imposes three pillars:
- Pillar 1: Quantitative capital requirements (SCR and MCR)
- Pillar 2: Risk governance and ORSA (Own Risk and Solvency Assessment)
- Pillar 3: Quantitative and qualitative reporting to supervisors and the public
Pillar 3 prudential reporting is based on QRTs (Quantitative Reporting Templates), standardised forms defined by EIOPA and submitted in XBRL format to national competent authorities. These QRTs cover the prudential balance sheet, SCR, MCR, own funds, investments, and technical provisions. As of mid-2025, EIOPA has published version 2.8.2 of the Data Point Model and XBRL taxonomy (EIOPA, DPM and XBRL).
At end-2024, the average SCR coverage ratio among European insurers remained well above 200%, though the exact figure varies by market and line of business. The SCR has increased for many groups due to higher interest rate sensitivity and claims inflation, making dynamic prudential monitoring a quarterly discipline. The ERP must therefore regularly feed this reporting process. It does not produce QRTs directly, but provides the source data: premiums, claims, provisions, investments, own funds. The quality of this data determines the reliability of prudential reporting.
Actuarial Integration: The ERP Feeds, Not Calculates
Data Flows Between the ERP and Actuarial Tools
This distinction is fundamental and rarely well understood in insurance ERP tenders: the ERP is not an actuarial tool. Complex calculations (SCR under the standard formula or internal model, Best Estimate provisions, stress test simulations) are performed in specialist software: Prophet, MOSES, or ResQ for life and protection, R or Python models for organisations that have internalised their calculations.
The ERP’s role in this flow is twofold. Upstream, it provides actuarial tools with base data: contract portfolio, policy breakdown by age band and coverage type, claims history, investment income by asset class. Downstream, it receives actuarial outputs: mathematical reserves to be recognised, SCR calculated for inclusion in the prudential balance sheet.
This two-way integration imposes stringent requirements on data quality in the ERP. A discrepancy between the contract database in the PAS and the accounting database in the ERP generates inconsistencies in actuarial calculations and therefore in Solvency II reporting. ERP projects in insurance often devote 30 to 40% of the budget to data reconciliation and quality.
XBRL Exchange Standards for EIOPA QRTs
The reporting format for national authorities and EIOPA is XBRL (eXtensible Business Reporting Language), a structured standard that enables automated data validation before transmission. EIOPA publishes and maintains the Solvency II XBRL taxonomy, updated periodically to reflect regulatory changes.
For organisations that produce their QRTs manually (via Excel or dedicated reporting tools), the ERP acts as a raw data provider. For those that have invested in an automated production chain, the ERP integrates with a prudential reporting tool (Invoke, Wolters Kluwer OneSumX, Regnology) that generates XBRL directly from ERP extracts.
Manual production via spreadsheet remains common in smaller organisations, but it is risky: no audit trail, risk of input errors, long production timescales. EIOPA and national supervisors have documented the difficulties some organisations face in producing their QRTs within regulatory deadlines, particularly for quarterly reports. An ERP well connected to the XBRL production chain reduces this risk.
Solvency II Compliance Within the ERP
Pillar 1: SCR and MCR Source Data
The SCR (Solvency Capital Requirement) is the capital required to absorb losses with 99.5% probability over one year. The MCR (Minimum Capital Requirement) is an absolute floor. Both indicators are calculated from data the ERP must supply: market value of assets, Best Estimate technical provisions, risk margin, premium and claims volume by line of business.
The ERP must therefore store and expose accounting data at the granularity level expected by the Solvency II standard formula. This requires a line-of-business nomenclature compliant with Annex I of Delegated Regulation 2015/35, and the ability to allocate premiums and claims by this nomenclature.
Pillar 2: Decision Traceability and Data Governance
Pillar 2 addresses internal governance. The ORSA (Own Risk and Solvency Assessment) is the self-assessment each organisation must carry out at least annually: it documents the risk profile, tests solvency under various stress scenarios, and concludes on the adequacy of capital to the risks assumed.
The ERP contributes to the ORSA by providing reliable historical data: provision trends, technical results by line of business, investment performance. Traceability is a key challenge. Supervisors expect to be able to reconstruct the path from source data in operational systems to the figures published in the QRTs. An ERP with robust audit trail, role-based access control, and change archiving meets this requirement.
Pillar 3: Automated XBRL Reporting to Supervisors
Pillar 3 imposes strict deadlines: quarterly reports (Solo and Group QRTs) and annual reports (SFCR for the public, RSR for the supervisor, ORSA Report). These reports comprise dozens of QRT tables each. Organisations that process this reporting manually face heavy workloads at each quarter-end.
Automating Pillar 3 requires a clear chain: ERP (accounting and technical data) + actuarial tool (provisions and SCR) + reporting tool (consolidation, XBRL generation, validation, NCA submission). The ERP is the first link in this chain. An ERP with unreliable or poorly allocated data blocks the entire downstream chain.
IFRS 17: Impact on the Chart of Accounts in the ERP
IFRS 17 is the international standard on insurance contracts, effective from 1 January 2023 for listed groups applying IFRS. Its impact on the chart of accounts is profound: it replaces IFRS 4 and introduces a new measurement model for insurance contracts, based on the present value of future cash flows and a Contractual Service Margin (CSM).
For the ERP, IFRS 17 requires storing and processing new accounting objects: contract groups (with their profitability level), expected cash flows, the current discount rate versus the original discount rate. Affected organisations have had to adapt their charts of accounts and create new interfaces between actuarial systems (which calculate IFRS 17 flows) and the accounting ERP.
Subsidiaries of internationally listed groups are directly subject to IFRS 17, and this constraint has driven several ERP overhaul projects since 2023.
ERP Solutions and Specialist Platforms in 2026
SAP FS-CD / FS-RI for Large Groups
SAP offers several insurance-dedicated modules within its S/4HANA ecosystem. FS-CD (Financial Services Collections & Disbursements) manages the insurer’s cash inflows and outflows: premiums, claims, broker commissions. FS-RI (Reinsurance Management) covers reinsurance treaty management: cession, accounting for cedant accounts, claims recoveries.
These modules have been adopted by groups such as AXA, HDI Global, and Gen Re (AppsRunTheWorld, SAP S/4HANA FS-RI customers). SAP remains the reference solution for large insurance groups with high volumes and international IFRS 17 reporting requirements. The investment and project duration are commensurate: a minimum of 18 to 36 months for a full deployment in a large group.
Oracle Financial Services Insurance
Oracle offers a suite dedicated to financial services with insurance modules covering policy management, technical accounting, and regulatory reporting. Oracle’s cloud environment facilitates automatic regulatory updates, an advantage in a sector where Solvency II and IFRS 17 evolve regularly.
Positioning is similar to SAP: large international groups. Oracle’s competitive advantage lies in its analytical capabilities and data warehouse tools, useful for portfolio analysis and group reporting.
Guidewire: The P&C Specialist Interfaced with the ERP
Guidewire is not strictly an ERP, but a platform specialised in P&C policy and claims management. PolicyCenter manages underwriting, BillingCenter manages invoicing and collections, ClaimCenter manages claims. Guidewire is widely adopted by P&C companies worldwide.
The integration with the ERP is a major design point in a Guidewire project: financial flows (premiums, claims) flow from Guidewire to the accounting ERP. This integration must be reliable, traceable, and reconcilable. Projects that overlook it end up with chronic accounting discrepancies between the management system and the general ledger.
Microsoft Dynamics 365 Finance with Insurance ISVs
Microsoft Dynamics 365 Finance covers general accounting and treasury. For insurance-specific functionality, ISV (Independent Software Vendors) editors offer add-on modules: Majesco and Duck Creek are active internationally. This combination appeals to mid-sized mutuals and insurers who want to avoid SAP complexity while benefiting from a modern ERP. Majesco in particular has expanded its European footprint and offers native Solvency II reporting connectors.
Specialist Insurance Platforms
For mid-sized organisations (health mutuals, provident institutions, regional insurers), specialist platforms offer a better functionality-to-cost ratio than full-blown ERP deployments.
Dedicated insurance platforms such as EbaoTech, Majesco, and Fadata INSIS cover policy administration, claims management, and regulatory reporting with pre-built Solvency II adapters. Their competitive advantage: deep sector knowledge and pre-configured regulatory content that accelerates time-to-compliance. These are particularly relevant for insurers who want to avoid the 24-month implementation timelines of Tier-1 ERPs.
For health mutuals operating national health insurance data exchange interfaces (equivalent to the French NOEMIE system or similar EDI standards in other EU markets), ensure the chosen platform holds active certification for the relevant national exchange standard and maintains it with each annual update.
Case Study: ERP Migration in a Mid-Sized Mutual Insurer
A supplemental health mutual managing 200,000 members, 400 employees, and €150 million in annual premium income is a typical profile for an ERP migration project.
Common starting point: an ageing contract management system (often a tool from the early 2000s), a generic accounting ERP, and a Solvency II reporting chain relying on Excel extracts. Reconciliation between management data and accounting is performed manually each month, with significant error risk and staff overhead.
Project scope: migration for an organisation of this size typically covers two components — replacement of the policy and claims management system (PAS/TPA), and upgrading the accounting ERP to integrate technical accounting and automate prudential reporting.
Duration and budget: for a structure of this size, a complete project takes 18 to 30 months. The budget range varies according to technology choices: from €800,000 (specialist European platform + mid-market ERP, limited scope) to €2.5 million (international solution with full IT overhaul). These ranges are indicative and depend heavily on the volume of historical data migration and the degree of automation targeted for prudential reporting.
Key risks: the migration of contract data (claims history, outstanding provisions) typically represents 20 to 30% of total effort. Training of actuarial and accounting teams on the new system is frequently underestimated. And obtaining auditor sign-off on the first close with the new system requires rigorous documentation of data flows.
Checklist: 12 Criteria for Choosing Your Insurance ERP
Before launching a tender, CIOs and CFOs should validate the following points with each candidate:
- Policy management: does the system natively support insurance business objects (policy, endorsement, premium, coverage) or must they be modelled in generic structures?
- Technical accounting: are technical provisions (unearned premium, outstanding claims, IBNR, mathematical reserves) managed natively with their accounting traceability?
- Actuarial interface: is there a documented and maintained interface with market actuarial tools (Prophet, R, Python) for provision and SCR data exchange?
- QRT production: does the system generate Solvency II QRTs or integrate with a certified XBRL prudential reporting solution?
- Audit trail: is every modification to sensitive data (provision, premium, claim) automatically logged with identity, timestamp, and before/after values?
- Access rights: is role-based access control sufficiently granular to meet Pillar 2 governance requirements?
- IFRS 17: if applicable, does the chart of accounts support contract groups and the CSM measurement required by IFRS 17?
- Reinsurance: are cession and retrocession flows managed natively, or do they require a third-party module?
- Health data exchange: for health mutuals, is the national health insurance data exchange interface certified and kept up to date with annual regulatory updates?
- Regulatory agility: does the vendor have a dedicated team for insurance regulatory updates (Solvency II review, IFRS 17 amendments) and what is their track record?
- Sector references: does the vendor or its integrator have verifiable references in organisations of comparable size and type (health mutual, provident institution, P&C company)?
- Total cost over 5 years: beyond licence and integration costs, what are the annual maintenance, regulatory update, and technical support costs for this type of organisation?
Insurance and mutual insurer information systems are at an inflection point. Solvency II reporting obligations are growing more complex, IFRS 17 has imposed deep adaptations on listed groups, and the pressure on data quality increases with every supervisory review. Choosing an ERP in this context is not an ordinary IT project: it is a project that commits the reliability of the prudential balance sheet and long-term regulatory compliance.
To go further, read our guide to ERP for regulated industries on traceability and compliance constraints, our article on ERP and GDPR for data governance requirements, and our comparison of cloud vs. on-premise ERP for the architecture choice best suited to insurance data residency constraints.
