When the 2027 taxonomy and calibration changes land, will your current platform absorb them, or trigger a new statement of work?
- What Solvency II software does: automates the reporting across all three pillars, from capital calculations (Pillar 1) through the governance and risk inputs behind Pillar 2 to the XBRL filings supervisors require (Pillar 3).
- The common gap: many tools only handle the final Pillar 3 filing, or run as black boxes, so the firm cannot show how a reported figure was calculated.
- The taxonomy timeline: EIOPA Taxonomy 2.8.2 applies for the 31 December 2026 reporting date. The first reporting period under the new 2.10.0 taxonomy begins in Q1 2027.
- The 2027 rule change: Directive (EU) 2025/2 applies from 30 January 2027 and recalibrates key figures, including the risk margin and a lighter regime for smaller, less complex insurers.
- The cleversoft solution: all three pillars on one platform, with open calculation models, EU-hosted infrastructure, and regulatory updates included in the running fee.
Your reporting team is staring at two parallel workstreams: closing the 2026 year-end under EIOPA Taxonomy 2.8.2, while preparing for Taxonomy 2.10.0 from Q1 2027 and the calibration changes under Directive (EU) 2025/2 from 30 January 2027. The operational question lands on procurement: does your current platform absorb both the format migration and the recalibrated SCR (Solvency Capital Requirement) logic inside the running contract, or does each change trigger a new statement of work? cleversoft delivers Solvency II compliance for insurers and pension funds across Pillars 1, 2 and 3 on one platform, with regulatory updates included through the Compliance Commitment.
The Limits of Generic XBRL Tools in Solvency II Reporting
Pillar 3-only filing tools sit at the end of the reporting chain. The actuarial engine, the SCR calculation and the narrative drafting all happen upstream, often in separate systems. The filing tool inherits whatever those systems hand over, without a connected record of how each figure was built.
Picture a typical audit scenario. A supervisor questions a specific capital charge in the S.25.01 QRT (Quantitative Reporting Template), the template that reports the SCR under the standard formula. To answer, the team has to stitch together spreadsheets, model logs and email approvals from across different teams to produce four things:
- the input data behind the figure
- the calculation step that was applied
- the model version that produced it
- the person who approved it
By the time the actuarial team reruns the model, the result has often shifted, and the original audit trail can no longer be reconstructed inside the supervisor’s response window.
Black-box enterprise platforms cause the opposite problem: the calculations run and the numbers appear, but the underlying formula logic cannot be inspected. So when a regulator asks why a figure came out the way it did, the insurer carries the audit risk, not the software vendor.
A connected Solvency II reporting platform is what closes both gaps.

How to Evaluate Solvency II Software for Your Firm
Choosing regulatory reporting software for Solvency II is harder than the demos suggest. Once the vendor demos are over, the feature lists tend to look almost identical: SCR calculation, QRT generation, XBRL export, EIOPA validations. The real differences sit underneath, and they only surface under audit pressure or during a taxonomy change. What matters is whether the platform fits your firm’s size, your jurisdictional footprint and your SCR method, rather than how long its capability list runs. The following three criteria separate the platforms that hold up under audit from those that file the numbers and stop there.
Pillar 1 to 3 Scope and SCR Method Fit
Most insurers with a stable risk profile can file under the standard formula for their SCR (Solvency Capital Requirement) and MCR (Minimum Capital Requirement) calculations, with open calculation models that stay inspectable from end to end. Larger or more complex undertakings need an internal model path instead, particularly those with material non-life catastrophe exposure or bespoke asset structures. For them, the platform has to accept SCR inputs from the firm’s own actuarial engine and reconcile them against the economic balance sheet, all without breaking the audit trail.
For cross-border insurers, the scope widens to group SCR and consolidated SFCR (Solvency and Financial Condition Report). Intercompany elimination, currency translation and sub-group reporting all need to sit inside the same platform that produces the solo QRTs, so that figures filed at group level reconcile to the entity-level submissions without any manual bridging.
Jurisdictional Coverage: National Specific Templates and Solvency UK
EIOPA QRTs are the baseline, not the full filing obligation. National supervisors layer their own templates and validations on top, and a credible platform has to absorb them inside the same workflow that produces the EU submissions.
- National Specific Templates (NSTs) issued by national supervisors alongside EIOPA QRTs
- PRA (Prudential Regulation Authority) validations and UK reporting requirements for firms supervised by the Bank of England
- Group-level templates for cross-border insurance and reinsurance undertakings
For any firm with UK exposure, dual-regime support across EU Solvency II and Solvency UK is operationally non-negotiable. Since Brexit, the EIOPA and PRA taxonomies have evolved on separate timelines, so running two disconnected tools means manually reconciling diverging validation rules, filing windows and template revisions every single cycle.
Audit Trail Depth and Calculation Transparency
A usable audit trail has to show five things for every figure that lands in a QRT:
- the input source
- the calculation step applied
- the user action taken
- the timestamp
- the change against the previous revision
Without that chain, a reporting team cannot reconstruct why a specific S.25.01 capital charge moved between two filing cycles, and the regulator’s question goes unanswered.
Open calculation models close that gap, because every formula behind the SCR, MCR and risk margin stays inspectable, which keeps the derivation logic defensible from end to end.
Black-box engines create the reverse situation: the regulator receives the number, while neither the vendor nor the insurer can show why it was assigned that value. This matters more each year, because supervisors increasingly ask why a specific risk score or capital charge came out as it did, rather than simply whether a process was followed. The Solvency II reporting and disclosure consultation highlights exactly this shift in supervisory expectations.
Is Your Software Ready for EIOPA Taxonomy 2.10.0 — and What Changes Between 2026 and 2027?
The reporting timeline splits cleanly in two. For the 31 December 2026 reference date, EIOPA Taxonomy 2.8.2 (or the 2.8.2 NACE 2.1 Optional Hotfix) applies, with no new taxonomy requirements for the 2026 year-end cycle. The first reporting period under Taxonomy 2.10.0 is expected to begin in Q1 2027, per the EIOPA Taxonomy Roadmap update of 5 January 2026.
The scale of the 2.10.0 change is substantial. According to EIOPA’s October 2025 consultation, the taxonomy removes 12 templates, adds 5 new ones, and revises labels and metrics, including catastrophe data and ECB reporting on premiums and claims.
Running in parallel: Directive (EU) 2025/2 applies at the latest from 30 January 2027. It recalibrates the numbers rather than the file format. The revised risk margin, the new SNCU regime and adjusted long-term guarantee measures change the figures feeding the QRTs, while 2.10.0 changes the templates those numbers land in.
| Milestone | Date | Impact |
|---|---|---|
| Taxonomy 2.8.2 applies | Through 31 December 2026 | No new taxonomy requirements for 2026 year-end |
| Taxonomy 2.10.0 first reporting period | Q1 2027 | 12 templates removed, 5 added, labels and metrics revised |
| Directive (EU) 2025/2 applies | 30 January 2027 | Revised risk margin, SNCU regime, recalibrated LTG (long-term guarantee) measures |
The procurement question is direct: will your vendor absorb both the taxonomy migration and the calibration changes within the existing contract, or does each trigger a chargeable change request, or worse, a forced re-tender?
Is your 2027 reporting covered by your current contract?
The shift from Taxonomy 2.8.2 to 2.10.0 and the calibration changes under Directive (EU) 2025/2 land in the same reporting cycle. Before that gap surfaces under audit pressure, it’s worth checking whether your existing vendor absorbs both within the running fee, or whether each will trigger a chargeable change request. A focused conversation with cleversoft’s Solvency II specialists clarifies where your current setup stands against the 2027 requirements.
cleversoft: The Solvency II Solution for Pillars 1, 2 and 3
cleversoft sits between the Pillar 3-only filing tools and the oversized enterprise platforms. It is a three-pillar service built for insurers and pension funds that need defensible reporting without having to re-tender at every regulatory cycle. The platform already supports EIOPA Taxonomy 2.8.2, including the NACE 2.1 Optional Hotfix, for the 2026 reporting cycle. Its roadmap is aligned with EIOPA to deliver full 2.10.0 support ahead of the Q1 2027 obligations, so that XBRL taxonomy updates are absorbed within the running fee under the Compliance Commitment.

The service covers all three Solvency II pillars on one platform:
- Pillar 1: SCR and MCR standard formula calculations
- Pillar 2: Shocks & Scenarios reporting
- Pillar 3: QRT reporting plus SFCR and RSR narrative disclosure, filed through XBRL reporting, with NST support and both EIOPA and PRA validations
A set of operational guarantees backs the reporting workflow:
- Fact Navigation: full data traceability from input through calculation to the QRT report
- Four-eyes principle: the QRT books are approved under dual control, after which the XBRL file is generated automatically for filing
- Open calculation models: the logic behind SCR, MCR and risk margin stays inspectable, with no black boxes
- EU-hosted cloud infrastructure with a 99.98% availability rate

Map your Solvency II setup against the 2027 requirements
Before the dual deadline of Taxonomy 2.10.0 in Q1 2027 and Directive (EU) 2025/2 on 30 January 2027 lands on your reporting team, it pays to know exactly where your current platform stands. A focused conversation with cleversoft’s Solvency II specialists works through your Pillar 1 to 3 scope, the taxonomy migration path and the calibration changes, and pinpoints any gaps before they surface under audit pressure.
Conclusion: Choosing a Solvency II Solution That Carries You Through 2027
The 2027 transition is binary: either the vendor absorbs it, or the reporting team carries the manual workload. Taxonomy 2.8.2 closes the 2026 year-end, Taxonomy 2.10.0 opens Q1 2027 with 12 templates removed and 5 added, and Directive (EU) 2025/2 applies from 30 January 2027 with revised risk margin and the new SNCU regime. Vendor selection comes down to four criteria: genuine Pillar 1 to 3 coverage on one platform, a defensible audit trail with traceable calculation logic, dual-regime support where UK exposure exists, and a contract that delivers regulatory updates without re-tendering.
cleversoft is built for exactly that brief: three pillars on one platform, open calculation models with no black-box logic, EU-hosted infrastructure, and a Compliance Commitment that absorbs the 2027 taxonomy and calibration changes within the running fee. The practical next step is a focused conversation about your current reporting setup and where the gaps sit ahead of 2027.
FAQ
What does Solvency II reporting software actually do?
It collects an insurer’s figures from source systems, applies the required Solvency II calculations and validations, and produces the filing in the XBRL format the supervisor accepts. Scope varies: some tools cover only Pillar 3 filing, while others span Pillars 1 to 3, including SCR/MCR calculation, SFCR/RSR narrative reporting and QRT submission.
What does a Solvency II audit trail need to capture?
A defensible audit trail must capture the input source, calculation step, user action, timestamp and the change against the previous revision for every reported figure. cleversoft logs every action at user level, applies the four-eyes principle to the approval of the QRT books, and uses Fact Navigation to trace data from input through calculation to the QRT report. Once the books are approved, the XBRL file is generated automatically for filing.
Which taxonomy applies to my 31 December 2026 reporting?
Version 2.8.2 (or the 2.8.2 NACE 2.1 Optional Hotfix) applies for the 31 December 2026 reference date, with no new taxonomy requirements for that cycle. The first reporting period under Taxonomy 2.10.0 is expected to begin in Q1 2027, per the EIOPA Taxonomy Roadmap update of 5 January 2026.
Will my software handle the 2027 taxonomy and calibration changes, or will I need to re-tender?
Both the move to Taxonomy 2.10.0 and the calibration changes under Directive (EU) 2025/2 should be delivered as part of normal vendor service, not as a chargeable change request or a trigger for re-procurement. cleversoft’s Compliance Commitment absorbs both updates within the running fee, with the roadmap already aligned to EIOPA’s timeline ahead of the Q1 2027 reporting obligations.










