Table of Contents

1 Abstract

Business reports typically provide information about the entity preparing the report, for example, a company’s financial statements. In doing so it is common to also include some information about other parties. For example, the report may contain information about subsidiaries and associates of the preparer, transactions with its related parties, and engagement of third parties. We use the term “entity” to refer to all possible types of other party.

As a result, there is a need to identify each of the entities whose data is reported in the preparer’s report. This document discusses the different approaches that can be used when modelling such information in an XBRL taxonomy.

This document will discuss various use cases and provide guidance for taxonomy authors on how to implement these use cases.

The appendices contain examples of taxonomies that use the approaches mentioned.

2 Identifying the preparer of a report

In this document, the term "preparer" is used to refer to the entity responsible for the report and its content, even if the practical work of creating report is actually outsourced to a third-party agent.

Best practice is to use the "entity" built-in dimension to identify the preparer of the XBRL report. The entity dimension consists of an identifier, and a URI identifying the scheme from which that identifier is drawn. For example, the identifier could be a Legal Entity Identifier (LEI) in which case the scheme should be the URI http://standards.iso.org/iso/17442.

If a report has been created by a third-party on behalf of the preparer, and it is necessary to disclose this in the report, then a structure in the taxonomy should be used to identify the third-party and the nature of the relationship between the preparer and that entity.

3 Use cases - identifying multiple entities

The use cases are determined by the number of entities involved.

Use cases described in this document:

1. At most one entity being reported. For example, the accountant of the preparer.

2. An unknown number of entities are being reported. For example, listing all subsidiaries of the preparer.

3. A fixed number of entities being reported. For example, listing the top 10 customers that products are sold to.

3.1 Use case 1: At most one other entity being reported

In this case, there is at most one entity having the specified relationship reported by the preparer. An example would be the parent company of the preparer or the auditor employed by the preparer.

Approaches:

• 1a: Specific concepts in the taxonomy.
• 1b: Specific dimensional structure in the taxonomy.

3.1.1 Approach 1a: Specific concepts in the taxonomy

A specific concept is created that identifies the entity and the nature of the relationship between the preparer and that entity, such as ParentID or AuditorID. Multiple concepts can be created to capture additional information about the entity, e.g. ParentIdentification, ParentAddress, AuditorIdentification and AuditorAddress.

See Appendix A for an implementation of this approach by the Danish Business Administration taxonomy for law firm information.

Characteristics:

• Needs additional concepts, as many as there are different facts to report
• Nature of the relationship is clear as is it part of the concept name or concept description
• Concepts of a generic nature cannot be reused for different entities. For example, in the case of postal address it is usually desirable that the structure of an address is defined once and then reused where required. This reuse is not possible using this scheme.

3.1.2 Approach 1b: Specific dimensional structure in the taxonomy

This approach creates generic concepts to capture the facts to be reported (e.g. identification, name and postal address) and uses a domain member to identify the nature of the relationship (e.g. Tax advisor or Auditor).

For the example used in approach 1a the taxonomy would define:

• An explicit dimension 'RelationshipTypes' with domain members Parent and Auditor
• A reportable concept for the id of the external entity: ExternalEntityIdentification
• A reportable concept for the address of the company: ExternalEntityAddress
• A dimensional structure linking the reportable concepts with the RelationshipTypes dimension and its two domain members.

See Appendix B for the graphical representation of this dimensional structure.

Characteristics:

• Needs additional concepts. This approach requires as many reportable concepts as there generic facts to report and as many domain members as there are types of relationships.
• Needs a dimensional structure to link the generic reportable concepts to the structural elements.

3.2 Use case 2: An unknown number of entities are being reported

In this case, the preparer has to report all related parties. So it is not known in at the time of creation of the taxonomy how many occurrences will appear in the XBRL report (as it was in case 3). Therefore, an approach must be chosen that allows that.

Approaches:

• 2a. Typed dimensional structure

• 2b. Explicit dimensional structure (extension taxonomy)

3.2.1 Approach 2a: Typed dimensional structure

In a typed dimensional structure, the taxonomy defines the concepts that need to be reported (e.g. identification, name and address), but it does not enumerate the members for which this information can be provided in the XBRL report. Instead, it defines the type of member (e.g. integer or string) in the taxonomy and leaves it to the preparer to provide the actual member values (e.g. "01" or "LEI00012345678901274") in the XBRL report.

The typed dimension may be a meaningful identifier for the entity, such as the LEI or company number, a string, such as the company name, or an arbitrary "sequence number" that simply provides a grouping of facts with the same dimension value.

See Appendix C for the implementation of this approach in the ACRA taxonomy for investments in securities.

Characteristics:

• Datatypes can constrain the format of the typed member (value), ensuring consistency.
• Where the typed member (value) is a sequence number, it is difficult to connect facts relating to the same entity in different dimensional structures, or across different reports.

3.2.2 Approach 2b: Explicit dimensional structure (extension taxonomy)

In this approach, the taxonomy author does not define the domain members required to identify other entities. Instead, the domain members are defined by the preparer in an extension taxonomy. The preparer defines the exact members requried for their reporting requirements, can also give those domain members names that identify the entities.

See Appendix D for an example of this approach taken from Google's annual report, prepared against the US GAAP taxonomy.

Characteristics:

• Requires the preparer to create an extension taxonomy and thereby requires the preparer to have the skills and tools to do that.
• The specific domain members that identify an entity can be reused in other reporting structures making it very easy to connect the information.

3.3 Use case 3: A fixed number of entities being reported

Instead of single related entity to report information about, a known number of entities need to be described. An example is a requirement to list the ten top companies the preparer sells products to.

Approaches:

• 3a: Typed dimension
• 3b: Explicit dimensional structure (extension taxonomy)
• 3c: Explicit dimensional structure (generic members)

3.3.1 Approach 3a: Typed dimension

This approach is similar to the one described in 2a. The difference is that a validation rule is added that limits the number of items reported.

Additional characteristics::

• Easy to change the number of items reported: only the validation rule needs to be changed.
• A validation rule is needed to make sure that there are no more entities are reported than allowed.

3.3.2 Approach 3b: Explicit dimensional structure (extension taxonomy)

See approach 2b.

3.3.3 Approach 3c: Explicit dimensional structure (generic members)

In this approach, the taxonomy author defines the reportable concepts for the facts that need to be reported (e.g. identification, name and address) and a set of generic domain members (e.g. company01 to company10) that allows the concepts to be repeated for each entity.

Unlike the extension taxonomy approach (3b) the domain members are generic, so the taxonomy should provide a concept that can be used to report the name of the entity, if required.

See Appendix E for the implementation of this approach in the Indian MCA taxonomy of Malaysia for primary segments.

Characteristics:

• It is clear to the preparer how many entities need to be reported about.
• It is not possible to report more entities.
• The domain members are generic, so a reportable concept is needed to identify the entity.
• New items can be easily added to the initial structure to change the reporting requirements.

Appendix A Example of specific concepts

From the Danish GAAP taxonomy (Official URI)

Figure 1: Danish GAAP taxonomy example

Appendix B Graphical representation of a dimensional structure

Figure 2: External entity dimensional structure example

Appendix C Example of a typed dimensional structure

From the ACRA Taxonomy (Official URI)

Figure 3: ACRA taxonomy example

Appendix D Example of an extension approach in an explicit dimensional structure

Extract from the base taxonomy - US GAAP

Figure 4: US GAAP base taxonomy example

Extract from company extended taxonomy (Google 10-K filing)

Figure 5: Company extension taxonomy example

Appendix E Example of an explicit dimensional structure with fixed number of domain members

From the Indian MCA Taxonomy (Official URI) comes this example where up to twenty segments may be reported.

Figure 6: MCA India CI taxonomy