Reportwide Calculations: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
Zeile 113: | Zeile 113: | ||
To check other occurences, their calculations are shown in additional tabs: | To check other occurences, their calculations are shown in additional tabs: | ||
[[Datei:Reportwide Calculations3.png|center| | [[Datei:Reportwide Calculations3.png|center|1200px]] | ||
In the example above, you will be able to see which page contains the tag that causes the calculation difference. In the cell tab you will see that "Profit loss" is part of a calculation and an additional tab with the page number shows a calculation in a different page which contains the same tag with a different value. | In the example above, you will be able to see which page contains the tag that causes the calculation difference. In the cell tab you will see that "Profit loss" is part of a calculation and an additional tab with the page number shows a calculation in a different page which contains the same tag with a different value. |
Aktuelle Version vom 27. Oktober 2023, 07:41 Uhr
Basics of Calculation
Calculations in XBRL reports can give rise to many questions, especially when SignLogic and balance types are involved. We have already published some entries about the basics of calculation, which you can find at the links below:
Another topic that has raised a lot of questions with calculations relates to the following question:
For which part of the report is a calculation valid?
The short answer is: Everywhere!
The XBRL specification defines the validity of a calculation as following: For a given Extended Link role R and summation item S, another item I is a contributing item if all of the following conditions are satisfied:
|
The important bit here is #2
- U-Equal means Unit-Equal: All facts contributing to a calculation must have the same unit (e.g. EUR)
- C-Equal means Context-Equal: All facts contributing to a calculation must belong to the same context.
What information is part of a context?
- Entity information (The LEI code in case of ESEF)
- Period information (Enddate, Startdate, forever)
- Dimensional information (Dimensions and Members, for example "Share Premium" in "Components of Equity")
This means that facts that belong to the same entity, share the same period and have identical dimensional information will be used for any given calculation in a report.
Let’s look at a specific example
Let's say you have the following calculation for Comprehensive Income in your Statement of Comprehensive Income:
The calculation is successful and you do not encounter any problems at this point. However, you revalidate your report and all of a sudden there is a validation error in the Statement of Changes in Equity:
What happened here
As mentioned before, calculations are valid and being calculated for all occurrences in the report. When you have no duplicates or dimensions in your report, that does not make any difference. But the Statement of Changes in Equity' has dimensions defined for each column. The Retained Earnings column in the example above has the dimension member Retained Earnings in the Components of Equity axis assigned.
Since the dimensional information is part of the context, and calculations are being calculated for all C-Equal facts, the calculation that has been set up in the Statement of Comprehensive Income is also being calculated for the existing facts in this dimensional combination. Since there are not values for all facts present, the calculation is as follows:
11,606 (tagged with Comprehensive Income) |
From the perspective of the XBRL calculation, this is not correct.
How can this be fixed?
This depends very much on the structure of the report. In our example, the calculation in the Statement of Comprehensive Income could be replaced with Comprehensive Income = Other Comprehensive Income + Profit Loss, which would work for both statements. It is not always that easy though. Here are the four most common options:
- Amend the calculation so it fits all occurrences of the tagged concept (with all dimensional variations).
- Make sure your rows are aligned between the Statement of Comprehensive Income and the Statement of Changes in Equity with respect to the calculations created.
- Accept and ignore the calculation validation warning.
- Delete the calculation.
firesys Version 22.3.1 and newer introduce Calculations tabs To check other occurences, their calculations are shown in additional tabs: In the example above, you will be able to see which page contains the tag that causes the calculation difference. In the cell tab you will see that "Profit loss" is part of a calculation and an additional tab with the page number shows a calculation in a different page which contains the same tag with a different value. The summands being shown are the summands that are valid in the context of this given cell, meaning if you have added a calculation for certain dimensions, it would show the values for tags existing in the dimension selection for the selected cells. This will make it more transparent why a calculation in another part of the report might lead to a calculation warning in the currently selected table. All calculations that have not been created for the selected cell can only be edited in the original cell. |
The XBRL specification has no mechanism to limit a specific calculation to a specific statement. However, requirements for a revised standard are already collected and discussed:
Requirements for Calculations 2.0
Siehe auch
Further Guidance
Packaging and Publishing of ESEF iXBRL Reports
Presentation Linkbase, Preferred Labels and Periods
Understanding Taxonomies and Reports
Weitere Inhalte
→ Webseite
→ Kundenbereich
→ YouTube