Taxonomy Development Process

Learning Objectives link

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

• Distinguish between the business-oriented and technical phases of taxonomy development
• Establish comprehensive data modelling rules and principles that create consistency across taxonomy architecture, including element naming conventions and classification of information into metrics, dimensions, and structural formats
• Develop systematic regulatory mapping processes that define reporting scope, determine appropriate granularity levels, and align data requirements with submission schedules
• Create high-quality data models through structured data dictionary development, logical reporting table design, and comprehensive business rule definition
• Navigate the technical implementation process using XBRL taxonomy editors, including tool selection, namespace definition, element creation, and the development of presentation trees, calculation relationships, and dimensional structures
• Implement advanced taxonomy components such as formula rules, table linkbase structures, label resources, and reference mappings
• Execute comprehensive validation and testing procedures that verify technical compliance and business content accuracy
• Manage taxonomy development as an iterative, business-driven process that balances regulatory requirements with practical implementation needs
• Apply a systematic framework for managing complex taxonomy development projects effectively

Introduction link

The development of an XBRL taxonomy follows a structured process, moving from high-level design to technical implementation and validation. It starts with mapping regulatory requirements into a business data model, then translating that model into technical taxonomy files using tools, schemas, and linkbases, followed by validation to ensure accuracy and usability.

The choices made at each stage directly affect data quality, preparer usability, and regulatory analysis. A clear overview helps regulators and stakeholders plan XBRL implementation more effectively, ensuring expectations, resources, and timelines are aligned. This section explains the considerations of each stage, highlighting the practical decisions and trade-offs that shape the success of the final taxonomy.

Step 1: Data Modelling Rules and Principles link

The foundation of any successful XBRL implementation begins with the preparation of a thorough, yet at this stage, high-level, data model, along with gathering related information and creating other non-technical documentation. This occurs before any technical work commences, establishing the blueprint for the entire reporting system by defining what information must be collected, how it should be structured, and what rules govern its use. The data model serves as an architectural plan before constructing the target XBRL taxonomy; the clearer and more comprehensive these plans are, the more successful the final implementation will be.

Regulatory Mapping link

Regulatory mapping represents the critical first step in understanding exactly what information the reporting system must capture and deliver to the reporting entities. This process involves systematically documenting the complete scope of reporting requirements by collecting all source documents, such as legal acts, regulatory documents, and reporting guidance. Additionally, the appropriate level of detail needed, and the frequency and timing of report submissions must be defined.

The scope of reporting defines the boundaries of what information falls within the reporting system and what remains outside it. For example, a banking supervisor might determine that the scope includes all deposit-taking institutions but excludes insurance companies and investment funds. A company register may collect data from companies that fulfil certain thresholds of balance sheet value, revenue or number of employees. Establishing clear scope boundaries prevents confusion during implementation and ensures that the taxonomy serves its intended purpose.

Granularity refers to the level of detail required in the reported information. Different reporting programmes require different approaches to granularity. Some may require highly detailed tagging where individual line items are marked separately (e.g. each reported fact of the balance sheet, income statement, or cashflow) enabling precise analysis and comparison. Others might accept block text approaches where entire sections of reports, such as explanatory notes in the financial statements, are captured as single units, providing less analytical precision but reducing preparation burden.

Submission schedules define the timing and frequency of reports:

• Monthly reports: Operational data requiring rapid collection and analysis
• Quarterly reports: Performance metrics and trend analysis
• Annual reports: Comprehensive assessments and forward-looking information

The regulatory mapping process must align data requirements with submission frequencies, recognising that more frequent reporting may require simpler data structures to ensure timely compliance.

Modelling Rules link

Establishing clear modelling rules creates consistency across the entire taxonomy and ensures that similar information is handled uniformly throughout the system. These rules serve as the guiding principles that taxonomy architects use when making design decisions about how to represent different types of information. There are at least two commonly used modelling approaches. First, the Data Point Model, which is broadly used in the European financial market supervision for collecting data from banks, insurance companies and pension funds. Second, the accounting taxonomy architectures such as IFRS which are commonly used by capital market supervisors or business registers to collect data from privately held companies.

Element naming conventions provide the foundation for a coherent taxonomy structure. These conventions establish how concepts will be named, ensuring that users can easily understand and locate relevant information. Consistent naming patterns help preparers navigate the taxonomy more efficiently and reduce the likelihood of errors during report creation, where a given reported fact is named differently across taxonomy (e.g. Short-term Assets vs. Current Assets). The conventions should be intuitive to the users while maintaining the technical precision required for automated processing. The above mentioned IFRS Taxonomy Architecture document defines these rules in the Style Guide section.

The other aspect to be addressed by modelling rules is the classification of information into metrics or dimensions, which represents a fundamental design decision that affects how data can be analysed and compared. Metrics typically represent measurable values such as monetary amounts, percentages, or counts. Dimensions provide the context that qualifies these metrics, such as geographic regions, time periods, or business segments. Proper classification ensures that the resulting data can support the analytical requirements of collectors and consumers.

Information can be organised in different structures:

• Lists: For sequential or hierarchal data where order matters (e.g, balance sheet items).
• Tables: For multi-dimensional information where data points are qualified by multiple characteristics simultaneously (e.g., changes in equity or operating segments) A
• Text blocks: For narrative information that does not fit structured formats.

When designing tables, the distinction between open and closed dimensions becomes crucial. Closed axes have predetermined, fixed values that preparers must select from, ensuring consistency and comparability across reports. Open axes allow preparers to add their own values, providing flexibility for entity-specific circumstances but potentially reducing comparability. The choice between open and closed approaches depends on the reporting objectives and the diversity of reporting entities.

In the context of ESG reporting, open dimensions include operating segments that are entity specific. This flexibility allows a technology company to define segments like “Cloud Services,” “Hardware,” and “Software Licensing,” while a manufacturing company might use “Production,” “Distribution,” and “Research & Development.” For closed dimensions, an example is listing of countries belonging to the European Economic Area, which might require selection from a standardised list of ISO country codes, ensuring consistent geographic categorisation.

Step 2: Developing the Data Model link

The modelling rules or principles establish the foundation for developing a data model. Created by business experts such as policy specialists or data users, this non-technical, business-oriented artefact defines precisely the scope and characteristics of the reported data. The data model is a critical component of the target reporting framework and significantly impacts the quality of collected data.

A poor-quality data model, which due to the lack of validation of modelling rules contains duplicated concepts, will most likely result in an XBRL taxonomy which will contain such a duplication and as a result will lower the quality of collected data. Conversely, a high-quality data model provides clear and explicit requirements, and when properly converted to the XBRL taxonomy, it constitutes a solid foundation for target data reporting.

In terms of tooling, a data model can be developed using a spreadsheet tool such as Microsoft Excel or software dedicated to this purpose. Dedicated solutions offer functionalities that allow users to define modelling principles and rules which automatically ensure that given artefacts, such as concepts, are respected. Using a spreadsheet tool requires more self-discipline and more manual checks to ensure that the established modelling rules are respected.

Developing the Data Dictionary link

The first step of developing a data model is creating a data dictionary, that, based on the agreed naming rules and classification into metrics, dimensions, and domain members, defines all unique concepts of a target reporting framework. Based on the formal requirements, metrics are defined by the data types and correspond to legal acts or formal documentation.

A data dictionary generally contains limited structures, primarily nested lists, supporting navigation across a vast number of concepts.

When creating the data dictionary, the authors must ensure that all concepts for the target reporting tables and other reporting structures are defined.

Designing Reporting Tables and Other Reporting Structures link

Developing the logical structure of reporting concepts and their relationships establishes how different pieces of information connect to form a coherent whole. This framework provides the intellectual foundation for the taxonomy and guides decisions about how concepts should be organised and related within reporting lists, two- or multi-dimensional tables, or nested or unnested textual information.

The conceptual framework identifies natural groupings of related concepts and establishes hierarchical relationships between general and specific concepts. It also defines how concepts from different reporting areas interact and where information might be shared or cross-referenced between different parts of the reporting system.

The structure and content of required reporting tables and schedules translates the conceptual framework into practical reporting formats that preparers can understand and complete. This design process considers both the analytical needs of data collectors and the practical constraints faced by data preparers.

Schedule coordination ensures that information reported in different tables or at different times maintains consistency and supports comprehensive analysis. This coordination identifies where the same information might appear in multiple contexts and establishes rules for ensuring consistency.

Business Rule Definition link

Business rules define the logical constraints and validation requirements that reported data must satisfy. These rules ensure data quality and consistency while preventing common errors that could undermine the usefulness of collected information. Business rules include:

• Logical validation rules: Establish mathematical and logical relationships between different data points such as total assets, which must equal the sum of current assets and non-current assets. These rules enable automated checking of report consistency and help identify potential errors before or during the business report submission process.

• Business constraints: Define the acceptable ranges or characteristics for different types of information. Monetary amounts might have minimum and maximum thresholds. Dates might be restricted to specific periods. Text fields might require formats or exclude certain characters. Well-defined constraints improve data quality and reduce the need for manual data cleansing.

• Cross-validation rules: Establish requirements that span multiple related data points or reporting periods. These might require that certain ratios fall within expected ranges or that changes between periods are explained when they exceed specified thresholds. Cross-validation rules help identify unusual circumstances that merit additional attention from analysts.

Legal References link

Each concept defined in the data dictionary should be mapped to the relevant legal acts, regulations or authoritative guidance creating a clear audit trail between reporting requirements and their legal foundation. This mapping serves multiple purposes: it justifies the existence of given concepts, helps preparers understand the authority behind each requirement, supports legal compliance verification, and facilitates maintenance when legal requirements change.

The reference mapping process identifies the specific legal provisions that mandate each piece of information. This might include primary legislation, implementing regulations, technical standards, or interpretive guidance. Comprehensive legal references help preparers understand not just what to report, but why it must be reported and how it fits within the broader regulatory framework.

Reference documentation should be sufficiently detailed to enable preparers to locate the relevant legal provisions independently. This includes citation formats that follow local legal conventions and sufficient detail to identify specific sections or paragraphs. Clear references also support taxonomy maintenance by enabling architects to track when legal changes require taxonomy updates.

Step 3: Technical Implementation Using XBRL Taxonomy Editors link

The transition from conceptual design to technical implementation represents a crucial turning point in taxonomy development. This stage transforms the carefully crafted business requirements and data model into functional XBRL components that software systems can process and validate. The quality and precision of this translation directly determines whether the final taxonomy will meet its intended purpose effectively.

Understanding this implementation stage is essential for regulatory representatives because the technical choices made here will influence how preparers interact with the taxonomy, how data collectors receive and process information, and how successfully the entire reporting programme achieves its policy objectives. Unlike earlier stages that focus primarily on business logic, this step requires close collaboration between business experts and technical specialists to ensure that nothing is lost in translation.

Tool Selection link

The foundation of successful technical implementation begins with selecting appropriate XBRL taxonomy development tools that match the project’s complexity, team capabilities, and long-term maintenance requirements. Taxonomy development tools fall into several categories, each designed to support different aspects of the creation process and varying levels of technical expertise.

Professional taxonomy authoring environments provide comprehensive functionality for creating, editing, and validating complex taxonomies. These tools typically offer graphical interfaces that allow business experts to participate directly in the technical creation process while automatically generating the underlying XML code required by the XBRL specification. Such environments usually include built-in validation engines that check for technical compliance as the taxonomy is being developed, helping to identify and resolve issues before they become embedded in the final product.

Often, taxonomy editors allow for import of the previously developed data model, significantly reducing the effort required for migration of this information. This feature significantly reduces the risk of misinterpretation caused by manual rekeying of the data model into a taxonomy editor.

Specialised schema editors focus primarily on the technical aspects of taxonomy creation, providing detailed control over XML schema structures and XBRL-specific features. These tools are particularly valuable when creating taxonomies that require sophisticated technical features or when integrating with existing technical infrastructure. However, they typically require greater technical expertise and may be less accessible to business experts who need to contribute to the taxonomy development process.

Collaborative development platforms combine taxonomy authoring capabilities with project management features, enabling distributed teams to work together effectively. These platforms become particularly important when taxonomy development involves multiple organisations or when the development timeline spans extended periods. The ability to track changes, manage versions, and coordinate contributions from different team members can significantly improve the efficiency and quality of the development process.

The selection process should consider not only the immediate requirements of the current taxonomy project but also the long-term needs for taxonomy maintenance and evolution. A tool should not only address the requirements for developing the first public version of an XBRL taxonomy. Ideally, it should also provide adequate support for ongoing taxonomy updates, offering version management and integration with data collection systems. Additionally, the availability of technical support, training resources, and user communities can significantly influence the success of implementation.

Technical Architecture link

Converting the data model into the XBRL technical specifications that form an XBRL taxonomy requires systematic attention to each component that contributes to the taxonomy’s functionality. This conversion process must preserve the business logic captured during earlier phases while optimising the technical implementation for performance, maintainability, and user experience.

Namespace Definition link

Once appropriate tools are selected, the taxonomy development team must establish unique identifiers for the taxonomy that prevent conflicts when different reporting systems operate together. This namespace definition process addresses a fundamental challenge in digital reporting: ensuring that each taxonomy component has a globally unique identity that cannot be confused with similar components from other sources.

The namespace design process requires careful consideration of how the taxonomy will be used both now and in the future. The identifiers chosen today will appear in every report created using the taxonomy, so they must remain stable and accessible over the entire lifecycle of the reporting programme. This stability requirement means that namespace design decisions should avoid dependencies on organisational structures or technical systems that might change over time.

Element Definition link

Creating the core XBRL schema files transforms the namespace design and data model specifications into the technical foundation that defines how the taxonomy will function. Schema development requires translating business concepts into XML schema constructs while ensuring compliance with XBRL specification requirements and maintaining compatibility with processing software.

The schema development process begins with defining the fundamental data types that the taxonomy will support. Standard XBRL data types cover most common reporting requirements, including monetary amounts, percentages, dates, and text. However, specialised reporting domains may require custom data types that provide additional functionality or validation capabilities. The selection and definition of data types directly influences how preparers will input information and how validation systems will check data quality.

Element definitions within the schema establish the building blocks that preparers will use to tag their reports. Each element must be carefully specified with appropriate attributes and validation requirements. The precision of these definitions determines whether the resulting data will meet the analytical requirements documented in the data model.

Read more about components of taxonomy in this article.

Presentation Tree link

Establishing hierarchical parent-child relationships for elements creates the logical structure that preparers will see when navigating the taxonomy. The presentation tree serves as the primary interface between the taxonomy’s technical implementation and the users who must apply it to their reporting requirements.

The presentation tree design process requires careful consideration of how preparers think about their information and how they naturally organise their reporting processes. Effective presentation trees follow logical business hierarchies that mirror the structure of typical reports in the relevant domain.

Hierarchical relationships within the presentation tree can serve multiple purposes beyond simple organisation. Parent-child relationships may indicate aggregation requirements, logical dependencies, or contextual relationships that help users understand how different pieces of information relate to each other. These relationships also provide valuable information for analysis systems that need to understand the structure of reported data.

Calculation Relationships link

Capturing required relationships between concepts, such as “concept a + concept b = concept c”, enables automatic validation of mathematical consistency within reported data. Calculation relationships serve both quality assurance and user guidance functions, helping preparers identify potential errors while providing analysts with confidence in the mathematical integrity of collected information.

The process of defining calculation relationships requires systematic review of all mathematical dependencies within the data model. These relationships may be straightforward additions and subtractions or more complex formulas that involve multiple variables and conditional logic. Each relationship must be specified precisely to enable automated validation while remaining comprehensible to preparers who need to understand how their data will be checked.

Calculation tree structures organise mathematical relationships into logical groupings that reflect natural business hierarchies. For illustration only, a balance sheet calculation tree might start with total assets at the top, break down into current and non-current assets at the second level, and further subdivide into specific asset categories. This hierarchical approach helps preparers understand both the mathematical requirements and the business logic underlying the relationships.

Dimensions link

Establishing dimensional frameworks within the taxonomy enables the capture of multi-dimensional business information that reflects the complex realities of modern reporting requirements. Dimensional structures transform simple data points into contextually rich information by defining the qualifying characteristics that specify exactly what each reported fact represents. This architectural approach addresses the fundamental challenge that most business information cannot be meaningfully understood without knowing the specific circumstances, time periods, geographic regions, or business segments to which it relates.

The dimensional architecture emerges directly from the modelling decisions made during earlier phases regarding open and closed dimension requirements. These architectural choices determine whether preparers must select dimension values from predetermined lists or whether they can define their own contextual categories to reflect entity-specific circumstances. Closed dimensions provide consistency and comparability by restricting preparers to standardised classification schemes, such as predefined lists of countries, currencies, or accounting standards. Open dimensions offer flexibility for entity-specific situations by allowing preparers to define their own dimension values, such as business segments that reflect their unique operational structure or product categories that align with their internal management reporting.

Multi-dimensional data structures defined as cubes, combine sets of qualifying dimensions with reported concepts to create comprehensive information frameworks. Unlike physical three-dimensional objects, these analytical structures can accommodate any number of dimensions simultaneously, enabling sophisticated analysis across multiple business characteristics. A single revenue figure, for example, might be qualified by geographic region, business segment, accounting standard, and reporting period dimensions, providing analysts with a precise understanding of what the reported amount represents.

The dimensional framework design process requires careful balance between analytical sophistication and practical usability. Each additional dimension increases the analytical power of the collected data, but also adds complexity for preparers who must understand and apply the dimensional structure correctly. The architecture must support the analytical requirements identified during data modelling, while remaining clear for preparers with varying levels of technical expertise.

Formula Rules link

Incorporating validation rules as XBRL Formula Rules enables sophisticated automated checking that goes beyond simple mathematical relationships. Formula rules can implement complex business logic, cross-referencing requirements, and conditional validations that ensure reported data meets quality and consistency standards appropriate to the reporting domain.

Development of formula rules requires close collaboration between business experts who understand the validation requirements and technical specialists who can implement them effectively. Business validation rules identified during earlier phases must be translated into formula syntax while preserving their intended function and providing clear error messages when violations occur.

Rule complexity must be balanced against processing performance and maintainability considerations. Highly complex rules may provide comprehensive validation coverage but could create performance bottlenecks during report processing or become difficult to maintain as business requirements evolve. Rule design should prioritise the most important validation requirements while providing clear paths for future enhancement.

Formula rule documentation becomes particularly important because these rules implement business logic that may not be immediately apparent from examining their technical implementation. Clear documentation helps report preparers understand what validations will be applied to their data and enables taxonomy maintainers to update rules correctly when business requirements change.

XBRL Reporting Templates (Table Linkbase) link

Creating structured presentation formats transforms the technical taxonomy components into user-friendly reporting templates that preparers can easily understand and complete. Table linkbase functionality enables the design of multi-dimensional reporting formats that mirror the familiar spreadsheet layouts commonly used in business reporting, providing preparers with intuitive interfaces while maintaining the precision required for automated data processing.

The table linkbase development process addresses a fundamental challenge in digital reporting: presenting complex, multi-dimensional information in formats that are both analytically powerful and practically accessible to preparers. This mechanism proves particularly valuable in closed reporting scenarios where regulatory authorities, in particular banking or insurance supervisors, prescribe specific reporting templates that all entities within the reporting population must follow. By defining standardised tabular presentations, regulators ensure consistency in how information is collected while reducing the learning burden on preparers who can work with familiar table-based formats.

The table linkbase architecture integrates seamlessly with other taxonomy components, ensuring that presentation templates remain synchronized with underlying validation rules, calculation relationships, and business logic defined as dimensional structures. This integration means that changes to the business requirements can be reflected consistently across both the analytical structure and user-facing presentation formats, ensuring ongoing alignment between regulatory needs and preparer experience.

When implementing a presentation layer for the reported data, table linkbase is one of several mechanisms offered by XBRL specifications. This article explains in detail how table linkbase is positioned against other presentation mechanisms offered by the XBRL standard.

Label Resources link

Implementing a label style guide and creating human-readable descriptions ensures that the taxonomy provides clear guidance to preparers while maintaining consistency across all user-facing text. Labels serve as the primary interface between the technical taxonomy structure and the business users who must apply it to their reporting requirements.

Label development requires careful attention to the needs of different user communities who may interact with the taxonomy. Preparers need labels that clearly explain what information should be reported and how it should be calculated or determined. Software developers need labels that facilitate system integration and user interface development. Analysts need labels that support data interpretation and comparison across different reports.

Multilingual label support may be required depending on the geographic scope of the reporting programme and the diversity of the preparer community. The label architecture should accommodate multiple languages (e.g. local language and English) while maintaining consistency of meaning across translations. This requirement adds complexity to both initial development and ongoing maintenance activities but opens doors for international use of the published data.

Reference link

Linking elements to authoritative sources and legal references creates the audit trail that connects each technical implementation detail back to its regulatory or business justification. References serve multiple constituencies, including preparers who need to understand the authority behind reporting requirements, auditors who must verify compliance, and taxonomy maintainers who need to track the impact of regulatory changes.

Reference implementation requires systematic mapping between taxonomy elements and the legal or regulatory provisions that mandate their inclusion. This mapping must be sufficiently detailed to enable users to locate the relevant provisions independently while remaining concise enough to be practically useful. Reference formats should follow established conventions that are familiar to users in the relevant regulatory domain.

Reference maintenance becomes particularly important for taxonomies that will be used over extended periods. Legal and regulatory provisions may be amended, renumbered, or superseded, requiring corresponding updates to taxonomy references. The reference architecture should facilitate these maintenance activities while preserving historical information that may be needed for analysis of older reports.

Entry Points link

Logical organisation of the reported information into groups that limit the elements viewed makes it easier for preparers to quickly identify the elements needed for specific types of reports, e.g. quarterly, annual, solo, or consolidated. Entry points serve as customised views of the taxonomy that present only the information relevant to a given reporting scenario, reducing complexity and improving user experience.

Entry point design requires understanding the different types of preparers who will use the taxonomy and the various reporting scenarios they encounter. Sector-specific entry points might present only the elements relevant to banking institutions, insurance companies, or investment firms. Frequency-specific entry points could distinguish between monthly operational reports and annual comprehensive disclosures.

Entry point maintenance represents an ongoing responsibility that requires coordination between different user communities and their evolving requirements. As reporting programmes mature and user needs change, entry points may need to be added, modified, or retired. The entry point architecture should facilitate these changes while preserving stability for existing users.

Taxonomy Package Creation link

Organising a taxonomy as a set of files known as a taxonomy package provides a standardised distribution mechanism that simplifies deployment, version management, and integration activities. Taxonomy packages bundle all the components needed for a functioning taxonomy into a single, portable unit that can be easily shared and implemented across different systems and organisations.

The taxonomy package creation process requires careful attention to file organisation, dependency management, and versioning considerations. All schema files, linkbases, and supporting documentation must be included in appropriate directory structures that facilitate automated processing and manual inspection. Dependencies on external resources must be clearly identified and managed to ensure that packages function correctly in different deployment environments.

Learning from existing implementations can significantly reduce development time and improve compatibility with existing tools and systems. Examples of XBRL implementation that uses taxonomy packages, such as the ESEF programme in Europe, provide information on how this mechanism is implemented in each scenario.

Step 4: Technical Content Validation and Testing link

Technical content validation represents the quality assurance phase where the completed taxonomy undergoes systematic testing to ensure it functions correctly as a technical product while faithfully implementing the business requirements established in earlier phases.

The technical validation process begins with systematic verification that the taxonomy complies with all relevant XBRL specifications and technical standards. This compliance checking ensures that the taxonomy will function correctly with standard XBRL processing software. Syntax validation focuses on the fundamental technical correctness of all taxonomy components, ensuring that the underlying code structure follows proper formatting rules and contains no structural errors that would prevent processing software from interpreting the taxonomy correctly. This level of validation catches basic technical mistakes that could render the entire taxonomy unusable, such as malformed file structures, incorrect references between components, or violations of XML formatting requirements. While syntax errors represent the most basic category of technical problems, they can have devastating effects on taxonomy deployment if not identified and corrected during the validation phase.

Another area of technical verification is package validation, including testing procedures which ensure that distributed packages function correctly across different deployment scenarios and software platforms. Validation should cover both technical compliance with packaging standards and functional testing with representative data and use cases.

Performance testing evaluates how the taxonomy behaves under realistic operating conditions, assessing factors such as loading times, memory requirements, and processing efficiency that will affect the practical experience of preparers and collectors. A taxonomy that functions correctly but performs poorly may create barriers to adoption or impose significant costs on users who must invest in additional computing resources to achieve acceptable performance. Performance validation typically involves testing the taxonomy with representative data volumes and realistic usage patterns to identify potential bottlenecks or resource constraints that could affect deployment success.

The technical validation phase concludes when the taxonomy has demonstrated reliable performance across all anticipated use cases and operating conditions. At this point, regulatory representatives can have confidence that the technical implementation will support their policy objectives effectively while providing preparers with a reliable tool for meeting their reporting obligations. The thoroughness and precision of technical validation directly influence the success of subsequent deployment and adoption phases, making this step a critical determinant of overall programme effectiveness.

Step 5: Business Content Validation and Testing link

Business content validation represents the crucial testing phase where the completed taxonomy demonstrates its ability to capture and process real-world reporting scenarios effectively. During this process all the technical components are verified if they work together seamlessly to support actual reporting activities under realistic conditions. This phase bridges the gap between technical correctness and practical utility, ensuring that the taxonomy will serve its intended purpose when deployed in the regulatory environment.

This validation phase addresses a fundamental question that regulatory representatives must answer before launching their reporting programme: does the taxonomy work for real preparers dealing with real business situations? Technical validation confirms that the taxonomy meets specification requirements, but business content validation demonstrates whether those technically correct specifications translate into a functional reporting system that captures the information needed for regulatory analysis and policy implementation.

The business validation process begins with creating sample reports using, to the extent possible, actual data that should be representative of the report preparers who fall within the scope of the reporting programme. This sample report creation serves multiple purposes beyond simple functionality testing. It reveals how preparers will experience the taxonomy when working with their own information, identifies practical challenges that may not have been apparent during conceptual design, and demonstrates whether the taxonomy structure aligns with natural business information flows.

Creating sample reports often exposes gaps or ambiguities in the taxonomy design that were not evident during earlier development phases. Business information rarely fits perfectly into the neat categories that conceptual models suggest, and preparers frequently encounter edge cases, exceptions, and unusual circumstances that challenge standard reporting approaches. These discoveries during business validation provide opportunities to refine the taxonomy design before deployment, addressing practical problems when corrections are still relatively straightforward rather than after widespread adoption has made changes more disruptive.

Calculation and formula-based rule validation focuses on testing the mathematical and logical relationships embedded within the taxonomy against realistic data scenarios. This testing process verifies that validation rules function correctly with actual business data, identifying situations where rules may be too restrictive, too permissive, or inappropriate for legitimate business circumstances.

Completeness testing systematically verifies that the taxonomy captures all information required to support the regulatory analysis and policy objectives that motivated the reporting programme. This testing process often reveals subtle gaps where important information falls between the defined reporting categories or where the level of detail provided by the taxonomy proves insufficient for intended analytical purposes.

Edge case testing explores how the taxonomy behaves when confronted with unusual, boundary, or extreme data scenarios that fall outside normal business operations. This testing process helps identify situations where the taxonomy may produce unexpected results, fail to validate correctly, or provide misleading analytical output. Edge cases often reveal assumptions embedded within the taxonomy design that may not hold under all circumstances, providing opportunities to strengthen the overall robustness of the reporting system.

The business content validation phase concludes when the taxonomy has demonstrated reliable performance across representative real-world scenarios, comprehensive coverage of required information, and robust handling of exceptional circumstances. At this point, regulatory representatives can proceed with confidence toward public consultation and deployment phases, knowing that the taxonomy has been thoroughly tested under realistic conditions and proven capable of supporting its intended regulatory objectives effectively.

The last step in the taxonomy development process is preparation of the corresponding taxonomy documentation and publication of the created artefacts.

Read more about taxonomy publication in this article

Business-Driven, Iterative Development Process link

Although it may appear technical, the taxonomy development process is a primarily business-oriented exercise, where policy experts and data users play key roles. The final deliverable - an XBRL taxonomy - is a technical artefact which, in addition to business requirements, also meets technical needs.

Taxonomy development is not a one-off exercise, but an iterative process where the data model and, subsequently, the XBRL taxonomy undergoes modification resulting from small cycles of testing that validate conformance with XML and XBRL specifications and best practices. While formal requirements and modelling rules are stable components of the taxonomy process, the data model and taxonomy may undergo multiple modifications before they become final artefacts.

Timeline and Duration Factors for Taxonomy Development link

Developing a taxonomy is not a one-size-fits-all process. The timeline can range widely depending on several factors:

• Scope and complexity of the legal framework
• Extent of validation rules
• Opportunities for reuse of existing taxonomies
• The pace of development of local expertise
• Rigour of governance and review cycles

Each of these dimensions directly shapes how quickly an initial version can be finalised. On average, most projects take six to nine months, but the actual duration varies significantly with scope, alignment, and stakeholder processes.

Scope and Complexity of Legal Framework link

The time required for developing an initial taxonomy version depends fundamentally on the scope and complexity of the underlying legal framework that the taxonomy must represent. Policy requirements are typically drafted without considering their eventual translation into structured data models, which often results in additional time needed for clarification and addressing inconsistencies in concept definitions or contradictory requirements that emerge during data model development.

When the data model is developed in parallel with the completion of policy wording, the combined timeline for both tasks may be shorter compared to scenarios where the data model is developed as a subsequent step after policy establishment. This parallel approach enables iterative refinement where policy drafters can consider the implications of their requirements for structured reporting, while taxonomy developers can identify potential implementation challenges before policies become fixed.

The scope and complexity of the underlying framework materialises significantly in the number and complexity of data quality checks that must be converted to validation rules. Higher numbers of complex validation requirements require proportionally more time to implement and test properly, as each rule must be precisely specified, coded, and verified against various data scenarios.

Taxonomy Reuse Opportunities and Existing Standards link

A second factor that substantially impacts development duration is whether the underlying policy framework permits reuse of existing taxonomies or components. When policy frameworks align closely with already established taxonomies, reusing such taxonomies can significantly shorten the time required for developing the target taxonomy. This reuse might involve adopting entire sections of the taxonomy, adapting existing concepts to local requirements, or using established patterns for structuring similar types of information.

The degree of alignment between local requirements and international standards affects both the extent of possible reuse and the complexity of any necessary adaptations. Frameworks that closely follow international standards such as IFRS or Basel requirements can leverage substantial existing work, while highly jurisdiction-specific requirements may require more original development effort.

Knowledge Transfer and Local Expertise Development link

The third critical factor involves knowledge transfer and the development of local expertise. Even when external experts with multiple years of taxonomy development experience are engaged, the time required for developing the target taxonomy depends significantly on how quickly local experts can learn the development process and take prompt decisions on data model and taxonomy development aspects raised by external consultants.

This learning requirement exists because external experts, despite their technical proficiency, lack complete knowledge and understanding of local reporting requirements, regulatory context, and institutional priorities. Local experts must therefore develop sufficient understanding of taxonomy development principles to make informed decisions about trade-offs, priorities, and implementation approaches that align with domestic regulatory objectives.

Governance and Review Processes link

The number of governance review rounds significantly affects development timelines, with multiple internal, external, and stakeholder review cycles extending the finalisation process. Each review round typically involves collecting feedback, analysing suggested changes, making necessary modifications, and providing new version of the taxonomy for subsequent review. The complexity of this process increases when multiple stakeholder groups have different priorities or when review cycles reveal fundamental issues that require substantial revisions.

Effective governance structures can accelerate this process by establishing clear decision-making authorities, defining specific review criteria, and creating mechanisms for resolving conflicts between different stakeholder requirements. However, thorough review processes remain essential for ensuring that taxonomies meet their intended purposes and gain necessary stakeholder acceptance.

Typical Development Timeframes link

Typically, developing an initial taxonomy version requires six to nine months, though this timeframe can vary significantly based on the factors described above. Simple taxonomies that reuse substantial existing components and address straightforward policy requirements may be completed more quickly, while complex frameworks addressing novel regulatory requirements with extensive validation rules may require longer development periods.

This period refers solely to the first version of the public taxonomy and does not include the time required for developing a technological platform for generating XBRL reports, validation, and collection. It neither covers conducting pilot tests with stakeholders which are conducted once taxonomy is publicly available.

Summary link

The taxonomy development process represents a systematic approach to creating structured digital reporting frameworks that serve both regulatory objectives and practical implementation needs. This comprehensive process transforms policy requirements into functional XBRL taxonomies through five distinct yet interconnected phases, each building upon the previous stage to ensure both technical compliance and business utility.

Throughout this process, taxonomy development remains fundamentally a business-driven exercise where policy specialists and data users play central roles. The iterative nature of development ensures that both business requirements and technical constraints are addressed through successive refinement cycles. Success depends not only on technical correctness but also on how well the final taxonomy serves the practical needs of preparers while supporting the analytical objectives of data collectors and policy makers.

The systematic approach outlined in this process overview provides regulatory representatives with a framework for managing complex taxonomy development projects effectively. By understanding each phase and its contribution to the overall objective, regulators can provide appropriate oversight while ensuring that their digital reporting programmes achieve their intended policy goals efficiently and sustainably.