1 Introduction

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.

2 Issues with XBRL v2.1 summation-item

2.1 Rounding

Consider a report which summarises the following actual values on a balance sheet:

The report may present these values in millions of Euros, rounded to the nearest €0.1m:

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.

2.2 Duplicates

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.

2.3 Syntactic dependencies

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.

3 In scope requirements

3.1 Interval-based arithmetic

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).

Calculations should be considered consistent if there is overlap between the interval of the reported total, and the calculated interval.

3.2 Support for different rounding methods

There are a number of different approaches used to round "half" values. For example 10.5 may be rounded to 11 ("half away from zero") or to 10 ("half to even"/"bankers rounding"). The solution should not require the report to state the rounding method that has been used, and where the consistency of an calculation cannot be established without knowing the rounding method, it should be treated as consistent.

3.3 Support for duplicate facts

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.

3.4 Syntax independence

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

4 Out of scope requirements

4.1 Additional functionality

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.

Appendix A Intellectual property status (non-normative)

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).

Appendix B Document history