1 Introduction

Automated validation rules can play a key role in ensuring the quality of XBRL reports. Validation rules that are backed by requirements from the underlying business domain are referred to as business validation rules, whereas validation rules that are driven by the technical requirements and limitations of a filing system are referred to as filing rules.

XBRL best practice recommends minimising the use of filing rules as they create a burden for software developers and preparers and can create interoperability issues. A separate piece of guidance discusses the broad principles for creation and publication of filing rules.

This guidance provides a checklist of commonly found filing rules. It also provides examples of the types of rule that should not be included as filing rules. This checklist is intended to be used as a reference while defining filing rules for an XBRL reporting programme. This guidance is targeted towards XBRL and iXBRL report collectors.

The filing rules discussed in this document are provided as guidance only. Data collectors should consider whether each rule is necessary and applicable to their reporting system.

2 Scope

This guidance covers filing rules applicable for XBRL/iXBRL reports. The guidance is not intended to provide a comprehensive list of filing rules. The taskforce studied filing rules across XBRL programmes such as SBR (Netherlands), CRD IV (including a number of country-specific CRD IV implementations), HMRC (UK) and SEC (US).

This guidance does not cover filing rules that relate to extension taxonomies. The task force plans to cover this in the future as a separate piece of guidance.

3 Filing Rules

This section describes filing rules for different categories, such as those related to submission, use of Inline XBRL, report contents and built-in dimensions.

3.1 Rules related to the submission of reports

Restrictions are often placed on the format in which the filing is submitted.

3.1.1 Number of files

Requirements for the number of files in a submission vary by reporting environment. In an XBRL reporting environment, filing rules should specify the number of XBRL report files required. In an iXBRL reporting environment filing, rules should specify the number of Inline XBRL documents that can be included in an Inline XBRL document set. Filing rules may also specify the inclusion of other XBRL file types (for example, to require an extension taxonomy schema and linkbase) or other non-XBRL files.

3.1.2 File name suffixes

Filing rules should specify which suffixes are acceptable for use on submitted files. The Report Packages Working Group Note recommends:

• .xbrl for XBRL reports.
• .html for iXBRL reports.

.xml and .xhtml are also in common use for XBRL and iXBRL reports, respectively. It should be noted that the choice of suffix for iXBRL reports can influence how browsers will render the report.

Where an extension taxonomy is submitted alongside the report, .xsd and .xml should be used for schema and linkbase files respectively.

3.1.3 File naming

Filing rules may specify file naming conventions to ensure consistency. Any file naming conventions specified should be possible to validate automatically.

3.1.4 File compression

Many regulators may require or permit reports to be compressed in order to allow for the packaging of extension taxonomies or for the collection of large files. Filing rules should specify whether compressed submissions are acceptable and/or required, including the permitted compression formats. The Report Packages working group note defines the preferred approach for combining XBRL and iXBRL reports within an accompanying taxonomy package for submission to a filing system.

3.1.5 File size

If a collection imposes a limit on permissible file size then this should be specified by filing rules. Guidance should also be provided on how to comply with these restrictions, for example by compressing the files contained within a submission.

3.2 iXBRL-specific rules

This section covers filing rules that are specific to Inline XBRL (iXBRL) reporting systems.

3.2.1 Multiple target documents

iXBRL allows the generation of multiple XBRL reports from a single iXBRL report. The XBRL reports generated from an iXBRL report are referred to as a “target documents”. Filing rules should specify if multiple target documents are permitted, and if so the number of target documents allowed and the rationale and the reporting scenarios for which they should be used.

3.2.2 Images in iXBRL reports

Filing rules should specify if images may be included in iXBRL reports, and if so whether they should be embedded in the report, or referenced as separate files. If the images are to be referenced as separate files, filing rules should specify if they must be provided as part of the filing, or if references to external images are acceptable.

3.2.3 Executable code in iXBRL reports

An iXBRL report, being an XHTML document, may include executable codes (e.g. Java applets, javascript, VB script, Shockwave, Flash, etc). Such executable code can be a potential security threat. Filings rules may be defined to restrict executable code in the HTML <script> element or elsewhere within the file.

3.2.4 CSS in iXBRL reports

iXBRL allows preparers to retain fine-grained control over the presentation of their report through the use of CSS. Filing rules should specify if the CSS must be embedded in the iXBRL report, or referenced from an external file. If an external file is used, filing rules should specify if the this needs to be submitted as the part of the filing.

Additionally, filing rules may constrain certain features of CSS. For example, CSS can be used to provide different styling for print, or for specific screen sizes.

3.2.5 Hidden Content

iXBRL allows facts to be reported in a “hidden” section. Such facts are not linked to information in the document that is displayed when a user views the document in a browser. Although the use of the hidden section is sometimes necessary for technical reasons, its use should be minimised as it is preferable for facts to be linked to the preparer’s presentation wherever possible.

Filing rules should specify the circumstances in which a hidden section may be used in an iXBRL report. One possible approach to this is to specify a list of allowed data types for concepts that may be included in the hidden section.

3.3 Taxonomy references

The recommended way to reference a base taxonomy in an XBRL document is to use the official URL for the taxonomy (see separate guidance on Taxonomy Publication). Filing rules should list the valid taxonomy URLs that may be referenced by reports and extension taxonomies. This rule is often complemented by a business validation rule that specifies the applicable reporting periods for different taxonomy versions or the source from which preparers can get such information.

3.4 Allowed standards and versions

The XBRL standard is made up of a number of interrelated, modular technical specifications. A reporting system will use the specification modules that best meet its requirements. In some cases, a number of different versions of a specification may exist. Filing rules should therefore specify the XBRL specifications and versions to be used when creating and processing XBRL reports.

Examples of such rules are:

• XBRL reports must be created using XBRL 2.1 and Dimensions 1.0. Note that these two are considered to be core specifications.
• iXBRL reports must be created using Inline XBRL 1.1 and using transformations from Transformation Rules Registry version 3.
• Units reported in the XBRL report must comply with the Unit Type Registry 1.0 (UTR) specification.
• XBRL reports will be evaluated against XBRL formula rules using Formula 1.0.
• The filing system will render XBRL reports as per XBRL reporting templates defined in the taxonomy using Table Linkbase 1.0.

3.5 XBRL formula rule results

Where XBRL formula rules are defined, filing rules should specify how rule failures will be treated. For example, a filing system may reject reports that have rule failures with an “error” severity, but accept filings if the only rule failures have a “warning” severity.

3.6 XBRL content rules

This section lists filing rules that define or restrict the content of XBRL reports

3.6.1 Language identification

Text facts and footnotes can be reported in multiple languages in an XBRL or iXBRL report. Filings rules should specify the language or languages that may be used in a report to identify textual content. If multiple languages are allowed, filing rules should specify whether preparers can use more than one language in a single report.

Filing rules should specify the treatment given to facts that are differentiated only by the language property. Refer to the working group note on duplicates for more information on multi-language duplicates.

3.6.2 Footnotes

Filing rules should specify whether footnotes are allowed in an XBRL/iXBRL report. The XBRL standard allows two types of footnotes:

• Linking a fact to explanatory text ("fact-footnote")
• Linking two facts ("fact-factexplanatoryFact")

For reporting environments that accept footnotes, filing rules should specify the types of footnote that are allowed. Generally, this filing rule is also complemented by footnote usage guidance. For example, the data collector may allow footnotes to be used for capturing explanations, or referencing an explanatory document.

3.6.3 Nil facts

XBRL reports can have fact values reported with a special value of "nil" (nil facts). This is distinct from both reporting the fact with a value of "0" or omitting the fact from the report entirely. Filing rules should specify if such nil facts can be reported.

Ideally the usage of nil facts should be controlled by the taxonomy, as concepts can be defined as being “nillable” or not, but if third party taxonomies are used then this will need to be specified as a filing rule. This rule should be complemented by guidance explaining where nil facts should be used and how such facts will be interpreted by the filing system.

3.6.4 Duplicate facts

XBRL reports may include duplicate facts, that is, they may provide multiple values for the same data point. This is common in iXBRL reports, as the same fact may be presented multiple times in different sections of the report. Recommended practice is to tag all occurrences of such facts, which may lead to duplicate facts when XBRL data is extracted from the report.

Duplicate facts are not prohibited by the XBRL specification, but a data collector must specify how such facts will be handled. This may include filing rules that cause the rejection of filings with certain types of duplicate fact. The issues surrounding the use of duplicate facts, and recommended approaches for dealing with them, are laid out in a separate working group note.

3.7 Constraining built-in dimensions

Filing rules can be used to place additional constraints on the use of built-in dimensions to incorporate the specific requirements of the reporting programme.

3.7.1 Entity identification

Facts in XBRL reports specify an entity to which they relate using the "entity" built-in dimension, which combines an identifier for the entity with a URI identifying the scheme from which that identifier is taken.

Filing rules should specify which entity identification schemes may be used and the allowed entity identifier format. An example of such rule is as follows:

• The entity identifier value must be the Legal Entity Identifier of the reporting entity. The entity identifier scheme must be http://standard.iso.org/iso/17442

See the guidance on Multiple Entities for more information on identifying entities in an XBRL report.

3.7.2 Period reporting

Periods in XBRL reports are identified using "date times" – the combination of a date and a time of day - but it is common for business reports to identify reporting periods using only dates. This is represented in XBRL by specifying dates with a time of "00:00:00" ("midnight").

Filing rules should specify whether it is acceptable to use dates with a time other than midnight. Note that the XBRL syntax permits the time component of dates to be omitted, and the XBRL specification defines how such dates are converted into date times. Filing rules should not require or restrict the use of this abbreviated form.

Filing rules should specify whether the date should be reported with the relevant time zone or with no specified time zone. XBRL provides a special period of "forever". Filing rules should specify whether the "forever" period is permissible and if so, the scenarios in which it can or should be used.

3.7.3 Unit

The Units Types Registry provides a centralised list of units, to promote consistent use of units across preparers and jurisdictions. Filing rules are encouraged to specify that units used in XBRL/iXBRL reports must comply with the Units Type Registry. Business validation rules may impose further restrictions on the units that may be used in a report. For example, by the specifying the currencies that may be used in a report.

3.7.4 Non-dimensional elements

Filing rules should forbid the use of non-dimensional elements in the "segment" or "scenario" container. This recommendation is in line with the working group note on Technical Considerations for the use of XBRL Dimensions 1.0 and the proposed Open Information Model aiming to achieve a simplified, logical view of XBRL data.

3.7.5 Dimensional container

For historical reasons, XBRL provides two alternative elements ("segment" and "scenario") which may be used to contain dimensional information. Data collectors should constrain the use of these containers, so that only valid dimensional information is included in the report. Specific recommendations on how to do this can be found in the Technical Considerations for the use of XBRL Dimensions Working Group Note.

The recommendations of the working group note are primarily related to taxonomy construction, although the final recommendation of section 2.1 is to constrain the use of the unused dimensional container through an external mechanism. It is recommended that this is implemented as a filing rule.

4 Examples of rules to be avoided

Unnecessary filing rules create a burden on preparers and software developers, and can ultimately harm interoperability. This section includes some examples of rules which are not recommended to be used as filing rules. XBRL report collectors in general should ensure the following types of rules are not defined as filing rules. Whilst report collectors should not prescribe specifc syntactic constraints as discussed in this section, preparers are encouraged to produce concise and efficient documents.

4.1 Avoid restricting unused namespaces

Filing rules should not restrict the inclusion of unused namespace bindings in XBRL documents. Although such declarations are superfluous, they are harmless, and enforcing such a constraint imposes an unnecessary burden on software.

4.2 Avoid restricting unused ID attribute facts

Filing rules should not restrict the use of unreferenced ID attributes on facts. IDs are useful to uniquely identify facts in XBRL/iXBRL reports and they also enable fact navigation between extracted XBRL data and iXBRL reports. IDs are helpful to maintain traceability to and from other source data files or systems.

4.3 Avoid prescribing specific namespace prefixes

Data collectors often define namespace prefixes that must be used for specific namespaces in XBRL or iXBRL reports. The semantics of elements are derived from the namespace and not the namespace prefix. Prefixes are not required to be globally unique, and the constraints of using specified prefixes create additional work for software developers. Filing rules should not prescribe the use of canonical prefixes, but data collectors may publish a list of preferred prefixes as guidance separate from their filing rules.

4.4 Avoid constraints that can be built into the taxonomy

Wherever possible, constraints on the content of report should be built into the taxonomy. Rules that do not leverage the built-in taxonomy validation mechanisms create an additional burden for software developers. Examples of constraints that can be defined in a taxonomy include:

• String facts must not start or end with space characters
• A fact value (string) must not be greater than 2048 characters in length
• ix:tuple and ix:fraction must not be used

4.5 Avoid imposing additional element order constraints

Filing rules should not specify constraints on the ordering of elements within an XBRL report (<schemaRef>, <linkbaseRef>, <roleRef>, <arcroleRef>, <context>, <units>, <facts>, <footnotes>) beyond those required by XBRL specifications. Specifying additional constraints on the ordering provides no benefit to consumers, and imposes an unnecessary burden on software developers, and harms interoperability.

4.6 Avoid specifying naming conventions for context IDs and other identifiers

ID attributes are used to reference elements in an XBRL report (such as <context> and <unit> elements). Data collectors should not prescribe formats or semantics for such IDs in their filing rules. Report creation software should be free to assign IDs freely, within the constraints imposed by the specification.

4.7 Avoid the use of XML comments and processing instructions to capture filing metadata

XML comments and processing instructions are easy ways to define filing metadata such as software application, creation date and author. However, there is no mechanism for defining or constraining the information that appears within comments or processing instructions. XBRL facts should be used to convey such information, possibly in a different namespace from the business elements. Filing rules should not expect preparers to report information in XML comments and/or processing instructions.

4.8 Avoid restricting unused contexts/units

Filing rules should not restrict the inclusion of unused contexts and units. Unused XBRL contexts and units are allowed by the XBRL specification, and do not alter the meaning of the report. Prohibiting their inclusion places an unnecessary burden on preparation software.

4.9 Avoid restricting duplicated contexts/units

Duplicated contexts and units are allowed by the specifications and their removal does not add business value. It takes more processing resources to identify duplicate context and units, hence it is recommended that filing rules do not restrict duplicate context or units.

4.10 Avoid restating specification constraints

Filing rules should not simply restate constraints that are already required by XBRL specifications. Examples of such filing rules include:

• Specifying date formats for the "period" aspect
• Requiring monetary facts to be associated with a currency unit (defined by ISO 4217)

Duplication of specification constraints does not add any value, as XBRL reports are already required to conform to these rules. Further, such restatements of a rule may include subtle differences that can lead to interoperability issues or cause confusion by distracting from those filing rules which do impose additional constraints.

If it is deemed necessary to highlight particular parts of the XBRL specification to preparers and software developers then this should be provided as additional guidance material, and not presented as a filing rule. Such guidance material should provide a reference to relevant sections of the specification.

4.11 Avoid restricting syntax for reporting precision

The precision to which numeric facts are reported in XBRL/iXBRL reports may be stated as either the number of decimal places (using the "decimals" attribute) or the number of significant figures (using the "precision" attribute), with "decimals" being more common. The two approaches are alternative syntactic mechanism for conveying the same information. The XBRL specification prescribes how to convert between the two syntaxes and conformant XBRL tools will be able to perform this conversion.

Data collectors may consider defining business rules on the minimum required precision for numeric facts but should not restrict the syntax required for reporting precision.

5 Summary

This guidance provides a checklist of recommended XBRL filing rules. The guidance is expected to be used by data collectors defining their own filing rules. The guidance is not intended to provide a comprehensive list of filing rules as many will be dependent on the individual reporting programme. Data collectors are expected to analyse the requirements of their filing system and carefully consider whether each rule is necessary before introducing them as filing rules.