# | Validation Messages | Answer | ||||
---|---|---|---|---|---|---|
401 | 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. | ||||
402 | 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)" | ||||
403 | 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. | ||||
404 | When validating the document, the warnings "Status …" are displayed: | Severity: Warning Check the affected cells and set the status to final: | ||||
405 | 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! | ||||
406 | 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). | ||||
407 | 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: | ||||
408 | 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. | ||||
409 | 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. | ||||
410 | 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. | ||||
411 | 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. | ||||
412 | 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). | ||||
413 | 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. | ||||
414 | Duplicate Label | Severity: Error or Warning 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, it's required to set its so-called Label Role. The most common Label Roles are (samples in brakets):
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: | ||||
415 | 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. | ||||
416 | 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. | ||||
417 | 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: | ||||
418 | 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. | ||||
419 | 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. | ||||
420 | 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 | ||||
421 | 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. | ||||
422 | 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] | ||||
423 | 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. | ||||
424 | 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. | ||||
425 | 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. | ||||
426 | 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.
| ||||
427 | 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:
How to switch to a newer version of a taxonomy:
| ||||
428 | 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.
| ||||
429 | 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. | ||||
430 | 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 /wiki/spaces/SND/pages/6228309 page. | ||||
431 | 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. | ||||
432 | The rounded value doesn't match the calculated value |
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.
A valid report can be filed with these validation results present. | ||||
433 | 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.
| ||||
434 | 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). 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. 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.
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.
| ||||
435 | 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)" | ||||
436 | 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. | ||||
437 | Guidance 3.4.2: ESEF Role 99999 |
"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: Unfortunately this is not what the ESMA conformance suite is validating in its current form. | ||||
438 | 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 the 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 using the Label Handling Option Extension Labels Only or Verbose. | ||||
439 | 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. | ||||
440 | 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:
| ||||
441 | 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:
| ||||
442 | 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. |
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|