European Filing Rules

From XBRLWiki

(Difference between revisions)

Current revision

CEN Workshop Agreement

Status: This is a public Working Space. Please refer the official publication at CWA 16744-4:2014 Improving transparency in financial and business reporting - Harmonisation topics - Part 4: European Filing Rules.

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

1 Foreword
2 Introduction
3 Objectives
4 Target Audience
- 4.1 Relationship to Other Work
5 Scope
6 Terms and definitions
7 Symbols and abbreviations
8 European Filing Rules
- 8.1 Filing syntax rules
- 8.2 Instance syntax rules
9 Annex
10 Open discussions
11 Bibliography

[edit]

Foreword

This document has been prepared by CEN/WS XBRL, under the supervision of the Secretariat of the Netherlands Standardization Institute (NEN).

This document has been officially promulgated in the CEN website Improving transparency in financial reporting (WS XBRL)

The direct link is CWA 16744-4:2014 Improving transparency in financial and business reporting - Harmonisation topics - Part 4: European Filing Rules.

[edit]

Introduction

The eXtensible Business Reporting Language (XBRL) specification provides a high degree of flexibility in the creation of XBRL instance documents. In part, this flexibility stems from the nature of the syntax XML, and in part it stems from the XBRL specification itself. This document provides guidance for regulators, relating to the syntax used in XBRL instances, to enable them to make restrictions where they feel it is appropriate to do so.

Disclaimer:
The filing rules represent a collection of recommendations to be seen as guidance to be implemented in the European supervisory reporting process. The rules are also recommended to be adopted by national supervisors for other reporting purposes when they do not contradict their needs, e.g., footnotes are sometimes necessary to explain the content of reported facts. The listed filing rules are influenced by the European Taxonomy Architecture in cases where the instance creation is implicated.

This document is a listing of best practices for the benefit of clear guidance on the preparation and validation of XBRL instance documents, and to improve the interoperability among computer applications that process these instances. The consistent use of best practices facilitates the analysis and comparison of XBRL instance documents for both the reporting entities and the receiving entities in the reporting process. The rules are primarily based on regulatory needs. One goal of this document is to minimize the reporting burden on the reporting entities in Europe. However, this goal is subject to the reporting statutes legislatded by National and European regulators.

Although the only authoritative restrictions are based on the XBRL specifications and the regulatory instructions, the following set of rules helps to avoid unnecessary complications by adopting well established Best Practices.

The language used to express some of the best practices is tightly connected to the environment in which these practices were developed. Guidelines stemming from the Global Filing Manual or the Edgar Filing Manual are based on RFC 2119. On the other hand, the CEN projects are using language from CEN T/C 123.

The guidance in this document is in the form of notes, and they will not make any emphasis on rules being a "must/shall" or "should/recommended" because this document does not have a mandate to establish such rules. Only the National and European regulators have such a mandate. The regulators can choose from the guidelines presented here in order to create their own set of rules.

[edit]

Objectives

The primary objective of the CWA1 working group is interoperability. This is achieved thanks to the harmonization and guidance relating to the best practices of the XBRL taxonomy creation process, as carried out by regulators, supervisory authorities, voluntary supply chains, and others. The secondary objective is to facilitate adoption of XBRL technology, by maintaining standard technological requirements for the creation of XBRL instance documents ,and by keeping them as simple as possible. The basic use case that is the underlying controlling factor for the following guidelines is the submission, by a reporting entity, of its regulatory filings, and the consumption of those regulatory filings by (several) reporting applications.

The following sections provide guidance on the preparation and validation of instance documents in XBRL format.

The guidelines in this document also aim to facilitate the analysis and comparison of reporting data as well as the interoperability of computer applications.

[edit]

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, others guidelines originate from features that are XBRL-specific, so the reasoning behind them may be less obvious.

To ease the understanding by software developers implementing these guidelines in their reporting system, a UML model has been created to show the relationships between the different XBRL objects mentioned in this document. Some of the filing rules are accompanied by constraints defined in the Object Constraint Language (OCL). OCL is part of the UML and allows adding constraints based on the UML objects of the class model. OCL is not a programming language; it just supports the definition of technical specifications. OCL eases the understanding of the rules by using a formal language to provide an unambiguous and consistent description [Karl12, p. 106].

[edit]

Relationship to Other Work

The guidelines in this document pertain to XBRL filings. Parts of this document reiterate documentation, for the clarification of certain syntactic and semantic restrictions imposed by XBRL, but this document does not modify XBRL. In the event of any conflict between this document and XBRL, XBRL prevails. This document does place additional restrictions beyond those prescribed by XBRL.

[edit]

Scope

The guidelines 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 a European supervisory authority, accompanied by an XBRL taxonomy as well as extensions of this taxonomy provided by national supervisors.

[edit]

Terms and definitions

Applicable taxonomy: An XBRL taxonomy recognised to be used as a basis for filings in a given filing system.
Data point: A data point is an information component that is defined by a supervisory authority and is 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 a 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 a 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 a XBRL instance document.
Instance document: An instance document is a 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 a XML file according to the XBRL 2.1 specification, which contains relationships between concepts, resources, and concepts, in addition to resources which provide 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 an institution or company with an obligation to prepare supervisory reports for national or European supervisory authorities.
Taxonomy: In the context of XBRL, a taxonomy is an electronic dictionary of business reporting elements that are relevant for reporting business data. A taxonomy is composed of a XML Schema and one or more linkbases directly referenced by that schema.
Taxonomy creator: See: Publisher of the schema
For XBRL-specific terms like context, unit, period, entity, s-equal, v-equal see Specification XBRL 2.1.

[edit]

Symbols and abbreviations

UML: Unified Modeling Language
W3C: World Wide Web Consortium
XBRL: eXtensible Business Reporting Language
XML: eXtensible Markup Language

[edit]

European Filing Rules

[edit]

Filing syntax rules

1.1 Filing naming
Common practice is to use the extension .xbrl for instance documents, but there is no technical restriction to use anything else. There are no restrictions on file names posed. Different naming conventions exist around the world; essentially these are conveying some kind of meaning about: the sender, the reported filing and/or the reported period. For software that is storing the file name of the instance in a relational database some restrictions on which characters may be used and the total length of the file name may be appropriate.
CWA Advice: Rules about the file name of an instance document need to be set by the receiver of the reports, if required.

1.2 Taxonomy publication
The reporter needs to be made aware of which taxonomy should be used for the instance creation. This information should be made publicly available in an official web location to facilitate the automated processing by software.
CWA Advice: The publisher of the taxonomy should ensure that each taxonomy file can be localised in the internet.

1.3 Taxonomy package
The publisher of the taxonomy might provide a compressed file enclosing all relevant taxonomy files to facilitate a download for an offline processing. This taxonomy package should only include those files for which the publisher of the taxonomy is responsible becaues, redistributing files under the control of other authorities can lead to interoperability problems if the latest published versions of these files do not match. Referenced files from other parties should be downloaded from the web address of the respective owner.
CWA Advice: A publisher of a schema should only provide taxonomy files for download where he is the owner.

1.4 Character encoding of XBRL instance documents
The XML and XBRL specifications place no restrictions on the character encodings that may be used in instance documents. In order to avoid using a character encoding that is not supported by a receiving processor, all instances should use the UTF-8 character encoding.
CWA Advice: "UTF-8" is the recommended encoding for XBRL instance documents. [GFM11, p. 11] If required, the instance receiver can restrict the set of characters or scripts defined in the Unicode.

context xmlDocument inv: 
    self.encoding = 'UTF-8'

1.5 Taxonomy entrypoint selection
A taxonomy is loaded through a reference to one or more URLs, with other files in the taxonomy being included through the process of DTS Discovery. Although technically a user can reference any file in the taxonomy, a taxonomy publisher will typically nominate specific URLs which are intended to be referenced by users of the taxonomy. These URLs are called entrypoints, and allow users to import the correct modules from the taxonomy, with different modules including different templates and different associated validation rules.
CWA Advice: The taxonomy publisher should provide a list of available entrypoints in the taxonomy as a list of absolute URLs.

1.6 Missing filing indicators
Each reported fact in a filing requires to be assigned to a template of a specific reporting domain. Filing indicators are used to hold these template names. They also trigger the taxonomy validation checks. Missing filing indicators can lead to inconsistencies because the unassigned facts are not validated.
CWA Advice: It is required to include filing indicators in the XBRL instance to express which templates are represented by the reported facts.

1.7 No facts for indicated templates
If a filing indicator is given in the XBRL instance, consistency checks are processed by the reporting system. In case no fact appears for an indicated template, the filing could be rejected because the system requires an appropriate set of fact values for the checks.
CWA Advice: It is recommended not to include filing indicators for templates which are not addressed by the facts reported.

1.8 Correct usage of filing indicators
As filing indicators play an essential role to ensure the data quality, the receiver of the instance should check that they are correctly set by the reporting entity.
CWA Advice: The receiver of the instance should implement checks that reveal missing or superfluous filing indicators in an instance document.

1.9 Valid XML-XBRL
Each XBRL instance in the filing is tested for XBRL 2.1 and XBRL Dimensions 1.0 validity. In order to increase the likelihood that instance documents pass validation, filers are required to validate their compliance with the XBRL 2.1 and XBRL Dimensions 1.0 specifications prior to submission.
CWA Advice: Instance documents are required to be XBRL 2.1 and XBRL Dimensions 1.0 valid. EFM13, Volume II, p. X-Y]

context Instance::isXBRLValid() : Boolean 
    post: result = true

1.10 Valid according to the defined business rules
XBRL allows the definition of business rules which can be discovered by XBRL software while opening the respective module referenced in the instance document. These business rules are applied on the content of the instance document to check the data quality. Tests that result in an error need to be corrected by the sending reporting entity. There may be tests that produce warnings. The need to solve these warnings depends on the content of the message and the perspective of the filer.
CWA Advice: It is recommended to have the XBRL instance document valid with regards to validation technology provided in the applicable taxonomy.

context Instance::isValidationValid() : Boolean 
    post: result = true

1.11 Taxonomy extensions by reporters
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. However, national supervisors may extend European taxonomies. For reporters, the combination of base and extension taxonomies is regarded as a single taxonomy.
CWA Advice: Reporters are required to reference only the taxonomy entrypoints specified by the relevant authority, and may not provide their own extension taxonomies.

context Taxonomy inv:
    self.owner = ‚European Banking Authority’
    or self.owner = ‚European Insurance and Occupational Pensions Authority’

1.12 Completeness of amendment files
In case corrections are needed on filings that already have been submitted, it is recommended that European Regulatory Authorities require the resubmission of the complete filing, rather than allowing partial data with just the corrected facts. It is important to ensure that all amended instances are valid according to XBRL and the business rules defined.
CWA Advice: It is recommended that European Regulatory Authorities require reporters resubmit the full report, in the event of an amendment being required.

[edit]

Instance syntax rules

2.1 @xml:base
XBRL processors interpret this attribute differently, and there is no semantic need for this attribute. XML-XBRL: The attribute xml:base may be inserted in XML documents to specify a base URI other than the base URI of the document or external entity.
CWA Advice: It is recommended that the attribute @xml:base not appear in any instance document. [EFM13, p. 6-7]

contextxmlDocument inv: 
   self.element->select(xml:base)->isEmpty()

2.2 xbrli:xbrl/link:schemaRef content
The taxonomy which is used by an XBRL report is identified by the URL(s) referenced by link:schemaRef elements. Although it is often convenient to work with local copies of the relevant taxonomies, it is important that link:schemaRef elements resolve to the published entrypoint locations. XBRL software typically provides functionality to “remap” references to URLs of published entrypoints to local copies of the taxonomy.
CWA Advice: It is required to have the link:schemaRef element resolve to the published entry point URL.

2.3 xbrli:xbrl/link:schemaRef
The element link:schemaRef can occur several times in an instance. Nevertheless, taxonomy authors will make sure that only a single entrypoint schema needs to be referenced to in the instance. This entrypoint will include all required data points. (See also 1.04)
CWA Advice: It is required to have only one xbrli:xbrl/link:schemaRef node in any XBRL instance document.

context Instance inv: 
   self.SchemaReference->size() = 1

2.4 xbrli:xbrl/link:linkbaseRef
Entrypoints will be defined by means of a schema. There is no use for link:linkbaseRef.
CWA Advice: It is required that instances reference the taxonomies only by means of the link:schemaRef element.

2.5 XML comment and documentation
Comments inside the instance that do not get reported as a fact will be ignored by the receiver. These comments clutter the instance and are of no use to the regulator. Some instance creator tools include the software identification as a XML comment.
CWA Advice: It is recommended that relevant data is only contained in contexts, units, schemaRefs and facts of an instance.

[edit]

Context related rules

2.6 xbrli:xbrl/xbrli:context/@id
The id attribute is meant as a unique technical key within a XML document. Semantics conveyed in the id attribute will be lost when the XML content is stored in a database (which generally works with database specific subrogated keys). Even though there is no limitation on the length of an id attribute, it is recommended to keep it as short as possible.
CWA Advice: It is recommended to refrain from expressing semantics in the xbrli:context/@id node.

2.7 Unused xbrli:xbrl/xbrli:context
Unused contexts (contexts which are not referred to by facts) clutter the instance and add no value to either regulator or reporter [GFM11, p. 12].
CWA Advice: It is recommended that unused xbrli:context nodes are not included in the instance. [FRIS04]

context Context inv:
   self.Fact.allInstances()->notEmpty()

2.8 Identification of the reporting entity
The xbrli:identifier node combined with the @scheme allows the identification of the reporting entity by the receiver. The @scheme provides a URI which uniquely identifies the type of identifier used in the xbrli:identifier node.
CWA Advice: It is required to use a scheme that is prescribed by the receiving regulator. [GFM11, p. 11]

 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)

2.9 One reporter
In general, an instance will be reported for only one reporter. Even if the content of the instance deals with a group of companies, there is only one entity reporting the instance to the regulator. The DTS author can determine the number of reporters in an instance.
CWA Advice: It is recommended to have all xbrli:identifier content with its corresponding @scheme to be identical. [EFM13, p. 6-8]

context Context inv: 
   self.Identifier.allInstances()->forAll(i1, i2|
   i1 = i2 implies i1.value = i2.value)

2.10 xbrli:xbrl/xbrli:context/xbrli:period/*
The xbrli:startDate, xbrli:endDate and xbrli:instant elements all have data type which is a union of the xs:date and xs:dateTime types. European regulators will only allow periods to be identified using whole days, specified without a timezone.
CWA Advice: It is required that all the xbrli:period date elements are valid against the xs:date data type, and that they are reported without a timezone. [GFM11, p. 16]

2.11 xbrli:xbrl/xbrli:context/xbrli:period/xbrli:forever
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.
CWA Advice: It is not allowed to use xbrli:forever as a reporting period. [GFM11, p. 19]

context Context inv: 
   self.Period.forever->isEmpty()

2.12 Fiscal reporting year
CWA Advice: Facts reporting information about an historic period shall be reported against the reporting period for the filing.

 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.

2.13 Reporting period consistency
The dates defined in xbrli:instant or xbrli:startDate / xbrli:endDate should not exceed the first or the last day of the reporting period in a single instance, as required by the regulator.
CWA Advice: It is recommended that the periods defined in the contexts refer to the same reporting period.
Example: corrections on previous periods MAY be using a different (version of the) taxonomy to prevent possible conflicts with the receiving regulator

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)

2.14 xbrli:xbrl/xbrli:context/xbrli:entity/xbrli:segment and xbrli:xbrl/xbrli:context/xbrli:scenario
The XBRL Dimensions specification allows taxonomies to specify dimensions for use within either the segment or the scenario of the context. For consistency reasons and simplification of processing, European taxonomy authors will only use the xbrli:scenario node.
CWA Advice: It is recommended that taxonomy publishers define all dimensions for use on xbrli:scenario.

context Context inv: 
   self.DimensionalContainer.segment->isEmpty()

2.15 xbrli:xbrl/xbrli:context/xbrli:entity/xbrli:segment and xbrli:xbrl/xbrli:context/xbrli:scenario
The xbrli:scenario or xbrli:segment element MUST NOT be used for anything other than for explicit or typed members. Custom reporter XML schema content may create problems with the regulatory system.
XML-XBRL: The XBRL specification allows xs:any content. This means that all XML schema content can be stored (not just XBRL Dimensions).
CWA Advice: If a xbrli:scenario (or xbrli:segment) element appears in a xbrli:context, then it is required for its children to be one or more xbrldi:explicitMember and/or xbrldi:typedMember elements, and not allowing any reporter custom content. [EFM13, p. 6-8]

[edit]

Fact related rules

2.16 Duplicate facts
An instance document must not have duplicated fact items. Item X and item Y are duplicates if and only if all the following conditions apply:
- 1. X is not identical to Y, and
- 2. the element local name of X is S-Equal to the element local name of Y, and
- 3. X and Y are defined in the same namespace, and
- 4. X is P-Equal to Y, and
- 5. X is C-Equal to Y, and
- 6. X is U-Equal to Y, and
- 7. X and Y are dimensionally equivalent (d-equal in all dimensions of each of X and Y), and
- 8. X and Y have S-Equal xml:lang attributes.
XML-XBRL: Duplicate facts are XML-XBRL syntax valid. However, the semantic meaning may be unclear.
CWA Advice: It is required to prohibit duplicated facts. [FRIS04],[EFM13, p. 6-10]

2.17 @precision
CWA Advice: It is required to use @decimals as the only means for expressing precision on a fact. [EFM13, p. 6-12]

2.18 @decimals
The @decimals is about the accuracy of the fact value. A positive value in @decimals means the number of accurate digits to the right of the decimal point. A negative value in @decimals means the number of non-accurate digits to the left of the decimal point. A value of INF in @decimals mean than all the digits are accurate. The XBRL processors use rounding conform to the IEEE Std 754 -2008 (4.3.1) for calculation linkbase and formula validation, which means round half to even. To enable XBRL Formulae calculations to be performed on instance values for validation purposes, no truncations or rounding or any other kind of change should apply to the numeric facts in the instance. See the explanatory RFC at http://www.xbrl.org/RFC/PDU/PWD-2008-10-09/PDU-RFC-PWD-2008-10-09.html. For XBRL Formula there is a function that can perform interval arithmetic if the formula creator desires so.
CWA Advice: The accuracy of a numeric fact is required to be expressed using @decimals, with no truncation, rounding or any change in the original fact value.
If the @decimals attribute of a numeric fact is not equal to “INF”, then the numeric fact is interpreted as interval arithmetic of the numeric fact ± 0.5(10 ^ -@decimals ). This rule is valuable when XBRL Formulas are used to validate the numeric facts.

2.19 zero value, empty, nil value @xsi:nil
There is a difference in reporting facts with the value zero, not present or xsi:nil='true'. It is up to the regulator to determine the meaning of the different situations.
CWA Advice: It is required for the regulator to describe the meaning of the situation @xsi:nil="true", if this is allowed on reported concepts.
Data related to numeric based white cells could be reported with the according value, as zero or as absent. 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	The regulator has to stipulate the meaning.	<p-cm-ca:CapitalRequirements xsi:nil="true" unitRef="EUR" contextRef="ctx_1"></p-cm-ca:CapitalRequirements>
No fact present.	The value is unknown or inapplicable.	The fact doesn't appear in the instance.

2.20 @xml:lang
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). The preferred option is to have multiple languages in a single instance.
CWA Advice: It is required to have a clear policy to define the language for non numeric facts.

[edit]

Unit related rules

2.21 Unused xbrli:xbrl/xbrli:unit
Unused units (units which are not referred to by facts) clutter the instance and add no value to either regulator or reporter.
CWA Advice: It is recommended to prevent unused xbrli:unit nodes to be present in the instance. [FRIS04]

context Unit inv: 
  self.Fact.allInstances()->notEmpty()

2.22 xbrli:xbrl/xbrli:unit/* content
XBRL International, Inc. has released a standard numeric data type registry which has a schema with numeric type declarations, and each numeric data type is associated with consistent unit declaration measures, numerators and denominators. Use of this registry that contains all the usual units facilitates implementation in software and simplifies validation. Link: XII UTR National supervisors that use units apart from UTR should apply for an integration of these units in this standardized registry of XBRL International Inc.
CWA Advice: It is recommended to have the xbrli:unit children referring to the XBRL International Unit Type Registry (UTR). [EFM13, p. 6-17]

2.23 One currency
Dealing with currency conversions in the reporting process increases the complexity of IT systems.
CWA Advice: It is recommended for national regulators to define one currency to be accepted for monetary values in instance documents.

2.24 xbrli:xbrl/xbrli:unit/xbrli:measure
Facts that represent amounts in any currency must be of an item that is derived from xbrli:monetaryItemType, and must thereby follow the restriction in XBRL 2.1, section 4.8.2, regarding monetaryItemType (i.e., unit measure is an ISO 4217 currency designation). Such facts may not have unit measures that express any scaling (which is covered by the @decimals attribute of the fact).
CWA Advice: It is required to have units representing currencies, to represent the actual physical value of these currencies.

context Instance inv: 
  self.Unit->select(measure.substring(1, 7) = #iso4217)->size()=1

[edit]

Footnote related rules

2.25 Footnotes
Footnotes can contain additional information on the facts reported. In European supervisory taxonomies all data requirements are reflected by data points reflected in concepts. Information contained in footnotes will not be handled by regulators. The usage of footnotes is only allowed for filing indicators.
CWA Advice: It is not recommended to communicate reporting related information in footnotes or any other resources.

[edit]

Annex

[edit]

Open discussions

The CWA1 is aware of a problem of processing very large XBRL instances by some computer systems. XBRL International has written a specification document [12] on the subject. However, since the ordering of XML nodes and duplication of content are both against the essence of the XML specification, no criteria can be given when an instance is too large and these large instances are the exception, the CWA1 has decided not to create rules enforcing such ordering and duplication.

For clarification to the reader and for those regulators that are dealing with these very large instances, CWA1 recommends that the regulator in question enforce rules on the instance creation in which the facts, the required context, and unit nodes are put in a sequence directly after one another in order to allow software to stream the instance and thus free up memory after the fact has been validated against the context and unit. For more details on these requirements, we recommend the XBRL International specification on the subject.

[edit]

Bibliography

[1] [GFM11] Global Filing Manual (Interoperable Taxonomy Architecture Project)
[2] [EFM13] EDGAR Filer Manual U.S. Securities and Exchange Commission
[3] [FRIS04] Financial Reporting Instance Standards 1.0
[4] [Karl12] Karle, Thomas (2012): Kollaborative Softwareentwicklung auf Basis serviceorientierter Architekturen. Karlsruhe: KIT Scientific Publishing
[5] [SBR13] SBR FRIS rules 2013
[6] EIOPA: EU-wide Reporting Formats
[7] European Banking Authority
[8] Extensible Business Reporting Language (XBRL) 2.1, available at : http://www.xbrl.org/specification/xbrl-recommendation-2003-12-31+corrected-errata-2012-01-25.htm
[9] XBRL Dimensions 1.0, available at: http://www.xbrl.org/specification/dimensions/rec-2012-01-25/dimensions-rec-2006-09-18+corrected-errata-2012-01-25-clean.html
[10] XBRL Registry Specification 1.0, available at: http://www.xbrl.org/Specification/registry/REC-2009-06-22/registry-REC-2009-06-22.html
[11] XBRL Formula specification 1.0, available at: http://www.xbrl.org/Specification/formula/REC-2009-06-22/overview/Formula-Overview-REC-2009-06-22.rtf
[12] Notes on the Processing of Large XBRL Instances 1.0 at: http://www.xbrl.org/WGN/large-instance-processing/WGN-2012-10-31/large-instance-processing-WGN-WGN-2012-10-31.html

Retrieved from "https://xbrlwiki.info/index.php?title=European_Filing_Rules"

European Filing Rules

From XBRLWiki

Current revision

Contents

Foreword

Introduction

Objectives

Target Audience

Relationship to Other Work

Scope

Terms and definitions

Symbols and abbreviations

European Filing Rules

Filing syntax rules

Instance syntax rules

Context related rules

Fact related rules

Unit related rules

Footnote related rules

Annex

Open discussions

Bibliography

Views

Personal tools

Navigation

Search

Toolbox

 <span style="font-size:18pt">'''CEN Workshop Agreement'''</span>
-'''Status''': Working Group Working Draft
+'''Status''': This is a public Working Space. Please refer the official publication at
+[ftp://ftp.cen.eu/CWA/CEN/XBRL/CWA_16744-4_2014.pdf CWA 16744-4:2014]  Improving transparency in financial and business reporting - Harmonisation topics - Part 4: European Filing Rules.
+'''CEN WS XBRL Experts''': Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)
 '''Editing rules'''
 =Foreword=
+This document has been prepared by CEN/WS XBRL, under the supervision of the Secretariat of the Netherlands Standardization Institute (NEN).
-<span style="background-color:#A9D0F5">Some text</span>
+This document has been officially promulgated in the CEN website [http://www.cen.eu/work/areas/ICT/eBusiness/Pages/WS-XBRL.aspx Improving transparency in financial reporting (WS XBRL) ]
+The direct link is [ftp://ftp.cen.eu/CWA/CEN/XBRL/CWA_16744-4_2014.pdf CWA 16744-4:2014]  Improving transparency in financial and business reporting - Harmonisation topics - Part 4: European Filing Rules.
 =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 limits 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 eXtensible Business Reporting Language (XBRL) specification provides a high degree of flexibility in the creation of XBRL instance documents. In part, this flexibility stems from the nature of the syntax XML, and in part it stems from the XBRL specification itself. This document provides guidance for regulators, relating to the syntax used in XBRL instances, to enable them to make restrictions where they feel it is appropriate to do so.
-These filing rules intend to decrease the reporting burden for reporting entities in Europe thus amendments to these rules by one or more regulators may contradict this objective.
+Disclaimer:<br/>
+'''The filing rules represent a collection of recommendations to be seen as guidance to be implemented in the European supervisory reporting process. The rules are also recommended to be adopted by national supervisors for other reporting purposes when they do not contradict their needs, e.g., footnotes are sometimes necessary to explain the content of reported facts. The listed filing rules are influenced by the European Taxonomy Architecture in cases where the instance creation is implicated.'''
-This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “MUST” (strong recommendation), “SHOULD” (recommendation) and “MAY” (possibility). Organizations wishing to implement this CWA (CEN Workshop Agreement) would be expected to consider all recommendations where the terms "MUST" and “SHOULD” are used.
+This document is a listing of best practices for the benefit of clear guidance on the preparation and validation of XBRL instance documents, and to improve the interoperability among computer applications that process these instances. The consistent use of best practices facilitates the analysis and comparison of XBRL instance documents for both the reporting entities and the receiving entities in the reporting process. The rules are primarily based on regulatory needs. One goal of this document is to minimize the reporting burden on the reporting entities in Europe. However, this goal is subject to the reporting statutes legislatded by National and European regulators.
-==Objective==
+Although the only authoritative restrictions are based on the XBRL specifications and the regulatory instructions, the following set of rules helps to avoid unnecessary complications by adopting well established Best Practices.
-The following set of rules provides guidance on the preparation and validation of instance documents in XBRL format. The rules in this document aim to facilitate the analysis and comparison of reporting data as well as the interoperability of computer applications. The fundamental use case that guides the rules is the submission, by a reporting entity, of its regulatory filings, and the consumption of those regulatory filings by several reporting applications.
-==Target Audience==
+The language used to express some of the best practices is tightly connected to the environment in which these practices were developed. Guidelines stemming from the [http://www.ifrs.org/XBRL/Resources/Documents/GlobalFilingManual20110419.pdf Global Filing Manual] or the [http://www.sec.gov/info/edgar/edmanuals.htm Edgar Filing Manual] are based on [http://www.ietf.org/rfc/rfc2119.txt RFC 2119].
-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.
+On the other hand, the CEN projects are using language from [http://cen.eurofiling.info/wp-content/upLoads/data/Drafting-CEN-ISO-deliverables-CommonRulesElements.2.0.pdf CEN T/C 123].
-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.
+The guidance in this document is in the form of notes, and they will not make any emphasis on rules being a "must/shall" or "should/recommended" because this document does not have a mandate to establish such rules. Only the National and European regulators have such a mandate. The regulators can choose from the guidelines presented here in order to create their own set of rules.
+=Objectives=
+The primary objective of the CWA1 working group is interoperability. This is achieved thanks to the harmonization and guidance relating to the best practices of the XBRL taxonomy creation process, as carried out by regulators, supervisory authorities, voluntary supply chains, and others. The secondary objective is to facilitate adoption of XBRL technology, by maintaining standard technological requirements for the creation of XBRL instance documents ,and by keeping them as simple as possible. The basic use case that is the underlying controlling factor for the following guidelines is the submission, by a reporting entity, of its regulatory filings, and the consumption of those regulatory filings by (several) reporting applications.
+The following sections provide guidance on the preparation and validation of instance documents in XBRL format.
+The guidelines 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, others guidelines originate from features that are XBRL-specific, so the reasoning behind them may be less obvious.
+To ease the understanding by software developers implementing these guidelines in their reporting system, a UML model has been created to show the relationships between the different XBRL objects mentioned in this document. Some of the filing rules are accompanied by constraints defined in the Object Constraint Language (OCL). OCL is part of the UML and allows adding constraints based on the UML objects of the class model. OCL is not a programming language; it just supports the definition of technical specifications. OCL eases the understanding of the rules by using a formal language to provide an unambiguous and consistent description [Karl12, p. 106].
 ==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.
+The guidelines in this document pertain to XBRL filings. Parts of this document reiterate documentation, for the clarification of certain syntactic and semantic restrictions imposed by XBRL, but this document does not modify XBRL.  In the event of any conflict 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.
+The guidelines 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 a European supervisory authority, accompanied by an XBRL taxonomy as well as extensions of this taxonomy provided by national supervisors.
-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=
-* [http://www.xbrl.org/specification/xbrl-recommendation-2003-12-31+corrected-errata-2012-01-25.htm XBRL 2.1]
-* [http://www.xbrl.org/specification/dimensions/rec-2012-01-25/dimensions-rec-2006-09-18+corrected-errata-2012-01-25-clean.html XBRL Dimensions 1.0]
-* [http://www.xbrl.org/Specification/registry/REC-2009-06-22/registry-REC-2009-06-22.html XBRL Registry specification 1.0]
-* [http://www.xbrl.org/Specification/formula/REC-2009-06-22/overview/Formula-Overview-REC-2009-06-22.rtf XBRL Formula specification 1.0]
 =Terms and definitions=
-; Applicable taxonomy : An XBRL taxonomy recognised to use as a base for filings in a given filing system.
+; Applicable taxonomy : An XBRL taxonomy recognised to be used as a basis for filings in a given filing system.
-; Data point : A <i>data point</i> 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.
+; Data point : A <i>data point</i> is an information component that is defined by a supervisory authority and is 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 <i>dimension</i> is an xs:element in the substitutionGroup of xbrldt:dimensionItem; it relates to the ability to express multidimensional information;
+; Dimension : A <i>dimension</i> is a xs:element in the substitutionGroup of xbrldt:dimensionItem; it relates to the ability to express multidimensional information;
-  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. In a presentation view a
-  dimension can be viewed as an axis in a table.
 ; 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 : 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 a 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.
+; Footnote : A footnote is used to associate text annotations with particular facts in a 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.
+; Instance document : An instance document is a 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.
+; Linkbase : A linkbase is a XML file according to the XBRL 2.1 specification, which contains relationships between concepts, resources, and concepts, in addition to resources which provide 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.
+; Reporting entity : A reporting entity is an 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 <i>Publisher of the schema</i>
+; Taxonomy: In the context of XBRL, a taxonomy is an electronic dictionary of business reporting elements that are relevant for reporting business data. A taxonomy is composed of a XML Schema and one or more linkbases directly referenced by that schema.
-; XBRL specific terms like context, unit, period, entity, s-equal, v-equal see [http://www.xbrl.org/specification/xbrl-recommendation-2003-12-31+corrected-errata-2012-01-25.htm XBRL 2.1]
+; Taxonomy creator : See: <i>Publisher of the schema</i>
+; For XBRL-specific terms like context, unit, period, entity, s-equal, v-equal see [http://www.xbrl.org/specification/xbrl-recommendation-2003-12-31+corrected-errata-2012-01-25.htm Specification XBRL 2.1].
 =Symbols and abbreviations=
-;UML : Unified Modelling Language
+;UML : Unified Modeling Language
 ;W3C : World Wide Web Consortium
 ;XBRL : eXtensible Business Reporting Language
 ;XML : eXtensible Markup Language
-=Rules=
+=European Filing Rules=
 ==Filing syntax rules==
 <ul>
-<li><span style="color:blue; font-weight:bold">1.01 &nbsp;&nbsp;</span>
+<li><span style="color:blue; font-weight:bold">1.1 &nbsp;&nbsp;</span>
-'''The file name of an instance document SHOULD follow the rules of the national filing system.'''
+'''Filing naming'''
 <br/>
-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.</li>
+Common practice is to use the extension .xbrl for instance documents, but there is no technical restriction to use anything else. There are no restrictions on file names posed. Different naming conventions exist around the world; essentially these are conveying some kind of meaning about: the sender, the reported filing and/or the reported period. For software that is storing the file name of the instance in a relational database some restrictions on which characters may be used and the total length of the file name may be appropriate.
-<li><span style="color:blue; font-weight:bold">1.02&nbsp;&nbsp;</span>
-'''Reporting entities SHOULD use one of the taxonomies as specified in the filing system as the applicable taxonomy.'''
 <br/>
-A listing of all taxonomy files respective modules recognised in the filing system should be provided on a web location.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Rules about the file name of an instance document need to be set by the receiver of the reports, if required.'''
 </li>
-<li><span style="color:blue; font-weight:bold">1.03&nbsp;&nbsp;</span>
-'''The encoding of all instance documents SHOULD be "UTF-8".'''
 <br/>
-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.<br/>
+<li><span style="color:blue; font-weight:bold">1.2&nbsp;&nbsp;</span>
+'''Taxonomy publication'''
+<br/>
+The reporter needs to be made aware of which taxonomy should be used for the instance creation. This information should be made publicly available in an official web location to facilitate the automated processing by software.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''The publisher of the taxonomy should ensure that each taxonomy file can be localised in the internet.'''
+</li>
+<br/>
+<li><span style="color:blue; font-weight:bold">1.3&nbsp;&nbsp;</span>
+'''Taxonomy package'''
+<br/>
+The publisher of the taxonomy might provide a compressed file enclosing all relevant taxonomy files to facilitate a download for an offline processing. This taxonomy package should only include those files for which the publisher of the taxonomy is responsible becaues, redistributing files under the control of other authorities can lead to interoperability problems if the latest published versions of these files do not match. Referenced files from other parties should be downloaded from the web address of the respective owner.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''A publisher of a schema should only provide taxonomy files for download where he is the owner.'''
+</li>
+<br/>
+<li><span style="color:blue; font-weight:bold">1.4&nbsp;&nbsp;</span>
+'''Character encoding of XBRL instance documents'''
+<br/>
+The XML and XBRL specifications place no restrictions on the character encodings that may be used in instance documents. In order to avoid using a character encoding that is not supported by a receiving processor, all instances should use the UTF-8 character encoding.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''"UTF-8" is the recommended encoding for XBRL instance documents.''' [GFM11, p. 11] '''If required, the instance receiver can restrict the set of characters or scripts defined in the Unicode.'''
 </li>
  '''context''' xmlDocument '''inv''':
      self.encoding = 'UTF-8'
-<li><span style="color:blue; font-weight:bold">1.04&nbsp;&nbsp;</span>
-'''Reporting entities SHOULD use only one of entrypoint schemas as specified in the applicable taxonomy.'''
 <br/>
-It is recommended to refer to a single entrypoint in an instance document and therefore include only one link:schemaRef element.
+<li><span style="color:blue; font-weight:bold">1.5&nbsp;&nbsp;</span>
+'''Taxonomy entrypoint selection'''
+<br/>
+A taxonomy is loaded through a reference to one or more URLs, with other files in the taxonomy being included through the process of DTS Discovery. Although technically a user can reference any file in the taxonomy, a taxonomy publisher will typically nominate specific URLs which are intended to be referenced by users of the taxonomy.  These URLs are called entrypoints, and allow users to import the correct modules from the taxonomy, with different modules including different templates and different associated validation rules.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''The taxonomy publisher should provide a list of available entrypoints in the taxonomy as a list of absolute URLs.'''
 </li>
-<li><span style="color:blue; font-weight:bold">1.05&nbsp;&nbsp;</span>
-'''Instance documents MUST be XBRL 2.1 and XBRL Dimensions 1.0 valid.'''
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">1.6&nbsp;&nbsp;</span>
+'''Missing filing indicators'''
+<br/>
+Each reported fact in a filing requires to be assigned to a template of a specific reporting domain. Filing indicators are used to hold these template names. They also trigger the taxonomy validation checks. Missing filing indicators can lead to inconsistencies because the unassigned facts are not validated.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to include filing indicators in the XBRL instance to express which templates are represented by the reported facts.'''
 </li>
- '''context''' instance::isXBRLValid() : Boolean
+<br/>
+<li><span style="color:blue; font-weight:bold">1.7&nbsp;&nbsp;</span>
+'''No facts for indicated templates'''
+<br/>
+If a filing indicator is given in the XBRL instance, consistency checks are processed by the reporting system. In case no fact appears for an indicated template, the filing could be rejected because the system requires an appropriate set of fact values for the checks.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended not to include filing indicators for templates which are not addressed by the facts reported.'''
+</li>
+<br/>
+<li><span style="color:blue; font-weight:bold">1.8&nbsp;&nbsp;</span>
+'''Correct usage of filing indicators'''
+<br/>
+As filing indicators play an essential role to ensure the data quality, the receiver of the instance should check that they are correctly set by the reporting entity.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''The receiver of the instance should implement checks that reveal missing or superfluous filing indicators in an instance document.'''
+</li>
+<br/>
+<li><span style="color:blue; font-weight:bold">1.9&nbsp;&nbsp;</span>
+'''Valid XML-XBRL'''
+<br/>
+Each XBRL instance in the filing is tested for XBRL 2.1 and XBRL Dimensions 1.0 validity. In order to increase the likelihood that instance documents pass validation, filers are required to validate their compliance with the XBRL 2.1 and XBRL Dimensions 1.0 specifications prior to submission.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Instance documents are required to be XBRL 2.1 and XBRL Dimensions 1.0 valid.''' EFM13, Volume II, p.  X-Y]
+</li>
+ '''context''' Instance::isXBRLValid() : Boolean
      '''post''': result = true
-<li><span style="color:blue; font-weight:bold">1.06&nbsp;&nbsp;</span>
-'''The instance documents SHOULD be valid with regards to XBRL Formula as defined in the applicable taxonomy.'''
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">1.10&nbsp;&nbsp;</span>
+'''Valid according to the defined business rules'''
+<br/>
+XBRL allows the definition of business rules which can be discovered by XBRL software while opening the respective module referenced in the instance document. These business rules are applied on the content of the instance document to check the data quality. Tests that result in an error need to be corrected by the sending reporting entity. There may be tests that produce warnings. The need to solve these warnings depends on the content of the message and the perspective of the filer.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to have the XBRL instance document valid with regards to validation technology provided in the applicable taxonomy.'''
 </li>
- '''context''' instance::isFormulaValid() : Boolean
+ '''context''' Instance::isValidationValid() : Boolean
      '''post''': result = true
-<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-14|Comment-14]]</span>
-<li><span style="color:blue; font-weight:bold">1.07&nbsp;&nbsp;</span>
-'''Reporter extensions MUST NOT be created.'''
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">1.11&nbsp;&nbsp;</span>
+'''Taxonomy extensions by reporters'''
+<br/>
+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. However, national supervisors may extend European taxonomies. For reporters, the combination of base and extension taxonomies is regarded as a single taxonomy.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Reporters are required to reference only the taxonomy entrypoints specified by the relevant authority, and may not provide their own extension taxonomies.'''
 </li>
-<li><span style="color:blue; font-weight:bold">1.08&nbsp;&nbsp;</span>
+ '''context''' Taxonomy '''inv''':
-'''Reporters SHOULD always send the full applicable dataset for an entrypoint schema in an instance document.'''
+     self.owner = ‚European Banking Authority’
+     '''or''' self.owner = ‚European Insurance and Occupational Pensions Authority’
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">1.12&nbsp;&nbsp;</span>
+'''Completeness of amendment files'''
+<br/>
+In case corrections are needed on filings that already have been submitted, it is recommended that European Regulatory Authorities require the resubmission of the complete filing, rather than allowing partial data with just the corrected facts. It is important to ensure that all amended instances are valid according to XBRL and the business rules defined.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that European Regulatory Authorities require reporters resubmit the full report, in the event of an amendment being required.'''
 </li>
 </ul>
+<br/>
-<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-12|Comment-12]]</span>
 ==Instance syntax rules==
 <ul>
-<li><span style="color:blue; font-weight:bold">2.01&nbsp;&nbsp;</span>
+<li><span style="color:blue; font-weight:bold">2.1&nbsp;&nbsp;</span>
-'''Attribute @xml:base SHOULD NOT appear in any instance document.'''
+'''@xml:base'''
 <br/>
-XML processors interpret this attribute differently, so it should not be used.
+XBRL processors interpret this attribute differently, and there is no semantic need for this attribute.
-</li>
+XML-XBRL: The attribute xml:base may be inserted in XML documents to specify a base URI other than the base URI of the document or external entity.
-<li><span style="color:blue; font-weight:bold">2.02&nbsp;&nbsp;</span>
-'''link:schemaRef MUST contain the full URL as published on the internet'''
 <br/>
-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.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: ''' It is recommended that the attribute @xml:base not appear in any instance document. [EFM13, p. 6-7]'''
 </li>
-<li><span style="color:blue; font-weight:bold">2.03&nbsp;&nbsp;</span>
+ '''context'''xmlDocument '''inv''':
-'''xmlversion in the instance MUST be 1.0 '''
+    self.element->select(xml:base)->isEmpty()
 <br/>
-Although version 1.1 exists, XBRL instances MUST be based on version 1.0.
+<li><span style="color:blue; font-weight:bold">2.2&nbsp;&nbsp;</span>
-</li>
+'''xbrli:xbrl/link:schemaRef content'''
-<li><span style="color:blue; font-weight:bold">2.04&nbsp;&nbsp;</span>
-'''Declared namespace prefixes SHOULD be used'''
 <br/>
-Declaring unused namespaces is uncalled for and clutters the instance document.
+The taxonomy which is used by an XBRL report is identified by the URL(s) referenced by link:schemaRef elements.  Although it is often convenient to work with local copies of the relevant taxonomies, it is important that link:schemaRef elements resolve to the published entrypoint locations.  XBRL software typically provides functionality to “remap” references to URLs of published entrypoints to local copies of the taxonomy.
-</li>
-<li><span style="color:blue; font-weight:bold">2.05&nbsp;&nbsp;</span>
-'''Declared namespace prefixes SHOULD mirror the namespace prefixes as defined by schema author(s)'''
 <br/>
-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.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have the link:schemaRef element resolve to the published entry point URL.'''
 </li>
-<li><span style="color:blue; font-weight:bold">2.06&nbsp;&nbsp;</span>
-'''There MUST NOT be more than one link:schemaRef in an instance'''
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">2.3&nbsp;&nbsp;</span>
-</li>
+'''xbrli:xbrl/link:schemaRef'''
-<li><span style="color:blue; font-weight:bold">2.07&nbsp;&nbsp;</span>
+<br/>
-'''link:linkbaseRef MUST NOT be used'''
+The element link:schemaRef can occur several times in an instance. Nevertheless, taxonomy authors will make sure that only a single entrypoint schema needs to be referenced to in the instance. This entrypoint will include all required data points. (See also 1.04)
 <br/>
-Entrypoints will be defined by means of a schema. And considering footnote linkbases are not allowed, there is no use for link:linkbaseRef.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have only one xbrli:xbrl/link:schemaRef node in any XBRL instance document.'''
 </li>
-<li><span style="color:blue; font-weight:bold">2.08&nbsp;&nbsp;</span>
+ '''context''' Instance '''inv''':
-'''xs:annotation/xs:documentation SHOULD NOT be used.'''
+    self.SchemaReference->size() = 1
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">2.4&nbsp;&nbsp;</span>
+''' xbrli:xbrl/link:linkbaseRef'''
+<br/>
+Entrypoints will be defined by means of a schema. There is no use for link:linkbaseRef.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required that instances reference the taxonomies only by means of the link:schemaRef element.'''
 </li>
-<li><span style="color:blue; font-weight:bold">2.09&nbsp;&nbsp;</span>
-'''xml comments SHOULD NOT be used.'''
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">2.5&nbsp;&nbsp;</span>
+'''XML comment and documentation'''
+<br/>
+Comments inside the instance that do not get reported as a fact will be ignored by the receiver. These comments clutter the instance and are of no use to the regulator. Some instance creator tools include the software identification as a XML comment.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that relevant data is only contained in contexts, units, schemaRefs and facts of an instance.'''
 </li>
+<br/>
 </ul>
 === Context related rules ===
-<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-23|Comment-23]]</span>
 <ul>
-<li><span style="color:blue; font-weight:bold">2.10&nbsp;&nbsp;</span>
+<li><span style="color:blue; font-weight:bold">2.6&nbsp;&nbsp;</span>
-'''xbrli:xbrl/xbrli:context MUST NOT have duplicates.'''
+'''xbrli:xbrl/xbrli:context/@id'''
 <br/>
-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.
+The id attribute is meant as a unique technical key within a XML document. Semantics conveyed in the id attribute will be lost when the XML content is stored in a database (which generally works with database specific subrogated keys). Even though there is no limitation on the length of an id attribute, it is recommended to keep it as short as possible.
-</li>
-<li><span style="color:blue; font-weight:bold">2.11&nbsp;&nbsp;</span>
-'''Id attributes SHOULD NOT contain any semantic meaning.'''
 <br/>
-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.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to refrain from expressing semantics in the xbrli:context/@id node.'''
 </li>
-<li><span style="color:blue; font-weight:bold">2.12&nbsp;&nbsp;</span>
-'''There MUST NOT be unused xbrli:context.'''
 <br/>
-Unused contexts (contexts which are not referred to by facts) clutter the instance and add no value.
+<li><span style="color:blue; font-weight:bold">2.7&nbsp;&nbsp;</span>
+'''Unused xbrli:xbrl/xbrli:context'''
+<br/>
+Unused contexts (contexts which are not referred to by facts) clutter the instance and add no value to either regulator or reporter [GFM11, p. 12].
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that unused xbrli:context nodes are not included in the instance.''' [FRIS04]
 </li>
-<li><span style="color:blue; font-weight:bold">2.13&nbsp;&nbsp;</span>
+ '''context''' Context '''inv''':
-'''xbrli:identifier/@scheme MUST follow the pattern recognised in the filing system.'''
+    self.Fact.allInstances()->notEmpty()
+<br/>
+<li><span style="color:blue; font-weight:bold">2.8&nbsp;&nbsp;</span>
+'''Identification of the reporting entity'''
+<br/>
+The xbrli:identifier node combined with the @scheme allows the identification of the reporting entity by the receiver. The @scheme provides a URI which uniquely identifies the type of identifier used in the xbrli:identifier node.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to use a scheme that is prescribed by the receiving regulator.''' [GFM11, p. 11]
 <br/>
-It is recommened to use a proprietary national id code with the scheme refering to the corresponding national central bank. <br/>
 </li>
   Example: <xbrli:identifier scheme="http://www.kredittilsynet.no">NO12345678</xbrli:identifier>
-<li><span style="color:blue; font-weight:bold">2.14&nbsp;&nbsp;</span>
-'''xbrli:identifier MUST have a number or identifier recognised in the filing system as its content.'''
+ '''let''' schemeUrl : String = ‘http://www.kredittilsynet.no’ -- URL to be replaced
+ '''context''' Context '''inv''':
+    self.Identifier.allInstances()->forAll(scheme = schemeURL)
 <br/>
-See explanation on rule 2.13
+<li><span style="color:blue; font-weight:bold">2.9&nbsp;&nbsp;</span>
-</li>
+'''One reporter'''
-<li><span style="color:blue; font-weight:bold">2.15&nbsp;&nbsp;</span>
-'''All xbrli:identifier content MUST be identical.'''
 <br/>
-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.
+In general, an instance will be reported for only one reporter. Even if the content of the instance deals with a group of companies, there is only one entity reporting the instance to the regulator. The DTS author can determine the number of reporters in an instance.
-</li>
-<li><span style="color:blue; font-weight:bold">2.16&nbsp;&nbsp;</span>
-'''All xbrli:identifier/@scheme content MUST be identical.'''
 <br/>
-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.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to have all xbrli:identifier content with its corresponding @scheme to be identical.''' [EFM13, p. 6-8]
 </li>
-<li><span style="color:blue; font-weight:bold">2.17&nbsp;&nbsp;</span>
+ '''context''' Context '''inv''':
-'''All xbrli:xbrl/xbrli:context/xbrli:period date elements MUST have ccyy-mm-dd format.'''
+    self.Identifier.allInstances()->forAll(i1, i2|
+    i1 = i2 '''implies''' i1.value = i2.value)
 <br/>
-The XBRL specification of this element has made it possible to enter a date or a dateTime. European regulators only allow dates.
+<li><span style="color:blue; font-weight:bold">2.10&nbsp;&nbsp;</span>
-</li>
+'''xbrli:xbrl/xbrli:context/xbrli:period/*'''
-<li><span style="color:blue; font-weight:bold">2.18&nbsp;&nbsp;</span>
-'''xbrli:xbrl/xbrli:context/xbrli:period/xbrli:forever MUST NOT exist.'''
 <br/>
-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.
+The xbrli:startDate, xbrli:endDate and xbrli:instant elements all have data type which is a union of the xs:date and xs:dateTime types. European regulators will only allow periods to be identified using whole days, specified without a timezone.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required that all the xbrli:period date elements are valid against the xs:date data type, and that they are reported without a timezone.''' [GFM11, p. 16]
 </li>
-<li><span style="color:blue; font-weight:bold">2.19&nbsp;&nbsp;</span>
-'''xbrli:startDate and xbrli:endDate in the same context MUST NOT have the same date.'''
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">2.11&nbsp;&nbsp;</span>
+'''xbrli:xbrl/xbrli:context/xbrli:period/xbrli:forever'''
+<br/>
+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.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is not allowed to use xbrli:forever as a reporting period.''' [GFM11, p. 19]
 </li>
-  Example: a company reporting at a May 31st, 2009 fiscal year-end will have contexts whose end date-time is
+ '''context''' Context '''inv''':
-  midnight at the end of 2008-05-31 (the prior fiscal year) and contexts whose start date-times are midnight at the
+    self.Period.forever->isEmpty()
-  beginning of 2008-06-01 (the current fiscal year). It will not have any contexts with start date-time of midnight
+<br/>
-  at the beginning of 2008-05-31, and no contexts with end date-time of midnight at the end of 2008-06-01.
+<li><span style="color:blue; font-weight:bold">2.12&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.20&nbsp;&nbsp;</span>
+'''Fiscal reporting year'''
-'''In an instance document reporting a fiscal year, non-numeric facts containing text about any portion of that or a prior year MUST have an @contextRef to an xbrli:context for the reporting period year.'''
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Facts reporting information about an historic period shall be reported against the reporting period for the filing.'''
 <br/>
 </li>
   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
+  the disclosure text should be in a context for fiscal 2009.
-  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.
-<li><span style="color:blue; font-weight:bold">2.21&nbsp;&nbsp;</span>
-'''In an instance document reporting a fiscal year-to-date, the non-numeric facts containing text about any portion of the year-to-date or prior year MUST have an @contextRef to an xbrli:context representing the year-to-date.'''
 <br/>
+<li><span style="color:blue; font-weight:bold">2.13&nbsp;&nbsp;</span>
+'''Reporting period consistency'''
+<br/>
+The dates defined in xbrli:instant or xbrli:startDate / xbrli:endDate should not exceed the first or the last day of the reporting period in a single instance, as required by the regulator.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that the periods defined in the contexts refer to the same reporting period.'''
+<br/>
+Example: corrections on previous periods MAY be using a different (version of the) taxonomy to prevent possible conflicts with the receiving regulator
 </li>
-  Example: a company completes an acquisition in its second fiscal quarter. In its 3rd quarter fiscal report, the
+ '''context''' Context '''inv''':
-  Acquisitions note contains text describing that same acquisition. The 3rd quarter text should be in the context
+    self.Period.allInstances()->forAll(p1, p2|
-  for the first nine months (that is, the year-to-date).
+    p1 = p2 '''implies''' (p1.start = p2.start
-<li><span style="color:blue; font-weight:bold">2.22&nbsp;&nbsp;</span>
+    '''and''' p1.end = p2.end) '''or''' p1.instant = p2.instant)
-'''In an instance document the periods defined in the contexts SHOULD refer to the same reporting period.'''
 <br/>
-The dates defined in instant or duration should not exceed the first or the last day of the reporting period.
+<li><span style="color:blue; font-weight:bold">2.14&nbsp;&nbsp;</span>
+'''xbrli:xbrl/xbrli:context/xbrli:entity/xbrli:segment and xbrli:xbrl/xbrli:context/xbrli:scenario'''
+<br/>
+The XBRL Dimensions specification allows taxonomies to specify dimensions for use within either the segment or the scenario of the context. For consistency reasons and simplification of processing, European taxonomy authors will only use the xbrli:scenario node.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that taxonomy publishers define all dimensions for use on xbrli:scenario.'''
 </li>
-<li><span style="color:blue; font-weight:bold">2.23&nbsp;&nbsp;</span>
+ '''context''' Context '''inv''':
-'''xbrli:segment MUST NOT be used.'''
+    self.DimensionalContainer.segment->isEmpty()
 <br/>
-As xbrli:scenario and xbrli:segment elements are treated as mutually exclusive, using both of them is prohibited.
+<li><span style="color:blue; font-weight:bold">2.15&nbsp;&nbsp;</span>
+'''xbrli:xbrl/xbrli:context/xbrli:entity/xbrli:segment and xbrli:xbrl/xbrli:context/xbrli:scenario'''
+<br/>
+The xbrli:scenario or xbrli:segment element MUST NOT be used for anything other than for explicit or typed members. Custom reporter XML schema content may create problems with the regulatory system.
+<br/>
+<span style="color:blue; font-weight:bold">XML-XBRL</span>: '''The XBRL specification allows xs:any content. This means that all XML schema content can be stored (not just XBRL Dimensions).'''
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''If a xbrli:scenario (or xbrli:segment) element appears in a xbrli:context, then it is required for its children to be one or more xbrldi:explicitMember and/or xbrldi:typedMember elements, and not allowing any reporter custom content.''' [EFM13, p. 6-8]
 </li>
 </ul>
-<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-17|Comment-17]]</span>
+<br/>
 === Fact related rules ===
 <ul>
-<li><span style="color:blue; font-weight:bold">2.13&nbsp;&nbsp;</span>
+<li><span style="color:blue; font-weight:bold">2.16&nbsp;&nbsp;</span>
-'''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.'''
+'''Duplicate facts'''<br/>
+An instance document must not have duplicated fact items. Item X and item Y are duplicates if and only if all the following conditions apply:
+<ul>
+<li>1. X is not identical to Y, and </li>
+<li>2. the element local name of X is S-Equal to the element local name of Y, and </li>
+<li>3. X and Y are defined in the same namespace, and </li>
+<li>4. X is P-Equal to Y, and </li>
+<li>5. X is C-Equal to Y, and </li>
+<li>6. X is U-Equal to Y, and </li>
+<li>7. X and Y are dimensionally equivalent (d-equal in all dimensions of each of X and Y), and</li>
+<li>8. X and Y have S-Equal xml:lang attributes.</li>
+</ul>
+<span style="color:blue; font-weight:bold">XML-XBRL</span>: '''Duplicate facts are XML-XBRL syntax valid. However, the semantic meaning may be unclear.'''
 <br/>
-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.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to prohibit duplicated facts.''' [FRIS04],[EFM13, p. 6-10]
-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.
 </li>
-<li><span style="color:blue; font-weight:bold">2.25&nbsp;&nbsp;</span>
-'''@precision MUST NOT be used.'''
 <br/>
-The decimal attribute must be used instead as it holds equivalent information.
+<li><span style="color:blue; font-weight:bold">2.17&nbsp;&nbsp;</span>
-</li>
+'''@precision'''
-<li><span style="color:blue; font-weight:bold">2.26&nbsp;&nbsp;</span>
-'''@decimals value MUST NOT cause non-zero digits in the fact value to be changed to zero.'''
 <br/>
-Instance documents must not contain truncations or roundings that result in reductions of the number of significant figures.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to use @decimals as the only means for expressing precision on a fact.''' [EFM13, p. 6-12]
-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:
-{| border="1" cellpadding="2" cellspacing="0"
-! scope="col" width="70px" bgcolor="#E6E6E6" | Fact text
-! scope="col" width="120px" bgcolor="#E6E6E6" | Decimals value
-! scope="col" width="120px" bgcolor="#E6E6E6" | Interpreted value
-! scope="col" width="70px" bgcolor="#E6E6E6" | Result
-|-
-| -2345.45 || INF || -2,345.45  || &nbsp;
-|-
-| -2345.45 || 2 || -2,345.45 || &nbsp;
-|-
-| -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.
 </li>
-<li><span style="color:blue; font-weight:bold">2.27&nbsp;&nbsp;</span>
-'''The @decimals value MUST correspond to the accuracy of the corresponding amount as reported in the regulatory filing.'''
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">2.18&nbsp;&nbsp;</span>
+'''@decimals'''
-{| border="1" cellpadding="2" cellspacing="0"
-! scope="col" width="300px" bgcolor="#E6E6E6" | Accuracy of the amount
-! scope="col" width="120px" bgcolor="#E6E6E6" | 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
-|}
 <br/>
-  Examples: The table below illustrates correct use.
+The @decimals is about the accuracy of the fact value. A positive value in @decimals means the number of accurate digits to the right of the decimal point. A negative value in @decimals means the number of non-accurate digits to the left of the decimal point. A value of INF in @decimals mean than all the digits are accurate. The XBRL processors use rounding conform to the IEEE Std 754 -2008 (4.3.1) for calculation linkbase and formula validation, which means round half to even. To enable XBRL Formulae calculations to be performed on instance values for validation purposes, no truncations or rounding or any other kind of change should apply to the numeric facts in the instance. See the explanatory RFC at http://www.xbrl.org/RFC/PDU/PWD-2008-10-09/PDU-RFC-PWD-2008-10-09.html. For XBRL Formula there is a function that can perform interval arithmetic if the formula creator desires so.
+<br/>
-{| border="1" cellpadding="2" cellspacing="0"
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''The accuracy of a numeric fact is required to be expressed using @decimals, with no truncation, rounding or any change in the original fact value.'''
-! scope="col" width="250px" bgcolor="#E6E6E6" | Fact
+<br/>
-! scope="col" width="50px" bgcolor="#E6E6E6" | Value
+If the @decimals attribute of a numeric fact is not equal to “INF”, then the numeric fact is interpreted as interval arithmetic of the numeric fact ± 0.5(10 ^ -@decimals ). This rule is valuable when XBRL Formulas are used to validate the numeric facts.
-! scope="col" width="120px" bgcolor="#E6E6E6" | 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.
 </li>
-<li><span style="color:blue; font-weight:bold">2.28&nbsp;&nbsp;</span>
-'''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.'''
 <br/>
-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:
+<li><span style="color:blue; font-weight:bold">2.19&nbsp;&nbsp;</span>
+'''zero value, empty, nil value @xsi:nil'''
+<br/>
+There is a difference in reporting facts with the value zero, not present or xsi:nil='true'. It is up to the regulator to determine the meaning of the different situations.
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required for the regulator to describe the meaning of the situation @xsi:nil="true", if this is allowed on reported concepts.'''
+<br/>
+Data related to numeric based white cells could be reported with the according value, as zero or as absent. The table below shows the different possible solutions:
 {| border="1" cellpadding="2" cellspacing="0" width="70%"
 | width="60%" | &lt;p-cm-ca:CapitalRequirements decimal="0" unitRef="EUR" contextRef="ctx_1"&gt;'''0'''&lt;/p-cm-ca:CapitalRequirements&gt;
 |- valign="top"
-! scope="row" width="10%" bgcolor="#E6E6E6" | nil value
+! scope="row" width="10%" bgcolor="#E6E6E6" | nil
-| The value of the fact is not known or can't be received. || &lt;p-cm-ca:CapitalRequirements '''xsi:nil="true"''' unitRef="EUR" contextRef="ctx_1"&gt;&lt;/p-cm-ca:CapitalRequirements&gt;
+| The regulator has to stipulate the meaning. || &lt;p-cm-ca:CapitalRequirements '''xsi:nil="true"''' unitRef="EUR" contextRef="ctx_1"&gt;&lt;/p-cm-ca:CapitalRequirements&gt;
 |- valign="top"
-! scope="row" width="10%" bgcolor="#E6E6E6" | not applicable information
+! scope="row" width="10%" bgcolor="#E6E6E6" | No fact present.
-| The value is inapplicable. || The fact doesn't appear in the instance.
+| The value is unknown or inapplicable. || The fact doesn't appear in the instance.
 |}
 </li>
-<li><span style="color:blue; font-weight:bold">2.29&nbsp;&nbsp;</span>
-'''The content of a numeric fact MUST NOT have a scale factor.'''
 <br/>
-</li>
+<li><span style="color:blue; font-weight:bold">2.20&nbsp;&nbsp;</span>
-  Examples:
+'''@xml:lang'''
-  The value “twenty thousand” may appear in a numeric fact as any legal decimal representation of 20,000, such as
-, 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,
-.2000.
-  The value “20%” must not appear in a numeric fact as “20”, “20/100”, “20%” or any variation of the integer “20”.
-<li><span style="color:blue; font-weight:bold">2.30&nbsp;&nbsp;</span>
-'''For non numeric facts: The language used MUST be clearly identified.'''
 <br/>
-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).
+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). The preferred option is to have multiple languages in a single instance.
-</li>
-<li><span style="color:blue; font-weight:bold">2.31&nbsp;&nbsp;</span>
-'''@id on individual facts SHOULD NOT be used.'''
 <br/>
-The @id on individual facts is meant to connect texts in the form of a footnote, which is prohibited.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have a clear policy to define the language for non numeric facts.'''
 </li>
 </ul>
+<br/>
 === Unit related rules ===
 <ul>
-<li><span style="color:blue; font-weight:bold">2.32&nbsp;&nbsp;</span>
+<li><span style="color:blue; font-weight:bold">2.21&nbsp;&nbsp;</span>
-'''xbrli:xbrl/xbrli:unit MUST NOT have duplicates.'''
+'''Unused xbrli:xbrl/xbrli:unit'''
 <br/>
-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.
+Unused units (units which are not referred to by facts) clutter the instance and add no value to either regulator or reporter.
-</li>
-<li><span style="color:blue; font-weight:bold">2.33&nbsp;&nbsp;</span>
-'''There MUST NOT be unused xbrli:xbrl/xbrli:unit.'''
 <br/>
-Unused units (units which are not referred to by facts) clutter the instance and add no value.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to prevent unused xbrli:unit nodes to be present in the instance.''' [FRIS04]
 </li>
-<li><span style="color:blue; font-weight:bold">2.34&nbsp;&nbsp;</span>
+ '''context''' Unit '''inv''':
-'''xbrli:xbrl/xbrli:unit declarations SHOULD adhere to XBRL international unit registry content.'''
+   self.Fact.allInstances()->notEmpty()
 <br/>
-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.
+<li><span style="color:blue; font-weight:bold">2.22&nbsp;&nbsp;</span>
+'''xbrli:xbrl/xbrli:unit/* content'''
 <br/>
-http://www.xbrl.org/utr/utr.xml
+XBRL International, Inc. has released a standard numeric data type registry which has a schema with numeric type declarations, and each numeric data type is associated with consistent unit declaration measures, numerators and denominators. Use of this registry that contains all the usual units facilitates implementation in software and simplifies validation. Link: [http://www.xbrl.org/utr/utr.xml XII UTR] National supervisors that use units apart from UTR should apply for an integration of these units in this standardized registry of XBRL International Inc.
 <br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to have the xbrli:unit children referring to the XBRL International Unit Type Registry (UTR).''' [EFM13, p. 6-17]
 </li>
-<li><span style="color:blue; font-weight:bold">2.35&nbsp;&nbsp;</span>
-'''xbrli:xbrl/xbrli:unit values MUST NOT imply a scale factor on a currency.'''
 <br/>
-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”.
+<li><span style="color:blue; font-weight:bold">2.23&nbsp;&nbsp;</span>
+'''One currency'''
+<br/>
+Dealing with currency conversions in the reporting process increases the complexity of IT systems.
 <br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended for national regulators to define one currency to be accepted for monetary values in instance documents.'''
 </li>
-<li><span style="color:blue; font-weight:bold">2.36&nbsp;&nbsp;</span>
-'''An instance document SHOULD contain only a single currency unit.'''
 <br/>
-<span>Amounts that a reported should refer to only to one xbrl:unit with a xbrli:measure that content is a QName starting with iso4217. </span>
+<li><span style="color:blue; font-weight:bold">2.24&nbsp;&nbsp;</span>
+'''xbrli:xbrl/xbrli:unit/xbrli:measure'''
+<br/>
+Facts that represent amounts in any currency must be of an item that is derived from xbrli:monetaryItemType, and must thereby follow the restriction in XBRL 2.1, section 4.8.2, regarding monetaryItemType (i.e., unit measure is an ISO 4217 currency designation). Such facts may not have unit measures that express any scaling (which is covered by the @decimals attribute of the fact).
+<br/>
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have units representing currencies, to represent the actual physical value of these currencies.'''
 </li>
+ '''context''' Instance '''inv''':
+   self.Unit->select(measure.substring(1, 7) = #iso4217)->size()=1
 </ul>
 === Footnote related rules ===
 <ul>
-<li><span style="color:blue; font-weight:bold">2.37&nbsp;&nbsp;</span>
+<li><span style="color:blue; font-weight:bold">2.25&nbsp;&nbsp;</span>
-'''Footnotes MUST NOT be used in instance documents.'''
+'''Footnotes'''
+<br/>
+Footnotes can contain additional information on the facts reported. In European supervisory taxonomies all data requirements are reflected by data points reflected in concepts. Information contained in footnotes will not be handled by regulators. The usage of footnotes is only allowed for filing indicators.
 <br/>
-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.
+<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is not recommended to communicate reporting related information in footnotes or any other resources.'''
 </li>
 </ul>
-=Bibliography=
-[http://www.ifrs.org/XBRL/Resources/Documents/GlobalFilingManual20110419.pdf GFM]
 =Annex=
 [[Image:UML-filing-rules.jpg]]
+=Open discussions=
+The CWA1 is aware of a problem of processing very large XBRL instances by some computer systems. XBRL International has written a specification document [12] on the subject. However, since the ordering of XML nodes and duplication of content are both against the essence of the XML specification, no criteria can be given when an instance is too large and these large instances are the exception, the CWA1 has decided not to create rules enforcing such ordering and duplication.
+For clarification to the reader and for those regulators that are dealing with these very large instances, CWA1 recommends that the regulator in question enforce rules on the instance creation in which the facts, the required context, and unit nodes are put in a sequence directly after one another in order to allow software to stream the instance and thus free up memory after the fact has been validated against the context and unit. For more details on these requirements, we recommend the XBRL International specification on the subject.
+=Bibliography=
+[1]	[GFM11] Global Filing Manual (Interoperable Taxonomy Architecture Project)<br/>
+[2]	[EFM13] [http://www.sec.gov/info/edgar/edmanuals.htm EDGAR Filer Manual]  U.S.  Securities and Exchange Commission<br/>
+[3]	[FRIS04] [http://www.xbrl.org/technical/guidance/FRIS-PWD-2004-11-14.htm Financial Reporting Instance Standards 1.0]<br/>
+[4]     [Karl12] Karle, Thomas (2012): Kollaborative Softwareentwicklung auf Basis serviceorientierter Architekturen. Karlsruhe: KIT Scientific Publishing<br/>
+[5]	[SBR13] [http://www.sbr-nl.nl/fileadmin/SBR/documenten/NT_2013/definitief_03122012/NL-FRIS_NT2013_20121210.pdf SBR FRIS rules 2013]<br/>
+[6]	[https://eiopa.europa.eu/publications/eu-wide-reporting-formats/index.html EIOPA: EU-wide Reporting Formats]<br/>
+[7]	[http://eba.europa.eu/ European Banking Authority]<br/>
+[8]	Extensible Business Reporting Language (XBRL) 2.1, available at : http://www.xbrl.org/specification/xbrl-recommendation-2003-12-31+corrected-errata-2012-01-25.htm<br/>
+[9]	XBRL Dimensions 1.0, available at: http://www.xbrl.org/specification/dimensions/rec-2012-01-25/dimensions-rec-2006-09-18+corrected-errata-2012-01-25-clean.html<br/>
+[10]	XBRL Registry Specification 1.0, available at: http://www.xbrl.org/Specification/registry/REC-2009-06-22/registry-REC-2009-06-22.html<br/>
+[11]	XBRL Formula specification 1.0, available at: http://www.xbrl.org/Specification/formula/REC-2009-06-22/overview/Formula-Overview-REC-2009-06-22.rtf<br/>
+[12]    Notes on the Processing of Large XBRL Instances 1.0 at: http://www.xbrl.org/WGN/large-instance-processing/WGN-2012-10-31/large-instance-processing-WGN-WGN-2012-10-31.html