- Questions for Respondents
Stakeholders are invited to comment on all matters in this discussion document, particularly on the following questions for the management of ESDs. The task force has involved a range of stakeholders during the development process but additional feedback from the users of ESDs in XBRL would be particularly welcome.
Comments are most helpful if they identify and clearly explain the section and question they relate to.
Question 1: Do you agree or disagree that Inline XBRL helps with the programmatic consumption of ESDs? Please explain your response. If no, why not? Are there alternative solutions or considerations that could be considered? Are there other ways we can consider using Inline XBRL for the programmatic consumption of ESDs that were not discussed?
- For data users, please explain how you see Inline XBRL improving the programmatic consumption or usability of the ESDs.
- For reporting entities, please explain how Inline XBRL affects the preparation of the XBRL Report.
Question 2: Do you agree or disagree that some form of ESD to BT relationship (i.e., an anchor) should be required to facilitate ESD programmatic consumption? Please explain your response. If no, why not? Do you have any comments on the nature of this relationship? Are there alternative solutions or considerations that could be considered? Are there other ways we can consider “anchoring” ESDs that were not discussed?
Question 3: This report considers various mechanisms to establish relationships between ESD element extensions and the BT including: Inline XBRL, calculation, presentation, and definition (covers Dimension domain member construct, as well as other special relationships that could be included using the definition linkbase syntax).
Do you agree or disagree that these relationships are useful for the programmatic consumption of ESDs included as element extensions? If yes, which of the relationships described do you consider most useful. Please explain your response. If no, why not? Are there alternative solutions or considerations that could be considered?
Question 4: As discussed in the Analysis section , are there any other user requirements the task force should be considering or user requirements discussed that are more or less important?
Comments and feedback should be submitted by email to email@example.com. The deadline for comments is 23rd May 2018.
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.
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
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:
The task force research included identifying the requirement of different user groups relating to ESDs in digital financial reporting to support the recommendations.
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.
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'1). 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.
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, disclose certain elements by reporting segment.
- Broadly defined reporting requirement (e.g., describe your business), and
- Unpredictable information; the entity chooses to report under general overall 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.
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.
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, ie 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)
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.
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.
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 or alternatively how an ESD is comprised of other disclosures, of which many are likely to be BT elements. As such, calculation relationships are the most useful relationship available in XBRL. 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.
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.
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; however, the ESDTF is soliciting feedback on this topic.
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.
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.
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.
A subtotal combining two disclosures found elsewhere in the financial statements. ↩︎