Validation Messages: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 7: | Zeile 7: | ||
Severity: Warning, but Error in Production. | Severity: Warning, but Error in Production. | ||
A valid ESEF document needs the proper LEI of the filer: www.gleif.org | A valid ESEF document needs the proper LEI of the filer: [https://www.gleif.org/en www.gleif.org] | ||
Please go to Document → Settings, then enter the LEI under "Reporting Entity Identifier (e.g. LEI)" | Please go to Document → Settings, then enter the LEI under "Reporting Entity Identifier (e.g. LEI)" | ||
==When validating with the Tagger, the error "Table element ... has no table element mapped" is displayed== | |||
When validating with the Tagger, the error "Table element ... has no table element mapped" is displayed | |||
Severity: Error | Severity: Error | ||
| Zeile 20: | Zeile 17: | ||
It is necessary to tag an abstract element to the table. Every tagged table needs an abstract element from the basic taxonomy. This can be added by drag & drop from the right hand side taxonomy to the Table Tag above the table. | It is necessary to tag an abstract element to the table. Every tagged table needs an abstract element from the basic taxonomy. This can be added by drag & drop from the right hand side taxonomy to the Table Tag above the table. | ||
==When validating the document, the warnings "Status …" are displayed:== | |||
When validating the document, the warnings "Status …" are displayed: | |||
Severity: Warning | Severity: Warning | ||
| Zeile 29: | Zeile 23: | ||
Check the affected cells and set the status to final: | Check the affected cells and set the status to final: | ||
==When validating the document, the warnings "Table x has x cell(s) without a mapping" is displayed== | |||
When validating the document, the warnings "Table x has x cell(s) without a mapping" is displayed | |||
Severity: Warning | Severity: Warning | ||
| Zeile 38: | Zeile 29: | ||
A cell in a table with table tag has no mapping. All cells in the PFS (Primary Financial Statements) need to be tagged! | A cell in a table with table tag has no mapping. All cells in the PFS (Primary Financial Statements) need to be tagged! | ||
==When validating the document, the warning "Cell is not taking part in calculation relationship" is displayed== | |||
When validating the document, the warning "Cell is not taking part in calculation relationship" is displayed | |||
Severity: Warning | Severity: Warning | ||
| Zeile 47: | Zeile 35: | ||
All tagged cells in the PFS need to be part of a calculation relationship, except where it is not technically possible (e.g. Statement of changes in Equity, calculations like beginning balance +/- changes = ending balance, because this can't be modelled in XBRL taxonomies yet). | All tagged cells in the PFS need to be part of a calculation relationship, except where it is not technically possible (e.g. Statement of changes in Equity, calculations like beginning balance +/- changes = ending balance, because this can't be modelled in XBRL taxonomies yet). | ||
==When validating with the Tagger, the error "Duplicate mapping detected ..." is displayed== | |||
When validating with the Tagger, the error "Duplicate mapping detected ..." is displayed | |||
Severity: Error | Severity: Error | ||
| Zeile 58: | Zeile 43: | ||
Click on the error message to jump to the relevant table, where the error occurred. Several cells belonging to the same table are tagged to the same taxonomy element, but with different values (inconsistency). This might also happen when the Tagger is unable to identify the correct reporting date for a column. Please, make sure that the reporting date for any tagged cell is correct by checking the Table Cell Properties of a selected range of cells: | Click on the error message to jump to the relevant table, where the error occurred. Several cells belonging to the same table are tagged to the same taxonomy element, but with different values (inconsistency). This might also happen when the Tagger is unable to identify the correct reporting date for a column. Please, make sure that the reporting date for any tagged cell is correct by checking the Table Cell Properties of a selected range of cells: | ||
==When validating the document, the error "Extension element for cell x in table x has no anchors" is displayed== | |||
When validating the document, the error "Extension element for cell x in table x has no anchors" is displayed | |||
Severity: Error | Severity: Error | ||
| Zeile 67: | Zeile 49: | ||
Every extension needs to have at least one anchor, unless it is the total of a calculation relationship. | Every extension needs to have at least one anchor, unless it is the total of a calculation relationship. | ||
==When validating the document, the error "The value ... is not valid for the format ..." is displayed.== | |||
When validating the document, the error "The value ... is not valid for the format ..." is displayed. | |||
Severity: Error | Severity: Error | ||
| Zeile 76: | Zeile 55: | ||
The selected Number or Date Format cannot be applied to the value of the tag. Go to the affected tag → Properties → select a different format. | The selected Number or Date Format cannot be applied to the value of the tag. Go to the affected tag → Properties → select a different format. | ||
==When generating an XBRL report, the error "Element with name ... not found in Taxonomy" is displayed== | |||
When generating an XBRL report, the error "Element with name ... not found in Taxonomy" is displayed | |||
Severity: Error | Severity: Error | ||
| Zeile 85: | Zeile 61: | ||
The tagged element was not found in the taxonomy. Please check if you have a different version of the taxonomy, which does not contain the tagged element. | The tagged element was not found in the taxonomy. Please check if you have a different version of the taxonomy, which does not contain the tagged element. | ||
==When validating with the Tagger, the error "Line item missing in table..." is displayed== | |||
When validating with the Tagger, the error "Line item missing in table..." is displayed | |||
Severity: Error | Severity: Error | ||
| Zeile 96: | Zeile 69: | ||
To solve this issue, erase the tag for the dimension element (member), tag the line item, finally re-tag the dimension element. | To solve this issue, erase the tag for the dimension element (member), tag the line item, finally re-tag the dimension element. | ||
==When validating the document, the error "Dimensionally invalid" is displayed== | |||
When validating the document, the error "Dimensionally invalid" is displayed | |||
Severity: Error | Severity: Error | ||
| Zeile 105: | Zeile 75: | ||
Each mapping in a table has to contain the same dimensions. You can get this error either by tagging tables or textblocks (narrative disclosure). For example, if you tag an element that is supposed to be part of a table (as per the taxonomy) in the textblock section or you tag an element that is supposed be part of a textblock (as per the taxonomy) in a table. | Each mapping in a table has to contain the same dimensions. You can get this error either by tagging tables or textblocks (narrative disclosure). For example, if you tag an element that is supposed to be part of a table (as per the taxonomy) in the textblock section or you tag an element that is supposed be part of a textblock (as per the taxonomy) in a table. | ||
You can fix this error by performing a (a.) Parenthetical or (b.) by erasing the element in the wrong section and place it in the correct one. | You can fix this error by performing a '''(a.) [https://hilfe.firesys.de/wiki/Tagging_as_Parentheticals_/_Values_in_Footnotes Parenthetical]''' or '''(b.)''' by '''erasing''' the element in the wrong section and place it in the correct one. | ||
a. Performing a Parenthetical | '''a. Performing a Parenthetical''' | ||
You can use any abstract element from the taxonomy, for example the Notes, accounting policies and mandatory tags Tag for the textblock section or the Profit or loss placeholder for the table section, to solve the issue. | You can use any abstract element from the taxonomy, for example the Notes, accounting policies and mandatory tags Tag for the textblock section or the Profit or loss placeholder for the table section, to solve the issue. | ||
If your document is a Word document, please perform the Parenthetical procedure in the Tagger and not in Word. To do this open your document in the Tagger. Select the element in the taxonomy, for example "NotesAccountingPoliciesAndMandatoryTags" and "drag and drop" it into the tag, for example "DividendsRecognisedAsDistributionsToOwnersPerShares”. This solves the error! Don't forget to save the changes you have made. | If your document is a '''Word document''', please perform the '''Parenthetical''' procedure in the Tagger and '''not in Word'''. To do this open your document in the Tagger. Select the element in the taxonomy, for example "NotesAccountingPoliciesAndMandatoryTags" and "'''drag and drop'''" it into the tag, for example "DividendsRecognisedAsDistributionsToOwnersPerShares”. This solves the error! Don't forget to save the changes you have made. | ||
You should perform this procedure for all the elements of the taxonomy that are not of the "TextBlock" type, for example they are "Monatary" or "perShare", but should be in the TextBlock section nonetheless. | You should perform this procedure for all the elements of the taxonomy that are not of the "TextBlock" type, for example they are "Monatary" or "perShare", but should be in the TextBlock section nonetheless. | ||
b. Erasing the element in the wrong section and place it in the correct one. | '''b. Erasing''' the element in the wrong section and place it in the correct one. | ||
In the example below you can see that the element (in red) selected from the taxonomy belongs to a table (roll 220000) and not to the textblock section (in green). Delete the selected tag and place the correct one from the textblock section (roll 110000). | In the example below you can see that the element (in red) selected from the taxonomy belongs to a table (roll 220000) and not to the textblock section (in green). Delete the selected tag and place the correct one from the textblock section (roll 110000). | ||
==When validating the document, the error "The selected format x is incompatible with ..." is displayed== | |||
When validating the document, the error "The selected format x is incompatible with ..." is displayed | |||
Severity: Error | Severity: Error | ||
| Zeile 132: | Zeile 95: | ||
A wrong base format has been applied, e.g. a date format for a monetary value. Please check the tag and fix accordingly. | A wrong base format has been applied, e.g. a date format for a monetary value. Please check the tag and fix accordingly. | ||
==Duplicate Label== | |||
Duplicate Label | |||
Severity: Error | Severity: Error | ||
| Zeile 141: | Zeile 101: | ||
A duplicate label warning or error is displayed on cells with equal tag combinations but with different names (labels). For instance, "ifrs-full:Equity" might be tagged in the balance sheet as "Total Equity", as well as in the Statement of changes in Equity with the label "Equity at 01.01.2019" and "Equity at 31.12.2019". In this case, three different labels are provided for the same tag. In order to differentiate the meaning of the different labels, its required to set its so called label role. The most common label roles are (samples in brakets): | A duplicate label warning or error is displayed on cells with equal tag combinations but with different names (labels). For instance, "ifrs-full:Equity" might be tagged in the balance sheet as "Total Equity", as well as in the Statement of changes in Equity with the label "Equity at 01.01.2019" and "Equity at 31.12.2019". In this case, three different labels are provided for the same tag. In order to differentiate the meaning of the different labels, its required to set its so called label role. The most common label roles are (samples in brakets): | ||
* Standard label (Equity) | |||
* Total label (Total Equity) | |||
* Period start / Period end label (Equity at beginning/ending of period) | |||
* Verbose label (Equity, as determined by nature) | |||
It is important to align all labels used across the report for all values, that are tagged to the same element. Only one label per role is allowed. This also usually means to remove date references from the period start and end label, "Equity at the end of period" instead of "Equity at 31.12.2019", because two period end labels (31.12.2019 and 31.12.2020 ) are not possible. | It is important to align all labels used across the report for all values, that are tagged to the same element. Only one label per role is allowed. This also usually means to remove date references from the period start and end label, "Equity at the end of period" instead of "Equity at 31.12.2019", because two period end labels (31.12.2019 and 31.12.2020 ) are not possible. | ||
| Zeile 153: | Zeile 110: | ||
Change preferred label roles and labels under Table Cell Properties: | Change preferred label roles and labels under Table Cell Properties: | ||
==Duplicate Extension== | |||
Duplicate Extension | |||
Severity: Error | Severity: Error | ||
| Zeile 162: | Zeile 116: | ||
A duplicate extension error is displayed, when the cells with extensions have different properties: e.g. different anchors in the current an previous year; diffrent sign logic for every cell. | A duplicate extension error is displayed, when the cells with extensions have different properties: e.g. different anchors in the current an previous year; diffrent sign logic for every cell. | ||
==Period Type== | |||
Period Type | |||
Severity: Error | Severity: Error | ||
| Zeile 173: | Zeile 124: | ||
If the period type is not correct and the item is an extension, please change the period type under Taxonomy Extension Properties. | If the period type is not correct and the item is an extension, please change the period type under Taxonomy Extension Properties. | ||
==Insignificant Decimals== | |||
Insignificant Decimals | |||
Severity: Error | Severity: Error | ||
| Zeile 184: | Zeile 132: | ||
Changing the Decimals value to the correct number, in this case 2, helps to get rid of the Warning: | Changing the Decimals value to the correct number, in this case 2, helps to get rid of the Warning: | ||
==There are multiple tables with the element "..." and dimensional information. Dimensional information is only allowed on one layer== | |||
There are multiple tables with the element "..." and dimensional information. Dimensional information is only allowed on one layer | |||
Severity: Error | Severity: Error | ||
| Zeile 195: | Zeile 140: | ||
Make sure that the facts like the Table Name or the decimals set there are the same for all tables. | Make sure that the facts like the Table Name or the decimals set there are the same for all tables. | ||
==There are multiple tables with the same name "..." and distinct tagged table element. This will lead to one role containing multiple tables in the taxonomy== | |||
Severity: Error | Severity: Error | ||
To get rid of this message, you should make sure that the table names in the table setting, for all tables with the same table tag, are the same. Go to one of the tables, click inside it and click on the Table Settings symbol on the left side: | To get rid of this message, you should make sure that the '''table names''' in the table setting, for all tables with the same table tag, are the same. Go to one of the tables, click inside it and click on the Table Settings symbol on the left side: | ||
Make sure that the Table Names set there are the same for all tables. | Make sure that the '''Table Names''' set there are the same for all tables. | ||
==Duplicate Mapping in the TextBlock-Section== | |||
Duplicate Mapping in the TextBlock-Section | |||
Severity: Error | Severity: Error | ||
| Zeile 219: | Zeile 158: | ||
Go to properties, Misc, Continued At [...] in the window select the corresponding continuation. | Go to properties, Misc, Continued At [...] in the window select the corresponding continuation. | ||
Then you can check the order of the continuations with the Continuation Administration | Then you can check the order of the continuations with the [https://hilfe.firesys.de/wiki/Tagging_of_Textblocks_(Notes)_and_Mandatory_Items#Continuation_Administration Continuation Administration] | ||
==The Tagger raises InvalidCalculation issues, even if the values are adding up exactly== | |||
The Tagger raises InvalidCalculation issues, even if the values are adding up exactly | |||
Severity: Warning | Severity: Warning | ||
| Zeile 230: | Zeile 166: | ||
The reason is that the XBRL report will have an accuracy setting. In the example on the left, the values are reported in millions, but with one decimal place. It is required to incease the accurracy of the XBRL facts by setting the decimal attribute to -5 (millions with one decimal place) instead of minus -6 (millions). To change the decimals settings, please open "Document" menu and click on "Settings" and then "Advanced settings" tab. | The reason is that the XBRL report will have an accuracy setting. In the example on the left, the values are reported in millions, but with one decimal place. It is required to incease the accurracy of the XBRL facts by setting the decimal attribute to -5 (millions with one decimal place) instead of minus -6 (millions). To change the decimals settings, please open "Document" menu and click on "Settings" and then "Advanced settings" tab. | ||
==What does the warning message "Reported values for alternative tagging of same economic concept are not equal" mean?== | |||
What does the warning message "Reported values for alternative tagging of same economic concept are not equal" mean? | |||
Severity: Warning | Severity: Warning | ||
The "Reported values for alternative tagging of same economic concept are not equal" warning should be investigated. It is part of the Formula validation of the ESEF/IFRS taxonomy. If it appears you should be able to right click the message, then select “More information” and get a list of the cells involved. As for the meaning of the warning: | The "Reported values for alternative tagging of same economic concept are not equal" warning should be investigated. It is part of the [https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fwww.esma.europa.eu%2Fsites%2Fdefault%2Ffiles%2Flibrary%2Fesef_taxonomy_2022_validation_rules_summary.xlsx&wdOrigin=BROWSELINK Formula validation of the ESEF/IFRS taxonomy]. If it appears you should be able to right click the message, then select “More information” and get a list of the cells involved. As for the meaning of the warning: | ||
This checks if values that are equal in meaning but different in tagging have the same value, e.g. | This checks if values that are equal in meaning but different in tagging have the same value, e.g. | ||
Non-Dimensional Concept: Cash flows from (used in) investing activities, discontinued operations | '''Non-Dimensional Concept''': Cash flows from (used in) investing activities, discontinued operations | ||
Should be equal to | Should be equal to | ||
Concept: Cash flows from (used in) investing activities | '''Concept''': Cash flows from (used in) investing activities | ||
Used with Dimension: Continuing and discontinued operations [axis] and Member: Discontinued operations [member] | '''Used with Dimension''': Continuing and discontinued operations [axis] and '''Member''': Discontinued operations [member] | ||
==What does the warning message "Reported value below zero" mean?== | |||
What does the warning message "Reported value below zero" mean? | |||
Severity: Warning | Severity: Warning | ||
The "Reported values below zero" warning should be investigated. It is part of the Formula validation of the ESEF/IFRS taxonomy. If it appears you should be able to right click the message, then select “More information” and get a list of the cells involved. As for the meaning of the warning: | The "Reported values below zero" warning should be investigated. It is part of the [https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fwww.esma.europa.eu%2Fsites%2Fdefault%2Ffiles%2Flibrary%2Fesef_taxonomy_2022_validation_rules_summary.xlsx&wdOrigin=BROWSELINK Formula validation of the ESEF/IFRS taxonomy]. If it appears you should be able to right click the message, then select “More information” and get a list of the cells involved. As for the meaning of the warning: | ||
By default, the ESEF/IFRS XBRL taxonomy elements are defined in a positive way. For instance, the item "Cost of sales" should be reported as a positive number, even if it is usually reported with a negative sign on the face of the financial statements. Use the Sign-Logic in the XBRL Tagger to invert the sign of negative numbers and subtract it from the totals via the weight attribute of the calculation (e.g. from Revenue). | By default, the ESEF/IFRS XBRL taxonomy elements are defined in a positive way. For instance, the item "Cost of sales" should be reported as a positive number, even if it is usually reported with a negative sign on the face of the financial statements. Use the Sign-Logic in the XBRL Tagger to invert the sign of negative numbers and subtract it from the totals via the weight attribute of the calculation (e.g. from Revenue). | ||
Find more information on reporting of negative numbers, debit/credit attributes and calculations in the IFRS Taxonomy Preparers Guide, Page 46ff. | Find more information on reporting of negative numbers, debit/credit attributes and calculations in the [https://cdn.ifrs.org/content/dam/ifrs/resources-for/preparers/xbrl-using-the-ifrs-taxonomy-a-preparers-guide-january-2019.pdf?la=en IFRS Taxonomy Preparers Guide, Page 46ff]. | ||
==Why do I get an error message (code FormulaAssertion) when submitting my report to the Bundesanzeiger?== | |||
Why do I get an error message (code FormulaAssertion) when submitting my report to the Bundesanzeiger? | |||
This error message means, that there are warnings or errors left that are based on the XBRL Instance Formula 1.0 validation. Please review those messages that are displayed by the XBRL Tagger when generating the XBRL report. If harmless warnings are left, just continue to submit the file. | This error message means, that there are warnings or errors left that are based on the XBRL Instance Formula 1.0 validation. Please review those messages that are displayed by the XBRL Tagger when generating the XBRL report. If harmless warnings are left, just continue to submit the file. | ||
==Why are some calculation inconsistencies WARNINGS while others are ERRORS?== | |||
Why are some calculation inconsistencies WARNINGS while others are ERRORS? | |||
XBRL reports (like ESEF) usually come with an entity specific Calculation Linkbase, that defines how totals in tables are calculated. If calculation inconsistencies are signalled, it means that the calculated value of a total differs from the actual reported value. However, some calculation inconsistencies are often unavoidable: Due to reporting of rounded values (e.g. to millions), small rounding differences are “common practice”. In order to distinguish rounding inconsistencies from real calculation issues (that usually indicate tagging issues), the AMANA XBRL Engine allows to enable a Calculation Linkbase Validation Severity Error Threshold, which must be configured in the XBRL (user based) settings. If the threshold is activated and set to e.g. 1%, it means that the all calculation inconsistencies where the delta is smaller than 1% of the rounded reported value are deemed to be WARNINGS, while all inconsistencies with differences bigger then the threshold are deemed to be ERRORS. If the threshold is not set, all calculation inconsistencies are signalled with a WARNING severity. | XBRL reports (like ESEF) usually come with an entity specific Calculation Linkbase, that defines how totals in tables are calculated. If calculation inconsistencies are signalled, it means that the calculated value of a total differs from the actual reported value. However, some calculation inconsistencies are often unavoidable: Due to reporting of rounded values (e.g. to millions), small rounding differences are “common practice”. In order to distinguish rounding inconsistencies from real calculation issues (that usually indicate tagging issues), the AMANA XBRL Engine allows to enable a Calculation Linkbase Validation Severity Error Threshold, which must be configured in the XBRL (user based) settings. If the threshold is activated and set to e.g. 1%, it means that the all calculation inconsistencies where the delta is smaller than 1% of the rounded reported value are deemed to be WARNINGS, while all inconsistencies with differences bigger then the threshold are deemed to be ERRORS. If the threshold is not set, all calculation inconsistencies are signalled with a WARNING severity. | ||
Further reading: | Further reading: https://www.xbrl.org/esef-errors-and-common-pitfalls-8-rounding-and-calculations/ | ||
https://www.xbrl.org/esef-errors-and-common-pitfalls-8-rounding-and-calculations/ | |||
To activate this threshold you have to click on Settings>XBRL Processor Settings. | To activate this threshold you have to click on Settings>XBRL Processor Settings. | ||
| Zeile 292: | Zeile 214: | ||
This will no longer appear when using Calculation 1.1. | This will no longer appear when using Calculation 1.1. | ||
==Why are the following messages displayed? "This Word document contains embedded charts." / "The Word document has shapes/images as embedded Office objects."== | |||
Why are the following messages displayed? "This Word document contains embedded charts." / "The Word document has shapes/images as embedded Office objects." | |||
The messages are displayed, because XHTML supports only .png and .jpg for charts, shapes, images. Oher formats will not be converted to XHTML. | The messages are displayed, because XHTML supports only .png and .jpg for charts, shapes, images. Oher formats will not be converted to XHTML. | ||
* you can either manually convert all charts, shapes, images to .png/.jpg | |||
* or run the script provided here: https://amana.atlassian.net/wiki/spaces/SND/pages/6228309 (issues with svg are possible) | |||
==After generating iXBRL, the error message "No linkRole found for filter" is displayed== | |||
After generating iXBRL, the error message "No linkRole found for filter" is displayed | |||
Two or more versions of the same taxonomy are loaded. | Two or more versions of the same taxonomy are loaded. | ||
How to remove the additional taxonomies: | '''How to remove the additional taxonomies''': | ||
# Select "XBRL" > "Manage Additional Taxonomies". | |||
# Click on the red X next to all additional versions of the currently used taxonomy to remove them. The currently used taxonomy can be found in the bottom left corner next to the status icon. | |||
# Save document (via "File" > "Save", CTRL+S or the Disc Symbol). | |||
# Reload document (via "File" > "Open", CTRL+O or the Folder Icon). | |||
'''How to switch to a newer version of a taxonomy''': | |||
# Select "XBRL" > "Open/Load Taxonomy". | |||
# Select the desired taxonomy and version and click "Load". | |||
==After generating iXBRL, the error message "Unable to find XHTML_td cell for mapping ifrs-full:..." is displayed== | |||
This error appears because you have '''two tables''' with '''the same id''' in the table properties. | |||
# Open the document in Word | |||
# Identifiy the tables, | |||
# Right click on the second table | |||
# Removed duplicate id in the description of the second table | |||
# Load the document again into the Tagger | |||
==Cannot create grouping for "ifrs-full....", loop detected. Ignoring group== | |||
Cannot create grouping for "ifrs-full....", loop detected. Ignoring group | |||
This warning appears because the hierarchy in a table is not correct. You have to make sure that you select the correct abstract in the table. | This warning appears because the hierarchy in a table is not correct. You have to make sure that you select the correct abstract in the table. | ||
| Zeile 356: | Zeile 257: | ||
If your report looks like this, you will receive an error message. | If your report looks like this, you will receive an error message. | ||
==After creating the ESEF report, the numbering in the xHTML file is different from the original Word file== | |||
After creating the ESEF report, the numbering in the xHTML file is different from the original Word file | |||
This issue can be fixed by running the '''ListToText.vba''' script from our page. | |||
==After generating iXBRL, the Warning message " Document contains private characters ... " is displayed== | |||
After generating iXBRL, the Warning message " Document contains private characters ... " is displayed | |||
The private characters are widely used by designers to align elements properly and some fonts are mapped only to private Unicode characters. | The private characters are widely used by designers to align elements properly and some fonts are mapped only to private Unicode characters. | ||
| Zeile 378: | Zeile 271: | ||
The users may decide to check with their auditors, before submission, whether they should remove them or not. | The users may decide to check with their auditors, before submission, whether they should remove them or not. | ||
==The rounded value doesn't match the calculated value== | |||
The rounded value doesn't match the calculated value | |||
This Validation only appears when using Calculation 1.0. Have a look at this section of our documentation to set up Calculation 1.1. | This Validation only appears when using Calculation 1.0. Have a look at this section of our documentation to set up Calculation 1.1. https://hilfe.firesys.de/wiki/Tagger_Settings#Validation_Settings | ||
Any calculation that you make in the report will be validated when creating the final report. Calculation validation errors are traditionally just a warning, because rounding errors are very common. | Any calculation that you make in the report will be validated when creating the final report. Calculation validation errors are traditionally just a warning, because rounding errors are very common. | ||
| Zeile 391: | Zeile 281: | ||
To support this, the Tagger has a feature to make the user aware of issues that might not be just rounding errors: | To support this, the Tagger has a feature to make the user aware of issues that might not be just rounding errors: | ||
Sometimes the actual delta between the calculated value and the tagged value is so too big to be a rounding error, so it would make more sense to be an error than a warning. This behavior can now be changed in the XBRL Processor settings: | Sometimes the actual delta between the calculated value and the tagged value is so too big to be a rounding error, so it would make more sense to be an '''error than a warning'''. This behavior can now be changed in the XBRL Processor settings: | ||
You can enable or disable this functionality and also set the threshold for when a calculation warning should become an error. | You can enable or disable this functionality and also set the threshold for when a calculation warning should become an error. | ||
| Zeile 397: | Zeile 287: | ||
A valid report can be filed with these validation results present. | A valid report can be filed with these validation results present. | ||
==Guidance 1.3.3 / RTS Annex II.2: Unreported mandatory mark-ups== | |||
Guidance 1.3.3 / RTS Annex II.2: Unreported mandatory mark-ups | |||
“Annex II, paragraph 3 of the RTS on ESEF sets out the so called “block tagging” requirement, whereby issuers shall mark up all disclosures that correspond to the elements in Table 2 of Annex II if those disclosures are present in the issuer’s financial statement.” | “Annex II, paragraph 3 of the RTS on ESEF sets out the so called “block tagging” requirement, whereby issuers shall mark up all disclosures that correspond to the elements in Table 2 of Annex II if those disclosures are present in the issuer’s financial statement.” | ||
"Issuers shall mark up all disclosures made in IFRS consolidated financial statements.” | "Issuers shall mark up '''all disclosures made''' in IFRS consolidated financial statements.” | ||
There is a disconnect between the wording in the Guidance and the RTS and the recommended technical validation rules. Mark-up's in a report only have to be tagged if those are present in the report. There is no need to create hidden values for those tags or specifically add them to the report just for this purpose. | There is a disconnect between the wording in the Guidance and the RTS and the recommended technical validation rules. Mark-up's in a report only have to be tagged '''if those are present in the report'''. There is no need to create hidden values for those tags or specifically add them to the report just for this purpose. | ||
The auditors recent opinion about this rule is that “In order to avoid the technical validation error, the best practice is to create the tag and incorporate "Not Applicable" if the information is not applicable.” , which in our opinion is not correct. | The auditors recent opinion about this rule is that “In order to avoid the technical validation error, the best practice is to create the tag and incorporate "Not Applicable" if the information is not applicable.” , which in our opinion is not correct. | ||
| Zeile 412: | Zeile 299: | ||
As mentioned above, this is only a Warning. If your report does not contain the information in question, it can be ignored. | As mentioned above, this is only a Warning. If your report does not contain the information in question, it can be ignored. | ||
==Guidance 2.4.1: Hidden facts and "Eligible for transformation"== | |||
Guidance 2.4.1: Hidden facts and "Eligible for transformation" | |||
"Moreover, ESMA is of the opinion that for the ESEF reporting scenario the only relevant use case for inclusion of Inline XBRL constructs in the ix:hidden section (i.e. where content is not intended for display) is for facts that are not eligible for transformation (i.e. there is no transformation rule for a given format in the latest recommended Transformation Rules Registry; e.g. enumeration(Set)ItemType15 or durationItemType). | "Moreover, ESMA is of the opinion that for the ESEF reporting scenario the only relevant use case for inclusion of Inline XBRL constructs in the ix:hidden section (i.e. where content is not intended for display) is for facts that are '''not eligible for transformation''' (i.e. there is no transformation rule for a given format in the latest recommended Transformation Rules Registry; e.g. enumeration(Set)ItemType15 or durationItemType). | ||
In such case, the visible text in the report corresponding to the hidden fact shall have applied a custom style property “-esef-ix-hidden” which value follows the id attribute of that fact. Unlike other style properties, the value of ‘-esef-ix-hidden’ is not inherited." | In such case, the visible text in the report corresponding to the hidden fact shall have applied a custom style property “-esef-ix-hidden” which value follows the id attribute of that fact. Unlike other style properties, the value of ‘-esef-ix-hidden’ is not inherited." | ||
Properly designed iXBRL reports are becoming increasingly popular, especially for ESEF. If the XBRL Tagger is used to convert PDF files to XHTML, then in some cases "hidden" facts have to be used to make the typeface and layout match the PDF 1:1. | Properly designed iXBRL reports are becoming increasingly popular, especially for ESEF. If the XBRL Tagger is used to convert PDF files to XHTML, then in some cases "hidden" facts have to be used to make the typeface and layout match the PDF 1:1. | ||
Specifically, the problem relates to the transformation of Facts, as you can see in the following code snippet of a XHTML report with a number that needs to be tagged with a numeric tag (nonFraction) (in a web browser, it would simply display as a table cell with €2,451): | Specifically, the problem relates to the transformation of Facts, as you can see in the following code snippet of a XHTML report with a number that needs to be tagged with a numeric tag (nonFraction) (in a web browser, it would simply display as a table cell with €2,451): | ||
The span tags are usually used to format the value with proper spacing, but in some cases they are also important for the layout of larger sections of the report. Simply removing the spacing would "destroy" the layout. For non-numerics, the XBRL specification provides a solution: the contents of a multiply-assigned tag can be associated with a continueAt as specified in the XBRL specification. However, for nonFraction elements, this is not currently allowed in the specification. The problem is known to XBRL International and can be fixed in the long term with an adjustment to the XBRL specification. | The span tags are usually used to format the value with proper spacing, but in some cases they are also important for the layout of larger sections of the report. Simply removing the spacing would "destroy" the layout. For non-numerics, the XBRL specification provides a solution: the contents of a multiply-assigned tag can be associated with a continueAt as specified in the XBRL specification. However, for nonFraction elements, this is not currently allowed in the specification. The problem is known to XBRL International and can be fixed in the long term with an adjustment to the XBRL specification. | ||
But for now this case is clearly NOT “eligible for transformation” and thus these items should be allowed to be added to the hidden section of an iXBRL report. | But for now this case is clearly '''NOT''' “eligible for transformation” and thus these items should be allowed to be added to the hidden section of an iXBRL report. | ||
To get the layout of reports correct in these cases it is inevitable to "merge" the affected number, as in the following example. | To get the layout of reports correct in these cases it is inevitable to "merge" the affected number, as in the following example. | ||
"Hidden": Non-transformable values are added to the ix:hidden section of the report, as described in the ESEF Guidance in Section 2.4.1: | "Hidden": Non-transformable values are added to the ix:hidden section of the report, as described in the ESEF Guidance in Section 2.4.1: | ||
Some validators, for example Arelle, do have a different approach to this validation and show an error in technically valid reports. This is due to the fact that ESMA has not clearly specified what is eligible for transformation. | Some validators, for example Arelle, do have a different approach to this validation and show an error in technically valid reports. This is due to the fact that ESMA has not clearly specified what is '''eligible for transformation'''. | ||
We belive that using Inline XBRL 1.1, the official Inline XBRL Hidden mechanism, is the only valid way to tag those numbers. You can click here to find information on how to avoid hidden facts. | We belive that using Inline XBRL 1.1, the official Inline XBRL Hidden mechanism, is the only valid way to tag those numbers. You can click here to find information on how to avoid hidden facts. | ||
==Guidance 2.5.2: Indication of the language used in textual mark ups== | |||
Guidance 2.5.2: Indication of the language used in textual mark ups | |||
You get this message if the language selected in the document settings is not the same through the whole report. | You get this message if the language selected in the document settings is not the same through the whole report. | ||
For example, pay attention that the language of the report stays by "German" and not "German (Germany)" | For example, pay attention that the language of the report stays by "'''German'''" and not "'''German (Germany)'''" | ||
==Guidance 2.7.1: Ensuring report validity== | |||
Guidance 2.7.1: Ensuring report validity | |||
This validation comes in two severities: Warning and Error. This is an additional validation result that appears as soon as the report has any other warning or error respectively. | This validation comes in two severities: Warning and Error. This is an '''additional''' validation result that appears as soon as the report has '''any other''' warning or error respectively. | ||
==Guidance 3.4.2: ESEF Role 99999== | |||
Guidance 3.4.2: ESEF Role 99999 | |||
We do recommend to ignore this validation result for now. | We do recommend to ignore this validation result for now. | ||
| Zeile 467: | Zeile 340: | ||
This is also what the reporting manual states: | This is also what the reporting manual states: | ||
Furthermore, each line item used in the report to tag data should be valid according to at least one hypercube in the extension taxonomy’s definition linkbase. | Furthermore, each line item used in the report to tag data should be valid according to '''at least one hypercube''' in the extension taxonomy’s definition linkbase. | ||
Unfortunately this is not what the ESMA conformance suite is validating in its current form. | Unfortunately this is not what the ESMA conformance suite is validating in its current form. | ||
==Guidance 3.4.5: Use of labels on elements in extension taxonomies== | |||
Guidance 3.4.5: Use of labels on elements in extension taxonomies | |||
The Validation Rule will appear, when your report language and the language of an Extension Tag are different. | The Validation Rule will appear, when your report language and the language of an Extension Tag are different. | ||
| Zeile 480: | Zeile 350: | ||
If your label for the additional culture of your tag is German you should make sure, that your report language is German as well. | If your label for the additional culture of your tag is German you should make sure, that your report language is German as well. | ||
We also recommend to use the Label Handling Option Extension Labels Only or Verbose. | We also recommend to use the Label Handling Option '''Extension Labels Only''' or '''Verbose'''. | ||
==Guidance 3.4.6: Restriction of Taxonomy Relationships== | |||
Guidance 3.4.6: Restriction of Taxonomy Relationships | |||
This Validation Rule will show up, when you used a monetary or a perShare item from the TextBlock-Section. This tags have to be tagged the same way you would tag a Parenthetical. | This Validation Rule will show up, when you used a monetary or a perShare item from the TextBlock-Section. This tags have to be tagged the same way you would tag a [https://hilfe.firesys.de/wiki/Tagging_as_Parentheticals_/_Values_in_Footnotes Parenthetical]. | ||
For the example above you can use any abstract element, for example the Notes, accounting policies and mandatory tags Tag, and solve the issue. | For the example above you can use any abstract element, for example the Notes, accounting policies and mandatory tags Tag, and solve the issue. | ||
If your document is a word document please perform the Parenthetical procedure in the Tagger and not in Word. To do this open your document in the Tagger. Select the element in the taxonomy for example "NotesAccountingPoliciesAndMandatoryTags" and "drag and drop" it into the tag "DividendsRecognisedAsDistributionsToOwnersPerShares”. This solves the error! don't forget to save the changes you have made. | If your document is a '''word document''' please perform the '''Parenthetical''' procedure in the Tagger and '''not in Word'''. To do this open your document in the Tagger. Select the element in the taxonomy for example "NotesAccountingPoliciesAndMandatoryTags" and "'''drag and drop'''" it into the tag "DividendsRecognisedAsDistributionsToOwnersPerShares”. This solves the error! don't forget to save the changes you have made. | ||
==Guidance 3.1.1: Required components of extension taxonomies== | |||
Guidance 3.1.1: Required components of extension taxonomies | |||
This validation rule will show up when some structures are missing. | This validation rule will show up when some structures are missing. | ||
| Zeile 502: | Zeile 366: | ||
To resolve this error, ensure the file contains: | To resolve this error, ensure the file contains: | ||
* At least one calculation; | |||
* A presentation linkbase; | |||
* A definition linkbase. | |||
== Siehe auch == | == Siehe auch == | ||
Version vom 27. September 2023, 15:16 Uhr
When generating an XBRL report, the error "Your report is not valid..." is displayed
This message is displayed if the report is missing some mandatory mappings or has mapping inconsistencies (to be seen Status button in the left bottom corner). Please correct all errors (those having the red X before the message) and then generate iXBRL. However, it is possible to generate an XBRL file - but generation may fail with errors.
When validating the document, the warning "Please set the XBRL Identifier in the Report Settings" is displayed
Severity: Warning, but Error in Production.
A valid ESEF document needs the proper LEI of the filer: www.gleif.org
Please go to Document → Settings, then enter the LEI under "Reporting Entity Identifier (e.g. LEI)"
When validating with the Tagger, the error "Table element ... has no table element mapped" is displayed
Severity: Error
It is necessary to tag an abstract element to the table. Every tagged table needs an abstract element from the basic taxonomy. This can be added by drag & drop from the right hand side taxonomy to the Table Tag above the table.
When validating the document, the warnings "Status …" are displayed:
Severity: Warning
Check the affected cells and set the status to final:
When validating the document, the warnings "Table x has x cell(s) without a mapping" is displayed
Severity: Warning
A cell in a table with table tag has no mapping. All cells in the PFS (Primary Financial Statements) need to be tagged!
When validating the document, the warning "Cell is not taking part in calculation relationship" is displayed
Severity: Warning
All tagged cells in the PFS need to be part of a calculation relationship, except where it is not technically possible (e.g. Statement of changes in Equity, calculations like beginning balance +/- changes = ending balance, because this can't be modelled in XBRL taxonomies yet).
When validating with the Tagger, the error "Duplicate mapping detected ..." is displayed
Severity: Error
Tags can only appear twice in a document if the context (e.g the date) is different or the value is equal.
Click on the error message to jump to the relevant table, where the error occurred. Several cells belonging to the same table are tagged to the same taxonomy element, but with different values (inconsistency). This might also happen when the Tagger is unable to identify the correct reporting date for a column. Please, make sure that the reporting date for any tagged cell is correct by checking the Table Cell Properties of a selected range of cells:
When validating the document, the error "Extension element for cell x in table x has no anchors" is displayed
Severity: Error
Every extension needs to have at least one anchor, unless it is the total of a calculation relationship.
When validating the document, the error "The value ... is not valid for the format ..." is displayed.
Severity: Error
The selected Number or Date Format cannot be applied to the value of the tag. Go to the affected tag → Properties → select a different format.
When generating an XBRL report, the error "Element with name ... not found in Taxonomy" is displayed
Severity: Error
The tagged element was not found in the taxonomy. Please check if you have a different version of the taxonomy, which does not contain the tagged element.
When validating with the Tagger, the error "Line item missing in table..." is displayed
Severity: Error
This error message is displayed if a dimension element is tagged (member), but there is no corresponding line item tagged.
To solve this issue, erase the tag for the dimension element (member), tag the line item, finally re-tag the dimension element.
When validating the document, the error "Dimensionally invalid" is displayed
Severity: Error
Each mapping in a table has to contain the same dimensions. You can get this error either by tagging tables or textblocks (narrative disclosure). For example, if you tag an element that is supposed to be part of a table (as per the taxonomy) in the textblock section or you tag an element that is supposed be part of a textblock (as per the taxonomy) in a table.
You can fix this error by performing a (a.) Parenthetical or (b.) by erasing the element in the wrong section and place it in the correct one.
a. Performing a Parenthetical
You can use any abstract element from the taxonomy, for example the Notes, accounting policies and mandatory tags Tag for the textblock section or the Profit or loss placeholder for the table section, to solve the issue.
If your document is a Word document, please perform the Parenthetical procedure in the Tagger and not in Word. To do this open your document in the Tagger. Select the element in the taxonomy, for example "NotesAccountingPoliciesAndMandatoryTags" and "drag and drop" it into the tag, for example "DividendsRecognisedAsDistributionsToOwnersPerShares”. This solves the error! Don't forget to save the changes you have made.
You should perform this procedure for all the elements of the taxonomy that are not of the "TextBlock" type, for example they are "Monatary" or "perShare", but should be in the TextBlock section nonetheless.
b. Erasing the element in the wrong section and place it in the correct one.
In the example below you can see that the element (in red) selected from the taxonomy belongs to a table (roll 220000) and not to the textblock section (in green). Delete the selected tag and place the correct one from the textblock section (roll 110000).
When validating the document, the error "The selected format x is incompatible with ..." is displayed
Severity: Error
A wrong base format has been applied, e.g. a date format for a monetary value. Please check the tag and fix accordingly.
Duplicate Label
Severity: Error
A duplicate label warning or error is displayed on cells with equal tag combinations but with different names (labels). For instance, "ifrs-full:Equity" might be tagged in the balance sheet as "Total Equity", as well as in the Statement of changes in Equity with the label "Equity at 01.01.2019" and "Equity at 31.12.2019". In this case, three different labels are provided for the same tag. In order to differentiate the meaning of the different labels, its required to set its so called label role. The most common label roles are (samples in brakets):
- Standard label (Equity)
- Total label (Total Equity)
- Period start / Period end label (Equity at beginning/ending of period)
- Verbose label (Equity, as determined by nature)
It is important to align all labels used across the report for all values, that are tagged to the same element. Only one label per role is allowed. This also usually means to remove date references from the period start and end label, "Equity at the end of period" instead of "Equity at 31.12.2019", because two period end labels (31.12.2019 and 31.12.2020 ) are not possible.
Change preferred label roles and labels under Table Cell Properties:
Duplicate Extension
Severity: Error
A duplicate extension error is displayed, when the cells with extensions have different properties: e.g. different anchors in the current an previous year; diffrent sign logic for every cell.
Period Type
Severity: Error
The period type of the ifrs-full elements is defined in the taxonomy. Items with different period types cannot be included in one calculation:
If the period type is not correct and the item is an extension, please change the period type under Taxonomy Extension Properties.
Insignificant Decimals
Severity: Error
An "Insignificant Decimals" Warning is displayed, when the decimal value of the tagged value does not match the decimal value in the properties of the selected cell:
Changing the Decimals value to the correct number, in this case 2, helps to get rid of the Warning:
There are multiple tables with the element "..." and dimensional information. Dimensional information is only allowed on one layer
Severity: Error
To get rid of this error message, you should make sure, that the table setting for all tables with the same table tag are the same. Go to one of the tables, click inside it and click on the Table Settings symbol on the left side:
Make sure that the facts like the Table Name or the decimals set there are the same for all tables.
There are multiple tables with the same name "..." and distinct tagged table element. This will lead to one role containing multiple tables in the taxonomy
Severity: Error
To get rid of this message, you should make sure that the table names in the table setting, for all tables with the same table tag, are the same. Go to one of the tables, click inside it and click on the Table Settings symbol on the left side:
Make sure that the Table Names set there are the same for all tables.
Duplicate Mapping in the TextBlock-Section
Severity: Error
If you have a duplicate in the text block section that means that you have tagged in another part of the report one or more times the same taxonomy element.
To resolve this error you must manually put a continuation:
Go to properties, Misc, Continued At [...] in the window select the corresponding continuation.
Then you can check the order of the continuations with the Continuation Administration
The Tagger raises InvalidCalculation issues, even if the values are adding up exactly
Severity: Warning
The reason is that the XBRL report will have an accuracy setting. In the example on the left, the values are reported in millions, but with one decimal place. It is required to incease the accurracy of the XBRL facts by setting the decimal attribute to -5 (millions with one decimal place) instead of minus -6 (millions). To change the decimals settings, please open "Document" menu and click on "Settings" and then "Advanced settings" tab.
What does the warning message "Reported values for alternative tagging of same economic concept are not equal" mean?
Severity: Warning
The "Reported values for alternative tagging of same economic concept are not equal" warning should be investigated. It is part of the Formula validation of the ESEF/IFRS taxonomy. If it appears you should be able to right click the message, then select “More information” and get a list of the cells involved. As for the meaning of the warning:
This checks if values that are equal in meaning but different in tagging have the same value, e.g.
Non-Dimensional Concept: Cash flows from (used in) investing activities, discontinued operations
Should be equal to
Concept: Cash flows from (used in) investing activities
Used with Dimension: Continuing and discontinued operations [axis] and Member: Discontinued operations [member]
What does the warning message "Reported value below zero" mean?
Severity: Warning
The "Reported values below zero" warning should be investigated. It is part of the Formula validation of the ESEF/IFRS taxonomy. If it appears you should be able to right click the message, then select “More information” and get a list of the cells involved. As for the meaning of the warning:
By default, the ESEF/IFRS XBRL taxonomy elements are defined in a positive way. For instance, the item "Cost of sales" should be reported as a positive number, even if it is usually reported with a negative sign on the face of the financial statements. Use the Sign-Logic in the XBRL Tagger to invert the sign of negative numbers and subtract it from the totals via the weight attribute of the calculation (e.g. from Revenue).
Find more information on reporting of negative numbers, debit/credit attributes and calculations in the IFRS Taxonomy Preparers Guide, Page 46ff.
Why do I get an error message (code FormulaAssertion) when submitting my report to the Bundesanzeiger?
This error message means, that there are warnings or errors left that are based on the XBRL Instance Formula 1.0 validation. Please review those messages that are displayed by the XBRL Tagger when generating the XBRL report. If harmless warnings are left, just continue to submit the file.
Why are some calculation inconsistencies WARNINGS while others are ERRORS?
XBRL reports (like ESEF) usually come with an entity specific Calculation Linkbase, that defines how totals in tables are calculated. If calculation inconsistencies are signalled, it means that the calculated value of a total differs from the actual reported value. However, some calculation inconsistencies are often unavoidable: Due to reporting of rounded values (e.g. to millions), small rounding differences are “common practice”. In order to distinguish rounding inconsistencies from real calculation issues (that usually indicate tagging issues), the AMANA XBRL Engine allows to enable a Calculation Linkbase Validation Severity Error Threshold, which must be configured in the XBRL (user based) settings. If the threshold is activated and set to e.g. 1%, it means that the all calculation inconsistencies where the delta is smaller than 1% of the rounded reported value are deemed to be WARNINGS, while all inconsistencies with differences bigger then the threshold are deemed to be ERRORS. If the threshold is not set, all calculation inconsistencies are signalled with a WARNING severity.
Further reading: https://www.xbrl.org/esef-errors-and-common-pitfalls-8-rounding-and-calculations/
To activate this threshold you have to click on Settings>XBRL Processor Settings.
In the window you can mark the first option.
if "Disable" is selected, all calculation messages are disabled
if "Enable" is selected and the threshold is not activated, all calculation messages are displayed as warnings
if "Auto" is selected, the messages are not displayed if EBA or EIOPA reports are created
This will no longer appear when using Calculation 1.1.
Why are the following messages displayed? "This Word document contains embedded charts." / "The Word document has shapes/images as embedded Office objects."
The messages are displayed, because XHTML supports only .png and .jpg for charts, shapes, images. Oher formats will not be converted to XHTML.
- you can either manually convert all charts, shapes, images to .png/.jpg
- or run the script provided here: https://amana.atlassian.net/wiki/spaces/SND/pages/6228309 (issues with svg are possible)
After generating iXBRL, the error message "No linkRole found for filter" is displayed
Two or more versions of the same taxonomy are loaded.
How to remove the additional taxonomies:
- Select "XBRL" > "Manage Additional Taxonomies".
- Click on the red X next to all additional versions of the currently used taxonomy to remove them. The currently used taxonomy can be found in the bottom left corner next to the status icon.
- Save document (via "File" > "Save", CTRL+S or the Disc Symbol).
- Reload document (via "File" > "Open", CTRL+O or the Folder Icon).
How to switch to a newer version of a taxonomy:
- Select "XBRL" > "Open/Load Taxonomy".
- Select the desired taxonomy and version and click "Load".
After generating iXBRL, the error message "Unable to find XHTML_td cell for mapping ifrs-full:..." is displayed
This error appears because you have two tables with the same id in the table properties.
- Open the document in Word
- Identifiy the tables,
- Right click on the second table
- Removed duplicate id in the description of the second table
- Load the document again into the Tagger
Cannot create grouping for "ifrs-full....", loop detected. Ignoring group
This warning appears because the hierarchy in a table is not correct. You have to make sure that you select the correct abstract in the table.
For example:
In addition, make sure you are not using the same abstract twice in the same table:
If your report looks like this, you will receive an error message.
After creating the ESEF report, the numbering in the xHTML file is different from the original Word file
This issue can be fixed by running the ListToText.vba script from our page.
After generating iXBRL, the Warning message " Document contains private characters ... " is displayed
The private characters are widely used by designers to align elements properly and some fonts are mapped only to private Unicode characters.
The creator/designer of the document knows where these characters are located.
Furthermore, they do not represent a problem in most, almost all, cases. The warning is displayed because, in rare cases, auditors may flag this as a warning as well, but not as an error, since these private characters could sometimes impair usability of documents, e.g. blocking search or translation functionality.
The users may decide to check with their auditors, before submission, whether they should remove them or not.
The rounded value doesn't match the calculated value
This Validation only appears when using Calculation 1.0. Have a look at this section of our documentation to set up Calculation 1.1. https://hilfe.firesys.de/wiki/Tagger_Settings#Validation_Settings
Any calculation that you make in the report will be validated when creating the final report. Calculation validation errors are traditionally just a warning, because rounding errors are very common.
Still every occurrence of this validation result should be checked, if this really is just a rounding issue or something might have been tagged wrong.
To support this, the Tagger has a feature to make the user aware of issues that might not be just rounding errors:
Sometimes the actual delta between the calculated value and the tagged value is so too big to be a rounding error, so it would make more sense to be an error than a warning. This behavior can now be changed in the XBRL Processor settings:
You can enable or disable this functionality and also set the threshold for when a calculation warning should become an error.
A valid report can be filed with these validation results present.
Guidance 1.3.3 / RTS Annex II.2: Unreported mandatory mark-ups
“Annex II, paragraph 3 of the RTS on ESEF sets out the so called “block tagging” requirement, whereby issuers shall mark up all disclosures that correspond to the elements in Table 2 of Annex II if those disclosures are present in the issuer’s financial statement.”
"Issuers shall mark up all disclosures made in IFRS consolidated financial statements.”
There is a disconnect between the wording in the Guidance and the RTS and the recommended technical validation rules. Mark-up's in a report only have to be tagged if those are present in the report. There is no need to create hidden values for those tags or specifically add them to the report just for this purpose.
The auditors recent opinion about this rule is that “In order to avoid the technical validation error, the best practice is to create the tag and incorporate "Not Applicable" if the information is not applicable.” , which in our opinion is not correct.
As mentioned above, this is only a Warning. If your report does not contain the information in question, it can be ignored.
Guidance 2.4.1: Hidden facts and "Eligible for transformation"
"Moreover, ESMA is of the opinion that for the ESEF reporting scenario the only relevant use case for inclusion of Inline XBRL constructs in the ix:hidden section (i.e. where content is not intended for display) is for facts that are not eligible for transformation (i.e. there is no transformation rule for a given format in the latest recommended Transformation Rules Registry; e.g. enumeration(Set)ItemType15 or durationItemType). In such case, the visible text in the report corresponding to the hidden fact shall have applied a custom style property “-esef-ix-hidden” which value follows the id attribute of that fact. Unlike other style properties, the value of ‘-esef-ix-hidden’ is not inherited."
Properly designed iXBRL reports are becoming increasingly popular, especially for ESEF. If the XBRL Tagger is used to convert PDF files to XHTML, then in some cases "hidden" facts have to be used to make the typeface and layout match the PDF 1:1. Specifically, the problem relates to the transformation of Facts, as you can see in the following code snippet of a XHTML report with a number that needs to be tagged with a numeric tag (nonFraction) (in a web browser, it would simply display as a table cell with €2,451):
The span tags are usually used to format the value with proper spacing, but in some cases they are also important for the layout of larger sections of the report. Simply removing the spacing would "destroy" the layout. For non-numerics, the XBRL specification provides a solution: the contents of a multiply-assigned tag can be associated with a continueAt as specified in the XBRL specification. However, for nonFraction elements, this is not currently allowed in the specification. The problem is known to XBRL International and can be fixed in the long term with an adjustment to the XBRL specification.
But for now this case is clearly NOT “eligible for transformation” and thus these items should be allowed to be added to the hidden section of an iXBRL report.
To get the layout of reports correct in these cases it is inevitable to "merge" the affected number, as in the following example.
"Hidden": Non-transformable values are added to the ix:hidden section of the report, as described in the ESEF Guidance in Section 2.4.1:
Some validators, for example Arelle, do have a different approach to this validation and show an error in technically valid reports. This is due to the fact that ESMA has not clearly specified what is eligible for transformation.
We belive that using Inline XBRL 1.1, the official Inline XBRL Hidden mechanism, is the only valid way to tag those numbers. You can click here to find information on how to avoid hidden facts.
Guidance 2.5.2: Indication of the language used in textual mark ups
You get this message if the language selected in the document settings is not the same through the whole report.
For example, pay attention that the language of the report stays by "German" and not "German (Germany)"
Guidance 2.7.1: Ensuring report validity
This validation comes in two severities: Warning and Error. This is an additional validation result that appears as soon as the report has any other warning or error respectively.
Guidance 3.4.2: ESEF Role 99999
We do recommend to ignore this validation result for now.
"Line items that do not require any dimensional information to tag data MUST be linked to the dedicated “Line items not dimensionally qualified” hypercube in http://www.esma.europa.eu/xbrl/role/cor/esef_role-99999 declared in esef_cor.xsd."
The Tagger does take care of that, but on some occasions, confusion is added by validation tools that have a warning when there is no need for line items belonging to for example the statement of changes in equity to be in the 99999 table. Adding elements regardless does not decrease the quality of the taxonomy, the warning on the other hand creates a lot of uncertainty.
Furthermore, ensuring dimensional validity of items is already part of the XBRL specification and thus validated in any case. Hypercubes are “or” conditions for fact validity, so a line item can be a member of the 99999 hypercube as well as a member of an additional dimensionally qualified hypercube/table.
This is also what the reporting manual states: Furthermore, each line item used in the report to tag data should be valid according to at least one hypercube in the extension taxonomy’s definition linkbase.
Unfortunately this is not what the ESMA conformance suite is validating in its current form.
Guidance 3.4.5: Use of labels on elements in extension taxonomies
The Validation Rule will appear, when your report language and the language of an Extension Tag are different.
If your label for the additional culture of your tag is German you should make sure, that your report language is German as well.
We also recommend to use the Label Handling Option Extension Labels Only or Verbose.
Guidance 3.4.6: Restriction of Taxonomy Relationships
This Validation Rule will show up, when you used a monetary or a perShare item from the TextBlock-Section. This tags have to be tagged the same way you would tag a Parenthetical.
For the example above you can use any abstract element, for example the Notes, accounting policies and mandatory tags Tag, and solve the issue.
If your document is a word document please perform the Parenthetical procedure in the Tagger and not in Word. To do this open your document in the Tagger. Select the element in the taxonomy for example "NotesAccountingPoliciesAndMandatoryTags" and "drag and drop" it into the tag "DividendsRecognisedAsDistributionsToOwnersPerShares”. This solves the error! don't forget to save the changes you have made.
Guidance 3.1.1: Required components of extension taxonomies
This validation rule will show up when some structures are missing.
To resolve this error, ensure the file contains:
- At least one calculation;
- A presentation linkbase;
- A definition linkbase.
Siehe auch
FAQs, Validation Messages and Other Known Issues
Weitere Inhalte
→ Webseite
→ Kundenbereich
→ YouTube