Seeking Opinion: Low Standard Hypercube Usage Due to "Visual Consistency" Policy

[Json, park]

Hello Arelle users,

We are an XBRL solution developer based in South Korea. While our query is not directly related to Arelle, we are hoping to tap into the deep expertise of the XBRL professionals in this community for your valuable insights.

While analyzing Korean XBRL data, we discovered a significant issue: the usage rate of standard hypercubes in Korean XBRL reports is only about 40%. We were surprised by this remarkably low figure and conducted a further investigation.

Background on the Korean XBRL Filing System:
South Korea's XBRL implementation has a unique and strict structural requirement: a hypercube can only be used once under a single, specific linkrole. This means hypercubes cannot be reused across different linkroles.

(In contrast, we understand that in taxonomies like the one used by the SEC, a hypercube can be defined under a specific linkrole but can still be reused by other linkroles.)

For example, in the Korean taxonomy, the hypercube with the standard ID Disclosure of impairment loss and reversal of impairment loss [table] is strictly bound to the Notes - Impairment of assets linkrole and cannot be used anywhere else.

The Problem in Practice: An Example
To illustrate the problem, let's consider the note for "Property, Plant, and Equipment" (PPE) in a typical audited financial report:

• Note 6. Property, Plant, and Equipment
  • Information on the carrying amount of PPE.
  • Information on the impairment loss of PPE.

In Korea, XBRL reports are created to "exactly replicate the visual presentation (table structure, order, etc.) of the notes in the human-readable audit report." This policy of "visual consistency" is strictly enforced.

Because of this policy, the standard hypercube for impairment loss (Disclosure of impairment loss and reversal of impairment loss [table]) cannot be used within the PPE note. This is because the impairment information is presented within the PPE section of the report, not under the separate "Impairment of Assets" note section where the standard hypercube belongs.

This leads to the following structure in the Korean XBRL report:

Current Korean XBRL Practice:

• [Standard Linkrole] Property, Plant, and Equipment
  • (1) Information on carrying amount → [Standard Hypercube ID] Property, Plant, and Equipment [Table]
  • (2) Information on impairment loss → [Extension Hypercube ID] Impairment Loss [Table] (A new, custom hypercube is created)

As you can see, even though a standard hypercube for impairment loss exists, filers are forced to create an extension hypercube to comply with the visual layout of the original report.

Our Analysis: A Taxonomy-Compliant Approach
We believe that to adhere to the principles of the taxonomy's classification system, the report should be structured as follows:

Proposed Taxonomy-Compliant Structure:

• [Standard Linkrole] Property, Plant, and Equipment
  • (1) Information on carrying amount → [Standard Hypercube ID] Property, Plant, and Equipment [Table]
• [Standard Linkrole] Notes - Impairment of assets
  • (2) Information on impairment loss → [Standard Hypercube ID] Disclosure of impairment loss and reversal of impairment loss [table]

However, in Korea, if an XBRL report does not maintain this "visual consistency" with the original document, it is rejected, and the filer is penalized and required to revise the report—even if it is perfectly valid and correctly structured according to the taxonomy's classification.

Consequences of the "Visual Consistency" Policy:
This policy forces filers to create extension hypercubes for disclosures that are already defined in the standard taxonomy. The result is a standard hypercube usage rate hovering around a mere 40%.

In our view, this low figure indicates that the XBRL data has effectively lost its function as a structured, classifiable database. We believe this policy undermines the fundamental purpose of XBRL itself: data standardization, consistency, machine readability, and international comparability.

Our Questions for the Community:
We are preparing to present these concerns to the regulatory authorities in Korea and would be immensely grateful for your expert opinions.

1. From an international XBRL standards perspective, is our analysis of this situation correct?
   
   
2. Do you think it is wrong from an XBRL perspective to have a policy that forces companies to create and disclose extension hypercubes for the purpose of making reports look exactly like audit reports, even when standard hypercubes already exist?
   
   
3. In Korea, extension hypercubes are simply extended without including any additional information (for example, they do not specify that they are semantically identical to standard hypercubes). In this case, I'm curious whether these extended hypercubes have any meaningful value from a data perspective.
   
   
4. Are you aware of similar implementation challenges or policies in other jurisdictions?

Thank you for your time and for sharing your expertise.

Best regards,
Jason Park