Solvency II 2.8.2 to 2.10.0: migration deep dive

What your migration plan needs to explain

A taxonomy upgrade can change the meaning of a reported value while leaving its column code intact. It can also remove a recurring submission entry while retaining the underlying table for another purpose. A useful migration plan therefore needs to explain what happens to each affected source, calculation, reporting scope and review control.

This is the technical companion to our 2.8.2 Hotfix versus 2.10.0 comparison. It compares the official 2.8.2 optional NACE Hotfix with 2.10.0, using EIOPA's release notes, item-level change log and both annotated-template workbooks, checked on 17 October 2026. The baseline includes the optional NACE changes already available before 2.10.0.

The framework inventory and annual submission-list removals below are complete for the explicitly named objects and sheets. The field and validation sections are selected deep dives, not an exhaustive cell-by-cell migration specification. Practical actions and synthetic examples are our interpretation of the verified changes. An undertaking's reporting obligation still depends on the applicable legal requirements, module, exemptions and competent authority's instructions.

Changes at a glance

Start with the work owned by your team, then use the detailed sections to identify sources and acceptance checks.

Keep the reporting period separate from the migration date

EIOPA's release register assigns 2.8.2 through Q4 and annual 2026, inclusive, and 2.10.0 from the Q1 2027 reference period. A file submitted in 2027 can still belong to the 2026 reporting cycle. Keep annual-close work and the first 2.10.0 rehearsal separately identified.

For each entity, record the reference period, solo or group scope, annual or quarterly frequency, entry point, applicable authority and source package. Identify ECB add-ons and disclosure variants separately. A change demonstrated in an annual solo table is not evidence that the same table belongs in a quarterly or group submission.

The 2.10.0 release notes describe reporting simplifications and exemptions. Confirm your entity's eligibility before retiring a source feed or excluding a template.

How much changes: count objects, not spreadsheet rows

The official change log contains separate Dictionary, Framework, Table and Business rule sheets. Each object can have a summary row followed by several property changes. Counting all rows would mix object additions with label, expression and relationship changes.

Counting unique identifiers only on object-summary rows, where the Property column is blank, gives:

These are DPM change-log object counts. A TABLE is a detailed table identifier such as S.22.07.01.01; a TABLE_GROUP collects related tables. Neither count is a count of new legal obligations. A modified business rule may have a metadata change without a changed calculation. These counts also use a different unit from the XBRL assertion totals discussed in the release notes.

For a reproducible comparison, filter by object Type and Change, require a blank Property, then deduplicate Identifier. Retain the original workbook alongside the result. Search by identifier when revisiting a source: Excel row positions are useful locators for this checked file, not stable interfaces for future releases.

Annual submission lists: removals, additions and replacement

The Table sheet records eleven deleted row ordinates in the annual solo content list S.01.01.01.01 and two in the annual group list S.01.01.04.01. The old annotated workbook supplies the template names associated with those row codes.

The annual group deletions are R0430 → S.23.03.04, annual own-funds movements, and R0786 → S.37.03.04, concentration by asset class and rating. These are not the same set as the solo deletions. In particular, the solo S.23.02 removal must not be extrapolated to the group variant.

Source locators: change log, Table rows 274–284 and 391–392; old annotated workbook, S.01.01.01.01 and S.01.01.04.01, matched by row code. The lists above cover those two content-list variants only. Other module variants must be assessed separately.

The same annual solo content list adds R0575 → S.27.02.01, catastrophe loss data, and R0576 → S.27.03.01, catastrophe exposure and premium data. R0400 remains, but its reference changes from S.22.06.01 to S.22.07.01. Treat that as a replacement mapping; it is outside the eleven deleted rows above.

Source note: change log, Table rows 272–273 and 326–327; new annotated workbook, S.01.01.01.01 B61:C62 for the two additions. These additions and the R0400 replacement must be included in the annual solo planning exercise alongside the removals. Confirm applicability and update the submission selections before testing the associated data.

There is a consequential distinction here. EIOPA's 2.10.0 release notes, section V explain that S.30.01 and S.03.02 remain in the taxonomy for justified supervisory ad-hoc requests despite being outside the regular ITS submission content. Retain data needed for those requests and other continuing uses when retiring a recurring submission.

An operational retirement record should identify the removed submission, its remaining consumers, the owner of historical records, and the authority-specific decision. Keep that record with the migration plan rather than deleting every associated extraction job at once.

New and removed table structures beyond the annual headline

The four added table groups in Framework rows 22–25 are S.22.07.01, S.22.07.21, S.27.02.01 and S.27.03.01. The S.22.07 groups cover reporting and public-disclosure variants. The full inventory of 20 added TABLE objects is:

Here a range changes only the final segment: S.22.07.01.01–.03 means .01, .02 and .03. This inventory comes from Framework rows 2–21 and does not imply that every entity must report each table.

The 15 deleted TABLE_GROUP objects are E.02.01.16; S.21.01.01, S.21.02.01 and S.21.03.01; S.22.06.01; S.23.02.01; S.23.03.01, S.23.03.04 and S.23.03.07; S.29.01.01 and S.29.01.07; S.29.02.01, S.29.03.01 and S.29.04.01; and S.37.03.04. This is the complete group-deletion inventory in Framework rows 75–89. It is broader than the two annual content lists above and includes an ECB identifier and other variants.

Use the added tables to identify new data collection and the deleted groups to identify mappings requiring retirement or replacement. A net reduction in table count says little about the difficulty of the remaining work.

NACE: the same C0230 code now points to a different classification

The 2.8.2 Hotfix release notes, introduction and Annex 1 describe a transitional arrangement: retain NACE 2.0 where available and use the added NACE 2.1 fields where needed, with both permitted in the described cases. That history matters when reading a legacy extract.

Compare S.06.02.01.02 in the old annotated workbook and the new annotated workbook:

The old workbook shows these definitions in E5:F8; the new one shows C0230 in E5:E8. An unchanged field code or header is insufficient to justify copying the old value.

For each source record, identify the classification version and its provenance. An existing valid NACE 2.1 value from the Hotfix C0235 is a candidate for the new C0230 after checking the target hierarchy and record identity. A NACE 2.0 value in the old C0230 requires a classification review; moving it to the identically named target field does not perform a conversion. Where a correspondence offers multiple target activities, resolve the activity using business information rather than selecting the first code.

This also changes validation. BV792-5 applies to the same S.06.02.01.02 table used above. Its generated expression moves from accepting a populated C0235 or C0230 to requiring C0230. Preserve its applicability condition, including the CIC test. Match each other BV792 variant to its own table: BV792-1, for example, applies to the ECB add-on SE.06.02.18.02.

Source note: change log, Business rule rows 8915–8919, especially the expression at 8917 and generated expression at 8918.

Test a record with only the old NACE 2.0 field, one with only a valid Hotfix NACE 2.1 field, one with both, and one missing an applicable sector. Also test an asset outside the rule's applicability condition. The expected result must follow the target rule, not simply whether any old sector column was populated.

The sector key changes too: S.37.02.04.02 C0050 moves from optional to mandatory in the change log, Table row 1919. The old template exposes optional C0050/C0055 sector keys; the new one exposes mandatory C0050. Rebuild grouping and missing-key checks before loading the new concentration table.

Climate reporting: S.06.04 changes the type of value

In S.06.04.01.01, the old workbook's R0010 and R0020 use pure-ratio metrics pi2819 and pi2820. In the new workbook, those same row codes use monetary metric mi263, with separate portfolio members for transition-risk and physical-risk exposure and a Solvency II valuation dimension. Compare D5:D6 in both workbooks and E5:F6 in the new one.

The change log also deletes R0030 and R0040, previously used for explanations of unreported KPIs, at Table rows 679–680. This is more substantial than shortening the row labels.

Synthetic example: an old transition-risk ratio of 0.12 cannot be carried into a monetary cell as 0.12. If a fully reconciled underlying population contains EUR 12 million of in-scope exposure, the amount may be the relevant starting point for the new calculation. Reconstruct the amount from a verified population and valuation basis; the old percentage alone is insufficient.

Ask the investment-data owner for the underlying exposures, classification decisions and valuation basis. Reconcile the included population before calculating the new monetary output. Update the field's unit, formatting, import checks and reviewer explanation together. A parser that still accepts a percentage here could produce a technically numeric but economically meaningless result.

Volatility adjustment: rebuild S.22.06 mappings for S.22.07

The new S.22.07 structures cannot be implemented as a template-name substitution. In S.22.06.01.01, the old C0040 describes best estimate in the reporting currency. In S.22.07.01.01, new C0040 describes the euro portion. The new table also contains C0042 for asset sensitivity to credit spreads, C0044 for best-estimate sensitivity to interest rates and C0046 for the portfolio-based risk-corrected spread.

The precise locators are old D6:D7 and new C5:F8. The new row R0020 explicitly carries EUR in the currency dimension. A non-euro reporting currency makes the danger particularly visible: the old reporting-currency C0040 cannot be assumed to equal the new euro amount.

Allocate the new sensitivities and spread to an actuarial owner. Record the calculation basis, currency and portfolio coverage for each input. Reconcile the relevant best-estimate totals, but do not invent a one-to-one replacement for every old field. Inspect the other country/currency and disclosure variants separately.

The migration also reaches the submission list and validation. BV341-1 to BV341-4 update their descriptions to reference S.22.07 alongside S.22.01 when volatility adjustment is used. Their generated expressions also remove dv: [Default] from the S.01.02 R0180 input. The defaults on the R0370 and R0400 content-list inputs remain in those expressions. Test a missing R0180 separately from an explicitly reported selection, using the target expression and engine's missing-value semantics; this article does not infer a particular pass/fail result from the textual change alone.

For BV341-3, the change log also replaces the rule-constant identifier s2c_CN:x1 with $[s2c_CN:x1]. The generated expression still compares against the same member [s2c_CN:x1]. Verify that the target engine resolves the constant correctly, without treating a representation change as a new reporting obligation.

Source note: change log, Business rule rows 5614–5634; generated expressions at 5615, 5620, 5625 and 5632; constant addition/deletion at 5627–5628.

Test an explicit volatility-adjustment selection with both required content-list responses, each response missing or inconsistent, an explicit non-selection and an absent R0180 input. Keep the expected results tied to the target rule and the applicable module. This checks selection, missing-input handling and new template population together.

Product reporting: identifiers, row keys and commissions

Selected S.14.01 changes illustrate why the product-data team must participate:

Source locators: change log, Table rows 711–733; annotated workbooks, S.14.01.01.01 rows 3–7 and S.14.01.01.05 rows 3–7. The new product table retains its C0090 product reference and optional C0020 fund key alongside the artificial line identifier. A line identifier does not replace those business relationships.

For C0071, the metric remains mi2644 in both releases (old H7, new I7). The verified change is the label. It flags a source-basis question, but does not by itself prove that the underlying recognition requirement has changed. Compare the applicable instructions before changing an accounting or reporting policy.

Synthetic example: suppose the business identifies EUR 100,000 of commissions due for the year, of which EUR 80,000 has been paid. Copying the cash-paid extract would carry EUR 80,000 into a field now described on a due basis. The reporting owner must confirm the applicable instructions and reconcile the EUR 20,000 difference, rather than changing only the header. If the existing process already reports the required due amount, the revised label may require no calculation change. This example illustrates a possible source mismatch, subject to the recognition instructions described above.

Test products with several fund rows, products with no fund key where permitted, and a product referenced by more than one portfolio record. Check record counts and joins as well as financial totals: a duplicated join can inflate several monetary columns while leaving the identifiers looking credible.

Currency and catastrophe data: inspect the reporting grain

For S.16.01.01.01, the old workbook has a mandatory currency Z0030 at A6, alongside the non-life line-of-business and accident/underwriting-year axes. The new workbook retains the latter axes but removes that currency axis. This agrees with section V of the release notes.

Review how the source pipeline partitions records. Removing a currency column from an output file does not automatically combine the underlying records correctly. Establish the required valuation and conversion basis, then aggregate only compatible amounts. Check for duplicate remaining keys and reconcile the consolidated result to the source population. Do not add nominal amounts in different currencies.

The new catastrophe tables introduce data requirements beyond an updated layout:

• S.27.02.01.01, direct-business loss data, identifies records by peril, year, zone and asset type, with an artificial line key. It reports gross loss and separate claim counts. Metric ii34 at C0070 covers open claims and claims settled with payment; C0071 separately counts claims closed without payment, and C0072 counts those closed with payment. Do not sum all three counts as disjoint populations: C0072 overlaps the paid-settlement population in C0070. See new annotated-template rows 5–8.
• S.27.03.01.01, gross direct-business exposure, uses peril, zone and asset type, with an artificial line key. It reports exposure, risk count, deductible and loss limit. See rows 5–7.

These selected direct-business tables are only part of the new S.27.02/.03 families. Establish the applicable variant and instructions before collecting data. Claims and exposure teams should reconcile geographic coding, asset categories, event/year treatment and completeness. A total exposure file without the required breakdown cannot be made sufficient by assigning arbitrary line numbers.

For existing S(R).27.01 structures, the release notes identify added countries for flood, hail and subsidence, a vehicle-policy limit moving from EUR 24 million to EUR 32.4 million in the .08 table, and a vessel-count exemption value moving from EUR 250,000 to EUR 337,500 in .28. Add regression cases around the old and new values and use the exact target instructions for the boundary operator; this summary does not determine whether equality belongs above or below a threshold.

The release notes also identify diversification amendments in S(R).26 and changes to matching-adjustment-portfolio breakdowns. Treat these as separate actuarial review items. This article does not supply a complete S.26 calculation specification or a complete inventory of changed portfolio dimensions.

Concentration ratios: separate definition effects from exposure movements

The release notes describe the S.37.02 ratio changing from an exposure-to-total-assets basis to a specific-exposure-to-total-reported-exposures basis. A comparison across releases must therefore retain the denominator definition. The workbooks provide direct field-level evidence: S.37.02.04.02 C0040 changes from pi2974, exposure share relative to total assets, to pi3037, exposure share relative to total net exposure.

Source note: old annotated workbook, S.37.02.04.02 D6; new annotated workbook, the same sheet C6; change log, Table row 1915 (metricMemberCategorizations). The physical Excel column moves, while reporting column C0040 is retained.

Synthetic example: EUR 20 million divided by EUR 1 billion gives 2%. The same EUR 20 million divided by EUR 200 million gives 10%. The eight-percentage-point difference can arise entirely from the denominator in this deliberately fixed-exposure example. The exposure itself remains unchanged.

For a real movement explanation, keep the submitted prior-period result intact. If useful, create a separately labelled analytical restatement using the new basis, only when the necessary historical data and matching population are available. Then explain classification changes, population changes and genuine exposure movements separately. Do not overwrite a historical filing to make the trend look continuous.

The mandatory sector-key change discussed above belongs in the same workstream. New grouping or classification can alter the reported population, so validating the arithmetic alone is insufficient.

Validation: expression changes, tolerances and checks outside XBRL

The 1,028 added, 398 deleted and 1,967 modified business-rule objects above are an inventory of change, not a measure of validation coverage. Section VII of the release notes explains that roughly three quarters of the newly added XBRL assertions concern relationships between probabilities in S.26 cumulative distribution functions. Organise regression tests by the affected calculations and modules rather than allocating identical effort to every added identifier.

Three different kinds of change need different tests:

For the last case, the change log provides a concrete example: BV1871, Business rule row 3421, changes includeInXBRL from true to false. That is not a statement that the underlying business relationship is irrelevant. Record whether a check is performed by the reporting application, another calculation or an accountable review step. An XBRL-engine pass cannot answer that question by itself.

EIOPA also introduces custom margins alongside strict comparison and interval arithmetic: one based on a relative threshold and another on an absolute threshold. Use each rule's published expression and tolerance semantics. Do not install a single percentage tolerance for all equations or widen a margin until a failure disappears.

For each applicable changed calculation, retain one expected pass and one expected failure. For tolerance-sensitive checks, add cases just inside and outside the specified margin, including the units and decimal accuracy used in reporting. For distribution checks, exercise the relevant probability relationships. For applicability checks, test both selected and unselected reporting options. Record any check the chosen engine does not execute.

Package loading and source updates belong in the rehearsal

EIOPA's release notes and release register direct users to complete taxonomy packages rather than relying on downloads of individual canonical XML/XSD files. Validation deactivation files remain a separately maintained mechanism. The release also supplies random-data and zero-valued sample instances; these are useful for exercising entry points and enumerations, but they do not establish that an undertaking's mapping is correct.

Rehearse loading the intended package, resolving its dependencies and opening the applicable entry point. Record the validation/deactivation state used for the run and consult the release's known issues. Repeat the exercise with controlled business examples such as the NACE and monetary-field cases above. Keep the exported instance, findings and reviewer explanation together.

Successful package loading, passing implemented validations, reviewer approval and authority acceptance are separate outcomes. Name the outcome actually demonstrated in the rehearsal record.

Turn the comparison into an owned migration backlog

Use one record per meaningful change, with the exact old and new identifiers, applicable module, source owner, mapping decision, validation consequence and acceptance evidence. Classify the work as retirement, replacement, transformation, fresh collection or further investigation. Avoid labelling a field compatible solely because its code is unchanged.

Start with the changes that require upstream data or new calculations; a missing source cannot be fixed in the final export window. Then test transformations, retirement decisions and validation coverage against the chosen reporting scope. Use the taxonomy preparation guide to place these checks in the source-to-export workflow, and retain the introductory comparison for colleagues who need the overall transition explained first.