Taxonomy Approval Metrics and Process

This public exposure version was available for comment until April 5, 2018.
Return to XBRL US Taxonomy Approval Metrics and Process

The Taxonomy Approval Metrics (TAM) document establishes standards for the development of XBRL taxonomies and supporting materials, from the perspective of systems development. This set of standardized metrics will serve as an integral part of the XBRL US Taxonomy Approval Process to determine taxonomies that will be certified to produce consistent, good quality XBRL data that is easy to use, accessible, and consistent.

XBRL US members are also encouraged to participate in the work of the Domain Steering Committee which is tasked with creating the Taxonomy Development Toolkit, consisting of the Taxonomy Approval Metrics (in public review), the XBRL US Style Guide (completed), and the Taxonomy Guide (in development). To learn more, email info@xbrl.us.

Table of Contents

Scope

Purpose

XBRL US/DSC Goals

RFC-2119 Conformance

Governance

Process

TAM Approval Document

TAM Approval Document

1. Taxonomy Metrics
   1. Requirements Addressed
   2. Shared Data Elements
   3. Interfacing
   4. Open or Closed Architecture
   5. Instance Only
2. Support Requirements
   1. Published Documentation
   2. Implementation Procedures
   3. Revision Procedures
   4. Tools
3. General XBRL Requirements
   1. XBRL Specifications
   2. Data Architecture
   3. Data Types and Units
   4. Concepts/Elements
   5. Data (Facts)
   6. Labels and Label Roles
   7. Presentations
   8. Mathematical Relationships
   9. Normalization
4. XBRL Conformance Requirements
   1. Taxonomy Architecture
   2. Valid Instances
   3. XBRL US Conformance Tests
   4. XBRL US Style Guide

Purpose

The Taxonomy Approval Metrics (TAM) document establishes standards for XBRL taxonomy review and approval by the XBRL US Domain Steering Committee (DSC). For this document, the term “Taxonomy” will refer to not only the XBRL taxonomy but also the supporting materials. “Developer” refers to the author(s) of the Taxonomy.

XBRL US/DSC Goals

• To enable a meaningful exchange of information between two different business systems.
• To avoid confusion and difficulties in initial setup of systems for the preparation and consumption of XBRL-based information.
• To provide Developers with a clear understanding of the expectations of the requirements of the Domain Steering Committee (DSC) Taxonomy Approval Process.

RFC-2119 Conformance

Normative requirements will contain capitalized keywords. MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in IETF RFC 2119.

Governance

This document is maintained by the DSC. Comments and requests for changes should be directed to info@xbrl.us.
Authors:

Contributors:

Process

As new taxonomies are developed, either by XBRL US or other entities, the DSC can be employed to review proposed taxonomies and be a platform to increase quality and uniformity. The following puts forward an overview of the approval process:

• A taxonomy is proposed and one or more working groups are established for purpose of exploring taxonomy development.
• If XBRL US is involved in the development, the DSC will be notified of the undertaking. Third parties are welcomed to notify the DSC.
• XBRL US/DSC will provide supporting specifications and information as requested including the TAM.
• Developers can use those documents to aid in creating the taxonomy and supporting materials.
• As drafts are available, Developers can provide those documents to the DSC.
• The DSC will perform a review and return comments when requested throughout the process or at the end of the review.
• After any deficiencies have been resolved, the DSC will vote on the approval document, and if desired, the approval document will be published.

TAM Approval Document

Each taxonomy MUST be reviewed according to the specified metrics. Within the approval document, each metric SHOULD be listed along with conformance notes that MUST contain the following:

• One or more references to a specific document or sections within the support documentation that satisfies the requirement.
• Exception and rational if a requirement has not been met or is met in an unconventional manner.
• Conclusion as “Satisfies Requirement” or “Deficient” with an explanation.

For example:

3.1.1 The Taxonomy MUST conform to existing XBRL Specifications published by XBRL International and XBRL US.

WIP-PG, Section 1, Goals (Based on XBRL US GAAP Taxonomies v1.0 Preparer’s Guide), page 1.

Observed the taxonomy opens with no errors in Altova and Arelle.

Conclusion: Satisfies requirement.

As necessary, the document SHOULD contain reference documents and software test results.

Part B – Taxonomy Metrics

1. The Taxonomy Describes the Disclosed Data Architecture / Semantics
   1. Requirements Addressed
      1. Business requirements MUST be adequately and clearly described.
      2. Existing system(s), if any, SHOULD be described adequately and the differences between the proposed Taxonomy and existing system(s) enumerated.
      3. All stakeholders MUST be properly identified and aligned.
      4. Key stakeholder groups MUST be identified as participants in development.
      5. Developer SHOULD enumerate methods in which the Taxonomy exchanges information more efficiently than existing or alternative approaches.
      6. Developer SHOULD summarize ‘Actors and Processes’ of the above requirements.
   2. Shared Data Elements
      1. The Taxonomy MUST define a domain or business Semantic Data Model for the exchange of information including inputs, outputs and data views.
      2. Importable taxonomies and shared data elements MUST be identified.
      3. The characteristics of each data element MUST be defined.
      4. Private/Confidential aspects of the data model MUST be addressed.
   3. Interfacing
      1. Developer SHOULD define the typical source data elements and locations and addresses options for data extraction.
      2. Developer SHOULD define one or more rudimentary methods of viewing or presenting information in a meaningful way for preparers and consumers.
      3. Developer SHOULD address the level of burden to preparers and consumers on an initial and ongoing basis.
   4. Open or Closed Architecture
      1. The Taxonomy MUST be described as either “open” or “closed”.
      2. If open, Developer MUST describe the extent and manner preparers can extend the taxonomy, including details of the types of extensions (concepts, dimensions, units, etc.).
      3. If open, Developer SHOULD define what steps, if any, are required to normalize data.
      4. If closed, Developer SHOULD describe the methods allowed by the Taxonomy to footnote or provide additional information.
      5. Developer MUST define whether XBRL footnotes may be employed and in what manner.
   5. Instance Only
      1. Developer defines whether data within the Taxonomy can be consumed using only an instance document.
2. Support Requirements
   1. Published Documentation
      1. The Taxonomy MUST include an Overview Document describing the overall application, justification and approach to the development of the Taxonomy, definitions of concepts within the Taxonomy and required and optional Taxonomy data. The document SHOULD also outline revision mechanics and governing bodies.
      2. The Taxonomy MUST include a Preparer’s Guide to aid in the proper assembly and structure of XBRL instance data and associated linkbases.
      3. The Taxonomy MUST include an Implementation Guide to aid system developers in the exportation and importation of instance data components and linkbases.
   2. Implementation Procedures
      1. Developer MUST provide internal documentation for the management of the implementation of the Taxonomy.
      2. Developer MUST discuss the method of implementation, impediments to implementation and major implementation milestones.
      3. Developer MUST include a plan for the operation of governing bodies.
      4. Developer MUST define related third parties that may be required or relied upon for implementation.
   3. Revision Procedures
      1. Developer MUST provide internal documentation for the methods and procedures pertaining to revising the Taxonomy and its supporting documentation.
      2. Developer SHOULD create public revision procedures that SHOULD include review and comment periods.
   4. Tools
      1. Developer MUST discuss tools for preparers, such as for validation and accuracy.
      2. Developer MUST discuss whether tools will be provided for consumers.
      3. Developer MUST provide at least two sample instance documents.
3. General XBRL Requirements
   1. XBRL Specifications
      1. The Taxonomy MUST conform to existing XBRL Specifications published by XBRL International and XBRL US.
      2. Developer MUST specify any other standards or groups relied upon to create and maintain the Taxonomy.
   2. Data Architecture
      1. Developer MUST describe the overall data architecture, including graphics, as required, to illustrate hierarchical and domain relationships.
      2. Developer MUST describe any required parent-child relationships.
      3. For repetitive submissions, Developer MUST describe whether various data elements will be reiterated for previous filings and, if so, why. If reiteration is allowed, Developer MUST describe a policy for differences from submission to submission.
   3. Data Types and Units
      1. The Taxonomy SHOULD employ the most restrictive data types for common values. For example, if a concept can only have non-negative values (regardless of dimensionality), a non-negative data type SHOULD be employed.
      2. If custom data types or unit types are required for the Taxonomy, the unit type(s) to be used SHOULD be specified and a request SHOULD be made to add the custom type(s) to the appropriate XBRL registry.
      3. The Taxonomy MUST express which units are allowed or declare an appropriate Unit Type Registry (UTR), such as XBRL International’s UTR, and whether extension units can be used by preparers. Any identified extension units SHOULD be added to XBRL International’s UTR.
      4. The Taxonomy MUST express how scaled units SHOULD be used, if at all.
   4. Concepts/Elements
      1. The naming of elements MUST conform to XBRL requirements.
      2. The naming of elements MUST be consistent and clear to avoid overlapping names, excessively terse or verbose names, or ambiguous names and comply with XBRL US Style Guide.
      3. Elements MUST be specified for context and dimensional requirements restrictions.
      4. The Taxonomy MUST define: (i) required and optional concepts; (ii) mutually dependent concepts; and, (iii) mutually exclusive concepts.
      5. If Taxonomy extensions are allowed, Developer MUST specify guidelines, rules and the scope for creating extensions.
      6. Each concept’s properties MUST be defined to include: (i) the period/context type (relationship in time); and, (ii) any extra information such as balance types, if applicable. These SHOULD be in conformance with the Balance Type and Period Type Guide.
   5. Data (Facts)
      1. Each concept MUST use a defined data type included in the Taxonomy.
      2. Each numeric concept/fact SHOULD use a standard Unit Type from the XBRL International UTR. If a non-standard unit is necessary, the Taxonomy SHOULD clearly express the reasoning for the use of such a unit.
      3. Each concept SHOULD exist within the presentation or mathematical relationships of the Taxonomy.
   6. Labels and Label Roles
      1. The Taxonomy SHOULD only use XBRL International approved label roles.
      2. The Taxonomy MUST provide for each concept an associated label for each applicable label role.
      3. The Taxonomy MUST express whether extension concepts require documentation and what that documentation SHOULD express.
      4. The Taxonomy MUST express whether each label role must be unique within an instance and the reasoning behind that choice.
   7. Presentations
      1. The Taxonomy MUST define proper abstract usage and comply with the XBRL US Style Guide.
      2. All elements included in the Taxonomy SHOULD be represented in a presentation linkbase.
      3. Abstract items SHOULD be used to group elements together in logical groupings or headings.
      4. Developer MUST define the purpose and scope of default presentations and ad hoc presentations.
      5. Developer MUST define whether the concepts specified for use on a default presentation can also be used on other presentations for which the concept is not specified for use.
      6. The Taxonomy MUST define mandatory and optional presentations.
      7. The Taxonomy MUST define proper abstract usage.
      8. If extensions are allowed, the Taxonomy MUST require presentations to define relationships with other elements.
      9. The content generated from XBRL SHOULD match the existing system in structure and/or human readability.
   8. Mathematical Relationships
      1. The Taxonomy MUST express relationships between concepts as calculations or formulae as applicable.
   9. Normalization
      1. Developer MUST define whether normalization of data is required for consumption and, if so, to the extent practicable, the method of normalization.
      2. If normalization is required, Developer MUST address any potential issues.
4. XBRL Conformance Requirements
   1. Taxonomy Architecture
      1. The Taxonomy SHOULD comply with FRTA 1.0 guidance as published by XBRL International.
   2. Valid Instances
      1. Valid instance documents SHOULD be provided with the Taxonomy that demonstrate the use of all fields in the Taxonomy.
   3. XBRL US Conformance Tests
      1. The Taxonomy MUST comply with the XBRL US conformance tests [add links final].
   4. XBRL US Style Guide
      1. The Taxonomy MUST comply with the XBRL US Style Guide.

Topic -