Filing Indicators 1.0

Requirements Document 11 October 2017

Copyright © XBRL International Inc., All Rights Reserved.

This version:
Paul Warren, XBRL International Inc. <>
Mark Goodhand, CoreFiling <>
Paul Hulst, De Nederlandsche Bank N.V. <>


Circulation of this Requirements Document is unrestricted. Other documents may supersede this document.


This document defines requirements for a standardised mechanism for the inclusion of "filing indicators" in an XBRL report, using a syntax that is compatible with the XBRL Open Information Model. Filing indicators allow preparers to make an explicit statement about which data sets, or templates, within a reporting requirement they have intended to complete.

Table of Contents

1 Introduction
1.1 Terminology
2 Current approach
3 Requirements
3.1 List of templates
3.2 Uniqueness
3.3 Definition of available templates
3.4 OIM compatibility
3.5 Impact of adoption
3.6 Transformations
3.7 Extensibility
3.8 Co-existence with current syntax
3.9 Utility functions


A References
B Intellectual property status (non-normative)
C Document History (non-normative)
D Errata Corrections incorporated in this document



1 Introduction

In a number of filing environments, XBRL is used to report very large, complex and highly-dimensional data sets. For the purposes of managing and defining the reporting requirements, and for report visualisation, the data set is often described in terms of a number of templates. Filers will provide an XBRL report that contains data for one or more templates, with different entities required to report different templates based on their individual circumstances. Rather than modelling these templates as discrete forms, XBRL enables a logical and consistent approach to data modelling to be taken, so that where the same piece of information appears on multiple templates, it is modelled the same way and need only be reported once.

In many cases, it is important for the collector of the report to be able to determine which reporting templates the filer intended to complete. This may be used to trigger validation, to filter the set of templates that are rendered, or to determine if the filer has met their filing obligation. A single XBRL fact may participate in multiple templates, which means that it is not possible to reliably determine which templates the filer has intended to complete by simple inspection of the reported data.

Filing indicators are a mechanism used by a number of XBRL implementations to enable filers to explicitly state which reporting templates they have completed.

The syntax currently used by these projects uses constructs that are not compatible with the XBRL Open Information Model. This document defines requirements for a representation of XBRL "filing indicators" that is compatible with the assumptions of the Open Information Model.

Filing indicators are currently modelled using tuples and make use of a custom attribute (i.e. one not defined in an XBRL specification). The Open Information Model [OIM] does not support custom attributes, and the use of tuples is increasingly discouraged for new projects. These issues with filing indicators are the only technical barrier to the use of the OIM, and its related CSV and JSON-based representations, for the large quantities of data that are collected by the projects using this approach.

This document defines the requirements for an alternative syntax for filing indicators that is compatible with the OIM, and accompanying transformations that allow conversion to and from the current syntax and the proposed new syntax.

1.1 Terminology

The solution is the specification or other artefacts developed to satisfy the requirements described in this document.

An implementer is a regulator or other collector of XBRL reports that contain filing indicators prepared according to the solution.

A filer is an entity that creates an XBRL report that is required to contain filing indicators prepared according to the solution.

2 Current approach

The current approach to filing indicators uses a tuple element ( <fIndicators> ) containing a single, repeating element ( <filingIndicator> ), the content of which is the identifier of a template. The element has an optional, boolean attribute ( @filed) that enables filers to explicitly state that a template has not been filed. If this attribute is omitted, or included with a true value, it is a statement that the template has been included.

The example below asserts that templates C_00.01 and C_01.00 have been reported, and that C_02.00 has not.

<find:filingIndicator contextRef="c1">C_00.01</find:filingIndicator>
<find:filingIndicator contextRef="c1">C_01.00</find:filingIndicator>
<find:filingIndicator contextRef="c1" find:filed="false">C_02.00</find:filingIndicator>

In current implementations, the codes used to identify templates correspond to labels with a specified role attached to table linkbase tables.

3 Requirements

3.1 List of templates

The solution must allow filers to include a list of templates, and make a positive or negative assertion that the template has been included in the report.

3.2 Uniqueness

The solution must validate that only a single assertion is made about a given template.

3.3 Definition of available templates

The solution should not assume any relationship between a "template" and components in the DTS (such as Table Linkbase tables). Implementers should be free to define the mechanism by which the list of allowed templates is defined. It should be possible for implementers to prescribe validation of the list of allowed templates.

3.4 OIM compatibility

The solution must only make use of XBRL syntax that is supported under the assumptions listed in the OIM specification [OIM].

3.5 Impact of adoption

The impact on existing systems of adopting the new syntax must be minimised. For example, the solution should not require that existing taxonomies be modified in order to support adoption.

3.6 Transformations

The solution must define a bi-directional mapping between the current filing indicator syntax and the proposed new syntax. Ideally, the solution should include implementations of the transformation using a suitable standard, platform-neutral technology (e.g. XBRL Formula, XSLT).

The solution does not need to support the use of multiple <find:fIndicators> tuples within a single report. If a report contains multiple <find:fIndicators> it should be considered equivalent to a single tuple containing the contents of both.

3.7 Extensibility

The solution should be straightforwardly extensible to include additional information about reported (or unreported) templates using OIM-compatible syntax.

3.8 Co-existence with current syntax

The solution should provide validation to ensure that where the new syntax is used, filing indicators are not also reported using the current syntax.

3.9 Utility functions

The solution should define custom XBRL Formula functions that perform the following functions:

  1. Return a list of reported templates
  2. Return a list of templates that have been asserted to be not reported
  3. Testing whether a given template has been reported
  4. Testing whether a given template has been asserted to be not reported

These functions should be able to process both the current syntax and the proposed new syntax, so that formula assertions can be written in a syntax-independent manner.

Ideally, the solution should include XPath implementations of the custom functions.

Appendix A References

XBRL International Inc.. "XBRL Open Information Model"
Paul Warren.


Appendix B Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (


The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (

Appendix C Document History (non-normative)

29 June 2017Paul Warren


Appendix D Errata Corrections incorporated in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Specification Maintenance Working Group (SWG) up to and including 11 October 2017. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.