How to choose Solvency II software: reporting, calculation and what to check before a demo

Solvency II software is sold under one name for two different jobs: producing the regulatory reports and calculating the numbers that go in them. Selection projects go wrong when the two are treated as one purchase, or when vendors are compared on feature lists instead of on a real quarter. This article separates the jobs, gives a requirements checklist to score vendors against, lists twelve questions to send before a demo and describes how to test a tool on your own data before you sign. It applies under Solvency II, under Solvency UK for firms reporting to the PRA, and under IORP II for pension funds. We build reporting and calculation tools ourselves, so where a requirement comes from how our own products work, we say so. The checklist itself is vendor neutral.

The two jobs: reporting and calculation

Reporting software turns data an insurer already holds into a supervisory submission, in five steps. Data integration pulls balances, asset lists and claims figures out of the ledger, the asset manager’s files and the actuarial systems. Template population puts those figures into the templates defined by Implementing Regulation (EU) 2023/894, from the S.02 balance sheet to the S.25 capital requirement; our complete list of Solvency II QRTs has the full set. Validation runs the supervisor’s rules across the filled templates. XBRL generation encodes them as an instance file against the current taxonomy. Filing sends that file to the supervisor’s portal, or to BEEDS for the Bank of England.

Calculation software produces the figures the templates report. Under Directive 2009/138/EC and Delegated Regulation (EU) 2015/35 that means the Solvency Capital Requirement by module, the Minimum Capital Requirement, the best estimate and risk margin of the technical provisions and, for insurers with ring-fenced funds, a separate SCR per fund plus the adjustment for lost diversification. ORSA projections reuse the same engine.

The jobs are often bought separately because different teams own them. The actuarial function picks the calculation engine that fits its models; the reporting function picks the filing tool that fits the close calendar. The purchases happen years apart, and the join between them ends up as a spreadsheet that copies the SCR into S.25.01. That join is where errors hide, so whatever you buy, ask to see it working.

Requirements checklist

Score each row from 0 (not available) to 3 (shown working on your own data).

Taxonomy updates: who ships what and when

A tool is only as current as the taxonomy it validates against. EIOPA publishes the Solvency II XBRL taxonomy. Version 2.8.2 covers reference dates from Q4 2024 up to and including the annual 2026 submission. Version 2.10.0 was published on 3 July 2026 and applies from the Q1 2027 reference date with the amended templates that follow Directive (EU) 2025/2. EIOPA publishes the Pension Funds taxonomy for IORP reporting separately; version 2.9.0 has applied since the 1 January 2025 reference date.

The Bank of England publishes its own Insurance Taxonomy for Solvency UK. Version 2.0.2 was published on 2 October 2025 for reference dates from 31 December 2025. Version 2.1.0 followed on 16 December 2025 with the liquidity entry points the largest firms file from the 30 September 2026 reference date. Version 2.2.0 was published on 2 September 2026 and implements PS18/26 for every return with a reference date on or after 31 December 2026. Our article on Bank of England Insurance Taxonomy 2.1.0 and PS18/26 has the detail.

So a UK group with EU subsidiaries closes the 2026 year end on BoE 2.2.0 and EIOPA 2.8.2, then opens Q1 2027 on EIOPA 2.10.0. Ask every vendor when they shipped each release and whether two can be open at once. A vendor who ships a taxonomy after its filing window opens has left the work to you.

Multi-entity and multi-regulator

Groups and consultants rarely file for one entity. Ask whether every legal entity sits under one login, whether an entity’s data can be kept separate on request, and whether one asset feed can serve an EU entity on the EIOPA taxonomy and a UK entity on the Bank of England taxonomy. The regimes are compared in our article on Solvency UK and Solvency II; for the software, the point is that the PRA publishes its own risk-free interest rate term structures and symmetric adjustment, so a calculation tool has to accept either set.

Security and hosting: the factual questions

Where is the data stored, in which region, and does that satisfy your policy and your supervisor? Who at the vendor can access customer data, and is that access logged? How often are backups taken and how long does a restore take? Can access be limited per entity and per template? Is the product hosted by the vendor or installed on your infrastructure, and who applies updates? Get the answers in writing and keep them with the contract. Marketing pages answer with adjectives; the demo is where you get facts.

Support

Deadlines do not move for a support ticket. Ask who answers during the five weeks after quarter end and what the response time is then, whether the vendor helps with the first integration of your source systems or hands you a manual, and who explains a validation rule that nobody on your side understands.

Twelve questions to ask before a demo

Send these in advance so the demo is prepared against your case, not the standard script.

1. Which of the two jobs does the product cover, and where does the other job’s output enter it?
2. On what date did you ship EIOPA taxonomy 2.10.0, and when will you ship Bank of England taxonomy 2.2.0?
3. Can an annual package on the previous taxonomy and a quarterly package on the new one be open at the same time?
4. Can you connect to our database, Excel and CSV sources in the demo, and does the mapping survive to next quarter?
5. Which validation rules do you run beyond EIOPA’s, and for which national supervisors?
6. Show me a locked template being reviewed and released by a second user, and the audit trail entry that produces.
7. Can we trace one reported cell back to its source file and row?
8. How does the SCR result reach S.25.01, and the technical provisions S.17.01, without a spreadsheet?
9. How are ring-fenced funds handled: separate runs, a combined run, or not at all?
10. Can one login serve all our legal entities, and can an entity’s data be kept separate on request?
11. Where is our data stored, who at your company can access it, and what is the backup and restore procedure?
12. Can we run one full quarter in parallel on our own data before signing, and who supports us during it?

Evaluation method: one real quarter in parallel

Demos show what a tool does on the vendor’s sample data. The only test that predicts your close is your own data over a full cycle: pick a quarter that has already been filed and run it again in the candidate tool.

Measure two things. Validation errors: the count when the templates are first filled, after the tool’s own corrections and after your manual fixes, compared with the original filing. Hours: from source files received to XBRL instance produced, split between mapping done once and close work that repeats every quarter. Where calculation is in scope, reconcile the tool’s SCR and technical provisions to the filed figures and list every difference with its cause.

Give each vendor the same quarter and files, score the checklist on what you saw rather than what you were told, and weight the taxonomy and governance rows by how much the last close hurt. The winner is the tool that gets your quarter through with fewer manual fixes.

How vendors differ

Vendors differ along two lines. Some sell an integrated suite where reporting and calculation share one data model; others sell modular tools that exchange results through files or an interface. A suite reduces the number of joins; modular tools let an actuarial team keep an engine it trusts while the reporting team changes the filing tool. The second line is hosting: products hosted by the vendor and reached through a browser, or installed on the insurer’s own infrastructure. Hosted products put taxonomy updates in the vendor’s hands; installed products put them in yours. Neither suits everyone, so the checklist scores rows, not categories.

Where this lands in the software

SolvencyTool sells the two jobs as separate products that share data. For reporting, QRT Tool pulls data from databases, Excel and CSV files, keeps the transformations for reuse every quarter, validates against EIOPA’s rules and national additions with automatic resolvers, and has a planning tool with deadlines per template, locking and review by a second person. BOE Tool does the same for Bank of England reporting, IORP Tool for pension funds and IRRD Tool for recovery and resolution reporting. For calculation, SCR Tool shows every formula and presents results in QRT format, with the risk-free term structures and symmetric adjustment embedded and the PRA variants available for UK entities. TP Tool builds triangles from claim and premium transactions and populates the technical provision templates, and RFF Tool runs the SCR across ring-fenced funds and the remaining part in one go. All come with a free test and transition period.