Pension Funds taxonomy 2.9.0: the templates and what changed for reporting from Q1 2025 onwards

The Pension Funds taxonomy is the XBRL package that turns EIOPA’s pension templates into a file a supervisor can load. Version 2.9.0 has applied to every reference date from 1 January 2025, and it is the version a fund or its administrator builds against today. This article sets out where 2.9.0 sits in the release history, which of its nine entry points a fund actually uses, what each PF template does and how often it is due, what changed against the previous version 2.7.1, and which validations and filing rules the file has to pass. It closes with a checklist for a first 2.9.0 filing and a look at the Solvency II 2.10.0 and IRRD releases that share the calendar. The templates and entry points below are the ones IORP Tool populates and validates before submission, so the codes are written the way EIOPA prints them.

Where 2.9.0 sits in the release history

EIOPA numbers the pension taxonomy on the same scale as the Solvency II one, but the two lines do not move together. The first pension package was 2.3.0, published on 5 November 2018 for the reporting that started with the third quarter of 2019. It was followed by 2.5.0 on 15 July 2020, 2.6.0 on 15 July 2021 and 2.7.0 on 16 July 2022, each with a hotfix in the autumn. Version 2.7.0 brought the integration of PEPP prudential reporting into the pension model. Version 2.7.1 was a minor release with one change, the reflection of Croatia joining the euro area; EIOPA’s roadmap accepts 2.7.0 or 2.7.1 for reference dates from 30 June 2023, and 2.7.1 alone for the 2023 annual file and every reference date in 2024. There was no pension release numbered 2.4.0 and no 2.8.0: the 2.8.0 package of 17 March 2023 changed Solvency II only.

Version 2.9.0 is the release built for the 2023 Board of Supervisors decision, EIOPA-BoS-23-030, which applies from 1 January 2025 and is the legal basis for the IORP II reporting package described in our earlier article. EIOPA published the final 2.9.0 taxonomy on 17 July 2023, to be used from the first quarter 2025 reference date. On 16 July 2024 it published the 2.9.0 hotfix, which under EIOPA’s governance keeps the release number and replaces the original before anyone reports on it. On 30 June 2025 a second, optional hotfix added NACE Rev. 2.1 columns for reference dates from 31 December 2025, for funds whose data providers no longer deliver NACE 2.0 codes.

The early publication was deliberate. EIOPA’s governance document on taxonomy releases, EIOPA-BoS-24/411 of 24 October 2024, estimates that industry needs six to nine months before the first submission deadline and cites the 2.9.0 pension release as the case where the taxonomy was published as soon as the business package was final, regardless of the application date.

The nine entry points

An entry point is the schema file an XBRL instance references, and it fixes which templates the file may contain. The Pension Funds 2.9.0 hotfix package has nine, listed in Table 1 of the release notes. The suffix of each template code is the entry point code, so PF.06.02.24 is the annual individual list of assets and PF.06.02.26 the same template in the national aggregate.

The release notes mark the three aggregated entry points as level 2 reporting only, meaning the transmission between the national authority or central bank and EIOPA. A fund never files them. The ECB add-on entry points exist because Regulation (EU) 2018/231 of the European Central Bank collects pension fund statistics from the same institutions, and EIOPA carries the ECB requirements inside the package so that a euro area fund produces one file for both. In those entry points the templates that carry add-ons appear with the PFE prefix, for example PFE.02.01.30.01 for the annual balance sheet and PFE.06.02.31.01 for the quarterly list of assets, while templates without add-ons reuse the ordinary PF tables. Whether a fund files the combined entry point is for the national authority to say; the release notes are explicit that adoption of the taxonomy is subject to the national competent authorities.

Inside the individual entry points the fund also declares its PEPP position in the basic information template: PEPPs reported as an integrated part of the pension report, PEPPs reported in a dedicated report, or no PEPPs. Only the first case fills PF.52.01 and the extra PEPP columns in the list of assets and open derivatives.

The PF templates by frequency, and what 2.9.0 changed

The table lists the templates in the 2.9.0 hotfix package with the entry points they belong to, taken from the module schemas in the taxonomy zip, and the change EIOPA lists for each in the 2.9.0 and 2.9.0 hotfix release notes. Where the notes list nothing the template is marked as such. No template was removed in 2.9.0; the removals are parts inside PF.29.05.

Two things in the table matter for a data mapping. First, the quarterly list of assets and open derivatives are separate tables from the annual ones, with fewer columns, so a transformation built for PF.06.02.24 does not produce PF.06.02.25 without a second definition. Second, the annual set for a euro area fund draws on both prefixes: PF.04.03.24, PF.05.03.24, PF.06.03.24, PF.08.01.24, PF.09.02.24, PF.29.06.24, PF.51.01.24 and PF.52.01.24 sit in the ECB entry point unchanged, next to the PFE versions of the content, basic information, balance sheet, list of assets, changes in technical provisions and member data templates.

The Solvency II templates that PF.06.02 and PF.08.01 were aligned with are described in the Solvency II QRT list; an asset team that already produces S.06.02 for an insurer will recognise most of the columns.

Validations and filing rules

Every release ships a List of validations workbook, and the 2023 decision makes the pension validations mandatory in the same way EIOPA’s guidelines do for insurers. The 2.9.0 notes flag three things about that workbook. The definition and syntax of the business validations were rewritten so that each rule matches one XBRL assertion, and because the numbering changed, the release carries a column mapping the new validation numbers to their 2.7.1 counterparts. EIOPA restored the PTV0 validations, which compare the templates announced by the filing indicators with the content of the file. And it tightened filing rule S.23 so that mandatory artificial keys must not contain leading, trailing or double whitespace, with technical validations to enforce it. The second hotfix updated the NACE validations to accept 2.1 codes. Validations carry a severity: an error blocks the submission, a warning does not. The EIOPA validation errors article covers how the common ones are read.

The filing rules are one document across all EIOPA frameworks, EIOPA-15-253, versioned by its last update date. The update of 15 July 2024, shipped with the 2.9.0 hotfix, revised section VI, the pension section; the update of 30 June 2026 added IRRD and revised sections V and VI again. The rules that decide whether a pension file is accepted:

• S.1.5.(a): the instance references exactly one entry point schema, by full absolute URL, and that entry point must exist in production for the reference date.
• 1.6 and 1.7: positive filing indicators for every template reported, no positive indicator for a template with no facts, and no facts outside the indicated templates.
• 1.12: a file is a complete report; a correction is a full resubmission, not a delta.
• S.2.8: the entity identifier is the LEI, and a national code only where no LEI exists; it must be registered with EIOPA by the authority before the file is sent.
• 2.13 and 3.1: one reference date on every context, and one reporting currency declared in the basic information template.
• VI.4: the line identification keys in PF.06.02, PF.06.03 and PF.08.01 (typed dimensions XJ, XW and XV) are unique within the table and never nil.
• VI.5: where PF.04.03.26.01 asks for a set of countries in C0110, the ISO codes are separated by commas.

The deadlines moved with the decision as well. From 2.9.0 the roadmap shows only the national authority’s deadline to EIOPA, because EIOPA-BoS-23-030 sets no deadline for the fund itself: nine weeks after a quarter end, so 2 June 2025 for the first quarter of 2025, and 20 weeks after the year end, so 20 May 2026 for 2025. The fund’s own deadline is national and earlier.

What to check before your first 2.9.0 filing

• The reference date picks the version. A 2024 annual file, or any resubmission of one, stays on 2.7.1 even in 2026; only reference dates from 1 January 2025 use 2.9.0.
• Load the hotfix package of 16 July 2024, not the final of 17 July 2023, which it replaced. From the 31 December 2025 reference date decide whether the second hotfix is needed: only if NACE 2.0 is unavailable for some lines, and only if your authority has enabled it.
• Use the taxonomy zip package. EIOPA discontinued support for the individual canonical files with the second hotfix and asked the remaining users to stop by 31 December 2025.
• Confirm the entry point with your authority: full or exempted set, with or without the ECB add-ons, and the PEPP scenario in PF.01.02.
• Build separate transformations for the quarterly PF.06.02.25 and PF.08.01.25 tables; they have no PEPP columns.
• Drop the actuarial basis and inflation rate assumption parts from the PF.29.05 mapping.
• Source the new data: the cost breakdown in PF.05.03, the country split in PF.04.03 and the whole of PF.29.06.
• If you file the ECB entry point, add the issue price to the list of assets feed.
• Check the filing indicators against the content, since PTV0 is active again, and strip whitespace from every line identification key.
• Re-map any internal validation tracking with the 2.7.1 to 2.9.0 mapping column, and pull the current deactivation file from EIOPA before each run.

The release calendar around it: Solvency II 2.10.0 and IRRD

Pension funds are the quiet end of EIOPA’s calendar. Solvency II 2.10.0 was published on 3 July 2026 and applies from the first quarter 2027 reference date; the fourth quarter and annual 2026 files stay on 2.8.2 or its NACE 2.1 hotfix. Its start date sits next to the Solvency II review, which Directive (EU) 2025/2 applies from 30 January 2027. The IRRD taxonomy 2.11.0 followed on 27 July 2026 as a separate package with biannual solo and group entry points; the roadmap starts it with financial years ending between 30 January and 31 December 2027, due 20 weeks after the year end for solo entities and 26 weeks for groups, in line with the deadline set out in our article on IRRD and Directive (EU) 2025/1.

For pensions the roadmap of 15 July 2026 lists 2.9.0, or its optional NACE 2.1 hotfix, for every reference date to 31 December 2027, and notes that the decision on making NACE 2.1 mandatory is still to be taken. The governance document explains why: one adaptive release a year is the rule for Solvency II, while the other frameworks get a release only when there is an update to carry; the adaptive release is due by 30 June, the hotfix by 25 October, and from 2.10.0 onwards a new taxonomy applies from the fourth quarter of its year. The footnote adds that Pension Funds 2.9.0 remains applicable from the first quarter of 2025, and that any move to a 1 January start, even as an exception for IORPs, has to resolve the technical objections raised in the 2024 consultation. A new pension taxonomy will come when the decision or the ECB regulation changes, and the IORP II review, which works on Directive (EU) 2016/2341 rather than on the decision, is not that trigger. How an XBRL taxonomy works, including entry points and filing indicators, is explained in what XBRL is in insurance and pension reporting.

Where this lands in the software

IORP Tool holds the Pension Funds taxonomy versions still in use, 2.7.1 for the 2024 files and 2.9.0 with both hotfixes for everything since, and selects the version and entry point by reference date. Data comes in from databases, Excel and CSV files through transformations defined once and reused each quarter, with separate definitions for the annual and quarterly list of assets. The validation rules for the period run before submission and the resolvers correct the common errors automatically; in several countries the national supervisor’s additional validations are built in. SmartData, the embedded asset repository, completes PF.06.02 and PF.06.03 by ISIN, with LEI and ultimate parent data from the Global Legal Entity Identifier Foundation. It sits alongside QRT Tool and BOE Tool in the XBRL tools family, so an administrator serving both insurers and funds runs one platform.