How to prepare and publish filing rules

1 Introduction

Filing rules specify technical requirements of a filing system that must be satisfied by XBRL reports. This guidance explains the need for filing rules in an XBRL programme, provides a list of common classes of filing rules and identifies categories of filing rules that are not recommended. The guidance also provides recommendations on how to publish filing rules in a consistent manner.

This guidance is primarily targeted at XBRL report collectors.

2 Types of rules

One of the goals of an XBRL reporting programme is the collection of good quality data for analysis and further consumption. 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. Examples of business validation rules include:

• ensuring that mandatory facts are reported;
• checking that aggregated values are the sum of their children; and
• ensuring that negative values are not reported for a concept that should only have positive values.

Separate guidance on implementing business rules in XBRL programmes discusses possible approaches to the implementation of such rules.

Validation rules that are driven by the technical requirements of a filing system are referred to as filing rules. Filing rules are additional technical constraints beyond those imposed by the XBRL specifications. Examples of filing rules include:

• specifying which versions and modules of the XBRL specifications may be used in filings;
• defining any applicable file size limits; and
• restrictions on whether and how extension taxonomies should be constructed.

Data collectors may also publish non-automatable rules and tagging guidance to help preparers create XBRL reports. These may include choosing the right tags, explaining the extent to which tagging is required, specifying the precision to which facts need to be reported, guidance on extending elements, and other related issues. The application of such guidance cannot typically be automatically validated by XBRL processors, as it requires the judgement of preparers to apply correctly.

This document focuses on filing rules, the technical constraints imposed on an XBRL document within a filing programme. Figure 1 summarises the different types of rules and guidance which may be specified by a data collector.

Figure 1: Classes of filing rules and guidance

Wherever possible, filing programmes should refer to and re-use XBRL International best practice rules and guidance so that validation rules and filing guidance published by the data collector are restricted to issues that are specific to the programme. This improves consistency between filing programmes and thus minimises the effort needed by preparers and software developers in creating filings.

3 Why are filing rules needed?

Filing rules are needed to ensure that a submitted XBRL report complies with the technical requirements of the relevant filing system. For example, a filing system will typically only accept reports that have been prepared using a taxonomy approved by the collector, and so a filing rule is required to ensure that XBRL reports only use an approved taxonomy as their taxonomy entry point. Filing rules are typically validated by the collector at the point of submission, resulting in a rejection of a filing if it does not comply.

4 What issues can filing rules create?

Whilst filing rules are essential to ensure that XBRL reports meet the collector's requirements, unnecessary filing rules create a burden for software developers, and can create interoperability issues.

XBRL and iXBRL reports must comply with the constraints specified in the XBRL, iXBRL and related specifications. Compliant processors are required to be able to consume any report that complies with the relevant specifications, and this is tested by the comprehensive conformance suites that accompany the specifications. This ensures a very high level of interoperability between XBRL software products. In other words, it ensures that a report created in one piece of XBRL software can be consumed in any other and therefore additional syntax-level rules are not generally needed.

An example of an unnecessary and potentially harmful rule would be one which specifies additional constraints on the ordering of the elements within an XBRL report beyond that required by the XBRL specification. All compliant XBRL processors are required to consume such elements in any order allowed by the specification, so specifying additional constraints on the ordering provides no benefit to consumers. On the other hand, it creates an additional burden for preparers who may need to modify compliant XBRL software in order to satisfy this additional constraint. Further, if different programmes introduce different technical syntax rules, software solutions may cease to be reusable across markets.

It is recommended that filing rules are kept to a minimum, and in particular, unnecessary syntax-level constraints should be avoided.

5 Classes of filing rule

This section lists the classes of filing rules commonly found in reporting systems.

5.1 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 specification modules and versions to be used when creating XBRL reports. Examples of such rules are:

• 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.

5.2 Allowed taxonomies

Filing rules should specify the reporting taxonomies that reports may be prepared using. The recommended way of referencing a base taxonomy in XBRL documents is to use the official URL for the taxonomy (see Taxonomy Publication guidance). Filing rules should list the valid taxonomy URLs that may be referenced in XBRL reports or extension taxonomies.

The above rule is often complemented by a business rule that specifies the applicable reporting periods for different taxonomy versions or indicating the source from which preparers can get such information.

5.3 Constraining built-in dimensions

The requirements around reporting the content of built-in-dimensions (period, units, entity identification) are derived from the business domain, but filing rules need to specify the expected technical syntax for expressing these. Examples of such rules are:

• Defining the “scheme(s)” to be used for entity identification.
• Specifying whether the period dimension may be used to identify specific times of day, or just whole days.
• Units should typically be constrained by requiring compliance with the Unit Type Registry specification.

5.4 Approach to duplicates

XBRL reports may include duplicate facts, that is, two or more facts that purport to provide the same piece of information. 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 facts. The issues surrounding the use of duplicate facts, and recommended approaches for dealing with them are laid out in a separate working group note.

5.5 iXBRL rules

In a reporting programme collecting iXBRL reports, there are a few additional technical issues which should be addressed by filing rules. For example:

• It is possible to generate one single XBRL output from multiple iXBRL documents (an “iXBRL Document Set”) and also to generate multiple XBRL reports from a single iXBRL document. Whether either of these options is permitted should be specified by filing rules.
• iXBRL filing rules typically include HTML-related constraints on the inclusion of executable scripts or references to external resources such as images and stylesheets.

5.6 Taxonomy extension rules

In a reporting programme that allows or requires filers to provide extension taxonomy, filing rules should be provided to constrain the construction and content of such extension taxonomies. Examples of such constraints include:

• Which components from the base taxonomy should be used (e.g. labels, presentation tree, calculation tree, dimensions).
• What labels must be provided for any new concepts introduced by an extension taxonomy.
• How new concepts are required to be linked to base taxonomy components using presentation, calculation, dimensional or other relationships.

5.7 Submission-related rules

Filing rules should specify, in a separate section of the document to rules about the content of the XBRL report, how the XBRL report must be submitted in a collection system. Examples of submission-related rules include:

• Details of the submission protocol (i.e. how the filing is to be provided to the collector, including details of any required security mechanism(s)).
• Whether the filing should be provided in an archive format such as a ZIP file, and if so, how the contents of the archive should be arranged. This is particularly relevant where a submission may include multiple files, such as a report and an accompanying extension taxonomy (see the Report Packages Working Group Note for more information on this topic).
• Any file size limitations on the filing.
• Details of any digital signatures that are required on the filing.

6 Filing rules to be avoided

As discussed above, unnecessary filing rules create a burden on preparers and software developers, and can ultimately harm interoperability. This section discusses some types of filing rule which are not recommended.

6.1 Syntax-level constraints

It is generally not recommended to define filing rules that specify constraints on syntax which is allowed by the XBRL specifications.

The following are examples of syntax-level constraints which not should be defined as filing rules.

• A filing rule which specifies an ordering of the elements in an XBRL report (schemaRef, linkbaseRef, roleRef, arcroleRef, context, units, facts, footnotes) beyond that required by the XBRL specification. This imposes unnecessary constraints on XBRL software to create the XBRL report in a specific way. As well as creating an implementation burden, it would create an interoperability issue if different collection systems adopt differing ordering requirements.

• Filing rules which specify the format of context IDs, unit IDs or any other similar identifiers. Such identifiers carry no semantic information and software should be free to assign values to them using any approach that conforms with the relevant specifications. Prescribing rules for their format requires software to be modified in order to meet these additional constraints, and as for the previous example, further constraints serve only to create an implementation burden and create possible interoperability issues.

• Rules restricting unused or duplicate contexts and units in an XBRL report are not recommended. These syntactic constructs do not alter the semantics of the XBRL data.

The XBRL Open Information Model is an effort to formally define the semantic information conveyed by an XBRL report. Whilst this is still under development, public drafts are available, and as a general guide, filing rules should avoid constraining details that are not part of this model.

6.2 Restatement of specification rules

It is not recommended to include filing rules that simply restate the validation required by an XBRL specification. Restatement of specification rules does not add any value, as filings are already required to conform to the rule as stated in the specification. Further, such restatements of a rule may include subtle differences that can lead to interoperability issues, and cause confusion by distracting from those filing rules which do impose additional constraints.

For example, a filing rule that specifies that all monetary facts should have units taken from ISO currency list duplicates the constraint in XBRL 2.1. Another example of such a rule is “The default member of any axis should not be reported in any context”, which restates the requirements of the Dimensions 1.0 specification.

If it is deemed necessary to highlight particular parts of the specifications to preparers and software developers then this should be provided as additional guidance material, and not presented as a filing rule.

6.3 Non-automatable rules and guidance text

It is not recommended to include non-automatable rules, guidance or instructions as filing rules. Whilst such materials can be of value to preparers and software developers, they should be clearly distinguished from automatable filing rules.

Some examples of such non-automatable rules/guidance are:

• The value of the decimals attribute of a fact must correspond to the accuracy of the corresponding amount as reported in the financial statements.
• A "nil" fact must be used only to convey a value that is different from both “zero” and from not reporting the fact at all.
• If no value is entered for a dimension that has a default, then the default value shall be inferred.
• Do not define or use units that imply a scale factor on a currency.
• Text that is shown in a business report at the bottom of a page or at the bottom of a table preceded by a superscript must be reported in the instance as a footnote.

7 Creating and publishing filing rules

This section recommends best practices for the creation and publication of filing rules. Adopting these practices can help preparers gain a better understanding of the filing rules and ease the efforts of software vendors to implement the rules in their solutions.

7.1 XBRL formula rules

XBRL formula rules allow the definition of validation rules in a taxonomy. This enables conformant XBRL software to check the rules with no custom coding required. It is recommended to define filing rules as XBRL formula rules wherever possible.

Preparers using conformant XBRL software can then check conformance with the filing rules locally before submitting a report to the collection system. Implementing filing rules as XBRL formula rules also ensures that there is no ambiguity in rule interpretation.

7.2 Rule identifiers

Rules should be given a unique identifier. Identifiers should be persistent throughout subsequent versions of the filing rules document if possible.

7.3 Human-readable description of the rules

In addition to publishing rules in an executable format such as XBRL formula, it is recommended to publish a clear, human-readable description of all filing rules.

A human-readable description of the rules should include a reference to the unique identifier for each rule. This unique identification number can be used for cross-referencing in error reports sent from the collection system or in software solutions to inform preparers of the exact filing rule being referred to.

Providing a human-readable description of the rules also makes it easier for developers of filing software to understand the validation being applied, allowing them to design solutions that will prevent the creation of invalid filings in the first place. This can provide a better user experience than allowing the creation of invalid filings and checking them with validation rules which may result in potentially complex error messages.

The human-readable description of the filing rules, being external to the taxonomy, should always carry a reference to the version of the taxonomy to which it applies and the date on which the rules come in to force.

7.4 Test suite for the filing rules

A test suite is a collection of example filings documented with their expected validation behaviour (i.e. whether they are expected to pass or fail filing rule validation). Creation of test suites can help ensure that published filing rules are implemented correctly and can help software developers understand the details of a rule. It is recommended to publish a test suite for filing rules. Each filing rule should have one or more test cases to check compliance at the rule level.

7.5 Test services for the filing rules

A test service serves as a mock environment to check how XBRL reports would be validated by the collection system. Filings submitted to the test service are not subject to downstream processing by the collector.

Test services typically serve two separate functions: assisting software developers in the development of report creation software; and helping preparers to perform pre-submission checks to ensure their XBRL report passes all required validation rules.

It is recommended that a test service(s) for filing rules should be made available to meet the requirements of both software developers and preparers. Collectors should recognise that the test services for software developers and preparers may have different requirements in terms of performance, capacity and security.

7.6 Reusing filing rules

Filing rules are specific to the particular requirements of a reporting system. As such, collectors should avoid copying rules from other projects without carefully considering whether the rule is necessary and applicable to that reporting system. For example, whilst one system may need to implement a submission size limit of 2GB due to limitations in backend or processing systems, other collectors should consider what file size limit, if any, is actually applicable in their own system before implementing such a rule.