6.6.5 Add Dimensional Relationships into Notes

After the presentation relationships have been added to the extension taxonomy for notes and disclosures of the financial statements, the preparer will continue with dimensional relationships. The rules applying to dimensional relationships in the statements also apply in the disclosure:

An effective method of adding the presentation relationships is for preparers to work separately on each text block representing a table, adding dimensional relationships in the following order:

When a table has more than one axis element as a child of the table element, some software programs use this order to determine a default layout in the horizontal direction of the table. Preparers are free to order the axis elements to achieve a desired effect in their own software, but they should remember that other users will be able to rearrange the display as they see fit.

When a restatement appears in a disclosure, the "Scenario [Axis]" is used (as shown in Figure 65, "Fragment Containing Previously Reported, Adjusting, and Restated Data"). Figure 90 shows an example in which the restatement involves a reclassification of "Proceeds from Issuance of Perpetual Trust Securities" from Operating to Financing; no amounts are shown as adjustments, but there are distinct values for four items. The text of the disclosure is shown as a value of the element "Error Corrections and Prior Period Adjustments, Description".

Figure 90 Example of a Restatement in a Disclosure

A number of disclosures have axis elements that are meant to have hierarchical domains (that is, member elements having other member elements as children). Figure 73, "Components of Equity [Domain]", offers an example of a hierarchical domain.

Figure 74 Validation Messages about Dimensional Relationships sh Figure 74 shows validation messages that may appear while adding dimensional relationships.

The technical rules used in the XBRL US GAAP Taxonomy prohibit preparers from creating an overall table for all of the elements in a relationship group and including separate, individual tables within the relationship group. In other words, preparers cannot create a table within (as a descendant of) another table.

6.6.6 Add Calculation Relationships into Notes

The relationship groups for disclosures in the XBRL US GAAP Taxonomy contain calculation relationships similar to those in the relationship groups for statements. Therefore, in the relationship group in the extension that represents the notes, preparers will copy and add relationships between elements to reflect the reporting structure in much the same way as described for statements. There are three aspects that are different.

First, preparers should not add calculation relationships to the disclosures that are already in a statement. For example, Figure 87 showed a disclosure in which the "Accounts Receivable, Net, Current" element, the gross, and the allowance for doubtful accounts all appear. If the preparer had already copied a calculation relationship between these three elements into the Statement of Financial position, then copying the calculation relationship again into the notes would be redundant, and worse, could introduce calculation inconsistencies that did not appear before.

Second, most calculation relationships that appear in disclosures appear inside tables, between the elements that are presentation children of the "[Line Items]" abstract element. Preparers should focus calculations only on the line items and not attempt to add calculation relationships across any other axes of a table. For example, in Figure 40 (which showed how line items such as cost, gross, and net values related to an axis such as the type of security), calculations in that table are effective with respect to the line items laid out vertically, and have no effect for the securities type axis.

Third, a disclosure may show multiple breakdowns of the same figure. In Figure 30 and Figure 31, for example, deposits were broken down two different ways: by type and by source. Often a table is used to report such data, but not always. Figure 91 shows that the "main" presentation group in this example will contain different abstract elements to group each of the alternatives, while the calculations must be in separate relationship groups.

Figure 91 Deposits Example, Repeated

Two rules apply to this situation. One applies to the total element (in this example, "Customer Deposits") and its children in calculation relationships; the other applies to that same element as it will appear with siblings in presentation relationships:

Figure 62 shows validation errors and warnings that might occur while adding calculation relationships.

6.7    Method 7: Suppress or Change a Parent-Child Relationship in the XBRL US GAAP Taxonomy

In general, no relationship in one group interacts with relationships of the same kind in any other group. Therefore, the only reason that a preparer would need to modify an existing relationship in the XBRL US GAAP Taxonomy would be to resolve a validation error or calculation inconsistency resulting from one of the few situations where different relationship groups do interact:

1. An axis element must have only one default domain member anywhere in the taxonomy; this would lead to a validation error.
2. Facts in an instance document are checked for consistency using all the calculation relationships in the statement, disclosure, and schedule relationship groups used by the instance document.

To solve these problems the preparer must make sure that the extension taxonomy does not have any offending relationships in it. Depending on the software used, this may appear to the user as "detaching" a child from its parent, "prohibiting" the parent‑child relationship, or some other terminology such as "deleting". This guide's term for all such approaches is: to suppress the relationship. The preparer finds the parent element in the relationship, verifies that the relationship in question is specifically in the relationship group where the error occurred, and suppresses the relationship with the specific child of that relationship.

To resolve case 1, preparers must find every dimensional relationship group in the XBRL US GAAP Taxonomy where the axis element occurs, then suppress all child relationships in that dimensional relationship group.

To resolve case 2, preparers must first verify that there is no substantive cause for the inconsistency that should be corrected in the extension taxonomy or in the values reported in the instance document. Further action should be taken only when the element's sum is clearly a discrepancy between the desired calculation in the company's own statement or disclosure relationship groups. Then the preparer should find the element whose sum is inconsistent with the reported value, and in every calculation relationship group of the XBRL US GAAP Taxonomy for which that element is the parent, suppress all relationships with children whose values are reported in the instance.

Appendix C, Extension Naming and Files, offers advanced techniques for achieving the same effect without suppressing any relationships, as well as producing a more compact set of files.

Figure 45, "Methods of Extending a Taxonomy", arranged the methods in order of increasing impact on the reusability of the taxonomy and hence the instance documents. Preparers can use methods 1 through 7 to create an extension taxonomy with little negative impact on reusability, because none of them create elements that appear in an instance document. Methods 8 through 12, however, add new elements that will appear in instances. Preparers must take care to create only necessary elements, and to provide accurate definitions and relationships. Methods 8 through 12 explain how to do this for different kinds of elements that have increasing impact on reusability.

6.8 Method 8: Add a New Domain Member Element to an Existing Table Domain

A preparer must add a domain member to an extension when an axis element in the XBRL US GAAP Taxonomy is specifically intended for company-specific information (for example, the Major Customers axis in Figure 43). Figure 92 shows the attributes for a domain member, using the example "US Federal Government" major customer as an example.

Figure 92 Attributes of a Domain Member Element

Once the domain member has been created, it may be copied into any dimensional parent-child relationship where it would be the child of a domain. Validation errors that may occur as a result of adding domain members are shown in Figure 74.

When an axis of the XBRL US GAAP Taxonomy already has several domain members, the preparer should strive to find an appropriate domain member from those that exist.

Some tables have company-specific domains in which the members have no meaning other than to form a list. For example, in the XBRL US GAAP Taxonomy's relationship group "710000 – Disclosure – Compensation Related Costs", there are tables representing schedules of shares grouped by exercise price range. The element "Share-based Compensation, Shares Authorized under Stock Option Plans, Exercise Price Range, Lower Range [Domain]" is an example of such a domain. Each member of this domain represents a distinct, non-overlapping price range. The upper and lower values of each range are likely to change each period. Therefore, elements such as "Range01", "Range02", and so forth are better to use because each range can have a different upper range and lower range value in each period and each is a per-share line item. The name of the domain, in this case, is of no interest.

Each extension must create member elements wherever the domain is "Segment, Business [Domain]" (see Figure 63), because business segments are specific to the reporting company. New domain members representing each segment must be added as siblings of "Business Intersegment, Eliminations [member]". Furthermore, a number of disclosures have axis elements that are meant to have hierarchical domains (that is, member elements having other member elements as children). The "Entity [Domain]" in Figure 63 is an example of a hierarchical domain. Focusing on "Entity [Domain]" as an example, each affiliated entity, subsidiary (guarantor or non-guarantor)or joint venture that is separately reported in an instance document must be represented with a distinct domain member element. Domain members representing unconsolidated majority‑owned entities would have "Majority-Owned Entity, Unconsolidated [Member]" as their parent, partnerships would have "Partnership Interest[Member]" as their parent, and so on.

6.9    Method 9: Add a New Axis to an Existing Table

If the axes of an existing XBRL US GAAP Taxonomy table are insufficient to capture a complex disclosure, a preparer may need to add an axis element. For example, in the XBRL US GAAP Taxonomy relationship group "360000 – Disclosure – Property, Plant and Equipment", there is a table for "Long-lived Assets Held-for-sale by Asset Type" that has an axis for the asset type. If the preparer needs to disaggregate an asset type (property, for example) according to geographic region, then a new axis element will be needed for region. Figure 93 shows how the new axis element, "Long-lived Assets Held-for-sale by Location [Axis]" appears in dimensional relationships.

Figure 93 Long-lived Assets Held-for-sale, with New "Location" Axis (Dimensional Relationships)

As noted in an earlier rule of thumb, axes cannot usually be shared between tables, so adding an axis almost always means creating an axis element. Domain elements, however, can be shared, and this example uses the existing domain element "Segment, Geographical [Domain]". Figure 94 shows the required attributes of an axis element. The XBRL US GAAP Taxonomy naming convention for an axis has the base name of the table, followed by a comma and the name of the domain, ending with "[Axis]".

Figure 94 Attributes of an Axis Element

If an axis must be created, a domain element may or may not need to be created. In this example, the domain does not need to be created. Figure 95 shows the required attributes of the domain element as if it had been created in an extension. The domain element name should be chosen to indicate what the members of the domain will be. For most purposes, different domains may share the same members, but the domain element itself can only be shared by different axes if it always has exactly the same members.

Figure 95 Attributes of a Domain Element

The preparer may copy the new axis element and domain element into dimensional relationships just as any other axis and domain element, as in Figure 72, "Multiple Stock Classes (Dimensional Relationships)". If the software in use has a feature that previews table layouts from dimensional relationships, the preparer should use it to verify that the dimensional relationships can recreate the desired layout.

The table below interprets error or warning messages about new axis or domain elements that preparers may encounter while editing an extension taxonomy.

Figure 96 Extension Taxonomy Validation Messages about New Axis and Domain Elements

Figure 74 shows validation errors that may occur as a result of creating relationships involving the new axis and domain elements.

6.10Method 10: Add a New Table

The XBRL US GAAP Taxonomy includes required disclosures and common reporting practices in five industries (CI, BASI, BD, INS, and RE) and contains over two hundred tables. Preparers must perform a top- down analysis of available tables and decide whether an existing table is close enough to simply modify the table in an extension, rather than creating a whole new table. Modifying an existing table, as described in previous sections, is easier and more desirable than creating a new table and its supporting elements. One reason that a preparer might need to create a new table is to meet a reporting goal, such as reporting key performance indicators by business segment, that is not included in the XBRL US GAAP Taxonomy.

In the following example, a company has a financial statement note that discloses its deferred revenue by business segment, which is not included in the XBRL US GAAP Taxonomy. Figure 97 illustrates the attributes of an added table, and Figure 98 the attributes of the line items.

Figure 97 Attributes of a Table Element

Figure 98 Attributes of a Line Items Element

Finally, for reusability and the other reasons discussed above, a newly created table should be accompanied by a text block, as shown in Figure 99.

Figure 99 Attributes of a Table Text Block Element

The preparer may copy the new table element and other elements into dimensional relationships just as any other table element. If the software used has a feature that previews table layouts from dimensional relationships, the preparer should use it to verify that the dimensional relationships can recreate the desired layout.

The table below interprets error or warning messages about new axis table elements that preparers may encounter while editing an extension taxonomy.

Figure 100 Extension Taxonomy Validation Messages about New Tables

Figure 74 shows validation errors that may occur as a result of creating relationships involving the new table and its descendants.

6.11Method 11: Add a New Numeric Element Such as a Monetary, Per-share, or Other Amount

Preparers should create a new element only if they have thoroughly examined the taxonomy and confirmed that a financial concept reported in their financial statements is not in the taxonomy, and all other alternatives, such as creating new calculation relationships, new domain members, axes or tables, have been exhausted. A new numeric element will have a more significant impact on reusability than any of the methods described so far, because any user of the resulting taxonomy and instance documents will need to review the definition of the new element to determine its meaning and how it should be analyzed.

By following naming conventions, assigning balance attributes from the perspective of overall consistency with other elements, and properly constructing calculation and other relationships using the new element, the preparer can maximize the reusability and usefulness of the new element in the company's extension.

There are two situations that motivate creation of a new numeric element:

1. To combine two or more line items (with distinct definitions) into one element.
2. To add additional elements for financial reporting concepts that are not included in the XBRL US GAAP Taxonomy.

Combining two or more line items into one

In Figure 101, the subtotal of Liabilities and Minority Interest does not exist as a separate element in the XBRL US GAAP Taxonomy, although the separate elements "Liabilities" and "Minority Interest" do. Since the entity reports a combined total for these amounts, a new element should be created, as illustrated in Figure 102.

Figure 101 Liabilities and Minority Interest, a Subtotal Element

Figure 102 Attributes of Liabilities and Minority Interest, a Monetary Element

To complete the example, Figure 103 shows the presentation and calculation relationships where the new element is a parent or child.

Figure 103 Presentation and Calculation Relationships, Liabilities and Minority Interest

Adding elements for financial reporting detailed line items not included in the XBRL US GAAP Taxonomy

All line items in a statement relationship group, and most of those in disclosure and schedule relationship groups, are already line items within a table. Therefore, if a line item has a number of disaggregated values that are not different in kind, preparers should consider adding an axis to the table with appropriate domain members rather than creating new numeric elements. For example, if revenue, costs, and income on an income statement are disclosed separately as line items for "franchise operations", "mail order operations", and "owned stores", this is better handled as an axis added to the table "Statement [Table]" in the income statement.

The distinguishing feature that motivates addition of numeric elements to add detail line items is that the new elements would be siblings of other line items already mapped to existing XBRL US GAAP Taxonomy elements. An example is found in the cash flows statement (Figure 104) of the financial statement used in the previous example (Figure 102). All of the line items in the figure could be mapped to existing XBRL US GAAP Taxonomy elements other than the two highlighted. This is what suggests that they are new line items, rather than some other type of element such as a domain member.

Figure 104 Cash Flows from Financing Activities with Detail Line Items

Like any element that represents payments, the element "Principal payments on debt, excluding normal amortization" will have a period type of "duration" and a balance type of "credit". The amount of the payments is a positive value, but it is being subtracted from the net cash from financing activities and so it is presented as a negative amount on the cash flow. Therefore, it needs a negated label. The attributes of the new element are shown in Figure 105, and the calculation and presentation relationships are shown in Figure 106. The new element must be added to the dimensional relationships as well (as shown in Figure 83).

Figure 105 Attributes of Principal Payments on Debt Excluding Amortization Element

Figure 106 Presentation and Calculation Relationships, Repayments of Secured Debt, Excluding Amortization

The table below interprets error or warning messages about new numeric elements that preparers may encounter while editing an extension taxonomy.

Figure 107 Extension Taxonomy Validation Messages about New Numeric Elements

6.12Method 12: Add a New String, Text Block, Date, or Other
Non-numeric Element

Creating a new non-numeric, non-abstract element should always be a last resort. A non-numeric element in an extension has the same reusability drawbacks of a numeric element, without the benefit of calculation relationships to indicate how it relates to other existing elements.

Preparers are sometimes tempted to create a separate non-numeric, string element that contains every distinct paragraph or heading in a financial statement. At a minimum, these elements violate the rule of thumb that an extension taxonomy should include elements that are not likely to change each period. As discussed earlier, the purpose of an instance document is to convey reliable, unambiguous data, so the effort to duplicate original phrasing, layout, and formatting has rapidly diminishing returns.

The creation of a new text block element is appropriate when a new table is created (Figure 99). A text block could also be created to tag text that covers the subject matter of two distinct, existing text blocks. For example, if a company discusses the sale of shares in consolidated subsidiaries and the sale of shares in equity method investees in the same note to the financial statements, neither the "Equity Method Investments [Text Block]" nor "Stockholders' Equity Note Disclosure [Text Block]" would be appropriate to cover all of the disclosures in that note. Accordingly, a preparer should create a new text block for this disclosure. Figure 108 shows the resulting element.

Figure 108 Issuance of Stock by Equity Method Investees, Element

Because the user of the extension taxonomy is entirely dependent on the element definition to understand the purpose of the element and how it is distinct from other elements, non-numeric elements defined in an extension, in addition to being in a presentation relationship, must also have a definition.

<< PREVIOUS | NEXT >>