Taxonomy Calculation Hierarchy

Some taxonomies contain a calculation hierarchy, for example the South African CIPC and ESMA's ESEF taxonomies.  The calculation hierarchy defines the mathematical relationships of tags. This hierarchy is different from the hierarchy in the Primary tags panel.  For example, in the ESEF taxonomy, 

An extended taxonomy must include a calculation hierarchy which explains the mathematical relationship between used tags.  Furthermore, values inserted for each fact in the iXBRL instance document must conform with the described calculation hierarchy.

Calculation Hierarchy Panel

In Report Authority, the calculation hierarchy is displayed and can be edited in the Calculation Hierarchy panel dock to the right:

Report Authority will automatically add tags to the calculation hierarchy panel as they are used.  If a calculation hierarchy relationship exists between two tags in the core taxonomy, the relationship will be automatically represented.  However, the user must review these relationships and is expected to have to make manual adjustments as appropriate such as;

1. Adjusting a tag's rollup property to its parent to one of Add, Subtract or Do Not Rollup.
2. Adjusting the calculation hierarchy by dragging and dropping.

Editing the hierarchy 

In the example above, the calculation hierarchy displayed defaulted to the hierarchy in the core taxonomy.  However, the Profit (loss) before tax and the Tax income (expense) tags should rollup to the Profit (loss) tag, but are shown as siblings at the same level.  This default hierarchy must be edited by dragging both Profit (loss) before tax and the Tax income (expense) tags to become children of Profit (loss) as shown in this video:

In this example, the default calculation hierarchy for a balance sheet is presented as follows:

This default hierarchy requires significant changes, as illustrated in this video:

Validations

When validations are run, Report Authority will evaluate the calculation hierarchy using the numeric facts inserted in the iXBRL document.  Any errors will be reported in the validation panel:

In this example, it is clear we have a signage issue with Cost of Sales.  Cost of Sales should be positive in the XBRL document but is shown as a negative number.  To clear this issue, the Reverse Signage Convention tag property should be set to true. This will clear the validation failure.  Please note it would be incorrect to instead change the calculation hierarchy to add Cost of Sales to Turnover.  This may clear this validation failure, however, Cost of Sales will incorrectly be interpreted as a credit, which is why the Reverse Signage Convention tag property should instead be amended.

-----