What is XBRL in insurance reporting? Instances, taxonomies, DPM and validation explained

Every quarterly and annual Solvency II submission, every IORP II pension fund return and every Solvency UK return to the PRA leaves the insurer as an XBRL file. Most people who sign off those filings have never opened one, but it helps to know what the file contains, why a regulator rejects it, and what the software does between your spreadsheet and the supervisor’s portal.

This article explains XBRL as it is used for insurance reporting: the parts of a filing (taxonomy, entry point, instance, context, fact, filing indicator), how EIOPA and the Bank of England publish their taxonomies and on what timetable, the steps from raw data to a validated instance, and the validation errors that come up most often. The last section shows where each step lands in the XBRL tools from SolvencyTool.

What XBRL is

XBRL stands for eXtensible Business Reporting Language. It is a format for exchanging business data, built on XML, XML Schema and XLink, and maintained by XBRL International, a not for profit consortium. The base specification is XBRL 2.1, a recommendation dated 31 December 2003 with errata corrections up to 2013. A second specification, XBRL Dimensions 1.0 (recommendation of 18 September 2006), adds what regulatory templates depend on: a fact can be characterised by several dimensions, and a hypercube is an ordered list of the dimensions that apply to a set of facts.

That second specification is why XBRL suits supervisory reporting. A cell in S.02.01 Balance sheet is not just “total assets”. It is total assets for one legal entity, at one reference date, in one currency, for the remaining part or a specific ring fenced fund. Dimensions carry all of that with the number, so the regulator can load thousands of filings into one database and compare them. It receives one XML file per entity and reference date, and every check it runs is a check on that file.

The moving parts

These words come up in every EIOPA release note and every rejection message.

Two of these deserve a closer look. A template code such as S.02.01 is not itself a concept in the taxonomy. It is a table, and the DPM maps each cell of that table to a metric and a set of dimension members. That is why the S.02.01 Balance sheet reporting explanation reads in rows and columns while the taxonomy talks in metrics and dimensions. The other is the filing indicator, which the EIOPA XBRL Filing Rules treat as mandatory: rule 1.6.(a) says an instance must include a positive filing indicator for every template it intends to report, and a submission without one is invalid.

How EIOPA uses XBRL

Solvency II reporting rests on Directive 2009/138/EC, Delegated Regulation (EU) 2015/35 and the Implementing Technical Standards that set out the templates. EIOPA has published an XBRL taxonomy for those templates since the regime went live in 2016. Each release on EIOPA’s DPM and XBRL page bundles the DPM dictionary, annotated templates, XBRL taxonomy, list of validations and filing rules, and states which reference dates it applies to.

The versions that matter today:

• Solvency II taxonomy 2.8.2, published 15 October 2024, applies from the Q4 and annual 2024 reference dates through Q4 and annual 2026. An optional hotfix of 30 June 2025 allows NACE 2.1 codes; instances made with it stay backwards compatible.
• Solvency II taxonomy 2.10.0, published 3 July 2026, applies from the Q1 2027 reference period. It carries the amended templates from the Solvency II review. There is no 2.9.x release for insurers; 2.9.0 is the pension funds number.
• Pension Funds taxonomy 2.9.0 applies to IORP reporting from the Q1 2025 reference period, with the same optional NACE 2.1 hotfix of 30 June 2025.

So an insurer runs two taxonomies in parallel in early 2027: the annual 2026 package under 2.8.2 and the Q1 2027 quarterly package under 2.10.0 a few weeks later. Software has to hold both and pick the entry point from the reference date. Which templates are in the current release, and which are quarterly, annual, solo or group, is covered in our Solvency II QRT list.

How the Bank of England uses XBRL

The PRA has published its own Bank of England Insurance Taxonomy since 2018, and version 2.0.0 of April 2024 moved Solvency UK reporting onto it under PS3/24 for reference dates from 31 December 2024. It is still dimensional XBRL, but the template codes, entry points and release calendar are the Bank’s own. The current versions:

• v2.0.2, published 2 October 2025, effective from 1 January 2026 for reporting with a reference date on or after 31 December 2025. It implements policy statement PS15/24.
• v2.1.0, published 16 December 2025, adds four entry points for the liquidity reporting requirements in PS15/25. Liquidity reporting comes into force on 30 September 2026 for firms in scope. All entry points from v2.0.2 are carried over, so a firm can move everything to the newer taxonomy at once.
• v2.2.0, published 2 September 2026, introduces the MALIR reporting framework and implements PS18/26 on post implementation reporting amendments. The amended frameworks are effective from 1 January 2027 for reference dates on or after 31 December 2026.

Submissions go through BEEDS, the Bank of England Electronic Data Submission portal. A firm’s chief executive nominates a principal user, who receives credentials and can set up further users. How the UK templates diverge from EIOPA’s is covered in Solvency UK versus Solvency II.

From data to a validated instance

The pipeline is the same whether the destination is a national supervisor in the EU or BEEDS in London.

Mapping comes first. Each cell of each template is tied to a source: a ledger account, a column in the custodian’s asset file, a result from the technical provisions or SCR calculation, or a manual entry. Mapping is the expensive part, and it is what you keep from quarter to quarter.

Instance generation follows. The software reads the sources, applies the mapping and writes the XML: one context per entity, period and dimension combination, one unit per currency or ratio, one fact per populated cell with its decimals attribute, and a filing indicator for every template in scope. The entry point for the reference date goes into the schema reference at the top of the file.

Validation runs in layers. First, XML and schema validity: the file parses and every element is one the entry point knows. Second, the filing rules: identifier schemes, decimals, filing indicators, allowed contexts. Third, the assertions embedded in the taxonomy, written under the XBRL Formula specifications as value, existence and consistency assertions. Fourth, the regulator’s list of validations, the business rules that cross templates, plus any checks the national authority has added. The severity of each rule decides whether a failure blocks the submission.

Submission closes the loop. The authority runs the same rule sets on receipt and returns an acceptance or a list of failed rules. A rejected filing is corrected at the source or in the mapping and regenerated. Nobody edits the XML by hand.

The most common validation error classes

Rejections fall into a few classes, each with a typical cause.

The instance references the wrong entry point for its reference date, for example a 2.8.2 entry point on a Q1 2027 filing that needs 2.10.0. The fix is to regenerate under the right taxonomy.

The filing rules are breached. The entity identifier uses the wrong scheme: EIOPA requires the LEI with the scheme http://standards.iso.org/iso/17442, and a national code only where no LEI exists. Another frequent one is a ratio reported as 9.31 instead of 0.0931, which rule 3.2.(b) prohibits.

A filing indicator is missing or duplicated. A template’s facts are present but there is no positive filing indicator for it, so the facts are never validated, or the same template is flagged twice, which the duplicateFilingIndicator rule forbids.

A context or dimension is wrong. A fact carries a period end that does not match the reference date, or a closed list value outside its domain, for example a fund type in Z0020 of S.02.01 other than 1 for a ring fenced fund or 2 for the remaining part.

An assertion fails. A total does not equal the sum of its components after rounding, usually because source figures were rounded before mapping. Filing rule 2.18.(b) asks for values to be reported as known and unscaled; the total then reconciles.

A business rule fails across templates. Own funds in one template do not agree with the balance sheet in S.02.01, or a quarterly template is filed after an exemption was declared. These come from the regulator’s list of validations rather than the taxonomy and need an actuary or accountant, not a technician, to resolve.

XBRL, iXBRL and Excel

Inline XBRL (iXBRL) embeds XBRL tags inside an HTML document so that one file is both human readable and machine readable; listed companies use it for annual reports under ESEF, and neither EIOPA nor the PRA use it for prudential templates. xBRL-CSV, part of the Open Information Model from XBRL International, represents the same facts as tables rather than XML. Excel is where most figures originate and where most people want to review them, but it is neither an XBRL format nor a substitute for one. A later article will compare the three for insurance filings.

Where this lands in the software

QRT Tool, BOE Tool and IORP Tool each ship with the current EIOPA or Bank of England taxonomy and its entry points, so an annual 2026 package and a Q1 2027 package validate against the right release without a manual switch. The mapping step is the import layer in QRT Tool: databases, Excel or CSV files are pulled into the templates with transformations that are saved and reused each quarter. Validation runs inside the tool against the taxonomy assertions, the filing rules and the national specific checks, and the resolvers correct whole classes of error automatically. SmartData fills gaps in asset data from a repository of more than 13 million securities and the GLEIF register. Currency conversion at the ECB rate for the reference date, multi entity accounts for groups and a planning tool with per template deadlines and four eyes review are part of the same XBRL tools.