European Filing Rules
From XBRLWiki
Revision as of 07:16, 24 April 2013; Hommes (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
CEN Workshop Agreement
Status: Working Group Working Draft
CEN WS XBRL Experts: Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)
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 |
Foreword
Some text
Introduction
The eXtensible Business Reporting Language (XBRL) specification provides a high degree of flexibility in the creation of XBRL instance documents. The following set of rules are intended to recommend best practices on the freedom of choice for the benefit of clear guidance on preparation and validation of instance documents and an increase of interoperability between computer applications. They also facilitate the analysis and comparison of instance documents for preparers as well as receivers of XBRL in the reporting process.
The filing rules represent a collection of recommendations to be seen as advisable to be implemented in the European supervisory reporting process. The rules are recommended to be adopted by national supervisors for other reporting purposes when they do not contradict their needs, i.e. footnotes are sometimes necessary to explain the content of reported fact. The listed filing rules are influenced by the European Taxonomy Architecture in cases where the instance creation is affected.
The purpose of these filing rules is minimize the reporting burden for reporting entities in Europe notwithstanding amendments to these rules would be optionally prescribed by one or more regulators.
Notwhitstanding the only authoritative restrictions are respectivelly the XBRL specifications and the regulatory instructions, the following set of rules helps to avoid unnecesary complications by adopting well stablished best practices.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “MUST” (strong recommendation), “SHOULD” or "RECOMMENDED" (recommendation) and “MAY” (possibility). Organizations wishing to implement this CWA (CEN Workshop Agreement) would be expected to consider all recommendations where the terms "MUST", “SHOULD” and "RECOMMENDED" are used.
Objective
The primary objective is interoperability, by harmonization and guidance on the rules of XBRL taxonomy creation process carried out by regulators, supervisory authorities, voluntary suplly chains and others.
The secondary objective is facilitate adoption, by maintaining as simple as possible the technological requirements when creating XBRL instance documents.
The fundamental use case that guides the following set of rules is the submission, by a reporting entity, of its regulatory filings, and the consumption of those regulatory filings by several reporting applications.
The following set of rules provides guidance on the preparation and validation of instance documents in XBRL format.
The rules in this document also aim to facilitate the analysis and comparison of reporting data as well as the interoperability of computer applications.
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.
To ease understanding for software developers implementing these rules in their reporting system, an UML model has been created to show the relationships between the different XBRL objects mentioned in this document.
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.
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 European reporting standards that are published by an European supervisory authority and accompanied by an XBRL taxonomy as well as extensions on these taxonomies provided by national supervisors.
Normative references
Terms and definitions
- Applicable taxonomy
- An XBRL taxonomy recognised to use as a base for filings in a given filing system.
- Data point
- A data point is an information component that is defined by a supervisory authority to be sent in an instance document. In XBRL a data point is represented by a fact, its value and related dimensional combinations.
- Dimension
- A dimension is an xs:element in the substitutionGroup of xbrldt:dimensionItem; it relates to the ability to express multidimensional information;
- Entrypoint
- A schema or linkbase in the applicable taxonomy that represents the filing requirements and gets mentioned in the instance by the reporter.
- Fact
- A fact is an occurrence in an instance document of an element with a mandatory contextRef attribute and optional attributes like unitRef, xml:lang or xsi:nil.
- Filer
- A reporting entity.
- Filing
- A filing is the fundamental unit of information that is transmitted to a filing system for receipt, validation and acceptance. It is the conveyance of an XBRL instance document or series of XBRL instance documents.
- Filing system
- A system in which XBRL instance documents are filed, received, analysed and redistributed.
- Footnote
- A footnote is used to associate text annotations with particular facts in an XBRL instance document.
- Instance document
- An instance document is an XBRL file carrying facts. An instance document originating with a filer can only be sent as part of a filing. A filing comprises of one or more instance documents.
- Linkbase
- A linkbase is an XML file according to the XBRL 2.1 specification, containing relationships between concepts, resources and concepts and resources providing labels and references. There are different kinds of linkbases. One of them is the formula linkbase containing business rules in the syntax as prescribed by the XBRL Formula Specification.
- Publisher of the schema
- Organisation responsible for publishing a given XBRL taxonomy.
- Reporting entity
- A reporting entity is a institution or company with an obligation to prepare supervisory reports for national or European supervisory authorities.
- Taxonomy
- In the XBRL context, an electronic dictionary of business reporting elements relevant for reporting business data. A taxonomy is composed of an XML Schema and one or more linkbases directly referenced by that schema. ; Taxonomy creator : see Publisher of the schema
- XBRL specific terms like context, unit, period, entity, s-equal, v-equal see XBRL 2.1
Symbols and abbreviations
- UML
- Unified Modelling Language
- W3C
- World Wide Web Consortium
- XBRL
- eXtensible Business Reporting Language
- XML
- eXtensible Markup Language
Rules
Filing syntax rules
- 1.01
The file name of an instance document SHOULD follow the rules of the national filing system.
There is no prescribed way of handling instance document file names. Different naming conventions exist around the world, mostly conveying some kind of meaning about the sender, the reported filing or reported period. - 1.02
Reporting entities SHOULD use one of the taxonomies as specified in the filing system as the applicable taxonomy.
{GFM 1.1.5}
A listing of all taxonomy files respective modules recognised in the filing system should be provided on a web location. - 1.03
The encoding of all instance documents SHOULD be "UTF-8".
{GFM 1.1.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 instance document.
context xmlDocument inv:
self.encoding = 'UTF-8'
It is recommended to refer to a single entrypoint in an instance document and therefore include only one link:schemaRef element. This is because the data point modelled taxonomies MAY contain multiple tables but these are not treated as an entrypoint. Only the whole of the taxonomy has a single entrypoint for all tables. Through the 'FilingIndicators' it is communicated which tables are communicated in the instance.
Each instance document in the filing is tested separately for XBRL 2.1 validity. In order to increase the likelihood that instance documents pass validation, filers are encouraged to validate their compliance with the XBRL 2.1 Specification prior to submission.
context Instance::isXBRLValid() : Boolean
post: result = true
Any formula linkbase discovered by the XBRL software from opening the entrypoint can contain tests on the quality of the reported data. The tests that report an error on these data SHOULD be corrected. There MAY be tests that produce only warnings. Solving these warnings depends on the message content and the filer perspective on them.
context Instance::isFormulaValid() : Boolean
post: result = true
XBRL Taxonomies can be extended by anybody with the proper technical knowledge. Filings to European Regulatory Authorities are 'closed form' i.e. all data points allowed by the regulator are in the taxonomy. There can be no extension of the taxonomy by reporters to report more data points to the regulator.
context Taxonomy inv:
self.owner = ‚European Banking Authority’
or self.owner = ‚European Insurance and Occupational Pensions Authority’
In case of corrections it is recommended not to send partial data with just the corrected facts. Non-complete submissions could lead to invalid instance documents and might raise conflicts with already processed data in the reporting system of the receiver.
Instance syntax rules
- 2.01
Attribute @xml:base SHOULD NOT appear in any instance document.
XML processors interpret this attribute differently, so it should not be used.
context xmlDocument inv: self.element->select(xml:base)->isEmpty()
The version of any report is represented in folder names, not in URI namespaces. To correctly interpret the reported facts the proper entrypoint schema and its taxonomy must be present in the instance by including the full path (including the folder with the version indicator in it) in the link:schemaRef element.
Although version 1.1 exists, XBRL instances MUST be based on version 1.0.
context xmlDocument inv: self.version = '1.0'
Declaring unused namespaces is uncalled for and clutters the instance document.
The W3C, XBRL International and the taxonomy author all assign namespace prefixes to their schema's. Human interpretation of the instance could be confused when these namespace prefixes are not followed in the instance.
Taxonomy authors will make sure that a single entrypoint schema needs to be referred to in the instance. This entrypoint will refer all required data points.
context Instance inv: self.SchemaReference->size() = 1
Entrypoints will be defined by means of a schema. And considering footnote linkbases are not allowed, there is no use for link:linkbaseRef.
Verbose comments inside the instance that do not get reported as a fact will be ignored by the regulator. These comments clutter the instance and have no use to the regulator.
Verbose comments inside the instance that do not get reported as a fact will be ignored by the regulator. These comments clutter the instance and have no use to the regulator.
Context related rules
- 2.10
It SHOULD be avoided to have duplicates of xbrli:xbrl and xbrli:context elements.
An instance document must not contain equivalent xbrli:context elements.The two sub-elements of xbrl:context xbrli:segment and 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.
context Context inv: self.allInstances()->forAll(c1, c2| c1 <> c2 implies (c1.DimensionalContainer.scenario <> c2.DimensionalContainer.scenario and c1.Identifier.value <> c2.Identifier.value and c1.Identifier.scheme <> c2.Identifier.scheme and(c1.Period.start <> c2.Period.start and c1.Period.end <> c2.Period.end or c1.Period.instant <> c2.Period.instant)
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.
Unused contexts (contexts which are not referred to by facts) clutter the instance and add no value.
context Context inv: self.Fact.allInstances()->notEmpty()
It is recommened to use a proprietary national id code with the scheme refering to the corresponding national central bank.
Example: <xbrli:identifier scheme="http://www.kredittilsynet.no">NO12345678</xbrli:identifier>
let schemeUrl : String = ‘http://www.kredittilsynet.no’ -- URL to be replaced context Context inv: self.Identifier.allInstances()->forAll(scheme = schemeURL)
See explanation on rule 2.13
There can only be one reporter of an instance. Even if the content of the instance deals with a group of companies, there is only one entity reporting the instance to the regulator.
context Context inv: self.Identifier.allInstances()->forAll(i1, i2| i1 = i2 implies i1.value = i2.value)
The scheme attribute MUST correspond to the identifier of the reporting entity and there can only be one scheme defined for the reporting entity in an instance document.
context Context inv: self.Identifier.allInstances()->forAll(i1, i2| i1 = i2 implies i1.scheme = i2.scheme)
The XBRL specification of this element has made it possible to enter a date or a dateTime. European regulators only allow dates.
The extreme version of duration is 'forever'. The XBRL specification has created this to solve problems with dates starting 'at the beginning' and ending 'never'. E.g. the name of the filer has in general no end date. The regulator is only interested in type of data for the reported time segment that has a defined starting and ending date.
context Context inv: self.Period.forever->isEmpty()
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.
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.
context Context inv: self.Period->select(start < end)->notEmpty()
Example: in a fiscal year 2009 report a company describes litigation settled in fiscal year 2007. Nevertheless, the disclosure text should be in a context for fiscal 2009. A reporting period begins at 00:00:00 of its first day and ends at 24:00:00 of its last day, which is the XBRL 2.1 default for periods. Only the date, not the time part of the ISO 8601 date-times, should be used in contexts.
Example: a company completes an acquisition in its second fiscal quarter. In its 3rd quarter fiscal report, the Acquisitions note contains text describing that same acquisition. The 3rd quarter text should be in the context for the first nine months (that is, the year-to-date).
The dates defined in instant or duration should not exceed the first or the last day of the reporting period.
context Context inv: self.Period.allInstances()->forAll(p1, p2| p1 = p2 implies (p1.start = p2.start and p1.end = p2.end) or p1.instant = p2.instant)
As xbrli:scenario and xbrli:segment elements are treated as mutually exclusive, using both of them is prohibited.
Comment-25
context Context inv: self.DimensionalContainer.segment->isEmpty()
The xbrli:scenario element MUST NOT be used for anything other than for explicit or typed members.
Fact related rules
- 2.25
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 document 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. 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. - 2.26
@precision MUST NOT be used.
The decimal attribute must be used instead as it holds equivalent information. - 2.27
@decimals value MUST NOT cause non-zero digits in the fact value to be changed to zero.
Instance documents must not contain truncations or roundings that result in reductions of the number of significant figures. If the decimals attribute of a numeric fact is not equal to “INF”, then the value is interpreted as if certain digits were zero. Example: The table below illustrates correct and incorrect use:Fact text Decimals value Interpreted value Result -2345.45 INF -2,345.45 -2345.45 2 -2,345.45 -2345.45 0 -2,345.00 Error -2345.45 -2 -2,300.00 Error -2345.45 -3 -2,000.00 Error -2345.45 -6 0000.00 Error This rule is valuable when XBRL Formulas are used to evaluate the correctness of the data.
- 2.28
The @decimals value MUST correspond to the accuracy of the corresponding amount as reported in the regulatory filing.
The decimals attribute influences how numbers are interpreted in XBRL and any value for the decimals attribute other than the value INF implies rounding or truncation. Use the following table to select the correct value of the decimals attribute for a fact so that it corresponds to the value as presented (most often rounded) in instance documents.Accuracy of the amount Value of decimals attribute Exact monetary, percentage, basis point or any other amount INF Rounded to billions -9 Rounded to millions -6 Rounded to thousands -3 Rounded to units 0 Rounded to cents 2 Rounded to a whole percentage 4
Examples: The table below illustrates correct use.
Fact Value Value of decimals attribute A percentage of (exactly) 46% .46 INF A (rounded) profit margin of 9.3% .093 3 A (rounded) amount “in thousands” of 100 100000 -3 A (rounded) amount “in thousands” of 100 100200 -2 The decimals attribute is not a scale factor. The decimals attribute is not a formatting code; it does not indicate that the digits in the instance must subsequently be presented to a user in any particular way.
- 2.29
The @xsi:nil="true" MUST NOT be used for anything other than conveying a value that is different from both "zero" and not reporting the fact at all.
Data related to white cells could be reported with the according value, as zero or as unknown. The table below shows the different possible solutions:zero value The value of the fact is "0". <p-cm-ca:CapitalRequirements decimal="0" unitRef="EUR" contextRef="ctx_1">0</p-cm-ca:CapitalRequirements> nil value The value of the fact is not known or can't be received. <p-cm-ca:CapitalRequirements xsi:nil="true" unitRef="EUR" contextRef="ctx_1"></p-cm-ca:CapitalRequirements> not applicable information The value is inapplicable. The fact doesn't appear in the instance. - 2.30
The content of a numeric fact MUST NOT have a scale factor.
Examples: The value “twenty thousand” may appear in a numeric fact as any legal decimal representation of 20,000, such as 20000, 20000.0, or 020000. It must not appear as “20”. The value “20%” may appear in a numeric fact as any legal decimal representation of .2, such as 0.2, 0.20, 000.2000. The value “20%” must not appear in a numeric fact as “20”, “20/100”, “20%” or any variation of the integer “20”.
The language used on string based facts needs to be identified. This can be done by declaring the @xml:lang on the xbrli:xbrl element just once, or on every string based fact individually. No rules have been set for regulators allowing multiple language reportings (choices are to support all languages in a single instance or to require multiple, language based, instances). Comment-24
The @id on individual facts is meant to connect texts in the form of a footnote, which is prohibited.
Unit related rules
- 2.33
xbrli:xbrl/xbrli:unit MUST NOT have duplicates.
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.
context Unit inv: self.allInstances()->forAll(u1, u2| u1 <> u2 implies (u1.id <> u2.id and u1.measure->asOrderedSet() <> u2.measure->asOrderedSet())
Unused units (units which are not referred to by facts) clutter the instance and add no value.
context Unit inv: self.Fact.allInstances()->notEmpty()
XBRL 2.1 already enforces the requirement that a fact of type xbrli:monetaryItemType must have a unitRef whose xbrli:measure is an ISO standard currency. A standard numeric data type registry is similar but broader: it has a schema with numeric type declarations, and each numeric data type is associated with consistent unit declaration measures, numerators and denominators.
http://www.xbrl.org/utr/utr.xml
To express amounts in US Dollars, use only xbrli:unit with one xbrli:measure element whose content is the QName iso4217:USD. Do not define units such as “thousands of USD”, “millions of GBP”, or “pence”.
Amounts that a reported should refer to only to one xbrl:unit with a xbrli:measure that content is a QName starting with iso4217.
context Instance inv: self.Unit->select(measure.substring(1, 7) = #iso4217)->size()=1
Footnote related rules
- 2.38
Footnotes MUST NOT be used in instance documents.
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. Additional information to white cells outsourced in footnotes are not allowed.
Bibliography
- Global Filing Manual (Interoperable Taxonomy Architecture Project)
- EDGAR Filer Manual U.S. Securities and Exchange Commission
- IFRS Taxonomy Guide
Annex
