From XBRLWiki

CEN Workshop Agreement

Status: Working Group Working Draft

Editing rules

Editorial comments should be highlighted as follows: A comment

Text or rules in discussion (white): Some text

Text or rules already aligned (green): Some text

Text or rules to be deleted (red): Some text

Text to be delivered (blue): Some text

Contents 1 Foreword 2 Introduction 2.1 Objective 2.2 Target Audience 2.3 Relationship to Other Work 3 Scope 4 Normative references 5 Terms and definitions 6 Symbols and abbreviations 7 Rules 7.1 Filing syntax rules 7.2 Instance syntax rules 7.2.1 Context related rules 7.2.2 Fact related rules 7.2.3 Unit related rules 7.2.4 Footnote related rules 8 Bibliography

Foreword

Some text

Introduction

The rules in this document aim to facilitate the analysis and comparison of XBRL financial reporting data by computer applications and human readers. The following set of rules provides guidance on the preparation, filing, and validation of filings in eXtensible Business Reporting Language (XBRL).

This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “should” (recommendation), “may” (allowance) and “can” (possibility). Organizations wishing to implement this CWA would be expected to consider all recommendations where the term “should” is used.

Objective

The following set of rules provides guidance on the preparation, filing, and validation of filings in eXtensible Business Reporting Language (XBRL) format. The rules in this document aim to facilitate the analysis and comparison of XBRL financial reporting data by computer applications and human readers. The fundamental use case that guides the rules is the submission, by a single organisation, of its regulatory filings, and the consumption of those regulatory filings by many, initially unknown, users and software applications.

Target Audience

This document is intended for a technical audience and assumes that the reader has a working knowledge of the XBRL 2.1 and the XBRL Dimensions 1.0 Specifications and has a basic understanding of XML, Namespaces, and XML Schema. To readers with XML knowledge, many of the guidelines in this document will be familiar however, other rules originate from features that are XBRL-specific and therefore the reasoning behind these rules may be less obvious. Where appropriate, the rules are accompanied by a brief explanation.

Relationship to Other Work

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

Scope

The rules in this document have been created for regulatory filings in the context of European supervisory reporting.

In this document, “regulatory filings” encompasses authoritative financial reporting standards and generally accepted accounting principles/practices (or GAAP), regulatory reports whose subject matter is primarily financial position and performance and related explanatory disclosures, and data sets used in the collection of financial statistics; it excludes transaction- or journal-level reporting, primarily narrative reports (for example, internal controls assessments) and non-financial quantitative reports (for example, air pollution measurements).

Normative references

Some text

Terms and definitions

Authority 

Any person or organization that has the legally delegated or invested authorityComment-07, capacity, or power to provide a filing. Filer must own or control the authority name; for example, “example.com” could only be used by Example Inc. itself.Comment-08

Dimension 

xsd:element in the substitutionGroup of dimensionItem; relates to the ability to express multidimensional information; for example, profit from sales could be presented by products, regions, segments, etc; to express such relations XBRL International developed the Dimension 1.0 Specification, which enriches the general XBRL Specification with rules and procedures on how to construct dimensional taxonomies and instance documents.

Entry point 

A schema or linkbase in the taxonomy that represents the filing requirements and gets mentioned in the instance by the reporter.

Filing system 

System in which instance documents are filed, received, analysed and redistributed.

Reporting entity 

A person or entity on whose behalf a filing is made. Comment-09

Filing 

A filing is the fundamental unit of information that is transmitted to filing system for receipt, validation, and acceptance. It is the conveyance of an instance documents or series of XBRL instance documents.

Instance document 

An instance document is an XBRL file. A document originating with a filer can only be sent as part of a filing. One or more documents comprise a filing.

Publisher of the schema 

Organisation responsible for publishing a given XBRL taxonomy.

Applicable taxonomy 

A taxonomy recognised to use as a base for filings in a given filing system.

Hypercube 

xs:element in the substitutionGroup of xbrldt:hypercubeItem which represents a set of dimensions; relates to the ability to express multidimensional information; for example, profit from sales could be presented by products, regions, segments, etc; to express such relations XBRL International developed the Dimension 1.0 Specification, which enriches the general XBRL Specification with rules and procedures on how to construct dimensional taxonomies and instance documents.

Taxonomy

In this context, an electronic dictionary of business reporting elements used to report business data. A taxonomy is composed of an XML Schema and one or more linkbases directly referenced by that schema. [We have to quote this definition I just added]

Symbols and abbreviations

Some text

Rules

Filing syntax rules

• 1.1   The file name of an instance document SHOULD follow the rules of the national filing system.
  There is no prescribed way of handling instance document file names. Different naming conventions exist around the world, mostly conveying some kind of meaning about the sender, the reported filing or reported period.
• 1.2   Reporting entities SHOULD use one of the taxonomies as specified in the filing system as the applicable taxonomy.
  A listing of all taxonomy files respective modules recognised in the filing system should be provided on a web location.
• 1.3   Attribute @xml:base SHOULD NOT appear in any instance document.
  XML processors interpret this attribute differently, so it SHOULD not be used.
• 1.4   The encoding of all instance documents SHOULD be "UTF-8".
  Several standards exist on the representation and handling of text. Some of the standards like ISO-8859-1 are widely used in various countries but the standards itself are largely incompatible with each other . UTF-8 is the preferred and most used encoding in HTML documents and therefore defined as Best Practice. It is necessary to specify the encoding attribute in the prologue of an instance document.
• 1.5   Reporting entities SHOULD use only one of entrypoint schemas as specified in the applicable taxonomy.
  It is recommended to refer to a single entrypoint in an instance document and therefore include only one link:schemaRef element.
• 1.6   Instance documents MUST be XBRL 2.1 and XBRL Dimensions 1.0 valid.
  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.
• 1.7   The instance documents MUST be valid in regards to XBRL Formula as defined in the applicable taxonomy.
  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 MUST be corrected. There MAY be tests that produce only warnings. Solving these warnings depends on the message content and the filer perspective on them.
• 1.8   Reporter extensions MUST NOT be created
  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.
• 1.9   link:schemaRef MUST contain the full URL as published on the internet
  The version of any report is represented in folder names, not in URI namespaces. To correctly interpret the reported facts the proper entrypoint 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.

Comment-12

Instance syntax rules

Context related rules

• 2.1   An instance document must not contain duplicate xbrli:context elements.
  An instance document must not contain equivalent xbrli:context elements. xbrli:segment or xbrli:scenario elements are tested for equality of their children without regard to order. Contexts are defined to be equivalent if they have S-equal identifiers, equal dateUnion values for startDate, endDate and instant (respectively), and segment or scenario element children with equal QNames for each explicit dimension (either segment or scenario element is disallowed by another rule).
  Even though there is no limitation on the length of an id attribute it is recommended to keep it as short as possible. Id attributes should also be abstract and should not contain any semantic meaning.
• 2.2   Every xbrli:context element must appear in at least one contextRef attribute in the same instance.
  Unused xbrli:context elements have no benefit to users and are easily removed by the reporting entity before filing.
• 2.3   The scheme attribute of the xbrli:identifier element must follow the pattern recognised in the filing system.
  Some explanatory text and example.
• 2.4   An xbrli:identifier element must have a number or identifier recognised in the filing system as its content.
  Some explanatory text and example.
• 2.5   All xbrli:identifier elements in an instance must have identical content.
  Some explanatory text.
• 2.6   Dates in period element of the context must comply with yyyy-mm-dd format. No time is allowed in the value for dates.
  Some explanatory text and examples.
• 2.7   A context must not contain the xbrli:forever element.
  Some explanatory text
• 2.8   There must not be the same date in both xbrli:startDate and xbrli:endDate of the same context
  Note that XBRL 2.1 interprets a date used as a context start date as “midnight at the beginning of” that day. A date used as an instant or endDate in a context means “midnight at the end of” that day. For example, a company reporting at a May 31st, 2009 fiscal year-end will have contexts whose end date-time is midnight at the end of 2008-05-31 (the prior fiscal year) and contexts whose start date-times are midnight at the beginning of 2008-06-01 (the current fiscal year). It will not have any contexts with start date-time of midnight at the beginning of 2008-05-31, and no contexts with end date-time of midnight at the end of 2008-06-01.
• 2.9   In an instance document reporting a fiscal year, non-numeric facts containing text about any portion of that or a prior year must have a contextRef attribute to an xbrli:context for the reporting period year.
  For example, in a fiscal year 2009 report a company describes litigation settled in fiscal year 2007. Nevertheless, the disclosure text should be in a context for fiscal 2009. A reporting period begins at 00:00:00 of its first day and ends at 24:00:00 of its last day, which is the XBRL 2.1 default for periods. Only the date, not the time part of the ISO 8601 date-times, should be used in contexts.
• 2.10   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 a contextRef attribute to an xbrli:context representing the year-to-date.
  For example, a company completes an acquisition in its second fiscal quarter. In its 3rd quarter fiscal report, the Acquisitions note contains text describing that same acquisition. The 3rd quarter text should be in the context for the first nine months (that is, the year-to-date).
• 2.11   In an instance document the periods defined in the contexts should refer to the same reporting period.
  The dates defined in instant or duration should not exceed the first or the last day of the reporting period.
• 2.12   Only the xbrli:scenario element shall appear in any xbrli:context.
  As scenario and segment elements are treated as mutually exclusive so the use of both of them is prohibited.

Fact related rules

• 2.13   There must not be two facts having the same element name, equal contextRef attributes, and if they are present, equal unitRef attributes and xml:lang attributes, respectively.
  An instance document must not have more than one fact having S-Equal element names, equal contextRef attributes, and if they are present V-Equal, unitRef attributes and xml:lang attributes, respectively. A fact is an occurrence in an instance document of an element with a contextRef attribute. The values of the id attribute and the text content of the element are not relevant to detection of duplicate facts. Other rules forbidding equivalent xbrli:context and xbrli:unit elements ensure that duplicate values of the contextRef and unitRef attributes can be detected without dereferencing. The predicate V-Equal is as defined in the XBRL 2.1 specification. The V-Equal test is sensitive to the underlying data type, so the decimals attribute of ‘-6’ is V-Equal to decimals ‘-06.0’. In unusual cases the same fact may be presented with different levels of detail, such as “123456 Shares with decimals equal to ‘INF’”, and “120000 Shares with decimals equal to ‘-3’”. Instead of including both facts in the instance, the instance should contain only the more precise one.
• 2.14   The xbrli:xbrl element must not have any facts with the precision attribute.
  The decimal attribute shall be used instead as it holds equivalent information.
• 2.15   The decimals attribute value must not cause non-zero digits in the fact value to be changed to zero.
  If the decimals attribute of a numeric fact is not equal to “INF”, then the value is interpreted as if certain digits were zero. Instance documents must not contain truncations or roundings that result in reductions of the number of significant figures. The examples below illustrate correct and incorrect use:

  Fact text	Decimals value	Interpreted value	Result
  -2345.45	INF	-2,345.45
  -2345.45	2	-2,345.45
  -2345.45	0	-2,345.00	Error
  -2345.45	-2	-2,300.00	Error
  -2345.45	-3	-2,000.00	Error
  -2345.45	-6	0000.00	Error

  This rule is valuable when XBRL Formulas are used to evaluate the correctness of the data.

• 2.16   The value of the decimals attribute of a fact must correspond to the accuracy of the corresponding amount as reported in the regulatory filings.
  The decimals attribute influences how numbers are interpreted in XBRL and any value for the decimals attribute other than the value INF implies rounding or truncation. Use the following table to select the correct value of the decimals attribute for a fact so that it corresponds to the value as presented (most often rounded) in instance documents.

  Accuracy of the amount	Value of decimals attribute
  Exact monetary, percentage, basis point or any other amount	INF
  Rounded to billions	-9
  Rounded to millions	-6
  Rounded to thousands	-3
  Rounded to units	0
  Rounded to cents	2
  Rounded to a whole percentage	4

  
  Examples:

  Fact	Value	Value of decimals attribute
  A percentage of (exactly) 46%	.46	INF
  A (rounded) profit margin of 9.3%	.093	3
  A (rounded) amount “in thousands” of 100	100000	-3
  A (rounded) amount “in thousands” of 100	100200	-2

  The decimals attribute is not a scale factor. The decimals attribute is not a formatting code; it does not indicate that the digits in the instance must subsequently be presented to a user in any particular way.

• 2.17   The xsi:nil="true" attribute must be used only to convey a value that is different from both "zero" and different from not reporting the fact at all.
  Data related to white cells could be reported with the according value, as zero or as unknown. The table below shows the different possible solutions:

  zero value	The value of the fact is "0".	<p-cm-ca:CapitalRequirements decimal="0" unitRef="EUR" contextRef="ctx_1">0</p-cm-ca:CapitalRequirements>
  nil value	The value of the fact is not known or can't be received.	<p-cm-ca:CapitalRequirements xsi:nil="true" unitRef="EUR" contextRef="ctx_1"></p-cm-ca:CapitalRequirements>
  not applicable information	The value is inapplicable.	The fact doesn't appear in the instance.

• 2.18   The content of a numeric fact never has a scale factor.
  Examples:
  • The value “twenty thousand” may appear in a numeric fact as any legal decimal representation of 20,000, such as 20000, 20000.0, or 020000. It must not appear as “20”.
  • The value “20%” may appear in a numeric fact as any legal decimal representation of .2, such as 0.2, 0.20, 000.2000.
  • The value “20%” must not appear in a numeric fact as “20”, “20/100”, “20%” or any variation of the integer “20”.
• 2.19   The default value of the xml:lang attribute on non-numeric facts is equal to the default language.
  Some explanatory text and examples.

Unit related rules

• 2.20   Element xbrli:xbrl must not have duplicate child xbrli:unit elements.
  Element xbrli:xbrl must not have equivalent child xbrli:unit elements. Units are equivalent if they have equivalent measures or equivalent numerator and denominator. Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators are equivalent if they have a set of equivalent measures.
• 2.21   An instance document must not contain unused units.
  Some explanatory text
• 2.22   If a standard numeric data type registry namespace is in the DTS of an instance document, then the value of each 'unitRef' attribute on each fact of a type in that registry must refer to a unit declaration consistent with the data type of that fact, where consistency is defined by that registry.
  XBRL 2.1 already enforces the requirement that a fact of type xbrli:monetaryItemType must have a unitRef whose xbrli:measure is an ISO standard currency. A standard numeric data type registry is similar but broader: it has a schema with numeric type declarations, and each numeric data type is associated with consistent unit declaration measures, numerators and denominators.
  http://www.xbrl.org/utr/utr.xml
  Comment-03
• 2.23   Do not define or use units that imply a scale factor on a currency.
  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”.
  Comment-04
• 2.24   It is recommended to refer only to one currency in an instance document.
  Amounts that a reported should refer to only to one xbrl:unit with a xbrli:measure that content is a QName starting with iso4217.

Footnote related rules

• 2.25   Footnotes must not be used in instance documents.
  The tables of the European reporting frameworks consist of white, gray and crisscrossed cells. White cells can be reported if data is available and can be retrieved from the database of the reporting entity. Gray cells could be reported but they are not mandatory because the level of detail is excluded from the reporting. Crisscrossed cells make no sense from an economic point of view. Additional information to white cells outsourced in footnotes are not allowed.

Bibliography

Some text