Corresponding to XBRL 2.1 Recommendation 2003 12 31 with Corrected Errata 2005-04-25
is the NORMATIVE version of this document. All other versions and publication formats are non-normative.
Standard Advantage /
Consultant to PricewaterhouseCoopers
This document describes the architectureof financial reporting taxonomies using the eXtensible Business Reporting Language . The recommended architecture establishes rules and conventions that assist in comprehension, usage and performance among different financial reporting taxonomies. “Financial reporting” encompasses disclosures derived from authoritative financial reporting standards and/or applicable generally accepted accounting practice/principles, regulatory reports whose subject matter is primarily financial position and performance including related explanatory disclosures, and data sets used in the collection of financial statistics; it excludes transaction- or journal-level reporting, reports that primarily consist of narrative (for example, internal controls assessments) and non-financial quantitative reports (for example, air pollution measurements). This document assumes use of the XBRL 2.1 Specification.
This is a Recommendation whose circulation is unrestricted The XBRL International Steering Committee approved this for publication on 2005-04-25. Recipients of this document are invited to submit to the editor their questions and comments, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of Contents
Table of Contents 2
Table of Tables 2
Table of Figures 2
Table of Examples 2
1.1An extension must not modify the meaning of concepts in the base. 55
Table of Tables
Table of Figures
Table of Examples
XBRL International specifies this architecture to enhance consistency among the XBRL taxonomies used for financial reporting. An important design goal for financial reporting taxonomies is to maximise the usability of the taxonomy to the non-technical (from a computer science perspective) users and experts of the reporting domain, while not compromising the ability of the taxonomy to describe reporting requirements and possibilities in an accurate and XBRL-compliant manner. Where these goals conflict, the architecture is biased in favour of comprehensibility over implementation ease for software designed to support the architecture. The financial reporting taxonomy architecture addresses several areas of consistency:
Representation: Taxonomies should use similar XBRL structures to represent similar relationships among concepts. For example, financial reporting concepts that are measured the same, aggregated the same, and disclosed the same are represented using the same shared XBRL element. Distinctions such as period, entity, or units that are meant to be captured using XBRL contexts are not reflected in the taxonomy itself. The different levels of equivalency allowed within the architecture are a critical aspect of its design.
Modularity: Taxonomies should have a common approach to grouping taxonomy content at a file level. For example, language-specific labels and references are placed in separate linkbase files; jurisdiction-specific references are placed in separate linkbase files; sets of logically related elements that are unlikely to change separately are placed in the same schema files.
Evolution: Taxonomies built to the architecture set out in this document can be extended or revised using similar approaches.
Consistency among financial reporting taxonomies is important because lack of consistency may lead to additional effort being required to consume, use, compare and extend financial facts reported using these taxonomies.
Taxonomies are meant to be long-lived and broadly used across a business reporting supply-chain. In practice this means they are developed in collaboration among several parties. In recognition of this, the needs of those reviewing and maintaining the financial reporting taxonomies have also influenced this document.
Scope of the architecture
In this document, “financial reporting” encompasses authoritative financial reporting standards and financial reporting best practices (or GAAP), regulatory reports whose subject matter is primarily financial position and performance including related explanatory disclosures, and data sets used in the collection of financial statistics; it excludes transaction- or journal-level reporting, primarily narrative reports (for example, internal controls assessments) and non-financial quantitative reports (for example, air pollution measurements).
This architecture is NOT itself a set of financial reporting standards. For example, FAS and IFRS are financial reporting standards. FRTA—the Financial Reporting Taxonomy Architecture—provides the means by which disclosures made pursuant to those financial reporting standards, GAAP, and so forth can be captured using XBRL. This architecture improves the consistency with which such standards are expressed in the XBRL financial reports that are based on them. The architecture does NOT require that preparers of XBRL instances disclose any more information than they currently do in a non-XBRL environment.
This financial reporting taxonomy architecture assumes XBRL 2.1 . Parts of this document reiterate for expository clarity certain syntactic and semantic restrictions imposed by the XBRL Specification, but this document does not modify the XBRL Specification. In the event of any conflicts between this document and the XBRL 2.1 Specification, the XBRL 2.1 Specification prevails. This document does place additional restrictions above and beyond those prescribed by the XBRL Specification. The purpose of these additional restrictions is to maximize XBRL instance comparability of external financial reports where a large number of extension taxonomies are expected.
The IFRS and USFR taxonomy frameworks will provide examples of this architecture once they have achieved Approved status . In the event of any conflict between this document and any current version of IFRS and USFR taxonomy frameworks, this document prevails.
Goals of this document
A financial reporting taxonomy or extension of the USFR or IFRS taxonomy that receives Approved status from XBRL International must conform to this architecture. This document is normative with respect to such taxonomies. The architecture must be used during XBRL International’s review of taxonomies that are candidates for Approved status . All parts of this document not explicitly identified as non-normative are normative.
This document should be used by taxonomydevelopers, that is, those who already have some familiarity with XBRL usage, syntax and semantics and who are contributing to or responsible for a financial reporting taxonomy, either with:
financial reporting domain expertise and previous exposure to XBRL technology, or
XBRL software expertise and previous exposure to financial reporting concepts.
Taxonomy developers wishing to create a company-specific extension taxonomy to support their financial statements using XBRL using custom concepts and relationships; and
Application developers who support development or use taxonomies that meet the requirements set out in this document.
No part of this architecture requires any aspect of a taxonomy to have an English translation. Any rule which depends on a feature present in English but not in another language, may be ignored for taxonomy content in that other language.
Organisation of this document
This document describes the architecture in layers from the bottom up. Overall, the architecture comprises:
a Concept layer describing rules governing XBRL representation structures such as elements, concepts, and links;
a Relationship layer describing rules of link usage and how relationships are captured using link types such as definition, calculation and presentation;
a Discoverable Taxonomy Set layer defining the rules of the organisation of individual files to form discoverable taxonomy sets; and
an Extensions layer dealing with rules by which taxonomy extensions are to be created and general principles governing modularity.
XBRL is implicitly a part of this architecture although much of what is covered in the XBRL Specification is not repeated in this document. XML Schema and XML Linking Language are also implicitly part of the architecture because they are building blocks for XBRL, however they are not covered explicitly in this document either.
Example . Layers of the FR taxonomy architecture.
Many taxonomy development errors result from a lack of understanding the consequences for XBRL instances; hence there are examples and discussion relating to instances even though that is not the focus of this document.
Terminology used in XBRL frequently overlaps with terminology from other fields.
Table . Terminology used in this document.
“The fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution. This definition may just as usefully be applied to technical architecture” [IEEE].
This document describes in the form of design rules the organization of financial reporting taxonomies embodied by schemas, linkbases, concepts, links, and other components, their relationships to each other and to financial reporting standards, and principles that justify the design rules both for base taxonomies and for the extensions that will inevitably follow.
Contrast this with the IEEE definition of Software Engineering: “A systematic approach to developing, using, maintaining and liquidating systems;” this document does not cover approaches to development, use, maintenance or liquidation of taxonomies.
abstract element, ancestor, base set, bind, child, concept, concrete element, context, duplicate items, duplicate tuples, element, entity, essence concept, fact, fully conforming, grandparent, instance, item, least common ancestor, linkbase, minimally conforming, parent, period, sibling, taxonomy, taxonomy schema, tuple, uncle, unit
As defined in XBRL 2.1 specification.
must, must not, required, shall, shall not, should, should not, may, optional
See for definitions of these and other terms. These include, in particular:
Conforming documents and consuming applications are required to behave as described; otherwise they are in error.
Discoverable Taxonomy Set As defined in XBRL 2.1 specification.
An extension DTS is a DTS that is a proper superset of a base DTS. Because an extension must be a proper superset, a DTS is not an extension of itself.
As defined by the XML Linking Language . XBRL linkbases are made up of extended-type links.
Financial Reporting Taxonomies Architecture: the set of rules described in this document.
FRTA compliant (FRTA-compliant)
An element, attribute, linkbase, schema or DTS satisfying all applicable mandatory (“must”) rules in this document. Any of such artefacts that violates or ignores a recommended (“should”) rule is inferior to one that obeys it and should not be emulated.
Generally Accepted Accounting Practice/Principles: Term used to describe broadly the body of principles that governs the accounting for financial transactions underlying the preparation of a set of financial statements. Generally accepted principles are derived from a variety of sources, including promulgations of accounting standards boards, together with the general body of accounting literature consisting of textbooks, articles, papers, common practices, etc.
Link Role Registry. An online listing of XLink role and arc role attribute values that MAY appear in XBRL International acknowledged and approved taxonomies, along with structured information about their purpose, usage, and any intended impact on XBRL instance validation .
An XBRL International recommendation that depends on XBRL and defines the syntax and semantics of additional elements, attributes, roles or arc roles that cannot be defined entirely within an XBRL valid taxonomy.
Persisting DTS (persisting extension)
A DTS whose purpose is to be stored as files to be referenced by instances of multiple entities and published in some fashion for users to examine. This contrasts with a DTS that is ephemeral—for example, dynamically created while processing instances, only to be discarded.
The source of an arc is the element indicated by the “from” attribute.
The target of an arc is the element indicated by the “to” attribute.
This is non normative; see the Taxonomy Recognition Process :
Acknowledged: XBRL International recognizes that the taxonomy is technically in compliance with all appropriate specifications.
Approved: In addition to being Acknowledged, XBRL International warrants that the taxonomy was developed in an open fashion and it complies with all best practices for compatibility.
Recommended: In addition to being approved, XBRL International singles out a Recommended taxonomy as being the one preferred for a given type of reporting. Financial reporting taxonomies are not expected to achieve this status from XBRL International since it is not the custodian of the financial reporting standards themselves.
A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous revisions of individual files, and to compare any two revisions to view the changes between them.
XBRL 2.1 Recommendation, with corrected errata to 2005-04-25 .
XML instances and schemas that satisfy the syntax requirements of XBRL.
The following highlighting is used for non-normative examples in this document:
The following highlighting is used for non-normative counterexamples in this document:
Non-normative editorial comments are denoted as follows and removed from final recommendations:
WcH: This highlighting indicates editorial comments about the current draft, prefixed by the editor’s initials.
Italics are used for rhetorical emphasis only and do not convey any special normative meaning.
Figure illustrates drawing conventions followed in figures showing taxonomy fragments and taxonomies.
Figure . Legend of drawing conventions for taxonomy fragments.
Figure . Legend of taxonomy schema and Linkbase drawing conventions.
The following table summarizes the notation used in the diagrams of this document.
Table . Drawing notations in this document.
A “from-to” arc from a source element (end of line with no arrow), to a target element (end of line with arrow).