Table of Contents

1 Objective

Entity Specific Disclosures (ESD) in XBRL reports were addressed in the first publication of the Entity Specific Disclosure Task Force (ESDTF), "How to address Entity Specific Disclosures in XBRL reports" In this publication, the task force objective is to identify and recommend mechanisms that taxonomy architects and taxonomy authors can utilise to contain ESDs within the base taxonomy.

The taxonomy and filing rules should include mechanisms to accommodate ESDs that minimise extensions and facilitate use. Extension taxonomy elements in their various forms are used for reporting the ESD if not otherwise provided for in the base taxonomy structure, and anchoring is a mechanism for associating the extension to a base taxonomy element. ESD as defined in the XBRL International glossary:

Disclosures included in a report that are specific to the reporting entity, or to a small number of reporting entities. Such disclosures require special handling in XBRL as it is not practical for the base taxonomy to include the concepts and domain members needed to report all such disclosures for all entities. In order to facilitate the tagging of such disclosures, mechanisms such as entity-specific extension taxonomies may be used. Entity-specific disclosures are common in open reporting environments, but do not occur in closed reporting environments.

An appropriate ESD can 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 segment.
• Broadly defined reporting requirement. For example, describe your business.
• Unpredictable information: the entity chooses to report information that is consistent with but not required by reporting requirements. For example, subtotals.

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

2 Why?

Base taxonomy architecture significantly impacts the quality and usefulness of XBRL reports. A base taxonomy that provides effective mechanisms for ESD reporting should result in extension taxonomies that are consistent, easy to consume and facilitates comparison of XBRL reports. This guidance discusses different taxonomy modelling alternatives for ESD to help the taxonomy authors make better informed decisions.

In a taxonomy, a disclosure can be modelled at a broad level or narrowly using granular breakdowns. Choosing a broad level when a more granular breakdown is appropriate may result in collecting unstructured information that is relevant and beneficial to the user or conversely collecting redundant granular information that costs more to prepare and isn’t useful to the end user. The first part of the guidance describes a decision tree that provides considerations for choosing the optimal level of breakdown for disclosure modelling.

3 Scope

• Identify mechanisms for incorporating ESDs in the base taxonomy and their optimal use case.
• Modelling base taxonomy to manage the number of extension taxonomy elements to an appropriate level and providing a framework for robust extension to best fit the base taxonomy to address majority of ESD cases.
• Include "Taxonomy Modelling Decisions for Entity Specific Disclosures" decision tree to arrive at the extent to which a disclosure’s breakdown may be appropriate to be modelled in the base taxonomy, please see Appendix A.
• While most examples are from financial reporting the principles can be extended to other reporting frameworks.

4 Out of scope

• For this publication, it is assumed that the decision to provide for an ESD in the base taxonomy has already been made.
• This document does not include a general discussion on modelling choice such as concept versus dimensions or explicit versus typed dimension except within the context of ESDs.
• This document does not include discussion for alternative methods to incorporate narrative ESDs.
• This document is not applicable to closed reporting environments which have fixed lists of items for disclosure and open reporting environments which do not allow preparer ESDs.

5 Target Audience

The primary intended audiences for this document are taxonomy architects and taxonomy authors.

This document 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 the taxonomy authors 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; and
• The requirements of any existing filing/collection system.

6 Analysing Disclosure for Taxonomy Modelling

The first step to provide optimal ESD modelling in a base taxonomy is to gain an understanding of the reporting requirements and how these requirements influence modelling choices later in the process. This and subsequent steps will need to be repeated for each reporting requirement.

6.1 Understanding the Disclosure (#1 in the decision tree)

Understanding the scope and nature of a reporting requirement is a prerequisite to providing for an ESD in a base taxonomy as there can be more than one way to optimally provide for the ESD. Insufficient attention given to this step could result in wasted time or worse, making poor modelling choices.

The taxonomy architects and taxonomy authors should understand:

• The underlying framework that provides context for and informs the reporting requirement.

  For base taxonomy modelling, understanding the reporting requirement is the priority, as this is what the taxonomy authors must provide for. Nonetheless, an understanding of the underlying recognition and measurement requirements as well as scope, basis for conclusion, and other narrative is necessary as these requirements can influence how taxonomy authors might model the requirements in the base taxonomy and how ESDs can be contained. For example, a concept may have mixed measurements such as amortised cost and fair value, as in the case of financial instruments, that can only be understood with knowledge of the aforementioned requirements. If not a subject matter expert themselves, the taxonomy authors can obtain this understanding through an industry or subject matter expert. It will also be helpful to consider any examples of disclosure requirements provided with the standard to preview how preparers might consider meeting the requirements.

• How entities commonly report

  The taxonomy author should have a consistent and transparent methodology to identify the commonalities and differences in Common Practice Reporting (CPR) as defined and illustrated in Section 7. This is a bigger challenge for a new reporting requirement since common practice has not yet developed but is an important consideration for a new base taxonomy or for post adoption review where additional base taxonomy improvements are anticipated based on resulting common practice.

• How the reporting requirement relates to other reporting requirements

  Quite often a new reporting requirement can overlap or intersect with other reporting requirements particularly from a taxonomy modelling perspective. For example, Accumulated Other Comprehensive Income (AOCI) by its nature is frequently impacted by other reporting requirements. As such, the taxonomy authors needs to consider this overlap and how it might impact ESD modelling considerations.

6.2 Should the disclosure breakdown be structured? (#2 in the decision tree)

The taxonomy author will need to decide if they should model the disclosure as a single data point (i.e., not structured) or model its breakdown components (structured). Absent regulatory requirements that stipulate a specific way to model, the choices made here can affect how ESDs are reported and the resulting usefulness to the user and the related cost to the preparer. The following are considerations to help the taxonomy author decide:

• Consider structuring if:
  • The user is likely to use this information as discrete facts in analysis such as an earnings model, macro data analysis or regulatory monitoring where the discrete facts are useful
  • Benefit to the user justifies an additional cost by the preparer
• Consider not structuring if:
  • The user reads this disclosure in context
  • The disclosure does not lend itself to mathematical or structured analysis
  • The expected level of effort to consume the data is sufficiently high that users would not automatically consume the disclosure
  • The benefit to the user does not outweigh the cost to the preparer
• Alternatively, include the modelling in the taxonomy and phase in the tagging requirement over time where:
  • the utility might be realised later;
  • the cost/benefit is expected to change; or
  • you want to encourage movement in that direction.

6.3 Analyse the breakdown, if it needs to be structured (#3 in the decision tree)

The step above may lead to several ways a broken-down disclosure can be structured. Each of the breakdowns is further analysed, as follows:

• Analyse if each breakdown component needs to be further broken-down using the principles outlined above and iterate the whole process.
• Model each component of the breakdown as line items, dimensions, or some combination.
• If it is anticipated that ESDs will be reported for that breakdown choose an appropriate ESD modelling alternative, please see Section 7.

Refer to Appendix B for examples of how disclosure can be analysed for breakdowns.

7 ESD modelling choices in base taxonomy

This section discusses several mechanisms that the taxonomy authors can use to provide for ESDs in a base taxonomy. These mechanisms are not mutually exclusive and a combination may be used to achieve the best results. The focus is on supporting preparer element extensions for ESDs, but mechanisms that can minimise element extensions while still allowing for ESDs are also considered.

7.1 Common Practice Reporting Elements

Common Practice Reporting (CPR) is for information that entities report in practice that is not explicitly specified in the underlying reporting standards, is not prohibited or inconsistent with the standards, and is considered widely recognised and prevalent either generally or for a specific industry. Common practice reporting is the most common ESD situation that a taxonomy authors needs to address for an open reporting environment that allows preparer ESDs using element extensions.

For many implementations, the taxonomy authors will need to analyse many reports to identify and quantify the common practice reporting both before and after the XBRL filings. The significant limitation for identifying common practice reporting elements is that this exercise is often after the fact, particularly for new accounting standards. For example, with many base taxonomies, the taxonomy author is constrained from including base taxonomy elements for anything beyond what the standard requires until implementation of the standard can be observed in practice. Once the standard is observed in practice, elements can be added to the base taxonomy to address observed common reporting practice. Considerations are also different for a new base taxonomy where there may be considerable reporting already in place to analyse.

• The taxonomy author should first establish agreed upon criteria for including common practice elements in the base taxonomy. For example, common practice reporting elements should:
  • Be consistent with and conform to reporting standards throughout the guidance.
  • Not be affected by forthcoming reporting standards that are known or planned.
  • Be consistent with and conform to existing or intended modelling.
  • Be frequent enough to support inclusion in the base taxonomy, considering industry focus versus the entire population of preparers.
  • Meet identified user needs, i.e., don’t add just because it is common.
  • Not play to special interest groups that effectively distort the taxonomy.
• With agreed upon criteria, the taxonomy author will then need to identify common practice reporting elements for the disclosure and target population in question. The methods for identifying and grouping the extension elements is beyond the scope of this publication and will vary between projects.
• Perform evaluation of the extension elements based on established criteria to identify common practice elements for inclusion in the base taxonomy and how best to do so.

7.1.1 How to include common practice reporting element in base taxonomy

This section lists how to include common practice reporting elements in a base taxonomy to minimise the need for ESD elements as well as maximise their usefulness for "anchoring", by using relationships, and including relevant metadata. There is marginal benefit to including a common practice reporting element that is not adequately distinguished from and related to the existing base taxonomy structure. It is applicable for concepts, taxonomy-defined-dimensions, and domain members regardless of the intended modelling. This section focuses on the linkage to authoritative literature, relationships, and guidance to facilitate distinguishing common practice reporting elements from other elements. Common practice reporting elements should be easy for prepares to find but with a clear understanding of their common practice reporting nature and how they relate to base taxonomy elements.

• References:

  • An XBRL reference consists of a "reference role", describing the nature of the reference. Distinguish common practice reporting elements from other elements using references to accounting standards with unique reference roles. Common practice reporting elements should use the ‘commonPracticeRef’ reference role from the XBRL specification to distinguish between common practice reporting elements and other elements.

• Relationships:

  • Include common practice reporting elements in the same relationship tree hierarchy as related concepts in accordance with an applied model, e.g., accounting model. Common practice reporting elements should have appropriate relationship to other disclosure elements in a given presentation, calculation, or dimensional view (or some alternative if these views aren’t used or constrained).
    • Include as relationship to base taxonomy concept, e.g., Other Assets that are more specific.
    • Include grouping of common practice reporting elements by industry, for example banking and finance common practice reporting elements.
  • In some cases, it is not possible to associate a common practice reporting element with other disclosure elements and it may be necessary to include in a separate network.
  • Include common practice reporting dimensions for a breakdown that becomes common in practice and could provide an anchor point¹. For example, the IFRS taxonomy includes "Agricultural produce by group [axis]" as a common practice reporting element.
  • Consider including properties that can be used to provide additional meta data for base taxonomy element, e.g., members, extensible enumeration values.
    • For example, the US GAAP Taxonomy uses an Extensible Enumeration element, "Revenue from Contract with Customer, Product and Service [Extensible Enumeration]," that includes an extendable list of values used to modify an associated fact for another element, in this case, "Revenue from Contract with Customer, Including Assessed Tax." See "Product and Service [Domain]" in the SRT for a complete list of provided values. A sustainability taxonomy may define activities included in the measurement of ‘Scope 3 emissions’ as an enumeration, which can have common practice reporting items.
• Guidance:
  • Provide documentation for the common practice reporting modelling to help users identify common practice reporting elements and expected use.
  • Provide guidance for a consistent approach by preparers to create a common practice reporting extension in between official taxonomy updates that better relate those extensions to the base taxonomy, facilitates consumption by users, and simplifies updating in the subsequent period.

Other considerations

• Increased taxonomy elements that may require more taxonomy author resources to maintain.
• The effort required to identifying common practice reporting elements is on the high side both for identifying the elements used and performing the required analysis to gauge the usefulness.
• May be challenging to agree on the criteria for including common practice reporting elements.
• Data users may not find common practice reporting elements any more useful than a wider element already available in the taxonomy.

Expected benefits

• Improved comparability.
• Reduced number of extensions for common practice reporting elements.
• More likely that reporting entities will find an appropriate selection with a more comprehensive set of choices.
• Provides data users with fewer extensions, better semantics, and increased consistency.

7.2 Anchor Points for ESD Aggregations

An "Anchor Point" is a base taxonomy element to which an extension element is associated to convey a relationship in the meaning of the two elements. This section includes examples where base taxonomy anchor point elements for key aggregation points would be helpful for more specific ESDs that aggregate/rollup, such as totals, subtotals, and net.

Total/Subtotal Anchor Points: Each common aggregation point should be represented by a total element in the base taxonomy and each subsection should have a subtotal element, which can be used as anchor points for extension elements. This is common in base taxonomies with available anchor points such as "Total assets", "Total current assets", "Equity", "Total non-current liabilities".

Common aggregation points that could be used as anchor points are less frequently provided where a particular section of a primary statement is comprised of items with opposite signs. For example, disclosure of items with "gross" meanings adding up to a subtotal/total with a "net" meaning. For example:

• Both revenue/income and expense items adding up to a "net" item.
• Both inflows and outflows of cash item adding up to a "net" cash flow item.
• Both increase and decrease movements in a reserve adding up to balance carried forward amount.

ESDs that are components of these sections which also have a "net" meaning can be anchored to the "net" subtotal element. However, when entity specific disclosures have a "gross" meaning, quite often the closest wider anchor point is still the "net" item subtotal. This distances the accounting meaning of the anchor point from the ESD and can result in the extension element being anchored to a base taxonomy element with the opposite balance attribute.

7.2.1 Example 1: ESD is for a non-operating expense

"Subsidiaries Management" in Table 1 is a non-operating expense ESD.

• Line item: "Subsidiaries management"
• Extension element: "Subsidiaries management"
• Closest wider element available in a given base taxonomy: "Profit (loss) before tax".

Similarly, a "Total non-operating income" anchor point would provide a closer anchor point for entity specific non-operating income disclosures.

7.2.2 Example 2: ESD is for interest received as a financing activity

"Interest Received" in Table 2 is a financing activity ESD. The base taxonomy has an element for the reported "interest paid" but does not have a corresponding element for "interest received" under financing activities.

• Line item: "Interest received"
• Extension element: "Interest received, classified as financing activities"

Closest wider element available in a given base taxonomy could be: "Cash flows from (used in) financing activities" (this is a net element for all financing activities).

The balance attribute of the ESD and the reported fact polarity conveys to the user whether it is an increase or decrease in cash derived from financing activities. However, the user can’t determine if it is net or gross cash inflows or cash outflows. This scenario could be complicated further if the report facts include both an increase and decrease as separate line items (as it seems to be the case here given the "interest paid" reported). Moreover, using "Cash flows from (used in) financing activities" does not convey to the user that this is "interest".

Note that a base taxonomy may have "Interest received, operating activities" and "Interest received, investing activities" but wouldn’t offer a similar element under financing activities.

There is still some missing information regarding the interest attribute but that is beyond the scope of this document.

7.2.3 Example 3: Net anchor points for cashflow changes in operating activities / working capital

This ESD is a reduction in debt securities and an increase in cash for operating assets and liabilities.

• Line item: "Debt securities in issue"
• Extension element: "Adjustments for increase (decrease) in debt securities in issue"

Closest wider element available in a given base taxonomy could be "Cash flows from (used in) operating activities" or "Increase (decrease) in working capital" depending on reporting practices. The balance attribute of the ESD and the reported fact polarity convey to the user whether it is an increase or a decrease in cash. However, the user can’t tell if it is change in an asset or liability or that it is a change in debt for this case. This scenario could be complicated further if the reported facts include both an increase and decrease as separate line items.

7.2.4 Example 4: Roll forwards/Reconciliation

When a tabular reconciliation of total amounts at the beginning and end of the period of an accounting balance (e.g., goodwill) is required to be disclosed by a standard setter, an instant element for the beginning/ending balance and several duration elements for certain activity during the period would be available in the base taxonomy. However, it is not possible for the taxonomy author to anticipate nor include elements for all activity that could be disclosed for that roll forward. In these situations, a taxonomy author should consider including a "Period Increase (Decrease)" net element for each roll forward available in the base taxonomy to which ESDs could be anchored. Further, this "Period Increase (Decrease)" net element allows a calculation relationship to be established in the base taxonomy to communicate to users of the data it is the total for the existing roll forward activity elements available for the respective accounting balance. The balance attribute for each "Period Increase (Decrease)" net element should follow the convention applied for assigning this attribute in the given base taxonomy.

Including such anchor points can better convey to a user of the data that the ESD relates to the activity for a specific roll forward, which is not able to be conveyed as a calculation relationship under the current XBRL specification at the time this document was available for publication.

A taxonomy author should further consider whether separate "Period Increase" and "Period Decrease" gross elements are necessary to be included as children of the parent "Period Increase (Decrease)" net element for each roll forward as anchor points. Considerations could include, but are not limited to, whether users of the data would find the gross versus net trait of the data points relevant in trying to understand the ESD.

This ESD is for the reduction of goodwill due to disposals and the effect of net exchange differences arising on the translation of the financial statements from the functional currency into a different presentation currency.

• Line item: "Disposals/Exchange effect"
• Extension element: "Goodwill, Disposals and Exchange Effect"

If anchoring is required for such an ESD, the Figure 1 illustrates how the ESD would be anchored using the wider-narrower arc role for the fact pattern outlined in this example:

Figure 1: Anchoring proposal for example 4

7.2.5 Other anchor points for consideration

• Additional anchor points that taxonomy author should consider including in the base taxonomy:
  • Expenses, by function
  • Total operating income (to anchor specific items of ESD of operating income which are separately disclosed)

7.3 "Other" Elements

Taxonomies should include "Other" elements for facts reported as the "aggregation of items not otherwise reported separately" for any given breakdown of related facts where it is reasonable to expect that preparers will have items to report that are not precisely identified in the base taxonomy. These elements are a mechanism to reduce the need to extend for an ESD.

"Aggregation of items" can be either the aggregation of items not otherwise reported separately, e.g., "Other Warranties," or the aggregation of specific items, for example Other Comprehensive Income (OCI) and Accumulated Other Comprehensive Income(AOCI).

These elements are commonly identified with other in the element standard or documentation label, but it is important to understand the composition of an amount being referred to as "Other" rather than focus on the presence of the term "Other". When "Other" is used in the base taxonomy, the definition should be clear about its composition.

When "Other" is for an aggregation of items not otherwise reported separately, then the definition should include terminology that communicates this intent. These elements do not have a precise meaning beyond the breakdown they relate to. For example, "Other Warranties" has no meaning beyond "Warranties" and "Other." Contrast that with an ESD where the preparer reports a concept with a more precise meaning, e.g., "Extended Warranties." In this case, the preparer would not use "Other Warranties" to tag "Extended Warranties" because the preparer is communicating a fact with a more precise meaning ². "Extended Warranties" could be anchored to the total of the breakdown or an element in the breakdown that has a closer wider meaning.

When "Other" is used to represent an aggregation of specific items, it would then have a specific definition or precise meaning such as OCI.

While less common, components of an "Other" element may be reported. These components must also be recognised as participating in the disaggregation of the "Other" element and is also an aggregation of items not otherwise reported separately, i.e., the "miscellaneous other" element. For example, "Other Operating Expense" may have "Miscellaneous Other Operating Expense".

Taxonomy authors should consider the following guidelines for including "Other" elements in the base taxonomy:

• Use established common practice reporting criteria for including "Other" elements in the base taxonomy. Every breakdown in the taxonomy that includes a total should have an element for tagging the aggregation of items not otherwise reported separately, the exception would be for aggregation of specific items such as OCI and AOCI. The simplest approach is to include an "Other" element anywhere a further breakdown is possible, but this will likely result in the inclusion of many elements in the base taxonomy with marginal use. Consideration should be given to expected volume for the inclusion of an "Other" element. The following are examples of breakdowns where an "Other" element could be expected.
  • Warranties – Other Warranties
  • Asset Impairment Charges – Other Asset Impairment Charges
  • Long-term Debt – Other Long-term Debt
  • Expense by nature – Other expense by nature
• "Other" elements are also applicable for dimension members, e.g., Other Reserve Member.
• "Other" elements are rare on the statements (as opposed to the notes) but they can occur when the preparer reports an ESD on the statement possibly in combination with another ESD (or base taxonomy concept) as a disaggregation of a base taxonomy element. It is not necessary for the taxonomy author to include these possible "Other" elements on the statements, but they should be available in the note breakdown.
• Preparer guidance (element documentation label or separate guidance) should make it clear that the "Other" element can be used to tag items that are the "aggregation of items not otherwise reported separately" and should not be used for ESDs for which additional specificity has been provided. For example, "Other Warranties" included in a breakdown of "Warranties" should not be used to tag an ESD "Extended Warranties" as it has a more precise meaning.
• Taxonomy author should provide guidance for the preparers on how to use the "Other" elements. Anchoring to "Other" elements should only occur when there is a breakdown of a Other Element. This also applies to Dimension Members.
• "Other" elements should also be included in roll forwards to report the aggregation of items not otherwise reported separately but ESDs reported as part of a roll forward should more commonly use the period increase / decrease element for anchoring as discussed in the prior example.
• Consider other techniques used to model "Other" elements. For example, the FRC taxonomies, used by the HMRC mandate, use an "analysis item" element in each breakdown of the primary statements e.g. "Further item of debtors". Each such analysis item in the taxonomy is linked to a typed dimension defined as being a positive integer. The analysis item elements can be used multiple times to tag ESDs in each breakdown, each time with an incrementally higher integer member in the typed dimension. This construct reserves all elements in the taxonomy with the word other for use to tag line items with an "aggregation of items not otherwise reported separately" meaning. This method works well in XBRL reporting regimes which disallow or discourage extension taxonomies but does not work where ESDs are required to be tagged with named extension elements as the information relating to ESDs is tagged but not labelled.

7.4 Addressing ESDs using Taxonomy-defined Dimension

The taxonomy-defined dimension can be used to provide additional qualification needed to fully identify a fact. These additional qualifications can be entity specific which makes it necessary for taxonomy authors to provide mechanisms to handle ESDs in the dimensional breakdown. This section explains different use cases for addressing ESDs in the dimensional breakdown.

7.4.1 Use case 1: When complete breakdown is Entity Specific

In this case, as all the breakdown items are entity specific, it is difficult to define these in the base taxonomy. For example, revenue breakdown by major customers or investment breakdown into individual securities. There may be a few breakdowns which are common across entities in the same industries but may not be large enough to include in the base taxonomy.

Possible approaches are discussed below.

7.4.1.1 Explicit Dimensions – Dimension members added by preparer in the extension taxonomy

In this approach the base taxonomy defines only the explicit taxonomy-defined dimension and the domain indicating the breakdown required and the preparer domain members. For example, explicit dimension for business segments is defined in the taxonomy and the preparer adds domain members for each of their business segments. This approach has the following characteristics:

• A taxonomy extension is required.
• The domain member meaning can be self-explanatory using the standard label e.g., "Automobile Segment". Additional labels can be created to explain the member added by the preparer
• The domain members can be reused in other breakdowns or as enumerations fact value.
• Domain member defined by the preparer can be used across reporting periods facilitating time series comparison.
• May not be the most efficient approach for disclosures with large amounts of granular data where the domain member acts as a unique identifier; such as a real estate schedule in a Real Estate Investment Trust.

7.4.1.2 Explicit Dimensions – Generic Members defined in the base taxonomy

In this approach the base taxonomy defines an explicit dimension with generic domain members such as "Director 1", "Director 2", etc. The required number of domain members are available in the base taxonomy. For example, a disclosure requiring reporting details of stakeholders holding more than 5% of share capital may be modelled using this approach, which will require a bounded number of such generic members. This approach has the following characteristics:

• A taxonomy extension may not be required and can be avoided.
• An additional line item element is required to explain the meaning of the member, such as name of the counterparty or business segment.
• It may be challenging to do cross period comparison for the same member, for example "Director 1" may not represent the same person across periods.
• It may not be feasible where the number of breakdowns is so large that it isn’t practical to include in the base taxonomy.
• If the bounded number is smaller than the required breakdown some information may be lost or the design is unable to accommodate the filing requirement.

7.4.1.3 Typed Dimension

In this approach the base taxonomy defines a typed dimension and preparers are expected to add the typed domain members. For example, investment disclosure which requires details of each investment held modelled as typed dimension requires preparers to add each investment as typed domain member. This approach has the following characteristics:

• A taxonomy extension is not required.
• The format of typed dimension members to be added can be restricted in the taxonomy, for example for investment disclosure the ISIN format can be specified.
• It is easy to accommodate large breakdowns without the need to create an element for each breakdown in the taxonomy, e. g. transactional reporting.
• It may be challenging to compare across companies and periods if the domain members do not use standard identifies such as LEI, ISIN, date format.
• Non-identifiable breakdowns can be identified with an arbitrary "sequence number" that simply provides a grouping of facts with the same dimension value. For example, credit exposure breakdown by loans; will typically be modelled using an arbitrary identifier as the loans do not have a universal identifier.
• The concepts that can be reported without the typed dimension breakdown (e.g., aggregate values) need to be modelled in a separate cube that does not include the typed dimension.

The below table provides guidance to choose one of the above approaches depending on the requirement of the disclosure.

All the above approaches can co-exist in a base taxonomy.

7.4.2 Use case 2: When the common breakdown of items is mostly known

The common breakdown of items is mostly known and few additional items are required for ESDs. For example, in the case of property plant and equipment (PPE) disclosure, there are commonly reported PPE classes (such as Land & Building, Computers) and some classes which can be specific to the industry or entity (such as Furnace).

For this case, the recommended approach is to define the commonly known breakdown items as explicit dimension members in the base taxonomy and require preparers to add explicit domain members to capture the ESDs. The approach of defining common reporting elements and "others" elements (as discussed in the Section 7.3) can be applied to partially known breakdown as well.

Characteristics and Consequences

• A possible set of values acts as a guide for preparers to understand the modelling of disclosure.
• Labels can be created to explain the member added by the preparer.
• Ensure comparability across entities for commonly reported breakdowns.
• Entity specific disclosures are comparable across reporting period.
• Requires taxonomy extension.
• Aggregation rules for explicit breakdown can be defined where applicable, e.g., using XBRL formula rules can define members contribute to the default of the members.
• Placement and relationships within the domain hierarchy can imply semantic meaning, for example, the member "Furnace [Member]" as a child of "Building and Building Improvements [Member]" implies that it is part of "Building and Building Improvements".

It is recommended that typed dimension not be used to model the breakdown when majority of breakdown items are known beforehand as this will make the whole disclosure incomparable across entities/periods and does not have mechanism to describe the breakdown items.

7.4.3 Use case 3: When the breakdown of items is entirely known

In this case, most breakdown items are known and are required for an entity’s disclosure and the members are not ESDs. This use case falls into general modelling considerations but is included here for completeness. For example, revenue breakdown by currency is an ESD but the members are not ESDs and are entirely known. Similarly, with the fair value hierarchy disclosure, i.e., Level 1, 2, and 3.

Possible approaches are discussed below.

7.4.3.1 Explicit Dimensions – Dimension members added in the base taxonomy

In this approach the base taxonomy defines the explicit dimension indicating the breakdown required and includes all members. For example, an explicit dimension for currency is defined in the base taxonomy and provides for all currencies as members; or an explicit dimension for the fair value hierarchy is defined in the base taxonomy and provides for Levels 1, 2, and 3. This approach has the following characteristics:

• A taxonomy extension is not required.
• The dimension member meaning can be self-explanatory using the standard label e.g., "Switzerland, Francs" or "Fair Value, Inputs, Level 1". Additional labels can be provided, such as a documentation label, to expand on the member meaning if needed.
• The dimension members can be reused in other breakdowns or as Extensible Enumeration Facts.
• Members defined by the base taxonomy can be used across reporting periods facilitating time series comparison.
• Extension members can still be added for the rare case, e.g., combination of Level 1 and 2 in the fair value hierarchy.

7.4.3.2 Typed Dimension

In this approach the base taxonomy defines a typed dimension and preparers are expected to add the members even though the complete breakdown of members is knowable. For example, a disclosure that requires a breakdown by postal code or Legal Entity Identifier (LEI) can be modelled as a typed dimension rather than including all postal codes or LEIs as members in the base taxonomy. A disclosure that requires a breakdown by date can be modelled with the date as the member. This approach has the following characteristics:

• A taxonomy extension is not required.
• The format of typed domain members to be added can be restricted in the taxonomy by the member data type. For example, a maturity schedule without prescribed periods, can use a date formatted member, YYYY-MM-DD.
• It is easy to accommodate large breakdowns without the need to create an element for each breakdown in the taxonomy even when the population in known, e.g. dates or postal codes.
• Standard identifiers as domain members – such as LEI, ISIN, and date format – make it easier to compare across companies and periods.
• Non-identifiable breakdowns can be identified with an arbitrary "sequence number" that simply provides a grouping of facts with the same domain value. For example, credit exposure breakdown by loans; will typically be modelled using an arbitrary identifier as the loans do not have a universal identifier.
• The concepts that can be reported without the typed dimension breakdown (e.g., aggregate values) need to be modelled in a separate cube that does not include the typed dimension.

The below table provides guidance to choose one of the above approaches depending on the requirement of the disclosure.

All the above approaches can co-exist in a base taxonomy.

7.5 Mitigating extensions resulting from regulator lag adopting new accounting standards or updated taxonomies

• Provide guidance (best practice) to preparers for tagging new disclosure requirements not yet available in the regulator adopted taxonomy.
  • The European Single Electronic Format (ESEF) rule – extend elements available in the IFRS taxonomy but not yet in the ESEF taxonomy.
  • SEC/US-GAAP – encourage preparers to use elements from the development taxonomy for new accounting standards not available in SEC accepted taxonomy.
• How to mitigate lag:
  • Update taxonomy on annual basis to reflect all detailed requirements.
  • Update at least one text block to reflect the new standard disclosure, if detailed disclosure cannot be included.
  • Update "development" taxonomy concurrent with new accounting standards to provide preparers with element names for ESDs.
  • Different reference for such elements – indicating not ready for detailed tagging.
  • Assure that relevant base taxonomy or development taxonomies are available to preparers between annual updates.

7.6 General other practices

• Provide documentation for base taxonomy elements to aid in element selection, tagging, and identifying anchor points.
• Provide Calculation relationships wherever possible for preparers to understand the rolls-ups.
• Analyse extensions to find patterns for common ESDs and include in the next maintenance cycle as common practice reporting elements.
• Ensuring all broad level roll-ups required for analysis are available in the taxonomy.
  • These broad levels roll-ups to well defined wider concepts for anchoring.
• Provide true semantic framework that by design includes anchor points for ESDs; model those properties that "can be modelled" thus providing an anchor point.
• Consider other options for relationships to convey semantic meaning.

Appendix A Analysing disclosure for breakdown - decision tree

The decision tree to analyse a disclosure breakdown for taxonomy modelling is described in Figure 2

Figure 2: Taxonomy modelling decisions tree

Appendix B Analysing disclosure for breakdown - decision tree examples

Sample testing of decision tree in Appendix A with numeric disclosure is described in Figure 2

Figure 3: Sample testing of decision tree with numeric disclosure