Learning Objectives

By the end of this section, readers will be able to:

  • Establish a governance framework for taxonomy management, including dedicated teams, version control systems, and change approval procedures
  • Understand the publication process for XBRL taxonomies, including public exposure periods and the creation of taxonomy packages with supporting documentation
  • Implement post-publication support mechanisms, including feedback collection systems and ongoing stakeholder communication strategies

Introduction

Taxonomy publishing and maintenance refers to the complete process of making XBRL taxonomies available to users and keeping them current and reliable over time. This involves more than simply releasing technical files; it also requires establishing proper governance, managing public consultation periods, and providing ongoing support to stakeholders who depend on the taxonomy for their reporting obligations.

This section covers the complete taxonomy lifecycle through three main phases: pre-publication activities (including governance frameworks and public consultation), publication processes (including taxonomy packages and supporting documentation), and post-publication support (including feedback mechanisms and ongoing maintenance). Each phase contains specific activities that contribute to taxonomy reliability and stakeholder confidence.

Taxonomy Publishing Lifecycle

Pre-publication

Establishing the Taxonomy Governance Framework

Effective taxonomy publishing and maintenance is essential for successful digital reporting initiatives. Without proper processes, taxonomies can become inconsistent, outdated, or unusable, leading to poor data quality and stakeholder confusion. Well-managed taxonomies, by contrast, provide a stable foundation that enables accurate, comparable reporting across organisations and time periods.

A good governance process prevents common problems such as different teams making conflicting changes, software vendors working with different versions of the same taxonomy, or updates being released without proper testing. These situations create confusion and reduce the quality of reported data.

Forming a Dedicated Taxonomy Management Team

Effective governance requires clear roles and responsibilities. Three key roles support taxonomy management:

  • Taxonomy architects make design decisions that affect the overall structure and future development of the taxonomy. They ensure that current decisions support future needs and maintain consistency across the taxonomy.

  • Taxonomy authors develop the actual content by translating regulatory requirements into technical specifications. They create the concepts, labels, and relationships that make up the taxonomy.

  • Taxonomy owners maintain ongoing operations by monitoring performance, addressing issues, and coordinating updates. They ensure the taxonomy continues to meet user needs over time.

Each role serves a specific purpose while working towards the common goal of maintaining taxonomy quality and relevance. Clear role definitions prevent situations where important decisions are delayed because no one has clear responsibility for making them.

Implementing Version Control Systems

Version control systems track every change made to the taxonomy. These systems record what changed, when it changed, and who made the change. This creates a complete record that helps teams understand how the taxonomy has developed over time.

Version control prevents problems that occur when multiple people try to change the same part of a taxonomy at the same time. Without these systems, teams might work on outdated versions, create conflicting changes, or accidentally remove each other’s work.

These systems ensure that all stakeholders work with the same, current version of the taxonomy. This coordination is essential for maintaining consistency and preventing errors.

Developing Maintenance Schedules

Regular maintenance schedules, such as the one developed by the EIOPA, provide the predictable rhythm that keeps taxonomies current and relevant while avoiding the disruption of constant, unpredictable changes. These maintenance schedules are comparable to planned maintenance intervals for critical infrastructure like bridges or aircraft. Regular, scheduled attention prevents small issues from becoming major problems and ensures that the system continues to meet its intended purpose.

These schedules allow for systematic addressing of accumulated feedback, incorporation of new regulatory requirements, correction of identified errors, and implementation of improvements based on practical experience. The predictable nature of scheduled maintenance helps all stakeholders plan their own activities, whether that involves software updates, staff training, or reporting process adjustments.

Maintenance schedules also create natural points in time for comprehensive review and testing. Rather than implementing changes individually as they arise, scheduled maintenance allows for thorough evaluation of how different modifications interact with each other and with existing systems.

Taxonomy Change Approval Procedures

Formal procedures ensure that every change receives appropriate review before implementation. These procedures maintain the integrity and reliability that stakeholders depend upon. The change approval process typically includes several stages:

  • Initial requests are logged and evaluated for necessity and potential impact
  • Technical assessment confirms that proposed changes will not break existing functionality
  • Review ensures that modifications align with regulatory objectives and technical standards
  • External consultation gathers feedback from affected stakeholders when appropriate

This systematic approach prevents poorly considered modifications that might seem reasonable individually but could create problems when viewed in the broader context of the entire reporting system.

A comprehensive change log records the rationale behind each modification. This log provides valuable information for software vendors who need to understand how their systems should adapt to taxonomy updates. It helps report preparers understand what modifications they need to make to their reporting processes. It also serves as a learning tool for the governance team.

Public Exposure Period for Draft Artefacts

A public exposure period allows market participants to review and comment on proposed taxonomy structures before final publication. This period should be clearly announced and time-bound, usually lasting 30 to 60 days. Clear instructions explaining how to submit comments should accompany the exposure period announcement.

The materials published during the exposure period should match what will be included in the final publication. This ensures that stakeholders can provide meaningful feedback on what they will actually be required to use.

Public exposure periods promote transparency and build stakeholder ownership of the final product. They allow for gathering industry feedback which can be included in the final version of the taxonomy. This consultation process helps ensure that the final taxonomy meets the practical needs of those who will use it.

This matters because public exposure periods reduce implementation problems by identifying issues before final publication. Stakeholders can highlight practical concerns, suggest improvements, and prepare their systems based on near-final versions. This advance preparation leads to smoother adoption when the final taxonomy is released.

Publication

Publishing as Taxonomy Packages

Regulators should ensure that published taxonomies conform to the latest relevant specifications and guidelines developed by XBRL International. Best practice is to publish every taxonomy as taxonomy packages, which provide a standard approach for publishing, formatting conventions, and structuring of the technical artefacts. Taxonomy packages are easily consumable by software applications.

Another key reference for regulators is the XBRL International guidance on taxonomy publication which outlines practical recommendations for structuring and distributing taxonomy packages, hosting files securely, and ensuring discoverability and reusability. While the guidance is technical, it complements this article by equipping operational teams with the tools needed to implement the publication layer in a consistent and robust manner.

Providing Supporting Materials for Taxonomy Users

Taxonomy users require more than raw taxonomy files to understand the scope of a new taxonomy or changes to an existing one. Regulators should publish a comprehensive and accessible set of artefacts that explain the taxonomy’s purpose, structure, and expected application. These artefacts support better engagement and promote clarity across diverse stakeholder groups:

  • The data model (tabular or diagrammatic format): A business-friendly representation of the reporting requirements that illustrates the relationship between concepts, hierarchies, and validation rules. Data models are particularly valuable for non-technical users, offering a clear view of what is being reported without the need to interpret technical schema files

  • Validation rules (including business constraints): A structured list or documentation of rules that govern the logical consistency and integrity of the reported data. This may include cross-field validations, conditional requirements, or expected value ranges. Providing these helps preparers and software vendors validate reports correctly

  • Taxonomy packages (schema, linkbase files, entry points): The technical artefacts that define the taxonomy structure, including concepts, relationships, labels, and references. Packaged in accordance with XBRL International’s specifications, these files allow software systems to interpret and apply the taxonomy

  • Sample XBRL reports (typical reporting scenarios): practical examples of how a report would look when properly tagged using the taxonomy. These are extremely helpful for preparers and software developers as they demonstrate intended tagging approaches and clarify reporting expectations

  • Documentation on taxonomy architecture (naming conventions, modelling choices): An explanation of design decisions, such as why certain dimensions were used, how data points are grouped, or what conventions were applied in naming and referencing. This improves transparency and supports better alignment with any future extensions

  • Versioning reports (summary of changes across releases): A concise comparison between versions that explains what was added, removed, or modified in the taxonomy. This allows stakeholders to assess the impact of changes on their systems and reporting processes

  • Filing manuals or implementation guides: Practical instructions for report preparers and vendors on how to create and validate XBRL instance documents, submit filings, and interpret error messages. These guides often include FAQs, tagging policies, and references to regulatory reporting obligations.

This level of transparency not only improves the quality of stakeholder feedback during consultation but also lays the groundwork for smoother adoption and implementation of the published taxonomy.

Post-Publication

Feedback Collection and Response Mechanisms

Structured mechanisms should be in place to collect, review, and respond to feedback from taxonomy users. The feedback collection process should follow these steps:

Step 1: Collect feedback through multiple channels:

  • Online forms or feedback portals
  • Designated email channels
  • Issue tracking systems where comments and responses are publicly visible
  • Review workshops or webinars, especially for larger stakeholder groups

Step 2: Review and categorise feedback: Sort feedback by type (technical issues, clarification requests, improvement suggestions) and priority (urgent fixes needed, general improvements, future considerations).

Step 3: Respond to stakeholders: Each piece of feedback should be acknowledged promptly. Provide an initial response confirming receipt and an estimated timeline for full review.

Step 4: Publish consultation outcomes: Regulators should publish a summary of the consultation outcomes, including which suggestions were adopted and the reasoning behind decisions. This transparency helps stakeholders understand how their input influenced the final taxonomy.

Feedback mechanisms should accommodate users with varying technical expertise. This may include providing feedback forms in simple language, offering translated materials where appropriate, and ensuring that non-technical concerns receive equal consideration alongside technical issues.

Post-Publication Support and Ongoing Communication

Once the final taxonomy version is published, regulators should maintain open channels for ongoing support. This involves establishing clear processes for handling different types of user queries:

  • Support services:

    • Help desk or dedicated support email services for preparers, vendors, and other users
    • Response time commitments for different types of queries
    • Escalation procedures for urgent issues

  • Knowledge management:

    • Maintain a questions and answers log based on frequently encountered challenges
    • Regularly update implementation guides based on user experience
    • Document common issues and their solutions

  • Issue resolution:

    • Clear procedures for reporting technical problems or errors in the taxonomy
    • Communicate corrections through targeted updates (sometimes called hotfixes)
    • Regular notification schedules for non-urgent updates and improvements

  • Communication channels:

    • Regular newsletters or updates about taxonomy developments
    • Advance notice of upcoming changes or maintenance schedules
    • Clear contact information for different types of support needs

Ensuring continuity of communication helps build long-term trust and prevents disruptions during reporting periods. Regular communication also helps identify emerging issues before they become widespread problems.

Summary

Publishing and maintaining XBRL taxonomies involves a complete lifecycle that extends far beyond simply releasing technical files. This lifecycle approach ensures that taxonomies remain reliable, current, and useful for all stakeholders involved in digital reporting.

The pre-publication phase establishes the foundation for success through proper governance frameworks, dedicated management teams, version control systems, and structured change approval procedures. The public exposure period during this phase allows stakeholders to review and improve proposed taxonomies before final release.

The publication phase involves releasing taxonomies as standardised packages accompanied by comprehensive supporting materials. These materials help users understand the taxonomy’s purpose, structure, and application requirements.

The post-publication phase maintains the taxonomy’s value through structured feedback collection, ongoing support services, and regular communication with users. This phase ensures that taxonomies continue to meet evolving needs and that users receive the assistance they require for successful implementation.

For regulatory and supervisory bodies implementing digital reporting platforms, this lifecycle approach provides several key benefits. It reduces implementation problems by identifying issues early through consultation. It builds stakeholder confidence through transparent processes and reliable support. It ensures data quality through proper governance and validation. Most importantly, it creates a sustainable foundation for long-term digital reporting success.

Effective taxonomy publishing and maintenance requires commitment to all three lifecycle phases. Each phase builds upon the previous one, creating a comprehensive approach that transforms technical taxonomies into reliable tools for digital reporting initiatives.