The XBRL 2.1 Specification defines a standard XML-based syntax for XBRL business reports. It provides a syntax for defining calculation relationships (hereafter XBRL 2.1 summation-item) between numeric items in an XBRL report.
XBRL 2.1 summation-item relationships have defined validation behaviour, with conformant processors being required to signal an "inconsistency" if the facts in an XBRL report do not conform to the prescribed relationships.
Figures in financial reports are often presented after rounding and scaling in order to improve readability of the report. XBRL 2.1 allows facts to declare the precision to which they are reported. XBRL 2.1 summation-item prescribes how processors must treat this precision information, but unfortunately, the approach fails to handle common reporting scenarios correctly, leading to calculation inconsistencies being signalled for values which are in fact consistent.
This document describes the requirements for a minimal new specification that addresses this problem.
XBRL 2.1 summation-item relationships have a number of other limitations. For example, they are restricted to describing summation relationships between numeric facts which are c-equal, that is, which share the same period, dimensions and other contextual information.
Addressing these limitations is the subject of a separate Calculations 2.0 requirements document, and is considered out of scope for the Calculations 1.1 solution defined by this document.
Consider a report based on the following actual values on a balance sheet:
| Actual Value | |
|---|---|
| Debtors | €12,141,123 |
| Cash at bank and in hand | €45,441,321 |
| Current Assets | €57,582,444 |
These figures conform to the calculation "Current Assets = Debtors + Cash at bank and in hand".
A report may present these values in millions of Euros, rounded to the nearest €0.1m:
| Rounded Value | |
|---|---|
| Debtors | €12.1m |
| Cash at bank and in hand | €45.4m |
| Current Assets | €57.6m |
Note that the presented figures do not add up exactly, despite all having been correctly rounded from actual values which do. This is a common and normal result of rounding.
The XBRL v2.1 specification states that "A binding calculation is defined to be consistent if the rounded value of the summation item is equal to the total rounded to the decimals or inferred decimals of the summation item."
The specification describes how rounding is to be done, but in all common
scenarios, the output of the rounding process is the same as the input. For
example, the "Debtors" figure would be correctly tagged as 12100000 (decimals
= -5). The rounding process prescribes that we should round it to the nearest
100,000 — but this has already been done prior to including the value in the
report. Thus, the specification effectively requires that the reported (post
rounding) figures add up exactly, leading to common inconsistencies.
The XBRL v2.1 specification prescribes the situations in which a calculation is checked ("binds"). A calculation will only bind if there are no duplicate facts present for either the summation item (total) or any of the contributing items.
Financial reports often include the same value more than once, and in some cases reported to different levels of precision. For example, a figure may be presented to the nearest thousand in a table, but summarised to the nearest million in a textual statement.
The increasing use of Inline XBRL, and the associated best practice of tagging all occurrences of a fact, means that duplicates in XBRL are common, and provided that all values are consistent to their stated precision, do not represent an issue with the report.
The current XBRL v2.1 behaviour has the side effect of disabling some calculation checks which should be performed. This issue is made worse by the fact that the Inline XBRL specification permits, but does not require, de-duplication, leading to ambiguity in the required behaviour for calculation checks.
The XBRL v2.1 prescribes that calculations are checked amongst facts that are "C-Equal" and "U-Equal". This effectively requires that all facts have the same dimensions, including both built-in and taxonomy-defined dimensions, and the same units.
The definitions of "C-Equal" and "U-Equal" are in terms of the XML structure of
the <context> and <unit> elements, respectively. This is problematic for
"C-Equal" as the prescribed comparison is not type-aware, meaning that
equivalent, but syntactically different, context elements will not be
considered equal. The later XBRL Dimensions specification makes use of
QNames to identify dimension names. QNames that make use of different
prefixes bound to the same namespace URI should be considered equivalent, but
will not be unless the comparison is type-aware.
Similarly, dimension values can also be QNames (for explicit dimensions) or any XML Schema type for typed dimensions, and should be compared as typed values.
More broadly, the recent Open Information Model initiative defines a syntax-independent model, and it is desirable that the dimensional equivalence of facts should be determined under that model, rather than by comparing XML syntactic details.
The values in a report should be checked for consistency with a set of stated calculation relationships. Reported values should be deemed to be consistent with a calculation if there is a set of actual values from which the reported values could have been rounded which conform to the specified calculation.
Calculation consistency checking should be determined using interval arithmetic. Each fact reported with finite precision represents an interval of possible underlying values. For example, a value of 12 (decimals = 0) could have been rounded from any value between 11.5 and 12.5 (inclusivity of the bounds is discussed in the next section).
The requirement for consistency defined in Section 3.1 is met if there is overlap between the interval of the reported total, and the calculated interval.
There are a number of different approaches used to round values for presentation in a report.
Common methods include "round to nearest" and truncation ("round towards zero"). There are a number of variations of "round to nearest", with differing treatment of values that are exactly half way between two nearest values ("ties"). Common variations include "ties to even" and "ties away from zero".
The solution should support both "round to nearest" and truncation methods.
The solution should allow a processor to be configured to check calculations assuming that either "round to nearest" or trnucation methods.
When checking according to "round to nearest", the solution should not distinguish between the different treatment of ties. Where the consistency of a calculation cannot be established without knowing which variation has been used, it should be treated as consistent.
The rationale behind this approach is that the choice between "round to nearest" and truncate is typically established by jurisdictional conventions, and the difference leads to a subtantive difference between values that are considered consistent for a given calculation. On the other hand, the choice between different variations of "round to nearest" may vary between reports within a jurisdiction, but the difference makes a minimal difference to the values that would be considered consistent.
The presence of duplicate facts should not result in calculation checking being disabled. Where multiple consistent facts are present, the calculation should be checked using the most precise fact available. If there are multiple inconsistent facts present then an error should be signalled.
The solution should be defined in terms of the report model defined in the Open Information Model and should not depend on the XML syntax defined in XBRL v2.1
In order to keep the development process as short as possible, the solution should seek only to address deficiencies in the functionality intended to be provided by XBRL v2.1 summation-item. It should not attempt to introduce any new functionality, such as the ability to check cross-period or other cross-dimensional calculations. Any such requirements should instead be considered for inclusion in Calculations 2.0.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (https://www.xbrl.org/legal).
This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (https://www.xbrl.org/legal).
| Date | Author | Details |
|---|---|---|
| 9 November 2021 | Paul Warren | Initial draft |