Validation Messages
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 toolsxbrl, 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
_without_a_mapping_is_displayed1.png){kind=small}
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 toolsxbrl, 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 toolsxbrl 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 toolsxbrl, 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 toolsxbrl and not in Word. To do this open your document in toolsxbrl. 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 it's so-called Label Role. The most common Label Roles are (samples in brakets):
- Standard Label (Equity)
- Total Label (Total Equity)
- PeriodStart / PeriodEnd 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
toolsxbrl 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 toolsxbrl 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?
_when_submitting_my_report_to_the_Bundesanzeiger1.png)
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 toolsxbrl when generating the XBRL report. If harmless warnings are left, just continue to submit the file.
_when_submitting_my_report_to_the_Bundesanzeiger2.png)
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
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.
1. Open the document in Word 2. Identifiy the tables, 3. Right click on the second table
4. Removed duplicate id in the description of the second table
5. Load the document again into toolsxbrl
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 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/Toolsxbrl_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, toolsxbrl 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 toolsxbrl 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."
toolsxbrl 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 toolsxbrl and not in Word. To do this open your document in toolsxbrl. 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.
After generating iXBRL, the Error message " The calculationArc connect two non-numeric concepts " is displayed.
This error will show up if a calculation has both a numeric tag and textblock or text string part of the same calculation.
To resolve this error:
- View the calculation linkbase in the validation results excel sheet or in the tagger XBRL preview.
- Check and ensure that summands in the calculations do not have both non-numeric and numeric concepts as part of the same calculation.
When loading a source document I get a message saying, that “An error occured. The validation exception limit of 1000 is reached...”.
Source documents with this number of errors should be checked, so you can use a document which suits the technical requirements better.
However, if you want to continue with the document you can raise the number of validation exception to a bigger number like 100000.
Please note, that this should only be done in rare cases and checking the source document is recommended.
My auditor/regulator says that the json-file in the META-INF folder of my ESEF package causes problems. (Guidance 2.6.1)
According to the latest report package specification, the new .xbri packages have to include json files to define its type. It is optinal but recommened for .zip packages:
You can check out the specification here.
The ESEF Reporting Manual references to this specification in Guidance 2.6.1:
Siehe auch
FAQs, Validation Messages and Other Known Issues
Technical Issues
Tagging and Report Generation Issues
FAQ_on_ESG
Weitere Inhalte
→ Webseite
→ Kundenbereich
→ YouTube