How to address Entity Specific Disclosures in XBRL reports

[TOC]

Introduction

Goal of the Entity-Specific Disclosures Task Force (ESDTF)

The XBRL International Best Practices Board set up the Entity-Specific Disclosures Task Force in February 2016.

The overall goal of the task force is to identify and recommend mechanisms for including entity-specific disclosures (ESDs) in XBRL reports to optimize their utilization for automated processing by users. This is in response to data users observing that they are unable to understand the meaning of ESDs without human review of the original filing. Users have commented that ESDs are handled in a number of different ways in XBRL and in general these are not optimized for automated processing.

Within that goal the ESDTF also aims to consider:

• How ESDs are used and what they represent
• The business requirements for working with ESDs
• Recommendations for collectors of XBRL reports (often regulators) to improve how ESDs are represented in XBRL

In making the recommendations the group attempted to meet the following requirements:

• Leverage how ESD reporting currently works within existing XBRL systems
• Minimise changes to existing software
• Minimise cost and disruption for reporting entities
• Identify solutions that provide consistent results
• Gather requirements for any technical changes that may be required to appropriate XII technical groups

To some extent the effectiveness of these recommendations depends on the software vendors and other organizations supporting reporting entities.

Draft guidelines applying ESMA ESEF Rules to anchoring extensions

Prior to finalising this report, the ESDTF published draft guidance to help those who will be preparing iXBRL reports or developing software that complies with the European Securities and Markets Authority's (ESMA) European Single Electronic Format (ESEF) draft regulation better understand how to anchor entity-specific concepts to ESEF taxonomy concepts. This guidance is draft, and non-normative, but is intended to assist software firms and issuers dealing with this question. The guidelines are available on the XII website here.

Target audience

The primary intended audiences for this document are regulators and others acting as the collectors of XBRL reports. That is, collectors involved in setting the appropriate scope and rules for the filing system.

This report seeks to discuss the requirements and recommendations using language understandable by the business users of XBRL. Users with an interest in the technical details behind these discussions can find additional information in the linked documents and in future work.

Some factors a collector may want to bear in mind while reading this report include:

• The data requirements of the target users
• The impact the requirements have on reporting entities
• The requirements of any existing filing/collection system

Supporting requirements and analysis

This guidance is based on requirements and analysis undertaken by the ESDTF. The results of this supporting work has been split into a number of separate documents:

• Investor and data user requirements for entity-specific disclosures

  The task force research included identifying the requirement of different user groups relating to ESDs in digital financial reporting to support the recommendations.

• Analysis of ESDs and ESD use cases in XBRL

  The task force analysed various ESD use cases as part of its investigation into the business requirements for the users of ESDs and how those requirements are currently met.

Defining Entity Specific Disclosure (ESD)

An ESD is a fact included in a business report as a result of requirements from authoritative sources such as International Financial Reporting Standards (IFRS) and U.S. Generally Accepted Accounting Principles (US GAAP), or voluntarily provided by the reporting entity (e.g., 'Revenue from the Agriservices segment', and 'Revenues from BNSF and BHE'¹). They are sufficiently unique as to be considered specific to the reporting entity or to a small number of reporting entities. As ESDs are a feature of the reporting domain, and exist regardless of the technology being applied, our recommendations will not discuss how to change these reporting requirements.

At the same time, ESDs do require special handling in XBRL. The base taxonomy (BT) may not be intended, or even able, to cover all the possible reporting requirements that reporting entities include in reports when applying the principles and requirements of a specific reporting domain. In some jurisdictions extension elements for ESDs are often referred to simply as extensions, which is a misnomer as it includes other meanings. In this report, we will use the more precise language of "extension elements." Extension elements are one of the possible ways to work with ESDs in XBRL.

This guidance talks about the business requirements for ESDs that may lead to extension elements among other solutions and how to work with the results of these requirements in XBRL. Technical requirements will be considered by other groups.

ESDs and base taxonomies (BT)

ESDs are common in open reporting environments but do not occur in closed reporting environments.

In IFRS reporting the principle-based nature of the Standards results in, or encourages, ESDs. For example, IAS 1, paragraph 31 includes:

"An entity shall also consider whether to provide additional disclosures when compliance with the specific requirements in IFRS is insufficient to enable users of financial statements to understand the impact of particular transactions, other events and conditions on the entity's financial position and financial performance."

These general requirements make it impossible for a BT to provide elements for all of the possible additional disclosures as the nature of these disclosures is not known in advance.

This principle-based nature may also mean that if a specific fact is not material, an entity can aggregate it with other items. Paragraph 30 of IAS 1 Presentation of financial statements states:

"The final stage in the process of aggregation and classification is the presentation of condensed and classified data, which form line items in the financial statements'. If a line is individually not material, it is aggregated with other items either in those statements or in the notes. An item that is not sufficiently material to warrant separate presentation in those statements may warrant separate presentation in the notes."

The inclusion of immaterial figures in aggregated items leads to line items of the form "Intellectual property rights, brands and other intangible assets" where some of the components of the line item are explicitly described but others are grouped under the term "other intangible assets" making the contents of the aggregation uncertain.

Some reporting requirements may also include breakdowns or other categories that are determined by the entity and not directly specified in the Standard. For example, types of property, plant and equipment, and the division of the business into operating segments.

In US GAAP, some quantitative reporting requirements call for the disclosure of ESDs where the nature of the concepts (e.g., depreciable assets, common shares, debt instruments, revenue) is the same but the disaggregation categories (e.g., major classes of depreciable assets, major classes of common shares, types of debt instruments, revenue by product or service lines, etc.) will vary across companies.

As a result of these kinds of requirements, ESDs included in reporting requirements range between:

• Prescriptive and Predictable: the reporting is required and common to all entities but the details are unique to the reporting entity. For example, reporting certain disclosures by operating segment.
• Broadly defined reporting requirement (e.g., describe your business), and
• Unpredictable information: the entity chooses to report information that is consistent with but not required by reporting requirements, (e.g., subtotals).

Consequently, ESDs range from those with predictable relationships to existing disclosures in the BT to those which are more unpredictable in their form and relationships.

Scope

This guidance provides recommendations related to the handling of ESDs found in XBRL reporting. This guidance also discusses current practice for working with ESDs, analysis of the processing difficulties working with ESDs, and recommendations for regulators. The initial scope of work by the ESDTF focuses on ESDs in financial reporting and on numeric disclosures in particular. Some conclusions may also be useful to those working in non-financial reporting.

The ESDTF decided to primarily address how ESDs work in XBRL with the following assumptions:

• ESDs are a feature of the reporting domain and not the technology.
• The BT has an appropriate architecture and model. Issues resulting from poor taxonomy design or coverage are not discussed. Guidance on design of taxonomies is in the scope of the Taxonomy Architecture Guidance Task Force.
• When tagging of an ESD is discussed, tagging is assumed to be correct and appropriate.

Out of scope

In addition to ESDs there are a number of reasons facts may be included in a business report that are not provided for in the BT. These cases are out of scope for this report. They include but are not limited to BTs:

• shared by multiple collectors and therefore not containing information specific to the individual collectors' systems
• shared across regions or countries and therefore not containing concepts specific to individual regions or countries, e.g., The IFRS taxonomy
• covering a certain reporting domain. A report using the BT may however contain multiple domains (for example, reporting domains such as corporate social responsibility, key operating and financial performance indicators and entity identification systems)

Additionally, an entity may report an ESD that does not take part in any aggregation or disaggregation involving BT concepts and therefore does not appear to have relationships to a BT concept. However, the task force research has so far suggested that ESDs as standalone disclosures are rare and agreed to exclude from the scope of this report. This is discussed in greater detail in the Analysis of ESDs and ESD use cases in XBRL document.

Recommendations

The goal of these recommendations is to ensure there is sufficient context within an XBRL filing for users to easily identify, access and understand reported facts that are specific to an entity (ESDs) and to improve the automated processing of these facts.

Therefore, there are two primary recommended best practices:

'Anchor' entity-specific disclosures to the base taxonomy

• Provide an explicit relationship to the base taxonomy for all entity-specific disclosures
• This relationship should be calculation relationships wherever possible

In addition, and in line with existing XBRL International guidance, the following XBRL specifications are recommended:

• Inline XBRL
• XBRL Extensible Enumerations specification.

Entity-specific disclosures - without a reporting entity extension taxonomy

If you have specific data requirements for some ESDs in an open report then ESD mechanisms in the BT may provide useful relationships to support automation where:

• ESDs represent a disaggregation of a BT element;
• ESDs are predictable in nature. Either because their relationships with other disclosures are heavily prescribed by the reporting standards or as a result of other standardization in practice; and/or
• User requirements are focused on known areas of disclosure and are themselves predictable and stable.

An example of such a requirement is the collection of reports by a government agency with a specific set of data requirements as opposed to the collection and distribution of reports for general use. These mechanisms do not provide full context for all ESDs but may allow users to automate the processing of specific areas of entity-specific disclosure.

Entity-specific disclosures - with a reporting entity extension taxonomy

The calculation tree is recommended for use with ESDs however it does not provide a full solution for the automation of ESDs.

The most useful context that can be provided for an unknown (i.e. ESD) fact is to document a mathematical relationship to a known (base taxonomy) concept and use calculation relationships to do this.

Calculation relationships for numerical facts provide additional computer-readable information that can be used by users to help them understand the meaning of ESDs. These relationships express how an ESD contributes to the value of a BT element (e.g., rolls up to) or alternatively how an ESD is comprised of other disclosures (e.g., aggregates), of which many are likely to be BT elements. As such, calculation relationships are the most useful relationship currently available in XBRL to help understand the meaning of ESDs when consumed automatically. They facilitate automated consumption of ESDs, in particular, numeric ESDs as they relate ESDs to BT elements.

The calculation tree has limitations, as discussed in the analysis section. If relationships are also required for ESDs modeled using dimensional structures in XBRL or present in cross-period reporting then additional XBRL relationships will be required. Additionally if the calculation linkbase is used for validation then some ESDs roll-ups resulting in validation exceptions may be excluded from the tree.

While entity-specific disclosures modeled as members in BT domains may be missing calculation relationships, they have useful relationships via the syntax used to define the dimensions and domains.

ESDs tagged using extensions, and included as members in BT domains, already have a clear set of relationships as part of the usual XBRL syntax and therefore this allows some automated consumption of numeric ESDs. Entity-specific dimensions are lacking in useful relationships and should be avoided if possible.

Some improvements are required for the calculation tree to provide complete mathematical relationships for ESDs. The recommended improvements include:

• Calculation tree functionality to cover:
  • Calculations including XBRL dimensions
  • Cross-period calculations
• Calculation tree functionality that allows for documentation of non-validating relationships.

Calculations 2.0 Requirements Published

The XBRL International specification working group has undertaken a project to address these concerns starting with publishing Calculation 2.0 Requirements on 6 February 2019. Calculations 2.0 aims to improve XBRL 2.1's calculation functionality to better cover the calculations usually required in a financial report and to address the issue of calculation inconsistencies that arise when reports feature incomplete data sets.

Entity-specific values as extensible enumerations

If an ESD is providing an entity-specific value for a known concept, that also has a set of anticipated base values, then the XBRL Extensible Enumerations specification should be considered as the XBRL mechanism.

Extensible Enumerations is a modular addition to the XBRL standard for defining lists of allowed values in a taxonomy. XBRL International guidance is that Extensible Enumerations should be the default choice for representing concepts that take a value from a list of allowed values. The extensibility feature makes them particularly suitable for ESDs where reporting entities may need to extend such a list, but the benefits of Extensible Enumerations go beyond just extensibility. It is recommended that they are used consistently for all such lists, whether or not there is a requirement for extension.

No calculation tree

If the calculation tree is not available in a filing system or it is expected that a significant number of ESDs will be without a calculation relationship due to the limitations identified then provide an alternative connection (or anchor) to the BT.

If these additional relationships are provided for ESDs, it is recommend that they are reliably available to users (a mandatory part of a tagging requirement) and that they are easily accessed.

The most useful relationship to provide for automation purposes is one that allows the way that the ESD should contribute to document roll-ups to be identified - a mathematical relationship.

If the BT does not have an immediate calculation parent for the ESD, the link should be to the next most appropriate BT parent. It is recommended that the location of these links within a reporting entity extension taxonomy is clearly documented and consistent within a filing system.

In general, multiple anchoring links for an ESD should not be necessary or do not provide significant benefits compared with the cost to reporting entities.

In the absence of calculation tree relationships covering all ESDs, some users may make use of the presentation tree. However, the meaning of links used is poorly defined and the presentation relationship often does not provide an ESD with the most useful or immediate BT context.

Additional documentation of ESDs

Where additional documentation is required with entity-specific disclosures this should be provided as extension taxonomy labels.

Several collection systems surveyed during the ESDTF's research phase require that reporting entities provide some kind of documentation associated with tagged ESDs. This documentation may assist users with the manual processing of ESDs and/or with the understanding of ESDs without having to refer back to the Inline XBRL.

Inline XBRL

It is recommended that Inline XBRL is used with reporting containing ESDs.

Inline XBRL is already recommended for use as it allows a preparer-supplied presentation, without the need for dual filing, while also permitting the use of base taxonomy constructs for handling ESDs (e.g., as in the UK FRC/HMRC usage).

Inline XBRL provides context for reported information including untagged information. Inline XBRL is particularly helpful for supporting the inclusion of untagged narrative disclosures, including narrative ESDs, where detailed tagging may provide limited benefit. If there are some numeric disclosures that have not been tagged, for example, because they are highly variable and not deemed useful as structured data, they may also be retained for manual (or partially automated) processing as part of the Inline XBRL report.

Examples include details of commitments and contingencies or details that are specific to legal agreements such as debt instruments. In these cases, a collector may decide that some number of underlying facts may be tagged, including ESDs, but some facts and other content may be left to the Inline XBRL document for manual inspection and interpretation.

The use of Inline XBRL is applicable regardless of other choices regarding ESDs and filing.