Solvency II taxonomy 2.10.0 migration: what can you reuse?

“Where did the €250,000 go?”

That is the question a reviewer could ask after rehearsing a Solvency II filing migration from EIOPA 2.8.2 Hotfix to 2.10.0. In our synthetic example, one amount appears in the successor draft and another does not. The useful answer is in the migration evidence and in the original filing that remains available to check.

A useful rehearsal answers a practical question: which parts of the old filing can the team rely on, and which decisions must it make again? Creating the successor is only the starting point. The result should let a preparer explain every important retained or omitted item to a reviewer.

This guide follows two actual outcomes from a synthetic rehearsal, then shows how to turn them into a review record. The suggested review steps below are a working method for a reporting team; they are not additional automated checks claimed for the product.

Two amounts, two outcomes

The example team starts with two selected values in a partial filing:

These amounts belong to different reporting items. They are not a before-and-after total, and the omitted form does not mean that the insurer lost €250,000.

The rehearsal used SolvencyBridge's bundled definitions for 2.8.2 Hotfix and 2.10.0 in an isolated environment. Values and source links were seeded for the example; this is a migration demonstration, not a demonstration of importing the workbook. The filing is intentionally incomplete.

Keep the original and choose the target deliberately

In SolvencyBridge, an administrator or reviewer opens Export, then Taxonomy migration, to create a successor from an installed newer release in the same taxonomy family. The successor has its own filing identity. We checked that creating it left the original filing and both original values unchanged.

The filing lifecycle guide describes the migration controls and review steps; the support matrix explains supported scope.

This is a compatibility rehearsal, not a switch of reporting period. The successor retains the source's year-end 2026 reference period. It must not be treated as a valid 2026 submission using the new taxonomy or as a newly prepared Q1 2027 filing.

EIOPA confirms that Q4 and year-end 2026 use 2.8.2. Its 2.10.0 release notes identify Q1 2027 as the first reference period. The taxonomy guide explains that distinction. Choose the actual filing's release from its reference period and applicable authority instructions.

Separate the things you are reusing

Treat “reuse” as several decisions, rather than one approval of the whole filing.

Start with the source filing's actual reporting scope. Keep a record of its entity, reference period, release and relevant templates beside the target-release comparison. A whole-catalog comparison can help locate changes, but it does not tell you which templates your insurer must submit.

Worked example: the retained €1 million

The €1 million deferred-tax-asset value survives the move, together with its seeded source location, Rehearsal!B2. Its reporting target remains compatible in the two installed definitions.

That is useful reuse: a reviewer can follow the amount back to its evidence. It is not permission to use an old amount for a new period without checking it.

The migration comparison considers cell identity, data type, metrics and dimensions. It can identify compatibility in those definitions. The team still needs to read the reporting instructions and assess business meaning; a matching coordinate alone is not sufficient.

For this value, work through the following sequence:

1. Find the original fact. Open S.02.01.01.01, row R0040, column C0010, and confirm the source amount is €1,000,000. Record the label, not just the coordinate, so a reviewer knows this is deferred tax assets.
2. Check the successor. Locate the same target and compare the amount. In this rehearsal, €1,000,000 was retained. Do not infer that all other cells in the template behaved the same way.
3. Follow the evidence. Confirm that the retained source link points to Rehearsal!B2. Here that link was seeded; a real rehearsal should also establish that the underlying source file and relevant version are available to the reviewer.
4. Decide what the result proves. It proves carry-forward for this compatible target in this rehearsal. Before using it in an actual later-period filing, obtain the appropriate period's source amount and check the reporting instructions. Keeping the mapping does not mean keeping last period's balance.

A useful review note would read:

Deferred tax assets: carry-forward verified. Source and successor both show €1,000,000 at S.02.01.01.01 R0040/C0010. The successor retains the seeded source link Rehearsal!B2. This establishes technical reuse in the compatibility rehearsal. The preparer must supply and reconcile the appropriate source amount before using the mapping for another reporting period. Migration approval remains pending.

This note separates a completed check from work still required. “Migrated successfully” would hide that distinction.

S.21.01: investigating an omitted loss-distribution table

The second source value belongs to the loss-distribution table S.21.01.01.01. That table is present in the source bundle and absent from the target bundle. The successor therefore does not carry its form forward, and the associated mapping is marked unresolved.

The next task is to establish what the relevant reporting scope now requires, using the applicable instructions. Do not redirect the old mapping to a convenient-looking cell just to eliminate the unresolved item.

Return to the original filing when explaining the difference. Its €250,000 value is still there. The evidence separates an intentional omission from a lost source record.

Investigate the omission in this order:

1. Preserve the original evidence. Confirm the €250,000 at S.21.01.01.01 R0010/C0060 in the original filing. In this rehearsal, the original filing and its values remained unchanged.
2. Identify the reason for the omission. Check whether the source table is absent from the installed target definitions, or whether only a particular cell has changed. Here the whole table is absent. That is more specific than saying “the import lost a value”.
3. Check the reporting obligation separately. Consult the official change log, target instructions and relevant authority requirements for the intended filing scope. Absence from the converted bundle is evidence about the software's loaded definitions; by itself it does not settle every legal or national reporting obligation.
4. Assign the outstanding decision. The reporting owner must establish whether the information is no longer required for that scope, has a different reporting treatment, or exposes a definition-coverage issue that needs investigation. If another target is required, justify it from the instructions before changing the mapping.

The corresponding example record is deliberately still open:

Claims-incurred bracket: omission explained, reporting decision open. The €250,000 remains in the source at S.21.01.01.01 R0010/C0060. The table is absent from the installed target bundle and the mapping is unresolved. No replacement destination has been established in this rehearsal. The reporting owner must confirm the treatment against the applicable instructions before this item can be signed off. Do not map the amount elsewhere merely to clear the unresolved status.

The two values should not be added into a “migration reconciliation total”: deferred tax assets and claims incurred are different reporting items. Reconcile each to its own source and intended treatment. The useful question is whether each item's outcome is explained, not whether a sum of unrelated cells stayed constant.

Solvency II reporting meaning can change even when a cell remains

A table or coordinate can look familiar while the reporting instruction changes. EIOPA's 2.10.0 release notes, section V, describe a change to the exposure ratio in S.37.02: the denominator changes from total assets to total exposures reported in the template.

For illustration, €20 million divided by €1 billion is 2%; the same €20 million divided by €200 million is 10%. These are synthetic amounts, not a third outcome from our migration rehearsal. The worked taxonomy comparison explains this denominator change in its wider release context.

When reviewing such a change, write down the numerator, denominator, their source locations and the definition used for each release. Then calculate the expected result independently and compare it with the prepared filing. If your old mapping feeds an already-calculated ratio, identify who will update that upstream calculation. Moving the mapping alone cannot correct an old denominator.

This is why the definition comparison and the reporting-instruction review belong together. The software comparison checks the semantics represented in its loaded definitions; the reporting team must also assess the instructions and source calculations.

Give the reviewer decisions, not just a migration percentage

The successor remained a draft with one validation error, four warnings and migration review pending. Whole-catalog counts and percentages do not measure how much of this insurer’s filing is ready. For the two demonstrated items, a concise handoff could look like this. The roles are suggested owners; no founder or product approval is being recorded here.

Attach or link the original and successor, the release comparison, the relevant source evidence and the exact instruction passages used for decisions. Give unresolved items an owner and a point at which the decision must be made. Keep this record with the team's review evidence; the table above is a suggested handoff, not a claim that the product automatically creates it.

For each validation finding, identify the affected item and what the finding actually says before assigning a fix. A missing input, an incompatible target and an inconsistent amount need different responses. After changing data or a mapping, rerun the relevant checks and give the reviewer the updated result. Our error and warning counts alone do not diagnose their causes or show that they have been resolved.

A rehearsal can finish with an honest conclusion such as “carry-forward tested; scope decision outstanding”. A filing cannot become approved simply because the rehearsal is documented. An unresolved reporting obligation, unexplained missing value or unresolved blocking validation finding must be addressed before the team treats the successor as ready for sign-off. Any later follow-up needs to be clearly separated from those blockers; putting a name beside a blocker does not resolve it.

Try this with one source value

Pick one value your reviewer may question. Record its source location, reporting target, migration result and the reason for that result. If it was omitted, keep the original evidence and assign the follow-up decision to an owner. If it was retained, check its reporting period and meaning before reusing it.

That short evidence trail is more useful than saying “the migration ran.” To explore the workflow with your own supported reporting scope, choose Request a guided evaluation and describe the item you need to trace.

Sources and demonstration scope

EIOPA Q&A 3504, full answer checked 16 October 2026; 2.10.0 release notes, sections I and V, checked 19 October. The example's table and cell comparison uses the EIOPA-derived definitions bundled in SolvencyBridge; those converted files do not replace the official taxonomy package or filing instructions. The synthetic browser rehearsal ran on 19 October. It did not complete reviewer approval, submission or authority acceptance.