1 Introduction
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.
1.1 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.
1.2 Relationship to other work
This financial reporting taxonomy architecture assumes XBRL 2.1 [XBRL]. 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 [IFRS] [USFR] will provide examples of this architecture once they have achieved Approved status [TRP]. In the event of any conflict between this document and any current version of IFRS and USFR taxonomy frameworks, this document prevails.
1.3 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 [TRP]. All parts of this document not explicitly identified as non-normative are normative.
This document should be used by taxonomy developers, 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.
This document may also be useful to:
1. Taxonomy developers creating a financial reporting taxonomy who wishes to follow a broadly used set of practices;
2. Taxonomy developers wishing to create a company-specific extension taxonomy to support their financial statements using XBRL using custom concepts and relationships; and
3. 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.
1.4 Organisation of this document
This document describes the architecture in layers from the bottom up. Overall, the architecture comprises:
1. a Concept layer describing rules governing XBRL representation structures such as elements, concepts, and links;
2. a Relationship layer describing rules of link usage and how relationships are captured using link types such as definition, calculation and presentation;
3. a Discoverable Taxonomy Set layer defining the rules of the organisation of individual files to form discoverable taxonomy sets; and
4. 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 1. 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.
1.5 Terminology and document conventions
Terminology used in XBRL frequently overlaps with terminology from other fields.
Table 1. Terminology used in this document.
|
Architecture |
“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 [RFC2119] for definitions of these and other terms. These include, in particular:
|
||||
|
DTS |
Discoverable Taxonomy Set As defined in XBRL 2.1 specification. |
||||
|
base DTS extension DTS |
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. |
||||
|
extended-type link |
As defined by the XML Linking Language [XLINK]. XBRL linkbases are made up of extended-type links. |
||||
|
FRTA |
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. |
||||
|
GAAP |
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. [LLLL] |
||||
|
LRR |
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 [LRR]. |
||||
|
Module |
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. |
||||
|
source |
The source of an arc is the element indicated by the “from” attribute. |
||||
|
target |
The target of an arc is the element indicated by the “to” attribute. |
||||
|
Taxonomy status:
|
This is non‑normative; see the Taxonomy Recognition Process [TRP]: 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. |
||||
|
version control |
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 |
XBRL 2.1 Recommendation, with corrected errata to 2005-04-25 [XBRL]. |
||||
|
XBRL valid |
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 1 illustrates drawing conventions followed in figures showing taxonomy fragments and taxonomies.
Figure 1. Legend of drawing conventions for taxonomy fragments.
|
|
Figure 2. Legend of taxonomy schema and Linkbase drawing conventions.
The following table summarizes the notation used in the diagrams of this document.
Table 2. 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). |
|
|
A concept element |
|
|
An extended-type link element |
|
|
Taxonomy schema |
|
|
Linkbase |
|
|
Discoverable taxonomy set |
|
summation-item |
summation-item arc role |
|
weight = +1 |
Weight of 1 relative to parent (on summation-item arc) |
|
parent-child |
parent-child arc role |
|
essence-alias |
essence-alias arc role |
|
documentation |
documentation role |
|
terseLabel |
Label link, terse role |
|
lang = en |
xml:lang attribute value “en” |
|
… |
Abbreviation for http://www.xbrl.org/2003 |
|
…/role/this |
xlink:role attribute value “http://www.xbrl.org/2003/role/this” |
|
…/arcrole/that |
xlink:arcrole attribute value “http://www.xbrl.org/2003/arcrole/that” |
2 Concept Layer
In a syntactic sense, a concept is an XML Schema element definition, defining the element to be in the item element substitution group or in the tuple element substitution group. At a semantic level, a concept is a definition of kind of fact that can be reported about the activities or nature of a business entity. Taxonomies contain XBRL concepts represented by XML Schema element definitions. Concepts are meant to represent a type of fact, that is, data. The presentation of the concept in any given situation is described by other XBRL constructs, and that distinction between data and presentation is fundamental to XBRL.
2.1 Rules for all concepts
The rules covering concepts apply to items and to tuples.
Abstract concepts are concepts (elements in the item or tuple substitution group) having their XML Schema abstract attribute equal to true. Abstract concepts cannot be used in XBRL instances. Their role is limited to organisation (grouping) of other concepts defined in taxonomies. All rules applying to concepts apply also to abstract concepts unless otherwise indicated.
2.1.1 A taxonomy schema must define only one concept for each separately defined class of facts.
Having one concept per definition of how a class of facts is to be measured simplifies applications that must extract, compare and combine information from XBRL instances. Two facts fall into the same “class” in this sense if for any context the two values would always be the same in an instance. For example, “Cash Balance in Bank” would, theoretically, have only one element to express this concept, and XBRL instances would use different contexts to report the value for this element for different periods, different entities, etc. Similarly, concepts that have multiple uses within financial reporting (for example, in primary financial statements and in explanatory notes to financial statements) must be defined only once.
The uniqueness requirement only applies to sets of concepts defined within a single taxonomy schema and does not extend to discoverable taxonomy sets. Where duplicate concepts are identified, taxonomy authors should recognise such equivalencies using essence-alias relationships in definition extended-type links. For rules governing these relationships see chapter 4, “Discoverable taxonomy set layer” and chapter 5, “Taxonomy Extensions”.
The equivalency of two concepts must be assessed at the semantic level, by comparing the set of possible values that are valid to report using the syntax for those concepts. This requires a comparison of the labels, references and inter-concept relationships associated with the two concepts in the linkbases.
Example 2. Identical concepts.
|
Concept |
Concept |
Explanation |
|
Net Profit |
Net Loss |
These are not distinct concepts because an entity cannot have both a profit and loss in the same period. Concepts such as NetProfit and NetLoss are redundant and should be represented a single element such as NetProfitLoss. |
Example 3. Distinct concepts.
|
Concept |
Related but distinct concept |
Explanation |
|
Cash Balance |
Change in Cash Balance |
The first concept is the amount of cash at a specific instant; the other is the change in the cash balance between one instant and another. |
|
Revenue |
Change in Revenue Ratio |
The first concept is the amount of revenue over a period of time, and the other is the change in revenue between one period of time to another period of time expressed as a ratio. |
|
Inventory (measured using the LIFO or FIFO method) |
LIFO Inventory |
The 2nd concept is measured using the LIFO method only. |
|
FIFO Inventory |
The 2nd concept is measured using the FIFO method only. |
|
|
Inventory Measurement Policy |
Text describing how the inventory is measured. |
|
|
Trade Receivables, Net |
Trade Receivables, Gross |
These concepts are different because they are calculated differently; one nets out “Allowances for Bad Debts” and the other does not. |
|
Deferred Tax Assets |
Deferred Tax Liabilities |
These concepts are distinct because they are disclosed separately; that is, unlike net income which can only be a profit or loss, an entity may have both deferred tax assets and liabilities that do not offset. |
Equivalence of concepts is affected by four factors affecting the set of valid values for a concept: measurement, aggregation, materiality, and disclosure. These are discussed below and should be taken into account when determining whether two concepts are duplicates. Naturally, concepts should be examined on a case-by-case basis to determine appropriate modelling in the specific situation.
2.1.1.1 Measurement
Concepts that are measured differently MAY be represented by a single concept if that concept has a broad enough definition provided by its labels and references and by its calculation and definition extended-type link relationships to other concepts.
For example, LIFO and FIFO inventory both value inventory, but are measured differently. An inventory concept that allowed both measurement approaches could validly be defined to contain inventory facts measured using either approach.
In contrast an inventory concept that only allowed measurement using one approach should not be used to contain inventory facts measured using the other approach.
2.1.1.2 Aggregation
Concepts that are aggregated or calculated the same way MAY be equivalent and represented by a single concept.
Concepts MAY also be considered equivalent even if their values are calculated slightly differently, so long as their underlying definitions permit both kinds of calculations. However, in general, the calculation relationships describing how the values for one concept can be derived from the values of others provide a good guide to concept equivalencies: if they are calculated differently they are probably distinct.
Aggregation can also be a good guide to concept identification for non-numeric concepts. For example, notes can be provided as a single block of text or they can be provided as a series of separate facts whose text values can be combined to constitute the combined value of the non-numeric concept with the broader, more aggregated definition.
For example, a concept could be defined to validly contain a comprehensive description of all accounting policies. Alternatively a set of concepts could be defined so that each can only validly contain text about a particular kind of accounting policy. Depending on the granularity of reporting that specific instances are intended to achieve, either the aggregated single concept or the disaggregated set of concepts could appear in an instance.
To allow different levels of granularity in reporting, taxonomies MAY define both the single concept and the set of concepts and MAY represent the associations between the aggregate concept and the disaggregated concepts using presentation extended-type link parent-child relationships.
2.1.1.3 Materiality
Materiality guidelines generally call for disaggregating reported items down to some relative materiality, which differs from entity to entity depending on factors such as management discretion. For example, “Cash” under some standards includes postage stamps and under others do not, but it is unlikely in the general case that the total “Cash” amount disclosed would be materially different; hence these MAY be modelled as the same concept in an XBRL taxonomy so long as the underlying definition of the concept accommodates both approaches to measurement.
2.1.1.4 Disclosure
Reporting standards frequently mandate qualitative disclosures that nevertheless do not warrant separate XBRL items. For example, an “Inventory” monetary figure must be disclosed, but it may be neither necessary nor desirable to have different inventory items to distinguish every possible distinction (for example, perishable vs. durable). Such disclosures can be made in a text description provided with a separate concept.
XBRL does not provide an extended-type link relation between the numeric item and the non-numeric item that provides textual detail. The distinctions that can be captured in the disclosure description (text) concept must not be part of the concept definitions determining valid values for the concept whose disclosure is being described in additional detail. Returning to the Inventory example above, define either (a) an Inventory item and an Inventory Policy item, or (b) a LIFO Inventory and FIFO Inventory item, but not both (a) and (b).
2.1.2 Contextual and measurement information in XBRL instances must not result in different elements in a taxonomy.
For example, a concept definition must not specify that the concept is only to be used for facts about company XYZ or for facts that are true as at the end of a financial year.
XBRL instances contain facts that are instances of concepts. Facts can contain content values that should meet the semantic requirements associated with the concepts that they are instances of. Besides the value of a fact, such as “the value of cash is 500,000”, the XBRL instance provides contextual information necessary to correctly interpret each fact. This context includes:
· the entity that the value of the fact describes;
· a period for which or over which the fact is true; and
· the scenario under which the value of the fact has been measured.
Because only facts have a period associated with them, there is no such thing as “the period over which a concept applies.” Hence (for example) “cash,” “cash at the beginning of a period,” and “cash at the end of a period” are not distinct concepts. There is only one concept in this case: cash, and it is measured at an instant.
For numeric facts, XBRL instances also provide information relating to measurement accuracy and measurement units.
2.1.3 Concepts’ meanings must not depend on their position within an instance.
A single item or tuple can appear within many different tuples because all items and tuples are defined globally. For example, the item Residuals may appear within different tuples only if it has the same meaning in both places. Therefore, if one tuple relates to payments received for each rerun after an initial showing of a TV show, while another tuple relates to the value of oil not yet extracted from beneath leased property, two different items (for example, TelevisionResiduals and OilResiduals) should be defined.
An additional reason to distinguish between TelevisionResiduals and OilResiduals in this example is that the distinction is useful should the Oil and Television tuples happen to be siblings in an instance. If both concepts had been represented by the same element (Residuals), then it would not be possible to define a calculation for the value of TotalOilResiduals as the sum of all Residuals. The interaction between calculation arcs and tuples is discussed further in section 3.3.4 below.
2.1.4 Concept names should adhere to the LC3 convention.
LC3 means Label CamelCase Concatenation (LC3). LC3 rules require that:
1. Element names must be based on an appropriate presentation label for the element. A label should be a natural language expression that is meaningful to experts in the domain covered by a taxonomy (for example, “Revaluo Propio”, “Restatement of Fixed Assets”), for a given item.
2. If multiple labels exist for a concept, then any one of those labels MAY be used as the basis for construction of the element name. Furthermore, if the element name is originally based on a label and in a subsequent version of the taxonomy the label changes, the element name must not be changed merely to maintain agreement.
3. The first character of the element name must not be underscore (_); this leaves only letters (as defined in XML) as valid first characters.