European Filing Rules
From XBRLWiki
| Revision as of 14:57, 24 September 2012 (edit) Katrin (Talk | contribs) (→Instance syntax rules) ← Previous diff |
Revision as of 15:10, 24 September 2012 (edit) Katrin (Talk | contribs) (→Instance syntax rules) Next diff → |
||
| Line 103: | Line 103: | ||
| '''All xbrli:identifier elements in an instance must have identical content.''' | '''All xbrli:identifier elements in an instance must have identical content.''' | ||
| - | <span style="background-color:#A9D0F5">SSome explanatory text.</span> | + | <span style="background-color:#A9D0F5">Some explanatory text.</span> |
| '''Only the xbrli:scenario element shall appear in any xbrli:context.''' | '''Only the xbrli:scenario element shall appear in any xbrli:context.''' | ||
| As scenario and segment elements are treated as mutually exclusive so the use of both of them is prohibited. | As scenario and segment elements are treated as mutually exclusive so the use of both of them is prohibited. | ||
| - | |||
| - | '''An instance must not contain duplicate xbrli:context elements.''' | ||
| - | |||
| - | An instance must not contain equivalent xbrli:context elements. xbrli:segment or xbrli:scenario elements are tested for equality of their children without regard to order. Contexts are defined to be equivalent if they have S-equal identifiers, equal dateUnion values for startDate, endDate and instant (respectively), and segment or scenario element children with equal QNames for each explicit dimension (either segment or scenario element is disallowed by another rule). | ||
| - | |||
| - | Even though there is no limitation on the length of an id attribute it is recommended to keep it as short as possible. Id attributes should also be abstract and should not contain any semantic meaning. | ||
| '''Every xbrli:context element must appear in at least one contextRef attribute in the same instance.''' | '''Every xbrli:context element must appear in at least one contextRef attribute in the same instance.''' | ||
| Line 127: | Line 121: | ||
| Element xbrli:xbrl must not have equivalent child xbrli:unit elements. Units are equivalent if they have equivalent measures or equivalent numerator and denominator. Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators are equivalent if they have a set of equivalent measures. | Element xbrli:xbrl must not have equivalent child xbrli:unit elements. Units are equivalent if they have equivalent measures or equivalent numerator and denominator. Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators are equivalent if they have a set of equivalent measures. | ||
| + | |||
| + | |||
| + | '''An instance must not contain duplicate xbrli:context elements.''' | ||
| + | |||
| + | An instance must not contain equivalent xbrli:context elements. xbrli:segment or xbrli:scenario elements are tested for equality of their children without regard to order. Contexts are defined to be equivalent if they have S-equal identifiers, equal dateUnion values for startDate, endDate and instant (respectively), and segment or scenario element children with equal QNames for each explicit dimension (either segment or scenario element is disallowed by another rule). | ||
| + | |||
| + | Even though there is no limitation on the length of an id attribute it is recommended to keep it as short as possible. Id attributes should also be abstract and should not contain any semantic meaning. | ||
| + | |||
| + | '''There must not be two facts having the same element name, equal contextRef attributes, and if they are present, equal unitRef attributes and xml:lang attributes, respectively.''' | ||
| + | |||
| + | An instance must not have more than one fact having S-Equal element names, equal contextRef attributes, and if they are present V-Equal, unitRef attributes and xml:lang attributes, respectively. A fact is an occurrence in an instance of an element with a contextRef attribute. The values of the id attribute and the text content of the element are not relevant to detection of duplicate facts. Other rules forbidding equivalent xbrli:context and xbrli:unit elements ensure that duplicate values of the contextRef and unitRef attributes can be detected without dereferencing. | ||
| + | The predicate V-Equal is as defined in the XBRL 2.1 specification. The V-Equal test is sensitive to the underlying data type, so the decimals attribute of ‘-6’ is V-Equal to decimals ‘-06.0’. In unusual cases the same fact may be presented with different levels of detail, such as “123456 Shares with decimals equal to ‘INF’”, and “120000 Shares with decimals equal to ‘-3’”. Instead of including both facts in the instance, the instance should contain only the more precise one. | ||
| + | |||
| + | '''The default value of the xml:lang attribute on non-numeric facts and on link:footnote is equal to the default language.''' | ||
| + | |||
| + | <span style="background-color:#A9D0F5">Some explanatory text and examples.</span> | ||
Revision as of 15:10, 24 September 2012
Editing rules
Editorial comments should be highlighted as follows: A comment
Text or rules in discussion (white): Some text
Text or rules already aligned (green): Some text
Text or rules to be deleted (red): Some text
Text to be delivered (blue): Some text
Contents |
Abstract
The rules in this document aim to facilitate the analysis and comparison of XBRL financial reporting data by computer applications and human readers. The following set of rules provides guidance on the preparation, filing, and validation of filings in eXtensible Business Reporting Language (XBRL).
Objective
The following set of rules provides guidance on the preparation, filing, and validation of filings in eXtensible Business Reporting Language (XBRL) format. The rules in this document aim to facilitate the analysis and comparison of XBRL financial reporting data by computer applications and human readers. The fundamental use case that guides the rules is the submission, by a single organisation, of its regulatory filings, and the consumption of those regulatory filings by many, initially unknown, users and software applications.
Scope
The rules in this document have been created for regulatory filings in the context of European supervisory reporting.
In this document, “regulatory filings” encompasses authoritative financial reporting standards and generally accepted accounting principles/practices (or GAAP), regulatory reports whose subject matter is primarily financial position and performance and 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).
Target Audience
This document is intended for a technical audience and assumes that the reader has a working knowledge of the XBRL 2.1 and the XBRL Dimensions 1.0 Specifications and has a basic understanding of XML, Namespaces, and XML Schema. To readers with XML knowledge, many of the guidelines in this document will be familiar however, other rules originate from features that are XBRL-specific and therefore the reasoning behind these rules may be less obvious. Where appropriate, the rules are accompanied by a brief explanation.
Relationship to Other Work
The guidelines in this document pertain to XBRL filings. Parts of this document reiterate for expository clarity certain syntactic and semantic restrictions imposed by XBRL, but this document does not modify XBRL. In the event of any conflicts between this document and XBRL, XBRL prevails. This document does place additional restrictions beyond those prescribed by XBRL.
Tailoring this Document
This document is based on the assumption that filers in the Filing system will provide their filings according to taxonomies as published by the European supervisors. This document must be also tailored for each specific Filing system. This does include Filing systems on the European level (EBA, EIOPA and ESMA) as well as Filing Systems on the national level. Later filing systems might inherit this set of rules and potentially extend it further. This does guarantee that filings on a national level also comply with European rules and data can move along all participants without transforming the original filings. Furthermore, rules concerning the entity identifier and entity scheme should also be tailored. A summary table is provided at the end of this document which provides information about which rules should be tailored by individual regulators.
Validation of Regulatory Filings
Valdiation rules as published by the regulator and do accompany the taxonomies on the European level. This is to make submitted data does have a sufficient quality. These validation checks can be done through software in an automated process. The validation rules are harmonized across Europe so that the same results can be produced in each European reporting system.
Templates, Data Models and Taxonomies
The tables of the European reporting frameworks consist of white, gray and crisscrossed cells. White cells can be reported if data is available and can be retrieved from the database of the reporting entity. Gray cells could be reported but they are not mandatory because the level of detail is excluded from the reporting. Crisscrossed cells make no sense from an economic point of view.
Terminology
| Term | Definition |
|---|---|
| Authority | Any person or organization that has the legally delegated or invested authority, capacity, or power to provide a filing. Filer must own or control the authority name; for example, “example.com” could only be used by Example Inc. itself. |
| Dimension | xsd:element in the substitutionGroup of dimensionItem; relates to the ability to express multidimensional information; for example, profit from sales could be presented by products, regions, segments, etc; to express such relations XBRL International developed the Dimension 1.0 Specification, which enriches the general XBRL Specification with rules and procedures on how to construct dimensional taxonomies and instance documents. |
| Filing system | System in which XBRL filings are filed, received, analysed and redistributed. |
| Reporting entity | A person or entity on whose behalf a filing is made. |
| Filing | A filing is the fundamental unit of information that is transmitted to Filing system for receipt, validation, and acceptance. It is the conveyance of an XBRL document or series of XBRL filing documents. |
| Instance document | An instance document is an XBRL file. A document originating with a filer can only be sent as part of a filing. One or more documents comprise a filing. |
| Publisher of the schema | Organisation responsible for publishing a given XBRL taxonomy. |
| Applicable taxonomy | A taxonomy recognised to use as a base for filings in a given Filing system. |
| Hypercube | xsd:element in the substitutionGroup of hypercubeItem which represents a set of dimensions; relates to the ability to express multidimensional information; for example, profit from sales could be presented by products, regions, segments, etc; to express such relations XBRL International developed the Dimension 1.0 Specification, which enriches the general XBRL Specification with rules and procedures on how to construct dimensional taxonomies and instance documents. |
Rules
Filing syntax rules
XBRL document names follow the national rules on the file name in the filing system.
Some explanatory text.
Reporting entities must use one of the taxonomies as specified in the filing system as the applicable taxonomy.
A listing of all taxonomy files respective modules recognised in the Filing system should be provided on a web location.
Attribute xml:base must not appear in any filing document.
XML processors interpret this attribute differently, so it shall not be used.
Encoding of all XBRL documents must be "UTF-8".
Several standards exist on the representation and handling of text. Some of the standards like ISO-8859-1 are widely used in various countries but the standards itself are largely incompatible with each other . UTF-8 is the preferred and most used encoding in HTML documents and therefore defined as Best Practice. It is necessary to specify the encoding attribute in the prologue of an XBRL instance report.
Reporting entities shall use only one of entry point schema as specified in the filing system.
It is recommended to refer to one entry point in an instance document and therefore include only one schemaRef element.
Instance syntax rules
The scheme attribute of the xbrli:identifier element must follow the pattern recognised in the Filing system.
Some explanatory text and example.
An xbrli:identifier element must have a number or identifier recognised in the filing system as its content.
Some explanatory text and example.
All xbrli:identifier elements in an instance must have identical content.
Some explanatory text.
Only the xbrli:scenario element shall appear in any xbrli:context.
As scenario and segment elements are treated as mutually exclusive so the use of both of them is prohibited.
Every xbrli:context element must appear in at least one contextRef attribute in the same instance.
Unused xbrli:context elements have no benefit to users and are easily removed by the reporting entity before filing.
There must not be the same date in both xbrli:startDate and xbrli:endDate of the same context
Note that XBRL 2.1 interprets a date used as a context start date as “midnight at the beginning of” that day. A date used as an instant or endDate in a context means “midnight at the end of” that day. For example, a company reporting at a May 31st, 2009 fiscal year-end will have contexts whose end date-time is midnight at the end of 2008-05-31 (the prior fiscal year) and contexts whose start date-times are midnight at the beginning of 2008-06-01 (the current fiscal year). It will not have any contexts with start date-time of midnight at the beginning of 2008-05-31, and no contexts with end date-time of midnight at the end of 2008-06-01.
Element xbrli:xbrl must not have duplicate child xbrli:unit elements.
Element xbrli:xbrl must not have equivalent child xbrli:unit elements. Units are equivalent if they have equivalent measures or equivalent numerator and denominator. Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators are equivalent if they have a set of equivalent measures.
An instance must not contain duplicate xbrli:context elements.
An instance must not contain equivalent xbrli:context elements. xbrli:segment or xbrli:scenario elements are tested for equality of their children without regard to order. Contexts are defined to be equivalent if they have S-equal identifiers, equal dateUnion values for startDate, endDate and instant (respectively), and segment or scenario element children with equal QNames for each explicit dimension (either segment or scenario element is disallowed by another rule).
Even though there is no limitation on the length of an id attribute it is recommended to keep it as short as possible. Id attributes should also be abstract and should not contain any semantic meaning.
There must not be two facts having the same element name, equal contextRef attributes, and if they are present, equal unitRef attributes and xml:lang attributes, respectively.
An instance must not have more than one fact having S-Equal element names, equal contextRef attributes, and if they are present V-Equal, unitRef attributes and xml:lang attributes, respectively. A fact is an occurrence in an instance of an element with a contextRef attribute. The values of the id attribute and the text content of the element are not relevant to detection of duplicate facts. Other rules forbidding equivalent xbrli:context and xbrli:unit elements ensure that duplicate values of the contextRef and unitRef attributes can be detected without dereferencing. The predicate V-Equal is as defined in the XBRL 2.1 specification. The V-Equal test is sensitive to the underlying data type, so the decimals attribute of ‘-6’ is V-Equal to decimals ‘-06.0’. In unusual cases the same fact may be presented with different levels of detail, such as “123456 Shares with decimals equal to ‘INF’”, and “120000 Shares with decimals equal to ‘-3’”. Instead of including both facts in the instance, the instance should contain only the more precise one.
The default value of the xml:lang attribute on non-numeric facts and on link:footnote is equal to the default language.
Some explanatory text and examples.
