European XBRL Taxonomy Architecture
From XBRLWiki
Revision as of 05:56, 12 October 2012 (edit) Hommes (Talk | contribs) ← Previous diff |
Revision as of 05:57, 12 October 2012 (edit) Hommes (Talk | contribs) (→Terms and definitions) Next diff → |
||
Line 72: | Line 72: | ||
<span style="background-color:yellow">[[Talk:European_XBRL_Taxonomy_Architecture|Comment-02]]</span> | <span style="background-color:yellow">[[Talk:European_XBRL_Taxonomy_Architecture|Comment-02]]</span> | ||
- | <span style="background-color:yellow">RH: Public elements are just XBRL concepts, why not use that term? Moreover, IMO the MUST contain labels and definitions. How else are you going to interpret them? I advise not to hard link all the different languages. Too much overhead if you want Spanish only.</span> | + | <span style="background-color:yellow">[[Talk:European_XBRL_Taxonomy_Architecture|Comment-03]]</span> |
== Symbols and abbreviations == | == Symbols and abbreviations == |
Revision as of 05:57, 12 October 2012
Contents |
Forword
Introduction
These pages are hosting the guidelines to an European XBRL Taxonomy Architecture. (EXTA, for short)
- European; because this project is funded by the EU commission, but there is no restriction in applying it anywhere else;
- XBRL; because that is the syntax standard that has been chosen to be used in electronic information exchange between national banking supervisors and the European authorities;
- Taxonomy architecture, because creation of different 'dictionaries' or 'reporting frameworks' in XBRL have such a wide variety of options it would cause incompatability between the different XBRL taxonomies which would lead to increased implementation costs for all adopters in the EU market.
Objective
The objective of the EXTA is to create an XBRL taxonomy that is:
- Consistent and predictable;
- (Automated) controllable;
- Modular, which enables lean extensions and ease of maintenance;
- Following international best practices;
Target audience
EXTA is targetted at taxonomy authors. Initially organisations like EBA, EIOPA, ESMA, ECB etcetera. As a spin-off of these taxonomies, local (national) initiatives will emerge, hosted by National Supervisory Agencies (NSA's). To meet local legislation the European taxonomies may have to be extended with local requirements. The EXTA is also aimed at supporting these national extensions according to the same guiding principles. The main advantage being a consistent framework of XBRL taxonomies which enables a cost efficient implementation in software solutions.
Consistent taxonomies throughout Europe also creates the opportunity for cross-EU harmonisation of terminology and, in a later stage, consistent reported facts that are more easily analyzed since the underlying structure is the same and terms used are complementary to each other.
A consequence of a consistent taxonomy framework is that software developers can choose to support only the architectural guidelines of EXTA. Although this limits their software in supporting full fledged XBRL taxonomies it eases implementation costs.
Relationship to other work
The reader of this EXTA is expected to be familiar with the basic principles of data modelling and have a thorough understanding of the XBRL family of specifications to evaluate the impact of the rules set to the XBRL taxonomy that needs to be created.
Scope
From a semantic point of view, EXTA is aimed at European financial reporting frameworks. This involves (but not limits to) banks, insurance companies, pension funds, stock exchanges and investor vehicles that have an obligation to report their financial status to European supervisors.
From a syntax point of view, EXTA works with:
- XBRL 2.1
- XBRL for Dimensional Taxonomies (XDT) 1.0
- XBRL Generic Link 1.0
- XBRL Formula 1.0
- XBRL Versioning 1.0
- XBRL Table linkbase (not released yet)
The syntax standards documentation is freely available at | XBRL International
Approach
Designing any consistent architecture requires a methodology. For EU supervisors the Data Point Modelling (DPM) methodology has been chosen. This methodology relies on defining datapoints (facts) and support all of their aspects as dimensions. For an explanation of how to work with DPM, dedicated pages are provided in this Wiki at ...
As a consequence to EXTA the taxonomy will rely heavily on the use of dimensions and their members. Given the XBRL specification of how to express dimensions the taxonomy will have some 'exceptions' to support specific dimensional constructs. EXTA will also provide a number of naming conventions for the XBRL building blocks that are needed to construct the taxonomy.
There will be multiple taxonomies from multiple EU agencies based on multiple reporting frameworks. This means that modularity is important to prevent a complex structure with intensive maintenance tasks. It is recognized that there will be two major components to all of the taxonomies: the more or less 'fixed' part compromised of all the detailed building blocks like concepts, types and their labels, and the 'flexible' part that is formed by the reporting requirements of a single table, form or report. It is expected that both parts can be extended but that the frequency in which modifications will have to be made lies mostly in the 'flexible' part.
The 'fixed' part of the building blocks is known as the dictionary layer, the 'flexible' part as the framework.
Normative references
Terms and definitions
Term | Definition | Explanation |
---|---|---|
Owner | The owner represents an European institution that defines concepts in the data point model. | The owner is the top level of everything that is defined in the taxonomy. It is represented by a schema in which a number of characteristics of an owner are stored. |
Public elements | Public elements are XBRL concepts in the data point model. | They are identified by a code in a certain scope. They MAY include additional information such as readable labels, definitions and legal references in different languages. |
Symbols and abbreviations
Rules
Localisation, extensibility
There are two areas that are commonly understood as part of a 'localisation' of the taxonomy. In some cases this refers to enabling the taxonomy to operate in a certain language area and in other cases the term is referring to the enabling of the taxonomy to support local legal requirements. The term 'local' is often understood as geographical based but it can also be industry specific or represent any other grouping of businesses involved in the reporting domain.
Language
If there is a need to have a representation of taxonomy content for a certain language, XBRL offers the option of extending the taxonomy with extra labels in the language preferred. This can be done by anybody with the proper knowledge of the taxonomy content and the preferred language. In the European Union all member state language belong to the 'official' languages of the EU. It is up to the EU agency to provide the necessary languages with their taxonomy. By providing the different languages in separate files (linkbases) and NOT linking them directly into the taxonomy, any regulator can create an extension calling only the required languages and save on the size of the taxonomy being discovered by the XBRL enabled software.
Legal and other requirements
Local NSA's may create extra tables or extend existing tables with columns/rows that are needed to abide local legal regulations. For reporters that create reports in multiple countries it eases the reporting burden when these extensions to the base taxonomy are created in a similar way (from a technical perspective). The scenarios that allow for extensions are:
- adding rows/columns to existing tables
- adding new tables
- dividing existing cells