Learning Objectives

By the end of this section, readers will be able to:

  • Understand the purpose and importance of filing rules in regulatory reporting
  • Identify the different types and categories of filing rules
  • Understand the benefits of having consistent filing rules
  • Apply best practices in the preparation and publication of filing rules
  • Address common challenges and avoid errors in the implementation of filing rules

Introduction

Preparing and publishing filing rules is essential for managing a digital reporting system. Filing rules are driven by the technical requirements of the reporting programme to ensure interoperability. These rules define how XBRL reports must be structured and submitted, covering technical aspects such as file formats, naming conventions, size limits, and which specifications or extensions are allowed.

Filing rules help reduce avoidable errors, such as reports being submitted in the wrong format or exceeding size limits. By clarifying expectations, they ensure that submissions are compatible with the regulator’s platform, simplify the submission process and reduce the need for manual corrections. This section outlines how to create and publish clear, enforceable filing rules aligned with the reporting environment’s technical requirements.

Types of Validation Rules

Validation rules are grouped into two categories:

  • Filing rules: These focus on how a report is built and delivered. They cover things like file formats, naming conventions, size limits, and approved versions of the XBRL specifications. These rules ensure that the submission can be read and processed by the system.

  • Business validation rules: These focus on the report content. They help verify that the reported information is complete, consistent, and logically accurate. For example, they may require that certain facts are always reported or that totals match the sum of their parts.

The following table compares the two categories of validation rules:

Aspect Business Validation Rules Filing Rules
Definition Checks based on regulatory or business logic Technical constraints for system compatibility
Scope Ensure data completeness, consistency, and correctness Ensure the report can be accepted and processed by the submission system
Implementation Defined inside the taxonomy using XBRL formula rules Often external to the taxonomy
Validator Evaluated by XBRL processors Enforced by the regulator’s platform or custom tooling
Examples Required totals, valid dimensions, no negative values File size limits, naming formats, taxonomy reference URLs

This section focuses on best practices for filing rule creation and publication. For details on business rules and validation implementation in XBRL reporting systems, see Validating XBRL Data: Why and How?

Challenges with Filing Rules

While some filing rules are essential to ensure that XBRL reports meet the collector’s requirements, unnecessary filing rules create a burden for software developers, and may introduce interoperability issues.

Filing Rule Challenges

XBRL and iXBRL reports must comply with the constraints specified in the XBRL, iXBRL and related specifications. Compliant processors (see certified software list) 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 high level of interoperability between XBRL software products. In other words, a report produced using one XBRL software product can be processed by any other. Therefore, additional syntax-level rules are usually not 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.

Types of Filing Rules

Filing rules play a crucial role in aligning XBRL reports with the specific requirements of data collectors. However, it’s important to distinguish between essential rules and those that may inadvertently introduce technical burdens or hinder interoperability.

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. Two examples of such rules are:

Allowed Taxonomies

Filing rules should specify the reporting taxonomies that may be used to prepare reports.

Filing rules should list the valid taxonomy URLs that may be referenced in XBRL reports and extension taxonomies.

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

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

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.

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.

Taxonomy Extension Rules

In a reporting programme that allows or requires filers to provide extension taxonomies, 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

Filing rules should specify, in a section separate from 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 as XBRL Report Packages
  • Any file size limitations on the filing
  • Details of any digital signatures that are required on the filing

For a detailed checklist of potential filing rules, refer to Filing Rules XBRL Report Checklist and Filing Rules Checklist for Taxonomy Extensions.

Filing Rules to Be Avoided

Unnecessary filing rules create additional burdens for preparers and software developers, and may harm interoperability. The following types of filing rules are not recommended.

Syntax-Level Constraints

Filing rules should not impose constraints on syntax that is already permitted by the XBRL specifications. For example, rules requiring a specific ordering of elements in an XBRL report (such as schemaRef, linkbaseRef, context, units, facts, and footnotes) go beyond what the specification requires and introduce unnecessary implementation burdens. Similarly, specifying formats for context IDs, unit IDs, or other identifiers — which have no semantic meaning — imposes avoidable restrictions on software design.

Restatement of Specification Rules

Filing rules should not duplicate existing validation requirements already covered by XBRL specifications. Such repetition does not add value and may introduce subtle inconsistencies, leading to confusion or interoperability issues. For example, rules requiring monetary facts to use ISO currency units or forbidding the use of default members in contexts simply restate what is already required by the XBRL 2.1 and Dimensions 1.0 specifications. If certain specification requirements need emphasis for preparers or vendors, they should be included as guidance material, not filing rules.

Non-Automatable Rules and Guidance Text

Non-automatable guidance or instructions should not be presented as filing rules. While helpful for preparers, these materials should remain clearly separate from enforceable, automatable filing rules. Examples of such non-automatable guidance include requiring the decimals attribute to match reported precision, specifying the use of nil facts to distinguish between zero and omitted values, inferring default dimension values when not explicitly provided, discouraging units that imply scale factors on currency, and instructing how footnotes should be reported based on document layout.

Creating and Publishing Filing Rules

Establishing effective filing rules requires a clear understanding of the reporting ecosystem, practical testing, and thoughtful communication with all stakeholders. This section provides a guide to creating and publishing filing rules.

The first step in developing filing rules is understanding the environment in which the rules will operate. This means identifying technical and regulatory needs, and aligning them with:

  • The structure and capabilities of the taxonomy
  • The technical limits and validations of the submission system
  • The goals and expectations of the reporting programme

When well-designed, these rules improve quality, reduce errors, and support efficient validation processes. Effective publication supports compliance by ensuring that preparers and software vendors can interpret and implement rules consistently.

Creating and Publishing Filing Rules

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 ensures that there is no ambiguity in rule interpretation.

For a brief overview of how validation works in XBRL reporting, see Validation – Key Concepts, which explains the role of formulae in enforcing reporting consistency, alongside other validation layers like calculations and schema constraints.

To explore practical examples and guidance on building XBRL formula rules, refer to the XBRL Formula Rules Tutorial.

Rule Identifiers

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

Human-readable Rules Description

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 in format such as HTML or PDF.

Filing rules should be published with clear, structured documentation that explains not only what each rule is, but how it works in practice. This includes plain-language descriptions, technical definitions, and concrete examples of both compliant and non-compliant submissions. Providing this level of detail helps preparers understand the intent behind each rule, reduces interpretation errors, and supports consistent implementation across different tools and platforms.

Testing and Test Suite

Before filing rules are published, they must be thoroughly tested to ensure they function as intended in real-world scenarios. This involves simulating both valid and invalid submissions, reviewing system responses, and confirming that each rule aligns correctly with the taxonomy and reporting logic.

Testing filing rules serves multiple purposes. It helps identify conflicts between the rules and the taxonomy structure, ensures that valid reports are accepted while non-compliant ones are appropriately rejected, and confirms that error messages are triggered accurately and consistently. Additionally, it provides evidence that the rules can be reliably enforced by automated validation tools.

A good practice is to develop and publish a comprehensive set of test cases, each containing a simplified XBRL report designed to either pass or fail based on a specific rule. These test cases should be documented clearly, describing the scenario being tested, the expected outcome, and the actual system response observed during testing. Publishing test suites helps ensure that filing rules are implemented correctly and supports software developers in understanding their requirements.

Examples of test cases:

  • If a rule limits file size to 25 MB, two test cases can be created:

    • One instance with a total size of 24 MB, which should be accepted.
    • Another with a size of 27 MB, which should trigger the error: “File exceeds maximum allowed size of 25 MB.”

  • For a rule requiring that the report filename follow a specific pattern — such as [EntityID]Q[Quarter][Year].xbrl — a valid test instance would use a file named 12345_Q4_2023.xbrl, which should be accepted. Another test case using a file named report_final.xbrl would be rejected. The expected message might be: “Filename does not comply with the required pattern: [EntityID]Q[Quarter][Year].xbrl.”

Clear Error Messages

Filing rules should trigger error messages that are not only technically accurate but also easy for users to understand and act upon. A good error message clearly identifies what went wrong, refers to the specific rule or requirement that was violated, and suggests how the issue can be corrected.

Some examples are below:

Case Poor Message 1 Poor Message 2 Good Message
File Size Error “Validation failed: rule_102.” (Too vague. It doesn’t indicate which rule was violated, what caused the failure, or what action is needed.) “The file you submitted may not comply with one or more technical requirements.” (Although written in plain language, it doesn’t clearly explain what went wrong, which rule was violated, or how to resolve the issue.) “File exceeds maximum allowed size of 25 MB. Reduce the document size or split the report into multiple submissions.” (Clearly states the problem and how to fix it.)
Filename Format Error “Filename error.” (Too brief and vague. It doesn’t specify what pattern is expected, what is wrong with the current name, or how to correct it.) “Please check your filename and try again.” (Although polite, the message is unhelpful. It doesn’t explain what the correct filename should look like, what was wrong with the one submitted, or how to fix it.) “Filename does not match the required format: [EntityID]Q[Quarter][Year].xbrl. Example: 12345_Q4_2023.xbrl.” (Clearly states the expected format, references a concrete example, and guides the user to correct the issue immediately.)

Publishing Filing Rules

Filing rules, along with supporting documents, test cases, and rule files, should be made accessible through regulatory portals that are available to all stakeholders, including preparers and software vendors.

To avoid confusion, it is important to clearly specify the applicability of each set of rules, whether they apply only to a particular reporting period, a specific taxonomy version, or from their publication date until a new set is released.

Likewise, other contextual factors relevant to each reporting scenario should be considered and communicated, as appropriate, to prevent ambiguity and ensure that preparers and software vendors can interpret and apply the rules consistently, including by the regulator during subsequent analysis and future revisions.

Version Control

Filing rules, like taxonomies and validation platforms, evolve as requirements change or refinements are made. Effective version control ensures clarity and trust in the reporting process. Each rule release should include a clear version number and release date, accompanied by a detailed changelog that records any additions, modifications, or removals. Deprecated rules should remain accessible for reference and be clearly marked to avoid confusion.

Support and User Assistance

To support adoption and proper implementation, regulators should provide comprehensive assistance. This includes maintaining frequently asked questions and troubleshooting guides, establishing designated contact points for technical assistance and onboarding, and offering feedback channels through which users can report issues or suggest improvements. User feedback plays an important role in identifying gaps and improving the overall quality and usability of the filing rules. These measures help ensure that preparers and vendors apply the correct rules confidently, supporting consistency and collaboration across the reporting environment.

Summary

Filing rules are an essential component of any digital reporting programme. They provide the technical framework that ensures XBRL reports can be validated, processed, and interpreted consistently across systems. Unlike business rules, which define what data must be reported and how it is conceptually related, filing rules define the operational parameters of submission: what is allowed, what is required, and how the system will respond.

Good filing rules are not only technically sound, but also:

  • Clearly aligned with the taxonomy and reporting objectives
  • Easy to implement and validate automatically
  • Documented with clarity, test cases, and actionable error messages
  • Published in accessible formats with supporting tools and guidance
  • Updated transparently and iteratively, based on feedback and evolving needs

Well-designed and well-published filing rules build trust, reduce cost, and enhance the integrity of regulatory data ecosystems. By applying the insights and recommendations from this document, authorities can establish filing rule frameworks that are robust, flexible, and ready to support scalable, future-proof reporting environments.