Ensuring that numeric figures are tagged with the correct sign is a critical part of creating an XBRL report. In many cases, it may be necessary to tag a figure with the opposite sign to that with which it would be presented in a financial report. This document explains why this is necessary, and provides guidance on how to ensure that figures are tagged with the correct sign.
Target audience
This document is primarily aimed at preparers creating XBRL or iXBRL reports looking ensure that numbers are tagged correctly. It may also be of use to collectors who are looking to issues their own guidance to preparers, and to taxonomy architects looking to minimise sign issues in reports that use their taxonomy.
Contents
Introduction
A sign error is where a numeric value is tagged in an XBRL report with an incorrect sign; for example, a reported value is tagged as negative, when in fact it should be tagged as positive, or vice versa.
In XBRL, the sign with which a figure is tagged is critical to understanding its meaning. For example, figures representing both profit and loss are tagged using the same concept: Net profit (loss), with a positive value representing a profit, and a negative value representing a loss. Clearly, for anyone relying on XBRL data, using the wrong sign here would lead to a fundamental misunderstanding of a company’s performance.
Terminology
Sign errors typically arise from differences between the sign conventions used to display values in traditional paper-based financial reports, and the approach required in XBRL reports. In this document, we use the following terms to refer to the different types of reports that users may encounter:
|
Human-readable |
Paper-based report |
The traditional presentation of a report, as viewed on paper, or electronic paper-equivalents such as PDF. |
|
Rendered XBRL report |
The presentation of an XBRL report as viewed in a rendering tool. |
|
|
Structured Data |
The file that contains the data that is to be reported in an XBRL filing program |
|
|
Both human readable and structured data |
iXBRL (Inline XBRL) report |
An iXBRL report combines the structured data from an XBRL report and a human-readable report into a single document. |
Why Sign Errors Occur
The following sections discuss why sign errors occur, and explain how to determine the correct sign for a given value.
Representation vs. Presentation
In an XBRL report, the sign for an XBRL fact is represented in accordance with the definition of the concept and is independent of its presentation. In a human-readable report , a value is presented according to its impact on the total that it is contributing to. It is this difference that can lead to sign errors in XBRL reports. This difference is most easily understood by looking at an example. In the paper-based report, Figure 1 below, the value of “Interest Expense” is shown in brackets because interest expense reduces the “Other income” total that it is contributing to. In the XBRL report, Figure 2, the correct concept to be used to tag this line is “Interest Expense” and the value should be positive to reflect this meaning; it makes sense to say “there was an Interest Expense of $437 million”, it does not make sense to say “there was an Interest Expense of minus $437 million ”. As this example shows, sign issues in XBRL often arise because, in order to correctly tag a given figure, it may need to be given the opposite sign from what is presented in a paper-based report.
Figure 1: Presentation of Interest Expense (HTML)
Figure 2: XBRL data for Interest ExpenseConcept meaning and labels
The correct sign for a fact is determined by the concept meaning. The concept meaning does not change and this is true whether the value is presented as 437 or (437) in a human-readable report. Concept labels are an important factor in understanding an XBRL concept. In a well-designed taxonomy concept labels will describe the meaning of a positive value, as we have seen in our example “Interest Expense”. For concepts that can take both positive and negative values, known as ‘two-way’ concepts, the concept labels may describe the meaning of a negative number in parentheses. In Figure 1 we have the following ‘two-way’ concepts:
- Other Income (expense)
- Net gains (losses) on foreign currency remeasurements
Changing the sign for presentation
Some preparers will want to render an XBRL report so it matches the ‘paper-based’ report. For example, Figure 1 the preparer presented “Interest Expense” as “(437)”. As discussed, the figure is represented in XBRL by a positive value, so a separate mechanism is required to change the sign when creating a Rendered XBRL report. This is shown in Figure 3 below.
Figure 3: XBRL viewer for Interest ExpenseThe need to create Rendered XBRL reports that accurately follow an original paper-based report is significantly reduced by the use of iXBRL (see next section), but it remains relatively common to produce rendered XBRL reports based on information contained in the presentation tree in a taxonomy. The presentation tree provides a mechanism to select a specific label for use at particular points in the tree. It is common practice to use the selection of preferred label of a particular type, known as a negated label, as a hint to processors that the value of the fact should be inverted for presentation purposes. In the example above, selecting a negated label as the preferred label for the “Interest expense” line will typically lead a processor to present the reported value of “437” as “(437)”.
iXBRL (or Inline XBRL)
An iXBRL report combines a human-readable HTML report with the structured data from an XBRL report. The considerations for the use of signs are the same: numbers in the human-readable report are shown as they would be in a paper-based report, and iXBRL provides a mechanism for specifying if the number should be negated in order to have the correct sign for the concept against which it is reported.
Figure 4: XBRL viewer for Interest ExpenseThe example in Figure 4 shows an iXBRL document, with the figure for “Cost of sales” shown in brackets, as it reduces the figure for “Operating margin” to which it contributes. The sidebar on the right shows the tagged XBRL data, with the value shown as a positive value, as the meaning of the concept is “Cost of sales”. iXBRL also allows scaling to be applied, as the figure of 10,522 shown on the page, actually represents a value of 10.522 billion.
Balance attributes
XBRL concepts can have an optional “balance attribute” associated with them, which indicates whether the concept is a “debit” or a “credit”. In practice, balance attributes often add unnecessary complexity and confusion to the task of determining the correct sign, and whilst they can provide a useful cross-check, it is not recommended that they are used as the primary method for determining the correct sign.
Balance attributes indicate the nature of the underlying accounting concept. For example, in an Income Statement, Revenue are credits and Expenses are debits. The Net Income from the calculation “Revenue - Expenses”, is a credit value and forms part of Shareholders' equity on the Balance Sheet. The balance attribute can help with understanding the fundamental relationships between accounting concepts, but it is important to remember that the balance attribute describes the nature of the concept, but not an individual fact. For example, if Expenses exceed Revenue, in the above example, then a negative value is reported against the concept “Net Income (Loss)”, which is a credit concept.
Catching Sign Errors
The previous sections have described mitigating sign errors by ensuring the sign is consistent with the concept meaning. This activity should be accompanied by validation checks, and many taxonomies have rules that can flag potential sign errors. This section considers how sign errors can be caught by validation.
Validation using the calculation tree and xg:XBRL formula rules
XBRL provides two mechanisms that allow taxonomies to define expected calculation relationships between concepts: the calculation tree, and XBRL formula rules. Both of these mechanisms can be validated using an XBRL processor, and reports will generally fail validation if facts covered by these checks are tagged with the wrong sign.
In the example, Figure 4 , above, the table represents the following calculation:
Gross Margin = Sales - Cost of Sales
Which in this example is:
2,203 = 12,725 - 10,522
If “Cost of Sales” were incorrectly tagged with a negative value, the calculation for Gross Margin would become:
12,725 - (-10,522)
This gives 23,247 which is different from the reported figure of 2,203, and causes a validation failure if this calculation relationship is checked using either the calculation tree or an XBRL formula rule.
Where the concepts involved cannot reasonably take a negative value, for example, “Cost of Sales”, this can be enforced by the taxonomy in order to avoid sign errors. This can be done either by using a “non-negative” datatype for the concept, or by using an XBRL formula rule. XBRL formula rules are often preferred for this purpose, as they offer more flexibility. For example, some concepts may take a negative value only under exceptional circumstances, or when used in combination with a particular dimension member. XBRL Formula rules allow different severities to be attached to individual rules, so that a rule may be treated as a warning rather than an error. Rules can also be made conditional, based on the dimensional qualification of the fact.
Limitations of automated validation checks
These mechanisms are not a complete solution to sign tagging issues, as it is common that not all figures in a report are, or can be, covered by such validation checks.
Two-way concepts such as “Interest (expense), net” that may legitimately take either a positive or negative value, cannot be covered by rules that require a positive value.
As another example, where a calculation tree is provided by a preparer as part of an extension taxonomy it is possible that the preparer may make corresponding errors in the calculation tree which cancel out sign errors in the report. For example, a preparer may erroneously define the calculation as:
Gross Margin = Sales + Cost of Sales
In which case, incorrectly tagging “cost of sales” as “-10,522” would cause the validation to pass.
Reviewing XBRL reports
As described above, automated validation checks cannot detect all possible sign errors. Preparers should review their XBRL reports, in particular negative values, to ensure that the reported value matches the intended meaning.
Further Reading
Staff Observations from the Review of Interactive Data Financial Statements, SEC
The XBRL US Center For Data Quality: How It Will Help Filers Produce Accurate XBRL Disclosures
Blogs
This document was produced by the Implementation Guidance Task Force.
Published on: 2017-11-22.
