Analysis of ESDs and ESD use cases in XBRL

[TOC]

Introduction

The following section summarises the analysis work performed by the task force as part of the investigation into the business requirements of the users of ESDs and how those requirements are currently met.

The task force expects that a data user using automated computer consumption should be able to identify entity-specific disclosures (ESDs) properties that are shared with base taxonomy (BT) concepts if XBRL relationships connecting the ESDs to the BT are provided, for example, using calculation roll-ups.

Some properties may be unique to the ESD and could require investing upfront time to understand the properties. However, once the user determines the meaning of the reported item, and it remains consistent period over period, it can support an efficient and effective time series analysis.

The taskforce also made assumptions about the ease of automatic consumption of ESDs, including; labels are not an easy or reliable source of information for automation as we think language processing is not sufficiently developed yet; and, there will continue to be technological developments in data analysis but the aim is to improve the ease of automated processing now.

The analysis work included the discussion of a number of examples from financial statements. A few of these examples are provided but many more were used during the work of the task force.

Existing practice

To understand the different ways that existing XBRL filing systems already support ESDs, and any resulting challenges raised by the ESDs, the ESDTF asked for contributions describing current (and pending) market practice around the world. These voluntary contributions included information on filing projects in:

• Chile
• Denmark
• Europe
• India
• Japan
• The Netherlands
• Singapore
• Thailand
• UAE
• UK
• USA

Other projects also work with ESDs but did not volunteer information to the group.

The survey identified a number of approaches used in XBRL to support ESDs, including the use of:

• Reporting entity extension taxonomy, including variations such as:
  • which XBRL trees (e.g., calculation, presentation) and labels a reporting entity is required to provide; and
  • the types of XBRL element permitted to be included in a reporting entity extension (e.g., domain members only, line items only).
• Single "Text Block" tag to capture a block of the report including all text, formatting and embedded numeric disclosures.
• Typed dimensions in the BT to support the reporting of an entity-specific set of domain values without the need for an extension taxonomy
• Pre-defined sets of generic domain members for tagging and associated lists of entity-specific disclosures in a certain category, e.g., "Reportable operating segment 1," "Reportable operating segment 2," etc.
• 'Other' or 'analysis' taxonomy elements (usually combined with XBRL dimensions to allow multiple 'other' values to be reported)
• XBRL Footnotes including details for ESDs tagged with a general taxonomy item or otherwise remaining untagged
• XBRL Labels or References documenting the meaning of ESDs
• Controlled addition of requested concepts to the BT
• Not requiring the tagging of some or all ESDs (may be combined with the use of Inline XBRL)

Some of these mechanisms cause problems for users of the data for several reasons, including:

• The number of different ways that ESDs are handled in XBRL
• The completeness of the tagging of ESDs (both in terms of ESD availability in the XBRL data and in terms of context for the ESDs)
• The limited constraints on how ESDs (and similar disclosures) are handled in some filing systems
• The lack of a reliable mechanism tying ESDs back into the BT in some filing systems

A more detailed discussion of some of the problems faced by users and analysis of the reasons behind these problems is in the below section of this guidance.

ESDs and collector 'filing rules'

How ESDs are made available in filings depends significantly on the rules set by the collector that govern how filings must be prepared ("the filing rules").

However, other filing rules not directly related to ESDs can have a significant effect on:

• whether or not ESDs are tagged,
• the reporting entity' need to create extension elements for ESDs,
• the resulting volume of extension elements for ESDs across all filers, and
• how easily a data user can use ESDs.

In particular, the rules governing how much of a report a reporting entity must tag and the rules relating to how a reporting entity chooses the most appropriate elements from the BT can have a significant effect.

For example, requiring reporting entities to tag disclosures to the BT element with the most specific likeness to their disclosure will most likely result in increased variability of elements used by filers for that disclosure and more extension elements for ESDs as the filer is focused on finding a very specific element. On the other hand, if the rule directs the reporting entity to tag disclosures to a wider scope BT element, we can expect the opposite result and probably fewer extension elements for ESDs. A collector should consider how the broader set of rules they set for tagging affect the more specific requirements for tagging ESDs as well as how they affect the automated consumption of ESDs. Tagging rules may also be influenced by the data collection requirements. For example, it may be necessary for all facts in a report to be included in an electronic filing as structured data, or only a required subset.

ESDs and the BT

The design of the BT can influence the collection of entity-specific disclosures in two main ways:

• Whether the taxonomy design includes XBRL features allowing for the capture of entity-specific disclosures
• The extent to which the taxonomy covers the reporting domain and therefore covers entity-specific reporting.

Categorizing ESDs

As part of the analysis, the task force categorized how ESDs are most commonly expressed in reporting into three primary types:

• Entity-specific disaggregated components of another concept (whether reported directly or not)
• Entity-specific aggregating concepts of a number of components (whether reported directly or not), and
• standalone concepts

This categorization was based on the analysis of financial statements and the reporting requirements observed in accounting standards that lead to element extensions for ESDs. This should not be confused with discussion of the way that ESDs range from prescriptive to unpredictable as discussed in the section ESDs and base taxonomies.

ESDs as disaggregated components of a concept

An entity may provide a disaggregation of a concept with one or more of the components as ESDs.

For example:

Figure 1: ESDs as disaggregated components of a concept

The total of the disaggregating components may be reported in a different part of the report or not reported at all. An entity may also report an entire disaggregation with both ESD components and an ESD total.

ESDs as aggregating concepts for components

An entity may report an ESD as an aggregation of component concepts (a total) or just the aggregating concept itself. For example:

Figure 2: ESDs as aggregating concepts for components

In the base taxonomy however the two contributing concepts are displayed quite separately no common taxonomy parents.

Some of these aggregations may look obvious but it is not possible to anticipate all possible combinations that reporting entities may provide.

The component concepts in the breakdown also may be a combination of BT and ESD concepts.

Although "prepaid expenses" and "deposits" are present in the BT as distinct concepts, the aggregation is not, and is representative of a common ESD occurrence where the entity combines two or more BT concepts into a single reported item.

Additional examples may be made up from more granular components as you can see from these example labels:

• Intellectual property rights, brands and other intangible assets
• Raw materials, consumables and supplies

The component concepts of an ESD total may be reported directly with the ESD total, elsewhere in the report (for example in a note) or not at all. In the case of "Prepaid expenses and deposits," the entity commonly reports this "aggregation" without the component concepts.

ESDs as standalone concepts

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.

The overwhelming majority of ESDs are within the scope of the reporting domain as they are reported to comply with the standards or requirements defining the report, e.g., IFRS or US GAAP. For example, the ESDs provided to fulfil a requirement for the breakdown of a figure by reporting segment. BT elements are therefore expected to be available to provide useful relationships for ESD extension elements as the BT is generally designed to represent all reporting requirements; at least for numeric reporting requirements. It is also the case that standalone ESDs without relationships to other report items are less likely to be included in automated analysis.

At the same time, the task force acknowledges that this may be of greater concern for non-numeric reporting requirements where the relationship may be less direct than for numeric concepts forming part of an aggregation or disaggregation. As the task force is currently focused on numeric reporting, we may revisit this topic in future discussions.

Detailed use cases

The examples that follow describe disaggregation and aggregation use cases that include a mix of BT elements and extension elements for ESDs. While only a few use cases are discussed in detail, the identified concerns exist for many different combinations of ESD extension elements and BT elements.

ESDs as disaggregated components of a concept - Detailed use cases

An entity may provide a disaggregation of a concept with one or more of the components as ESDs. The ease of use of these ESD depends on the information available about the aggregating concept.

Use case: Disaggregating concepts that include several component elements that are not defined in the BT. The immediate aggregation is a BT element.

In this example 1a, the entity discloses several ESDs (identified with "ESD") that mathematically contribute to a BT element (identified with "BT") as an aggregation and the entity reports the immediate aggregating fact.

Example 1a: disaggregation with components as ESDs (included in Balance Sheet to simplify illustration but aggregation or disaggregation could exist elsewhere in the report).

In example 1a, it is assumed that there are no BT elements for the following concepts making them ESDs:

• Amount due from an associate, non-current
• Amount due from a joint venture, non-current
• Amount due from an investee company, non-current

These three ESDs are unique but do carry three common properties: receivables, non-current, and related party. There is a related element in the BT with the same properties used here as a total (Amount due from related parties, non-current).

In this case a person reading the report could easily understand that the ESDs sum to "Amount due from related parties, non-current". It is implied by the formatting of the report. That person could also infer that the three ESDs all describe values associated with specified related parties as this is implied by the label of the disclosures.

A data user using automated computer consumption can understand the common properties of these ESDs if XBRL relationships connecting the ESDs to the BT are provided in the XBRL report; for example, with presentation or calculation relationships. However, the data user cannot understand what makes each ESD unique, as in the different types of related parties, without referencing the source report or inferring meaning from the labels. Nonetheless, knowing that these ESDs are all receivables, non-current, and related party can improve the efficient and effective consumption of the data.

Investing the upfront time to understand the different types of related parties may be most relevant for time series analysis. Once the user determines the meaning of the reported item, and it remains consistent period over period, it can support an efficient and effective analysis going forward.

Use case: Disaggregating concepts that include several component elements that are not defined in the BT without aggregation using a BT element

In this example 1b built off of example 1a, a reporting entity discloses several ESDs that mathematically contribute to a BT element as an aggregation, but does not report a fact corresponding to that BT element.

Example 1b: disaggregation without BT aggregation reported

As in example 1a, it is assumed that there are no BT elements for the items labeled as "ESD". There is a BT element with the same common properties, "Amounts due from related parties, non-current," to which the ESDs would contribute, but a fact for this aggregation is not present in the report.

In this case a person reading the report can infer from the label that these ESDs relate to non-current amounts for other parties but cannot determine for certain from the reported facts that this constitutes all non-current receivables due from related parties.

The lack of a reported BT element relating to a total for non-current amounts relating to other parties would also prevent a computer from deriving that these disclosures are related to those activities via this route and also remove the link indicating that these disclosures form an amount that can be aggregated.

Variation 1: Incomplete disaggregation

In this scenario, ESDs cannot be assumed to be complete disaggregation of an element that exists in the BT or that they include all the relevant properties.

Example 2: incomplete disaggregation with missing link to exact sum

In this example, it is assumed that there are no BT elements for:

• Distribution costs
• Administrative costs

There is a BT element for "Distribution, general and administrative costs" to which the facts would roll up, but this aggregated fact is not reported nor is a disaggregated fact for "General costs." The implied relationship and aggregation of these concepts follows:

Figure 3: The implied relationship and aggregation of the concepts in Example 2

The only structured information within the report is that "distribution costs" and "administrative costs" are included within the calculation of "profit from continuing operations before income tax" therefore automated mapping of these ESDs to derive a value such as "Distribution, general and administrative expenses" is not possible without the inclusion of additional information about these facts.

A person reading this report might infer that General costs has a value of zero (or is immaterial) and therefore distribution expenses plus administrative expenses equals distribution, general and administrative expenses.

However, a data user using automated computer consumption cannot know that this is true without an explicit description of that summation (for example, with a calculation relationship). At best, the computer may infer some meaning from the labels but these are not consistent across entities and can't be "trusted" to communicate the correct or complete meaning of the underlying concept.

ESDs as aggregating concepts for BT components - Detailed use cases

An entity may report an ESD as an aggregation of component concepts (a total) or just the aggregating concept itself. The ease of use of that ESD depends on the information available about the components of the ESD and how that ESD may contribute to other summations.

Use case: Aggregation of two disclosures with BT elements to form an ESD total

In this example 3, the entity reports an ESD, "Prepaid pension and postretirement benefits" that represents the aggregation of two BT concepts that are not reported, "prepaid pension" and "postretirement benefits".

Example 3: Aggregation (From the SEC EDGAR Filer Manual (Version 41))

In this case a person reading the report can infer from the formatting that the ESD contributes to the value of the "total non-current assets" thus identifying the primary property of the ESD as "non-current assets". The reader may also infer some meaning from the ESD label to identify the BT component concepts not reported but labels are unreliable and inconsistently applied between entities.

A data user using automated computer consumption can recognize the ESD as a contribution to the "total non-current assets" if a calculation relationship is provided for the ESD to "total non-current assets". The data user cannot easily infer meaning from the BT component concepts by the label. If calculation relationships were provided between the ESD and the BT component concepts, the user could more precisely identify the additional properties of the ESD, "prepaid pension" and "postretirement benefits" as illustrated in the next example.

Variation 1: ESD aggregation with BT components elsewhere in the report

In this example 3a, the report includes the table described in example 3 and the following elsewhere in the report:

Example 3a: Aggregation with components elsewhere in the report

In this case a person reading the report can match up the two separate tables and use this information to now identify the two additional properties of the ESD, "prepaid pension" and "postretirement benefits".

A computer will also be able to do the same provided that:

• Filing rules require the reporting entity to tag this second table
• Calculation information is included

Variation 2: ESD aggregation with ESD components

In the case that an ESD aggregation concept has components that are also all ESDs then there is little information available for the set of concepts (outside of what the ESD aggregation rolls up to) as we see a combination of the problems described for disaggregation and those for the aggregation. This is the case whether the summation is provided in one location or split across the report.

ESD use cases in XBRL

ESD are handled in a number of different ways in XBRL implementations around the world.

The challenges identified and discussed can be an issue for users depending on the XBRL mechanisms currently used to tag ESDs. This guidance discusses how the analysis might have an impact on users working with Inline XBRL and within two broadly defined types of filing systems: with a reporting entity extension taxonomy and without a reporting entity extension taxonomy.

Relationships between ESDs and the BT allow for ESDs to be automatically identified with the properties of BT concepts that they are related to. For example, an ESD relating to a type of asset may have reporting entity taxonomy relationships to BT concepts also relating to the disclosure of information about assets. Consequently much of the analysis focuses on the availability and usefulness of ESD relationships to the BT.

Inline XBRL

Inline XBRL can be used with open reporting systems regardless of any requirement to tag ESDs for automated analysis. It is a good option for a specific filing regime or filing mandate when there is a general requirement that ESDs are available for possible human consumption but there is no requirement for those entity-specific disclosures to be consumed and analysed by software and therefore they may not be included in the XBRL tagging. This presupposes that the BT defines all the concepts that will be automatically consumed and analysed by a regulator who knows exactly the extent of the XBRL mark-up it wants, obviating the need for any entity to extend the BT for their own disclosure tagging purposes.

Inline XBRL can also be used in conjunction with taxonomy extensions (both "public" and entity-specific) to provide a further level of entity-specific disclosure over and above that which is practicable using taxonomy extension. It is particularly useful where unspecified additional narrative may be required that is not already catered for by text-based concepts or text blocks defined in the BT. It is possible to use Inline XBRL with just about any taxonomy, since the ability to embed XBRL metadata in an (X)HTML document is taxonomy-agnostic by design.

A key feature of Inline XBRL is that it places responsibility for XBRL report presentation in the hands of the reporting entity (regardless of any separate rendering solution that users might wish to apply to the extracted XBRL information) and provides the means to do so in a way that is independent of the taxonomy but specific to the reporting entity's needs.

Consequently, a taxonomy can, if Presentation Tree-based instance rendering is not required, reserve the Presentation Tree solely as a means to describe hierarchical concept relationships and support the comprehension and browsing of the taxonomy itself. Furthermore, if users (e.g., regulators, analysts) are satisfied to (re-)use the Inline XBRL presentation created by the reporting entity, there is no need for the taxonomy to contain a plethora of alternative labels to suit a variety of possible consumer rendering requirements - a standard concept, dimension or member label (and an associated documentation label) is all that is required to aid comprehension of the taxonomy. Taxonomy-defined labels do not appear in an Inline XBRL rendering.

Without a reporting entity extension taxonomy

There are a number of ways that filing systems currently work with ESDs that do not require the reporting entity to produce an extension taxonomy.

A number of filing systems make use of extensible features that can be provided within XBRL base taxonomies such as typed dimensions and so-called "dummy" or "generic" dimensions ¹. These features allow some reporting of ESDs within the scope of the BT.

Using reporting segments as an example, a BT designed to anticipate that certain ESDs will be provided could include an explicit dimension to contain the ESD extension members for each of the entity-specific segments (highlighted in the example below) but this would require a reporting entity extension taxonomy.

Example 4: Operating Segment Information

However, the BT can be designed to cover this ESD requirement without requiring an extension taxonomy by including BT dimension members (whether via typed dimensions or "generic" dimension members) to identify values associated with a particular segment. If typed dimensions are used then the segment names (highlighted) would be reported as typed dimension values in the XBRL Report and thereby associated with the BT dimension. If a "generic" dimension is used (where a list of members are included in the BT for example, Segment 1, Segment 2, Segment 3, and so on), an individual line item is used with the dimension and members to provide the reporting segment name. Both mechanisms contribute similarly to the automated processing of ESDs. The BT use of dimensions in these ways contributes the following information for users:

• Associates entity-specific information directly with BT dimensions and line items providing a clear relationship to the BT
• Data is provided as sets of grouped line items
• If a typed dimension is used then the format defined for the entity-specific values might provide additional useful information about those values. For example the format may be limited to valid years or a regulator-defined ID format.

However there are still some information gaps (as discussed in our use cases) for example:

• This model requires that the locations of ESDs in a report are predictable. In the example 4, the reporting requirements ask for ESDs within a specific category of information. This may not always be the case. The absence of a typed of "generic" BT dimension for a BT element implies that ESDs (which are a disaggregation of that BT element) are not directly related with that BT element.
• The consistent use of members across years needs to be constrained by business rules external to the BT
• For the group of entity-specific values, there is no XBRL-valid mechanism to convey their relationship to each other, other than as a member of the group. In the example there is no way for a data user using automated computer consumption to know that "ALL AGRISERVICES" is a subtotal.
• The dimensions do not provide the same information for ESDs that are aggregations

As such these methods work particularly well for ESD reporting requirements that are Prescriptive and predictable in areas where there is clearly required and defined, and therefore predictable, entity-specific disclosure; or more specifically where the consumer knows what ESDs they're interested in doing automated analysis of. Entity-specific disclosures that are added as a result of a more general requirement are much less predictable in form and location and therefore not easy to build into a BT.

With a reporting entity extension taxonomy

Reporting entity extension taxonomies are used in a number of collector systems around the world as discussed at existing practices section. The exact rules for the creation of these taxonomies vary but they usually include:

• Some number of extension elements
• At least one of the associated XBRL relationships (e.g. presentation tree, calculation tree)
• May also include labels and references for the extension elements

Some projects limit how extension elements for ESDs may be created; for example, allowing only ESD extension elements as line items or prohibiting ESDs as extension dimensions.

The multiple choices available for including ESDs in the reporting entity's extension taxonomy affects the information available for the automated processing of the ESDs. For example, the modeling for the same or similar ESDs could use XBRL line items in one case and XBRL dimensions in another. These may both be used for similar disclosures but the way that XBRL describes these choices creates differences in the information available for the automated consumption of the ESDs.

Additionally, the multiple types of XBRL relationships available for describing element-to-element relationships (presentation, calculation etc.) introduces perceived redundancy and the potential for conflict if the included relationships are not consistent between types. For example, an ESD extension element could be included as a child of "current assets" in the presentation tree but as a child of "assets" in the calculation tree. This inconsistency negatively impacts the automated processing of the ESD. As such, the inclusion of a larger number of the different XBRL relationships does not automatically improve the processing of ESDs.

As discussed, the primary source of information to support the automated processing of an ESD extension element is the relationship that concept has with known BT elements. XBRL allows for four main kinds of element-to-element relationship to be provided with a taxonomy, these are called the "presentation tree", "calculation tree", "dimension tree"², and more generally "definition" tree. Each of these might include an ESD in a relationship with elements from the BT.

As the relationships provided with a reporting entity extension taxonomy each provide different information about ESDs we will discuss the conclusions for each separately.

For all of the following sections we are assuming that (as we have an preparer extension taxonomy) that all ESDs are tagged with extension elements.

Presentation

The presentation tree provides a set of relationships for the reporting entity taxonomy describing how elements relate to each other in a hierarchy representing the report presentation (or view). As a result, ESDs will have relationships to the elements they are displayed with. For example, an ESD disaggregation element might be linked to a parent element that appears 'above' it in the statement along with a set of other elements all presented at the same level.

This set of links allows a computer to automatically display a tree for taxonomy navigation and may help understand how the financial statement is presented to some extent. However the presentation tree does not always link ESDs with the most appropriate taxonomy element(s). For example, if that presentation does not represent a complete set of relationships for that disclosure (i.e., if the disclosure is not presented with all related items) or the presentation is a summary and the full report context is elsewhere, i.e, in an unlinked note.

Revisiting example 1b this would mean the disaggregation ESDs (as presented) are linked to a number of other non-current assets but as no total for non-current assets is provided they are not linked to that total from the BT. It is also not clear from the flat presentation in the example that there are smaller related groups of non-current assets reported. A human user could use the labels to identify these smaller groups (for examples the ESDs are all related to amounts due from related parties) but automated analysis based only on the presentation tree would be difficult.

Example 1b(pre): disaggregation without BT aggregation reported from a presentation perspective.

For aggregation ESDs, the presentation may include relationships to the contributing values. However, many aggregations (particularly on the face statements) are presented separately to any reported contributing values (as in example 3a) and may not be provided with links to those contributing values.

Additionally, the description of the relationships in the presentation tree does not provide clear descriptions of aggregation and disaggregation relationships as the tree structure is only described using general parent to parent-child relationships. The presentation tree is primarily designed to allow a description of where the disclosures appear in a statement and not what they mean in relation to other non-presentation relationships.

Calculation

ESDs will often have a defined mathematical relationship to base taxonomy elements. The calculation tree allows this to be captured in the taxonomy in some cases. The calculation tree allows the automated validation of these relationships and specifies the addition of entity-specific values to known BT values as the relationship between the elements has a specified meaning relating to the summation of values.

In general, financial statements provide aggregations (totals and subtotals) for groups of disclosures with a clear relationship to each other via a set of shared characteristics. For example, in IFRS, IAS 1 states that "An entity shall not reduce the understandability of its financial statements by obscuring material information with immaterial information or by aggregating material items that have different natures or functions."

As a result, the relationships provided for ESDs in a calculation tree are almost always with elements in the BT (either directly or indirectly) with very similar properties.

Again, looking at example 1a from a calculation perspective, example 1a(cal) below, a calculation tree provided with a reporting entity extension would significantly improve automated consumption of the ESDs. The calculation tree would indicate that all three values aggregate to provide the value for the BT concept 'Amount due from related parties, non-current'.

Example 1a(cal): disaggregation with components as ESDs from a calculation perspective.

Similarly, for the entity-specific aggregation in example 3, if all the components are reported and calculation relationships are provided then the automated consumption of that ESD is significantly easier. Variation 2 of the aggregation example could be improved if the filing rules require that calculation relationships are provided for aggregations across locations in the financial report.

There are however use cases where the calculation tree does not support the automated consumption of ESDs. In example 1b the BT concept 'Amount due from related parties, non-current' is not reported and in example 3, variation 2 the relevant aggregation components are not reported. The use of the calculation tree as a validation tool means that inconsistency messages are reported when a calculation cannot be verified, for example because the total is not reported. As a result in most cases no calculation tree would be provided linking the ESDs for related party values to the BT elements for related party values.

In general, the calculation tree provides many ESDs with clearly specified links to related BT element. As these links are related to summation information, they are very likely to be useful during further quantitative analysis.

There are, however, a number of occasions when a reporting entity extension taxonomy would be unable to provide these relationships:

• The report does not contain a complete calculation relationship to describe. The calculation tree is not generally provided for taxonomy elements with no reported values provided in the report.
• The calculation tree is not able to document dimensional aggregations.
• The calculation tree is not able to document calculations across multiple time periods, e.g., a reconciliation from a value at the beginning of the reporting period to a value at the end of the reporting period.

An additional factor affecting the usefulness of the calculation tree is that it is used as a report validation tool. As a result any relationships provided that are not a complete roll-up or include unreported figures result in validation inconsistencies. These may not indicate any problem with the report but report preparers and collectors may be reluctant to file are report with such inconsistencies.

Dimensions

The definition tree in XBRL can be used for two purposes; to provide the relationships related to XBRL dimensions and to provide 'definition' related item relationships. The definition item relationships are discussed below section.

XBRL dimensions allow qualifying characteristics to be added to XBRL line items. The resulting sets of line items and qualifiers are often called cubes or tables (they may not always be presented as tables in financial statements). The ESDs in example 1 could be represented in XBRL in two ways:

Line items only: This tagging would match the presentation in example 1. A human reader can see the properties for each value from the labels and identify that these three values represent a disaggregation by related party as discussed in the detailed use case section.

Using XBRL dimensions:

Example 5: disaggregation by related party from a dimension perspective.

The dimensional layout may or may not match the presentation but importantly represents the data and can still be used to tag the values. XBRL tables are about how the tagging is broken down rather than how the data is presented. With Inline XBRL a human reader would still see the presentation as provided in example 1 and can still draw all the conclusions discussed above.

There are two main types of taxonomy-defined dimension in XBRL: explicit and typed.

Typed dimensions are rarely allowed in reporting entity extension taxonomies as they already provide a way to report an extensible set of values without additional preparer extension. As such they are primarily discussed in the section on handling ESDs without such a taxonomy. Explicit dimensions are however commonly found in reporting entity extension taxonomies.

If an explicit dimension is used to tag example 5 then a computer now potentially has more information available for the automated processing of the ESDs compared with the use of solely XBRL line items. However, there are certain tradeoffs as discussed below.

If, for example, it is assumed that the BT provides values for the overall 'Amount due, non-current' and the dimension 'related parties' then the use of the XBRL dimension 'Related parties' associates all the reported values automatically with the information that they are values for related parties. Each entity-specific type of related party is associated with that dimension and also with the line item indicating that these are non-current amounts. The dimensional model allows more automation of processing for the ESDs.

Additionally, members within a dimension can be arranged into a hierarchy similar to that seen in the other types of XBRL trees discussed. This hierarchy can provide information about the relationships between the ESDs that a computer can understand. For example, the ESDs from example 1b represented as members may have the following structure in the definition tree:

All related parties (177.7)

Associate (88.4)
Joint venture (14.3)
Investee company (75.0)

This structure can be used to imply that all three ESD members form a disaggregation of the top-level member.

If an entity-specific aggregation point can be represented as part of the member structure in a dimension then the automation benefits from the additional XBRL relationships created as part of defining members, domains, dimensions, and cubes.

However, much of this structure in the definition tree is not provided with a formal semantic meaning, therefore a computer cannot always assume that (for example) it represents the disaggregation so this information is unreliable.

There are, however, circumstances where the use of dimensions does not improve the information available to a computer. These cases are similar in nature to some of the issues with the use of the calculation tree. The relationships available within the dimension structure cannot reliably be used to infer information about ESDs if:

• The dimension is not "well-behaved" i.e.,:

  • There are overlaps in the definitions of members on the same level of the hierarchy (summations may include duplicate member values in order to include various subtotals)
  • The hierarchy does not form the complete set of possible reported values and therefore does not total to the report-wide value (the summation is not complete)

• The dimension itself is an entity-specific dimension and therefore the entity-specific member values are not directly connected with a BT dimension.

Additionally, dimensions are not covered by the calculation tree so information otherwise available via that tree for the line items might be incomplete or not available.

Definition relationships

The relationships provided for use in the definition tree (other than those provided for XBRL dimensions) are not frequently used with reporting entity extensions at the moment. There are four relationships defined in the XBRL specifications for use in definition trees but only two of these relationships are relevant to this discussion.

The "general-special"³ relationship is intended to provide relationships between concepts that are related via generalization (has a broader meaning) and/or one is a specialization (has a narrower meaning). This relationship has a more clearly defined meaning than the relationship used in the presentation tree, however this relationship does not necessarily provide any information about how a disclosure contributes to summations.

The specification also includes a relationship called essence-alias⁴. This relationship is provided to allow links between identical concepts and has a number of validation rules enforcing this use. As a result this link is not generally suitable for use with ESDs. For example the essence-alias relationship cannot be used to link differently dimensionalised concepts (as often seen in reporting systems using dimensions for detailed figures but not for headline totals).

Taxonomy design best practice is to define a concept once (with alternative labels, if required).

Other information provided with a reporting entity extension taxonomy

Labels

Reporting entity extension taxonomies often include labels. These can be for both any extensions covering ESDs and for entity-specific labels for BT elements. XBRL provides a way to identify a number of different types of labels associated with taxonomy elements. The types of label provided for in the XBRL specifications include:

• Terse
• Verbose
• Labels for the positive and negative sense of a concept
• A label for the concept when used as a total
• Labels related to reconciliation across periods, e.g., Period Start, Period End
• Documentation labels intended for the provision of longer pieces of description about an element.

In general, labels provide a human reader with additional useful information. They are not generally considered structured data however they may be of some help to automation making use of unstructured data. In particular, some types of automated system may make use of the labels provided with a concept via Natural Language Processing (NLP). Additionally, some of the labels may provide additional information for automation via the types of label (label role) provided for an element and which label is specified as the 'preferred'⁵ label for a particular reporting context. In particular the types of label relating to cross period calculations may be used to imply calculation information. These types of label are not limited to use in contexts where a calculation is appropriate however so this inference may not always be reliable. The use of Inline XBRL may also reduce the availability of the different types of label as the Inline document reduces the need for additional rendering information. As such regulators may be less likely to require the customization of base taxonomy labels.

References

XBRL elements may be provided with references to external materials. For example, elements in the IFRS Taxonomy and the US GAAP taxonomy are provided with references to paragraphs in the relevant standards. Extensions created for entity-specific disclosures could also be provided with references to appropriate resources such as associated accounting standards or industry body definitions.

XBRL references usually consist of a number of set fields describing a reference to specific parts of source Standards or requirements.

E.g., a set of elements with a common reference to a single disclosure paragraph can be inferred to be a related to a set of disclosures on that topic.

XBRL references can also be provided with types. For example, in the IFRS Taxonomy there are three types of reference, Disclosure, Example and Common Practice. Reference types may assist automation by providing the ability to look for additional information about the comparability or consistency of a disclosure.

If the reference is to a formal definition (e.g., another taxonomy or ontology) that can be automatically consumed then references may also contribute more meaningfully to the processing of ESDs.

Reference information for ESDs may be provided directly by a reporting entity or found via extension relationships to BT elements. XBRL References do not however usually provide directly automatable information about the detailed relationships between elements with the same references, such as how those elements contribute to summations or how they relate to other disclosures made by the entity.

Entity-specific adjustments to values (Extensible enumerations)

XBRL includes a mechanism for reporting a value taken from an enumerated list. For many ESDs the entity-specific nature of the disclosure is an additional value to such an enumerated list⁶: The Extensible Enumeration feature provides a mechanism to report these properties as facts using a taxonomy's existing domain hierarchy element as a fact value for a primary line item. These domains can be extended to contain the ESDs in a similar way that members can be added for dimensions. In fact, these domain hierarchies with ESD extensions can be used for both dimensions and extensible enumerations where appropriate⁷: The domain hierarchies are commonly described as a list of allowed values either provided by the BT or included by extension.

In this example 6, a filer needs to report their primary source of revenue and a description of that source of revenue with an additional property that is not provided for in the BT, they can use an Extensible Enumeration element to report the revenue type. The BT can provide a list of common sources of revenue. If the primary revenue is not on this list, it can be added, for example "crowd funded" as a source. The filer can report revenue using the primary line item provided for revenue accompanied by an element, e.g., "Primary Revenue Type" that is associated with this list of revenue types from the BT. It might look like this:

Example 6: Extensible enumerations example

In both these cases an XBRL Extensible Enumeration provides an extendible base set of values in a very similar way to the use of XBRL dimensions discussed. Extensible enumerations can be provided in a BT for use in a closed reporting system however, without a reporting entity extension taxonomy, the list of values cannot be extended to include entity-specific disclosures.

The ESDs are provided with BT context via the provided BT definition and set of values and the improved context for automation is very similar to that described for the use of dimensions and the definition tree.

Summary

ESDs are easiest to process automatically when they have a clear context, in particular in relation to the known BT elements.

As described in the analysis, there are a number of cases where entity-specific disclosures are already provided with good BT context, particularly where a calculation tree is provided or ESDs are included via the use of dimension members. Predictable ESDs provided with BT structures for reporting may also have useful relationships. This applies to both ESDs providing both aggregation and disaggregation items. Any standalone ESDs would not be included in the calculation tree but this type of ESD is also rare and less likely to be included in an automated analysis.

However a number of issues have been identified affecting how complete and useful this context is. The issues are generally related to the completeness of the report context provided for ESDs, both within base taxonomies designed to include ESDs and within reporting entity extension taxonomies.

Specifically the mathematical relationships required for the successful analysis of ESDs have a number of problems. These are seen most often where ESDs are:

• qualified by XBRL dimensions;
• provided as part of an XBRL dimension (e.g., as a member);
• contributing to cross-period calculations; and
• contributing to incomplete roll-ups and other calculations (e.g., not all concepts are reported or the calculation does not validate and therefore cannot be completed).

Other issues include that:

• mathematical context provided for ESDs is often split across multiple XBRL features (eg cross-period calculation information from the presentation tree)
• the meaning of the relationships being used may not be clear, often as these relationships were not designed specifically to communicate mathematical roll-ups and support ESD automation.