Tagging of Tables: Unterschied zwischen den Versionen

Aus firesys Hilfe
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
==Getting Ready to Tag Tables in PDF Documents==


Getting Ready to Tag Tables in PDF Documents
These steps must be performed before tables in '''PDF''' files can be tagged. It is not required for the other formats '''Word''', '''ePub''' (InDesign) and '''XHTML'''.
 
These steps must be performed before tables in PDF files can be tagged. It is not required for the other formats Word, ePub (InDesign) and XHTML.


PDF tagging works a little bit differently from the other sources being available in the Tagger. Due to technical reasons, PDF tables cannot be detected automatically. Once you have started the Tagger and loaded the file, you will be directed to the Preview tab. The Table Tagging tab is empty. The tables in the PDF file have to be defined after opening the document.
PDF tagging works a little bit differently from the other sources being available in the Tagger. Due to technical reasons, PDF tables cannot be detected automatically. Once you have started the Tagger and loaded the file, you will be directed to the Preview tab. The Table Tagging tab is empty. The tables in the PDF file have to be defined after opening the document.
Zeile 8: Zeile 7:
To tag tables you need to perform the following steps:
To tag tables you need to perform the following steps:


    Switch to the Preview tab
# Switch to the Preview tab


    Select the page with the table that needs to be tagged from the dropdown menu.
# Select the page with the table that needs to be tagged from the dropdown menu.


3. Select the whole table using the mouse cursor (you can use the two little blue dots to help you with the selection of the desired area), or click on the “Automatically select table area” symbol on the top left corner. Ideally, the table is selected withouth the headline, but including the column headers. The table area will then become yellow. At this point, choose an abstract element from the Taxonomy and simply drag and drop it into the yellow table area. It is important to choose the first concept below the folder icon with the label containing Placeholder in English language. (The table is now marked as a whole and it acquires a blue frame, as showed in the image below).
# Select the whole table using the mouse cursor (you can use the two little blue dots to help you with the selection of the desired area), or click on the “Automatically select table area” symbol on the top left corner. Ideally, the table is selected withouth the headline, but including the column headers. The table area will then become yellow. At this point, choose an abstract element from the Taxonomy and simply drag and drop it into the yellow table area. It is important to choose the first concept below the folder icon with the label containing Placeholder in English language. (The table is now marked as a whole and it acquires a blue frame, as showed in the image below).


4. Move to the Table Tagging tab where the table is now present and ready to be tagged.
# Move to the Table Tagging tab where the table is now present and ready to be tagged.


5. The selected table area can be changed even after adding a table and tagging cells. Go to the Preview tab, right click on the blue border of the table and select “Edit”. All tags still within the updated selected area will be kept.
# The selected table area can be changed even after adding a table and tagging cells. Go to the Preview tab, right click on the blue border of the table and select “Edit”. All tags still within the updated selected area will be kept.
Tagging Values
 
==Tagging Values==


Tagging a value in a table is a simple matter of drag and drop. Once the element from the XBRL taxonomy that suits a cell in the table has been identified, it can be dragged from the right part of the application onto the number that needs to be tagged.  
Tagging a value in a table is a simple matter of drag and drop. Once the element from the XBRL taxonomy that suits a cell in the table has been identified, it can be dragged from the right part of the application onto the number that needs to be tagged.  
Zeile 28: Zeile 28:


The tagging details can be checked under the Tags and Tagging Properties tabs after clicking on a cell. The displayed values inherit their specific settings from the table; table settings default values are inherited from the document settings. Values can be changed in the Tagging Properties dialog for individual values, if needed. This tab can also be used for audit purposes: under Audit you can see last change date and time and the name of the user who made a change. Tags can be removed under Tags.
The tagging details can be checked under the Tags and Tagging Properties tabs after clicking on a cell. The displayed values inherit their specific settings from the table; table settings default values are inherited from the document settings. Values can be changed in the Tagging Properties dialog for individual values, if needed. This tab can also be used for audit purposes: under Audit you can see last change date and time and the name of the user who made a change. Tags can be removed under Tags.
Auto Tag
 
==Auto Tag==


After you click on the Auto Tag Selected Cells button , the whole table will be checked and, if matches are found, automatically tagged.  
After you click on the Auto Tag Selected Cells button , the whole table will be checked and, if matches are found, automatically tagged.  
Zeile 35: Zeile 36:


With the help of Auto Tagger Strictness and Auto Tagger Mode options, users can define how the auto tagging will be performed: whether AI should be used and whether the name comparison should be strict or not.
With the help of Auto Tagger Strictness and Auto Tagger Mode options, users can define how the auto tagging will be performed: whether AI should be used and whether the name comparison should be strict or not.
Two-Page Table Tagging
 
==Two-Page Table Tagging==


Sometimes tables span over two pages, with the row label names only being available on the first page:
Sometimes tables span over two pages, with the row label names only being available on the first page:
Zeile 41: Zeile 43:
In this case, the table cannot be tagged properly:
In this case, the table cannot be tagged properly:


    RowLabelColumnId: This can be used if the row labels of a table are not the first row of a table. Simply set the column Id (0 based) of the column containing the labels.
* '''RowLabelColumnId''': This can be used if the row labels of a table are not the first row of a table. Simply set the column Id (0 based) of the column containing the labels.


    RowLabelTableId: Select a table from the dropdown that contains the row labels for this table. It can be used in conjunction with RowLabelColumnId if necessary.
* '''RowLabelTableId''': Select a table from the dropdown that contains the row labels for this table. It can be used in conjunction with RowLabelColumnId if necessary.


In this case just select the table containing the labels:
In this case just select the table containing the labels:
Zeile 52: Zeile 54:


It is also possible to tag the whole row including the first column:
It is also possible to tag the whole row including the first column:
Tagging of Two Tables on One Page
 
==Tagging of Two Tables on One Page==


Some tables represent two different tables as one "physical" table (example below: assets and liabilities). Some of the Tagger's mechanisms designed to make the life easier for customers can pose a problem here, for example the automatic detection of row labels and adjacent cells.
Some tables represent two different tables as one "physical" table (example below: assets and liabilities). Some of the Tagger's mechanisms designed to make the life easier for customers can pose a problem here, for example the automatic detection of row labels and adjacent cells.


To mitigate this situation, a new table setting has been introduced starting with Tagger version 1.5.5 called TwoInOneTableSplitColumnId.
To mitigate this situation, a new table setting has been introduced starting with Tagger version 1.5.5 called '''TwoInOneTableSplitColumnId'''.


This setting can be used to define a second RowHeader column, containing row names for the cells of the following columns, effectively splitting the table in two.
This setting can be used to define a second RowHeader column, containing row names for the cells of the following columns, effectively splitting the table in two.
Customizing the Dimensional Hierarchy
 
==Customizing the Dimensional Hierarchy==


The extension taxonomy filers usually have a dimensional hierarchy for the Statement of Changes in Equity. Usually, the Tagger infers this from the tagged elements and the default hierarchy in the ESEF taxonomy:
The extension taxonomy filers usually have a dimensional hierarchy for the Statement of Changes in Equity. Usually, the Tagger infers this from the tagged elements and the default hierarchy in the ESEF taxonomy:


You will now see the hierarchy as it currently would be, based on the  dimension tags that have been set to the table. You can move them around as necessary and even add new layers by just dragging and dropping them from the taxonomy window. Once you're done, just Save the hierarchy.
You will now see the hierarchy as it currently would be, based on the  dimension tags that have been set to the table. You can move them around as necessary and even add new layers by just dragging and dropping them from the taxonomy window. Once you're done, just '''Save''' the hierarchy.
 
It is also possible to '''Delete''' items, but only those that have been added manually and have not been tagged to an item.
 
==Customizing the Abstract Hierarchy==


It is also possible to Delete items, but only those that have been added manually and have not been tagged to an item.
In addition to the Dimension Hierarchy Customizer, it is sometimes also necessary to change '''Abstract Hierarchies'''. If the hierarchy of a statement in your report does not resemble the one in the ESEF taxonomy, you can now rearrange the positions and levels, add additional abstracts from the taxonomy and remove abstracts that are part of the default:
Customizing the Abstract Hierarchy


In addition to the Dimension Hierarchy Customizer, it is sometimes also necessary to change Abstract Hierarchies. If the hierarchy of a statement in your report does not resemble the one in the ESEF taxonomy, you can now rearrange the positions and levels, add additional abstracts from the taxonomy and remove abstracts that are part of the default:
Just select the hierarchy customizer for your table, select the '''role''' from which you want to copy the initial hierarchy and then '''drag and drop''' abstracts to this hierarchy. Once your are done, you drag and drop the abstract for a specific tag from this dialog onto the relevant tags, just as you did before from the taxonomy:


Just select the hierarchy customizer for your table, select the role from which you want to copy the initial hierarchy and then drag and drop abstracts to this hierarchy. Once your are done, you drag and drop the abstract for a specific tag from this dialog onto the relevant tags, just as you did before from the taxonomy:
==Rearranging the Row Order==
Rearranging the Row Order


It is important to bear in mind that the structure of statements in your company specific XBRL taxonomy extension will differ from what you have in the report. One such case is, for example, the following Statement of Changes in Equity. In the example report we can find two separate tables, one for each year. In the resulting taxonomy we will only have one combined table, with the period being selectable. In the below example we can further see that the table for 2017 has two rows more than the one for 2018. Where exactly these two rows are supposed to be placed in a combined table is up to the Filer and/or the Auditor. Per default they will just be added at the end, as shown below.
It is important to bear in mind that the structure of statements in your '''company specific XBRL taxonomy extension''' will differ from what you have in the report. One such case is, for example, the following '''Statement of Changes in Equity'''. In the example report we can find '''two separate tables''', one for each year. In the resulting taxonomy we will only have '''one combined table''', with the period being selectable. In the below example we can further see that the table for 2017 has two rows more than the one for 2018. Where exactly these two rows are supposed to be placed in a combined table is up to the '''Filer''' and/or the '''Auditor'''. Per default they will just be added at the end, as shown below.


With the custom row ordering feature, this can easily be changed by you. Just click on the highlighted button and rearrange the rows to your requirements. The result in the extension taxonomy will change accordingly:
With the custom row ordering feature, this can easily be changed by you. Just click on the highlighted button and rearrange the rows to your requirements. The result in the extension taxonomy will change accordingly:
Custom Date Formats


There are countless ways to represent a date; therefore, it is challenging to support all formats automatically in the Tagger. If a date is not recognized by default, from Tagger version 1.8 a custom format description can be created for the table in question.
==Custom Date Formats==
 
There are countless ways to represent a '''date'''; therefore, it is challenging to support all '''formats''' automatically in the Tagger. If a date is not recognized by default, from Tagger version 1.8 a '''custom format description''' can be created for the table in question.


Click on the "table settings" icon.
Click on the "table settings" icon.
Zeile 85: Zeile 92:


Select the desired date format, then click ok to save.
Select the desired date format, then click ok to save.
Member Tagging
 
==Member Tagging==


Tables with several columns require both line item tags and column tags (members).  
Tables with several columns require both line item tags and column tags (members).  
Zeile 93: Zeile 101:
Members are represented by a special icon in the ESEF taxonomy and have a label [member]:
Members are represented by a special icon in the ESEF taxonomy and have a label [member]:


To create a new extension for the selected column, select the column and click on the button ("Add Dimension Member").
To create a new extension for the selected column, select the '''column''' and click on the button ("Add Dimension Member").


To create an extended dimension click the "Create" button first. You can either select an existing axis of the selected Hypercube or create a new one. Please note, that you can only create one new member at a time. A mix of line item member isn't possible.
To create an extended dimension click the "Create" button first. You can either select an existing axis of the selected Hypercube or create a new one. Please note, that you can only create one new member at a time. A mix of line item member isn't possible.
Zeile 106: Zeile 114:
Add additional labels:
Add additional labels:
After clicking "Save" you can add additional labels for multiple languages to both the axis and the member. Simply double-click the combination in the list and then click on the "Dimension" or "Member" button to add new labels.
After clicking "Save" you can add additional labels for multiple languages to both the axis and the member. Simply double-click the combination in the list and then click on the "Dimension" or "Member" button to add new labels.
Extensions and Anchoring
 
Extensions
==Extensions and Anchoring==
 
===Extensions===


Entity specific disclosures, which are not available in the standard taxonomy, must be reported as taxonomy extensions.  
Entity specific disclosures, which are not available in the standard taxonomy, must be reported as taxonomy extensions.  
Zeile 113: Zeile 123:
The taxonomy extension is only allowed if the taxonomy does not contain a suitable item and if the core taxonomy element would lead to misrepresentation. A so-called "anchoring" must be used to specify the existing taxonomy positions with which the extension is semantically related.
The taxonomy extension is only allowed if the taxonomy does not contain a suitable item and if the core taxonomy element would lead to misrepresentation. A so-called "anchoring" must be used to specify the existing taxonomy positions with which the extension is semantically related.


To create a new extension for a line item, select the cell and click on the button Add XBRL Extensions to Selected Cell. The cell will be highlighted orange and a green cross appears beside the value.  
To create a new extension for a '''line item''', select the cell and click on the button Add XBRL Extensions to Selected Cell. The cell will be highlighted orange and a green cross appears beside the value.  


It is also possible to click the button Add XBRL Extensions to All Untagged Cells: As a result all untagged cells will be highlighted orange and marked with a green cross. Please keep in mind that it can be difficult to differenciate the cells that already have an anchoring from those that are not edited yet, since they all have the same highlight colour.
It is also possible to click the button Add XBRL Extensions to All Untagged Cells: As a result all untagged cells will be highlighted orange and marked with a green cross. Please keep in mind that it can be difficult to differenciate the cells that already have an anchoring from those that are not edited yet, since they all have the same highlight colour.
Zeile 119: Zeile 129:
Then go to the "Taxonomy Extension Properties" tab and select/add the corresponding attributes. The following attributes of the element are editable:
Then go to the "Taxonomy Extension Properties" tab and select/add the corresponding attributes. The following attributes of the element are editable:


    Balance Type: debit, credit or unknown
* Balance Type: debit, credit or unknown


    Element Name: technical name of the element (CamelCase)
* Element Name: technical name of the element (CamelCase)


    Item Type: select type (monetary, per share, string, text block etc.)
* Item Type: select type (monetary, per share, string, text block etc.)


    Label of the Element: element label (is copied from the table)
* Label of the Element: element label (is copied from the table)


    Period Type: instant, duration or unknown
* Period Type: instant, duration or unknown


    Reason for extension: You can describe the reasons, why a standard taxonomy concept cannot be used.
* Reason for extension: You can describe the reasons, why a standard taxonomy concept cannot be used.


    Summation Element: It defines if the element is the sum of other elements, in which case no anchors are needed. If the selected element is a total, true is displayed. It changes automatically, when calculation is created.
* Summation Element: It defines if the element is the sum of other elements, in which case no anchors are needed. If the selected element is a total, true is displayed. It changes automatically, when calculation is created.


Anchoring
===Anchoring===


The created extension needs to be linked to the core taxonomy. Extension taxonomy elements always have to be anchored to elements of the ESEF taxonomy, except for elements corresponding to subtotals (Summation Element: true). There are two options:
The created extension needs to be linked to the core taxonomy. Extension taxonomy elements always have to be anchored to elements of the ESEF taxonomy, except for elements corresponding to subtotals (Summation Element: true). There are two options:


    an extension taxonomy element has a narrower accounting meaning or scope than an element in the core taxonomy
* an extension taxonomy element has a narrower accounting meaning or scope than an element in the core taxonomy


    an extension taxonomy element has a wider accounting meaning or scope than an element in the core taxonomy
* an extension taxonomy element has a wider accounting meaning or scope than an element in the core taxonomy


For example, Very specific AMANA paid in capital in the table above is in the section Equity in the table, so it can be anchored to Total Equity in the ESEF taxonomy. To anchor the element, drag & drop the corresponding core taxonomy items to the Anchors area.
For example, Very specific AMANA paid in capital in the table above is in the section Equity in the table, so it can be anchored to Total Equity in the ESEF taxonomy. To anchor the element, drag & drop the corresponding core taxonomy items to the Anchors area.
Additional/Multilingual Labels
 
==Additional/Multilingual Labels==


If you want your extensions to have labels in different languages, not only the default language of your report, you can add labels for additional languages under Tagging Properties:
If you want your extensions to have labels in different languages, not only the default language of your report, you can add labels for additional languages under Tagging Properties:
Defining Calculations in Tables
 
==Defining Calculations in Tables==


Subtotals do not have to be anchored to an ESEF taxonomy concept. You can use the Calculation tab to define subtotal elements by defining the summands of the selected cell.
Subtotals do not have to be anchored to an ESEF taxonomy concept. You can use the Calculation tab to define subtotal elements by defining the summands of the selected cell.
Zeile 161: Zeile 173:
Calculations do have restrictions rooted in the XBRL specification, hence it is not possible to create calculations that:
Calculations do have restrictions rooted in the XBRL specification, hence it is not possible to create calculations that:


    span dimensions
* span dimensions
 
* contain a different period type than the total (will be highlighted red, see screenshot above)


    contain a different period type than the total (will be highlighted red, see screenshot above)
* state a calculation like Starting Balance + Change during period = End Balance


    state a calculation like Starting Balance + Change during period = End Balance
==Sign Logic (Reporting of Negative Values)==


Sign Logic (Reporting of Negative Values)
===Introduction to Sign Logic===
Introduction to Sign Logic


In some cases, the sign logic used in the report differs from the regulator's requirements. In general, XBRL taxonomies like the IFRS taxonomies require the reporting of positive numbers for certain item, like for "Cost of Sales" (ifrs-full:CostOfSales). If the item is presented as a negative number  on the face of a balance sheet, it might be required to invert its value in the XBRL report, but keeping it displayed as "negative". In some accounting systems (like SAP), all credit positions in the report have a negative sign, while the regulator expects those values to be reported with a positive sign.
In some cases, the sign logic used in the report differs from the regulator's requirements. In general, XBRL taxonomies like the IFRS taxonomies require the reporting of positive numbers for certain item, like for "Cost of Sales" (ifrs-full:CostOfSales). If the item is presented as a negative number  on the face of a balance sheet, it might be required to invert its value in the XBRL report, but keeping it displayed as "negative". In some accounting systems (like SAP), all credit positions in the report have a negative sign, while the regulator expects those values to be reported with a positive sign.


Setting the proper Sign Logic in the Tagger is not always an easy task. Several factors add to choosing the right value. It is recommended to start off with this article from XBRL.org:   (you need to be a member).
Setting the proper Sign Logic in the Tagger is not always an easy task. Several factors add to choosing the right value. It is recommended to start off with this article from XBRL.org: [https://www.xbrl.org/guidance/positive-and-negative-values/ Positive and Negative values in XBRL] (you need to be a member).


The main takeaway is: items may be displayed different from their value respective to the balance type. If a report displays -500 for a debit position (e.g. Cost of Sales), this usually means that the value is 500 (Cost) and just displayed with a minus to make its relation to other items in the report clearer without having to look at a tagged element's balance type. Negative cost would mean income, which for some items may be valid.
The main takeaway is: items may be displayed different from their value respective to the balance type. If a report displays -500 for a debit position (e.g. Cost of Sales), this usually means that the value is 500 (Cost) and just displayed with a minus to make its relation to other items in the report clearer without having to look at a tagged element's balance type. Negative cost would mean income, which for some items may be valid.
Zeile 213: Zeile 226:
Furthermore, items like Profit (loss) explicitly allow negative values due to their concept meaning and the respective label. The default/positive meaning of this concept is a profit, but when a negative value is displayed it might just mean that there is a loss rather than a SignLogic error. Other examples are:
Furthermore, items like Profit (loss) explicitly allow negative values due to their concept meaning and the respective label. The default/positive meaning of this concept is a profit, but when a negative value is displayed it might just mean that there is a loss rather than a SignLogic error. Other examples are:


    Profit (Loss)
* Profit (Loss)


    Operating profit (Loss)
* Operating profit (Loss)


    Profit (Loss) before tax
* Profit (Loss) before tax


    Gross Profit
* Gross Profit


    Earnings (loss)
* Earnings (loss)


    Earnings per share (loss)
* Earnings per share (loss)


    Gain (loss)
* Gain (loss)


    Cash flows from (used in)
* Cash flows from (used in)


    Cash inflows (outflows)
* Cash inflows (outflows)


    Income (expense)
* Income (expense)


    Finance income (expense)
* Finance income (expense)


    Increase (decrease)
* Increase (decrease)


Example of How Sign Logic is Used
===Example of How Sign Logic is Used===


Let's look at a concrete example:
Let's look at a concrete example:


    Financial income is tagged with: ifrs-full:FinancialIncome (Credit)
* Financial income is tagged with: ifrs-full:FinancialIncome (Credit)


    Financial expenses is tagged with: ifrs-full:FinanceCosts (Debit)
* Financial expenses is tagged with: ifrs-full:FinanceCosts (Debit)


    Net financial items is an extension with a Credit BalanceType. It could also be named Financial income (expenses)
* Net financial items is an extension with a Credit BalanceType. It could also be named Financial income (expenses)


Just looking at the table we can easily deduct that the company (in column 3) had a financial income of 394 monetary units, expenses of 1,184 monetary units leading to a total of 790 financial expenses. It is written the way it would be calculated: 394-1184=-790. Easy. It's also easy to see that there is an obvious mistake in the second column.  
Just looking at the table we can easily deduct that the company (in column 3) had a financial income of 394 monetary units, expenses of 1,184 monetary units leading to a total of 790 financial expenses. It is written the way it would be calculated: 394-1184=-790. Easy. It's also easy to see that there is an obvious mistake in the second column.  
Zeile 253: Zeile 266:
It is obvious that we do have different signs in this table. While NetFinancialItems still has the minus sign, both FinancialIncome and FinanceCosts now are positive. If we look at the BalanceType property of those XBRL concepts, this makes sense again:
It is obvious that we do have different signs in this table. While NetFinancialItems still has the minus sign, both FinancialIncome and FinanceCosts now are positive. If we look at the BalanceType property of those XBRL concepts, this makes sense again:


    FinancialIncome is Credit, translating to +394M
* FinancialIncome is Credit, translating to +394M


    FinanceCosts is Debit, translating to -1184M
* FinanceCosts is Debit, translating to -1184M


    NetFinancialItems is Credit, translating to -790M
* NetFinancialItems is Credit, translating to -790M


With this in mind, we can do the same calculation as above.  
With this in mind, we can do the same calculation as above.  
The SignLogic Property
 
===The SignLogic Property===


To connect the two views described above, XBRL knows a property called SignLogic. It tells the XBRL tools how to interpet the value displayed in the report. While this can in general be deducted from the concept itself, it is not something that can be completely automated. The real meaning of the displayed portion of a financial report can not be properly interpreted by just software (yet).
To connect the two views described above, XBRL knows a property called SignLogic. It tells the XBRL tools how to interpet the value displayed in the report. While this can in general be deducted from the concept itself, it is not something that can be completely automated. The real meaning of the displayed portion of a financial report can not be properly interpreted by just software (yet).
Zeile 266: Zeile 280:
The XBRL Tagger offers multiple ways of tackle it by inverting the sign of an number.
The XBRL Tagger offers multiple ways of tackle it by inverting the sign of an number.


When generating an iXBRL result document, it is possible to reverse the sign of values based on the balance attribute of the tagged element. For more information, see Generate Inline XBRL File.
When generating an iXBRL result document, it is possible to reverse the sign of values based on the balance attribute of the tagged element. For more information, see [https://hilfe.firesys.de/wiki/XBRL_File_Generation Generate Inline XBRL File].


In addition, it is possible to define a sign logic for a single cell. The sign logic applied to a selected cell is shown in the column "Sign logic" on the "Tags" tab.
In addition, it is possible to define a sign logic for a single cell. The sign logic applied to a selected cell is shown in the column "Sign logic" on the "Tags" tab.
Zeile 272: Zeile 286:
The following values for SignLogic are possible:
The following values for SignLogic are possible:


    None: no special sign logic will be applied. The sign can be overwritten, e.g. if the setting "Reverse sign of debit position" is active while generating the report and the tagged element has a debit balance.
* '''None''': no special sign logic will be applied. The sign can be overwritten, e.g. if the setting "Reverse sign of debit position" is active while generating the report and the tagged element has a debit balance.


    As Reported: the value will always be added to the iXBRL document with the same sign as the sign in the report. Even if the setting "Reverse sign of debit position" is active while generating the report, the sign will not be changed, even if the tagged element has a debit balance.
* '''As Reported''': the value will always be added to the iXBRL document with the same sign as the sign in the report. Even if the setting "Reverse sign of debit position" is active while generating the report, the sign will not be changed, even if the tagged element has a debit balance.


    Reverse: the sign will be reversed. Negative values will be reported as positive values in the iXBRL document and vice versa.
* '''Reverse''': the sign will be reversed. Negative values will be reported as positive values in the iXBRL document and vice versa.


    Always Positive: the value will always be reported with a positive sign.
* '''Always Positive''': the value will always be reported with a positive sign.


    Always Negative: the value will always be reported with a negative sign.
* '''Always Negative''': the value will always be reported with a negative sign.


Let's look again at the rows from our example above:
Let's look again at the rows from our example above:
Zeile 339: Zeile 353:


-790
-790
Calculation and Weight
 
===Calculation and Weight===


The selected SignLogic is very important for the validation of calculation relationships. In our example, the calculation would look like this:
The selected SignLogic is very important for the validation of calculation relationships. In our example, the calculation would look like this:


Net financial items = Financial Income - Financial Expenses
'''Net financial items = Financial Income - Financial Expenses'''


The weight attribute is automatically set depending on the balance type of the items involved and should not be changed, unless the concept has a balance type of Unknown.
The weight attribute is automatically set depending on the balance type of the items involved and should not be changed, unless the concept has a balance type of Unknown.
Zeile 349: Zeile 364:
If we now look at the complete picture we have the following result:
If we now look at the complete picture we have the following result:


    -790 * 1 (As Reported) = 394 * 1 (Always Positive) - (-1184 * -1 (Reverse)) ↔ -790 = 394 - 1184
-790 * 1 (As Reported) = 394 * 1 (Always Positive) - (-1184 * -1 (Reverse)) ↔ -790 = 394 - 1184


If we perform the same calculation for the second column of our example, the calculation validation does not work out and we can again see the obvious mistake, which we might have not seen yet, but needs to be corrected.
If we perform the same calculation for the second column of our example, the calculation validation does not work out and we can again see the obvious mistake, which we might have not seen yet, but needs to be corrected.

Version vom 25. September 2023, 14:36 Uhr

Getting Ready to Tag Tables in PDF Documents

These steps must be performed before tables in PDF files can be tagged. It is not required for the other formats Word, ePub (InDesign) and XHTML.

PDF tagging works a little bit differently from the other sources being available in the Tagger. Due to technical reasons, PDF tables cannot be detected automatically. Once you have started the Tagger and loaded the file, you will be directed to the Preview tab. The Table Tagging tab is empty. The tables in the PDF file have to be defined after opening the document.

To tag tables you need to perform the following steps:

  1. Switch to the Preview tab
  1. Select the page with the table that needs to be tagged from the dropdown menu.
  1. Select the whole table using the mouse cursor (you can use the two little blue dots to help you with the selection of the desired area), or click on the “Automatically select table area” symbol on the top left corner. Ideally, the table is selected withouth the headline, but including the column headers. The table area will then become yellow. At this point, choose an abstract element from the Taxonomy and simply drag and drop it into the yellow table area. It is important to choose the first concept below the folder icon with the label containing Placeholder in English language. (The table is now marked as a whole and it acquires a blue frame, as showed in the image below).
  1. Move to the Table Tagging tab where the table is now present and ready to be tagged.
  1. The selected table area can be changed even after adding a table and tagging cells. Go to the Preview tab, right click on the blue border of the table and select “Edit”. All tags still within the updated selected area will be kept.

Tagging Values

Tagging a value in a table is a simple matter of drag and drop. Once the element from the XBRL taxonomy that suits a cell in the table has been identified, it can be dragged from the right part of the application onto the number that needs to be tagged.

When the cell is highlighted green, it means that the tagging was successful.

One element from the taxonomy can be mapped to different periods, as showed in the image below.

The Tagger tries to conclude the period or date for the specific tag from the value in the first row of the column. In the example above, the value -45,456 is tagged with the period from 1st January 2018 to the 31st December of 2018, while the value -41,766 is tagged with these dates for the year 2017.

The tagging details can be checked under the Tags and Tagging Properties tabs after clicking on a cell. The displayed values inherit their specific settings from the table; table settings default values are inherited from the document settings. Values can be changed in the Tagging Properties dialog for individual values, if needed. This tab can also be used for audit purposes: under Audit you can see last change date and time and the name of the user who made a change. Tags can be removed under Tags.

Auto Tag

After you click on the Auto Tag Selected Cells button , the whole table will be checked and, if matches are found, automatically tagged.

The following message will be displayed after the tagging is finished:

With the help of Auto Tagger Strictness and Auto Tagger Mode options, users can define how the auto tagging will be performed: whether AI should be used and whether the name comparison should be strict or not.

Two-Page Table Tagging

Sometimes tables span over two pages, with the row label names only being available on the first page:

In this case, the table cannot be tagged properly:

  • RowLabelColumnId: This can be used if the row labels of a table are not the first row of a table. Simply set the column Id (0 based) of the column containing the labels.
  • RowLabelTableId: Select a table from the dropdown that contains the row labels for this table. It can be used in conjunction with RowLabelColumnId if necessary.

In this case just select the table containing the labels:

Both tables MUST have the same amount of rows AND the row order MUST be the same.

When hovering over a row or looking at the cell details, the label taken from the first table will be shown:

It is also possible to tag the whole row including the first column:

Tagging of Two Tables on One Page

Some tables represent two different tables as one "physical" table (example below: assets and liabilities). Some of the Tagger's mechanisms designed to make the life easier for customers can pose a problem here, for example the automatic detection of row labels and adjacent cells.

To mitigate this situation, a new table setting has been introduced starting with Tagger version 1.5.5 called TwoInOneTableSplitColumnId.

This setting can be used to define a second RowHeader column, containing row names for the cells of the following columns, effectively splitting the table in two.

Customizing the Dimensional Hierarchy

The extension taxonomy filers usually have a dimensional hierarchy for the Statement of Changes in Equity. Usually, the Tagger infers this from the tagged elements and the default hierarchy in the ESEF taxonomy:

You will now see the hierarchy as it currently would be, based on the dimension tags that have been set to the table. You can move them around as necessary and even add new layers by just dragging and dropping them from the taxonomy window. Once you're done, just Save the hierarchy.

It is also possible to Delete items, but only those that have been added manually and have not been tagged to an item.

Customizing the Abstract Hierarchy

In addition to the Dimension Hierarchy Customizer, it is sometimes also necessary to change Abstract Hierarchies. If the hierarchy of a statement in your report does not resemble the one in the ESEF taxonomy, you can now rearrange the positions and levels, add additional abstracts from the taxonomy and remove abstracts that are part of the default:

Just select the hierarchy customizer for your table, select the role from which you want to copy the initial hierarchy and then drag and drop abstracts to this hierarchy. Once your are done, you drag and drop the abstract for a specific tag from this dialog onto the relevant tags, just as you did before from the taxonomy:

Rearranging the Row Order

It is important to bear in mind that the structure of statements in your company specific XBRL taxonomy extension will differ from what you have in the report. One such case is, for example, the following Statement of Changes in Equity. In the example report we can find two separate tables, one for each year. In the resulting taxonomy we will only have one combined table, with the period being selectable. In the below example we can further see that the table for 2017 has two rows more than the one for 2018. Where exactly these two rows are supposed to be placed in a combined table is up to the Filer and/or the Auditor. Per default they will just be added at the end, as shown below.

With the custom row ordering feature, this can easily be changed by you. Just click on the highlighted button and rearrange the rows to your requirements. The result in the extension taxonomy will change accordingly:

Custom Date Formats

There are countless ways to represent a date; therefore, it is challenging to support all formats automatically in the Tagger. If a date is not recognized by default, from Tagger version 1.8 a custom format description can be created for the table in question.

Click on the "table settings" icon.

Go to Date Format and click on the ellipsis symbol on the right:

Select the desired date format, then click ok to save.

Member Tagging

Tables with several columns require both line item tags and column tags (members).

First tag the line items. After that, mark the column to be tagged, select the element from the XBRL taxonomy and drag it from the right part of the application onto the selected column. After a successful tagging the column will be highlighted.

Members are represented by a special icon in the ESEF taxonomy and have a label [member]:

To create a new extension for the selected column, select the column and click on the button ("Add Dimension Member").

To create an extended dimension click the "Create" button first. You can either select an existing axis of the selected Hypercube or create a new one. Please note, that you can only create one new member at a time. A mix of line item member isn't possible. If you want to create a new member but already used the Member Label you have to create a new Member Label. Just type in a new name, which can be a variant of the "old" name and click on save.

Use existing axis: If you do not need to create a new axis, just select an existing one and add a new member. You can change the technical name if necessary. Click "Save" when you are done.

Create new axis: To create a new axis check the "Extend" checkbox and add a label. You can change the technical name if necessary. Every axis needs one "Default" member, which will apply to all items in the table that have not explicitly been assigned a member of this particular dimension. Check the "Default" box for the member that is the default for your extended axis. Click "Save" when you are done.

Add additional labels: After clicking "Save" you can add additional labels for multiple languages to both the axis and the member. Simply double-click the combination in the list and then click on the "Dimension" or "Member" button to add new labels.

Extensions and Anchoring

Extensions

Entity specific disclosures, which are not available in the standard taxonomy, must be reported as taxonomy extensions.

The taxonomy extension is only allowed if the taxonomy does not contain a suitable item and if the core taxonomy element would lead to misrepresentation. A so-called "anchoring" must be used to specify the existing taxonomy positions with which the extension is semantically related.

To create a new extension for a line item, select the cell and click on the button Add XBRL Extensions to Selected Cell. The cell will be highlighted orange and a green cross appears beside the value.

It is also possible to click the button Add XBRL Extensions to All Untagged Cells: As a result all untagged cells will be highlighted orange and marked with a green cross. Please keep in mind that it can be difficult to differenciate the cells that already have an anchoring from those that are not edited yet, since they all have the same highlight colour.

Then go to the "Taxonomy Extension Properties" tab and select/add the corresponding attributes. The following attributes of the element are editable:

  • Balance Type: debit, credit or unknown
  • Element Name: technical name of the element (CamelCase)
  • Item Type: select type (monetary, per share, string, text block etc.)
  • Label of the Element: element label (is copied from the table)
  • Period Type: instant, duration or unknown
  • Reason for extension: You can describe the reasons, why a standard taxonomy concept cannot be used.
  • Summation Element: It defines if the element is the sum of other elements, in which case no anchors are needed. If the selected element is a total, true is displayed. It changes automatically, when calculation is created.

Anchoring

The created extension needs to be linked to the core taxonomy. Extension taxonomy elements always have to be anchored to elements of the ESEF taxonomy, except for elements corresponding to subtotals (Summation Element: true). There are two options:

  • an extension taxonomy element has a narrower accounting meaning or scope than an element in the core taxonomy
  • an extension taxonomy element has a wider accounting meaning or scope than an element in the core taxonomy

For example, Very specific AMANA paid in capital in the table above is in the section Equity in the table, so it can be anchored to Total Equity in the ESEF taxonomy. To anchor the element, drag & drop the corresponding core taxonomy items to the Anchors area.

Additional/Multilingual Labels

If you want your extensions to have labels in different languages, not only the default language of your report, you can add labels for additional languages under Tagging Properties:

Defining Calculations in Tables

Subtotals do not have to be anchored to an ESEF taxonomy concept. You can use the Calculation tab to define subtotal elements by defining the summands of the selected cell.

To add calculation, first select the subtotal, then activate summands ("Select Summands: on"). After that select the relevant cells and click on "Add Selection". The selected line items will then be added to the calculation relationship.

When all required summands are selected, click on Select Summands button again to change it to "off" and continue with other cells. It is possible to select summands from different tables. Simply leave the "Select Summands" button "On" and change the table to add further items.

The Calculation tab also displays information to help guide the creation of proper calculation relationships. You can see the current calculated total in the upper right corner, plus the delta if the calculation does not match the value in the total. Next to the "Add Selection" button you can see information about the total: The label of row and column, the balance type and the period type.

For more information about Sign Logic and weights please see the next section. Both settings can be changed for the items in the list right here in the calculation tab.

Please note that you cannot add calculations in the Statement of Changes in Equity table.

Calculations do have restrictions rooted in the XBRL specification, hence it is not possible to create calculations that:

  • span dimensions
  • contain a different period type than the total (will be highlighted red, see screenshot above)
  • state a calculation like Starting Balance + Change during period = End Balance

Sign Logic (Reporting of Negative Values)

Introduction to Sign Logic

In some cases, the sign logic used in the report differs from the regulator's requirements. In general, XBRL taxonomies like the IFRS taxonomies require the reporting of positive numbers for certain item, like for "Cost of Sales" (ifrs-full:CostOfSales). If the item is presented as a negative number on the face of a balance sheet, it might be required to invert its value in the XBRL report, but keeping it displayed as "negative". In some accounting systems (like SAP), all credit positions in the report have a negative sign, while the regulator expects those values to be reported with a positive sign.

Setting the proper Sign Logic in the Tagger is not always an easy task. Several factors add to choosing the right value. It is recommended to start off with this article from XBRL.org: Positive and Negative values in XBRL (you need to be a member).

The main takeaway is: items may be displayed different from their value respective to the balance type. If a report displays -500 for a debit position (e.g. Cost of Sales), this usually means that the value is 500 (Cost) and just displayed with a minus to make its relation to other items in the report clearer without having to look at a tagged element's balance type. Negative cost would mean income, which for some items may be valid.

The following table explains the meaning of the balance attribute (also called BalanceType) according to their usage in different financial statements.

Balance Attribute


Statement of Financial Position (Balance Sheet)


Statement of Comprehensive Income, profit or loss


Statement of cash flows

Debit


Assets


Expense


Cash inflow

Credit


Liabilities/Equity


Income


Cash outflow

Furthermore, items like Profit (loss) explicitly allow negative values due to their concept meaning and the respective label. The default/positive meaning of this concept is a profit, but when a negative value is displayed it might just mean that there is a loss rather than a SignLogic error. Other examples are:

  • Profit (Loss)
  • Operating profit (Loss)
  • Profit (Loss) before tax
  • Gross Profit
  • Earnings (loss)
  • Earnings per share (loss)
  • Gain (loss)
  • Cash flows from (used in)
  • Cash inflows (outflows)
  • Income (expense)
  • Finance income (expense)
  • Increase (decrease)

Example of How Sign Logic is Used

Let's look at a concrete example:

  • Financial income is tagged with: ifrs-full:FinancialIncome (Credit)
  • Financial expenses is tagged with: ifrs-full:FinanceCosts (Debit)
  • Net financial items is an extension with a Credit BalanceType. It could also be named Financial income (expenses)

Just looking at the table we can easily deduct that the company (in column 3) had a financial income of 394 monetary units, expenses of 1,184 monetary units leading to a total of 790 financial expenses. It is written the way it would be calculated: 394-1184=-790. Easy. It's also easy to see that there is an obvious mistake in the second column.

If we would look at the same table in an XBRL Data view it would look like this:

It is obvious that we do have different signs in this table. While NetFinancialItems still has the minus sign, both FinancialIncome and FinanceCosts now are positive. If we look at the BalanceType property of those XBRL concepts, this makes sense again:

  • FinancialIncome is Credit, translating to +394M
  • FinanceCosts is Debit, translating to -1184M
  • NetFinancialItems is Credit, translating to -790M

With this in mind, we can do the same calculation as above.

The SignLogic Property

To connect the two views described above, XBRL knows a property called SignLogic. It tells the XBRL tools how to interpet the value displayed in the report. While this can in general be deducted from the concept itself, it is not something that can be completely automated. The real meaning of the displayed portion of a financial report can not be properly interpreted by just software (yet).

The XBRL Tagger offers multiple ways of tackle it by inverting the sign of an number.

When generating an iXBRL result document, it is possible to reverse the sign of values based on the balance attribute of the tagged element. For more information, see Generate Inline XBRL File.

In addition, it is possible to define a sign logic for a single cell. The sign logic applied to a selected cell is shown in the column "Sign logic" on the "Tags" tab.

The following values for SignLogic are possible:

  • None: no special sign logic will be applied. The sign can be overwritten, e.g. if the setting "Reverse sign of debit position" is active while generating the report and the tagged element has a debit balance.
  • As Reported: the value will always be added to the iXBRL document with the same sign as the sign in the report. Even if the setting "Reverse sign of debit position" is active while generating the report, the sign will not be changed, even if the tagged element has a debit balance.
  • Reverse: the sign will be reversed. Negative values will be reported as positive values in the iXBRL document and vice versa.
  • Always Positive: the value will always be reported with a positive sign.
  • Always Negative: the value will always be reported with a negative sign.

Let's look again at the rows from our example above:

Concept


BalanceType


Displayed Value


SignLogic


XBRL Value

FinanceIncome


Credit


394


AlwaysPositive


394

FinanceCosts


Debit


-1184


Reverse


1184

NetFinancialItems


Credit


-790


AsReported


-790

Calculation and Weight

The selected SignLogic is very important for the validation of calculation relationships. In our example, the calculation would look like this:

Net financial items = Financial Income - Financial Expenses

The weight attribute is automatically set depending on the balance type of the items involved and should not be changed, unless the concept has a balance type of Unknown.

If we now look at the complete picture we have the following result:

-790 * 1 (As Reported) = 394 * 1 (Always Positive) - (-1184 * -1 (Reverse)) ↔ -790 = 394 - 1184

If we perform the same calculation for the second column of our example, the calculation validation does not work out and we can again see the obvious mistake, which we might have not seen yet, but needs to be corrected.

Siehe auch

Navigation hoch.svg Using the XBRL-Tagger

Weitere Inhalte

Webseite
Kundenbereich
YouTube