ESEF Errors and Common Pitfalls: 3 – Calculation Inconsistency
This is part of a series on common errors and pitfalls in ESEF filings, observed in our analysis of hundreds of reports collected in our repository, at filings.xbrl.org. For the series introduction, start here.
An XBRL taxonomy can define a calculation tree for describing and validating simple totals and subtotals in an XBRL Report. For example, let us consider a simple calculation relationship defined as Assets = Current Assets + Non-Current Assets. The facts reported for these three concepts should typically satisfy the arithmetic equation. A calculation inconsistency error occurs when the reported fact values do not conform to the calculation relationship defined in the taxonomy.
Many ESEF reports that have been filed so far have calculation inconsistencies. Calculation inconsistencies are not considered to be errors that would render the report invalid, but they do frequently indicate errors in the reported data, or in the construction of the calculation tree. There are rare cases where inconsistencies are reported in a correctly tagged document.
Common causes of calculation inconsistencies are:
- Facts have been reported with the wrong sign. This is a common reason, as the sign conventions used to present numbers on a financial report do not always match the approach required by XBRL. Our guidance on catching sign errors should be of help here.
- A rounding error has occurred, which may be due to the aggregation of rounded values not exactly matching the rounded actual total. These can often be addressed by ensuring that all reported figures are tagged with the correct accuracy.
- The concepts included in the calculation tree do not match the facts included in the report.
To illustrate this last point, let’s take an extract from an ESEF filing. This is the Statement of Changes In Equity:
The calculation tree is defined for this statement as below:
XBRL processors will calculate the figure for ‘Comprehensive income’ as the sum of ‘Profit (Loss)’ and ‘Other comprehensive income’. In this case, ‘Other comprehensive income’ has not been reported directly, so a processor will calculate the total in the Total equity column as €18,400,000, which does not match the reported value of €14,800,000, resulting in calculation inconsistency.
Although the contributing items for “Other comprehensive income” are reported, an XBRL processor will not use these to infer the unreported subtotal. The solution here would be to align the calculation tree by adjusting it via the extension taxonomy to mirror the report (as shown below). Alternatively, a report that includes the missing subtotal would also be considered consistent.
All conformant XBRL processors will identify calculation inconsistencies and preparers should ensure that any reported inconsistencies are addressed.
Note that documenting the arithmetic relationships between the reported concepts using the calculation tree is a requirement of the ESEF reporting manual, so inconsistencies should not be addressed by removing calculation relationships.
The RTS on ESEF states that no anchoring is required for an extension taxonomy concept corresponding to “a subtotal of other disclosures in the same statement.” The rationale for this is that such a roll-up relationship would be captured in the calculation tree. This is another reason to ensure that accurate calculation relationships are provided.