Page tree
Skip to end of metadata
Go to start of metadata

Validate taggings

The XBRL Tagger has two types of validations:

  1. On-the-fly validations which can be executed while editing the document


        2. Report Generation validation which are automatically executed when creating a result document


There are two ways to check the validations. They are marked by a red symbol in the table. By right-clicking on the cell and selecting Validations, the Warnings and Errors of the selected cell can be displayed.

As an alternative, the Status button in the bottom left corner can be clicked. All warnings and errors of the document will then be displayed.

Below is an overview of the different validations that you might encounter.

Tagger Live Validation (On-the-Fly)




Report Entity Identifier: LEI missing


A valid ESEF document needs the proper LEI of the filer:

Warning for test,

Error for production!

No Table Element mapped


Every table with mappings needs a table element tagged.


Cell status „in edit“ or „review pending“


Workflow only: Not all cells are in the final status.


Cell has no mapping

A cell in a table with table tag has no mapping. All cells in the PFS need to be tagged!


Cell not part of calculation relationship

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).


Duplicate mapping


Tags can only appear twice in a document if the context is different or the value is equal


Extension element has no anchors


Every extension needs at least one anchor, unless it is the total of a calculation relationship


The reported total does not match the calculated total

The rounded total of a calculation relationship does not equal the rounded calculated total. Does not need to be valid!


The selected format is incompatible with tag


A wrong base format has been applied, e.g. a date format for a monetary value. Please change the format under Table Cell Properties (Number or Date Format).


The value is not valid for the format

The selected format cannot be applied to the value of the tag.


Tagging element not found in taxonomy

The tagged element was not found in the taxonomy. Different version of the taxonomy?


Line item missing


A cell has dimension members tagged, but no line item.


Dimensionally invalid

Each mapping in a table has to contain the same dimensions


Duplicate Label

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

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 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

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:

XBRL Validation (Report Generation)




Empty XBRL taxonomy extension created

Does the report require a taxonomy extension?

Set the correct document setting.

All other types in Report generation folder

Errors during creation of the report.

If no validation errors during on-the-fly validation: Contact AMANA

XBRL Instance Dimension Specification

Invalid output file

If no validation errors during on-the-fly validation: Contact AMANA

Filing Rules Validation

The regulators filing rules are not satisfied.

Make sure the appropriate filing rules have been selected (e.g. ESMA for ESEF). Check the rules in the filing manual of the regulator.

XBRL Instance Specification 2.1

The converted XBRL file is not valid.

Ignore warnings (e.g. calculation relationship errors).

Contact AMANA if in doubt.

XBRL Taxonomy Specification 2.1

The extension taxonomy is not valid

Contact AMANA

XBRL Instance Formula 1.0 

Rules from the taxonomy are not satisfied

Ignore warnings if possible.

Correct errors if possible.

Contact AMANA if in doubt.

ESEF Validation and their Issues

Warnings in XBRL validations

The ESMA reporting manual and the formula validations included in the ESEF taxonomy contain a lot of validations that are classified as warnings. Many creators and auditors interpret this as something essential that has to be fixed before a report is valid. In the XBRL domain in general warnings are handled much more liberal. A warning can and should be interpreted as "Please have another look and make sure this is what you want to report". A report can be perfectly fine with several warnings.

Furthermore there are a lot of validations in the current version of the Reporting Manual that have general issues. Those are explained below.

Update - XBRL Europe also has published a document about these topics:

Guidance 3.2.1: Naming conventions for extension taxonomy elements 

“Extension taxonomy element names should represent the standard label of this element in the Label CamelCase Concatenation [LC3] convention unless it violates XML element naming rules.” 

This rule is supposed to standardize the technical names for extension elements. In its current form it is creating confusion. Different software vendors have different implementations and interpretations of how the LC3 convention should be used. The reason is that it is underspecified, especially with regards to other languages than English. 

The enforced relation to existing labels is also questionable, for example in a German report a line item is called Veränderungen der sonstigen Rückstellenwhich is modelled as a taxonomy extension with the technical element name AdjustmentsForOtherProvisionswhich is a perfect LC3 name, but in English. Of course, the extension item is also equipped with an appropriate German standard label. According to the rule this is allowed because there is no standard label which resembles the technical name

We do recommend to ignore this validation result for now. 

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 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. 

We do recommend to ignore this validation result for now.

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” requirementwhereby 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.

Reported value below 0

The reason for this rule is that in general in XBRL all values should be reported positive. There are exceptions of course, but ESMA has identified a set of elements where they want the preparer to double check if they really want to report this concept with a negative value, because it is not intended that way.

You can check the comprehensive list here:

It might still be ok to report it below zero, but this is a business decision.

To find out which cells are involved in the Tagger, just right-click the validation message and select "More information".

Further Information:

Reported values for alternative tagging of same economic concept are not equal

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]

You can check the comprehensive list here:

To find out which cells are involved in the Tagger, just right-click the validation message and select "More information".

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. 

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. 

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 3.2.1: Naming conventions for extension taxonomy elements

“Extension taxonomy element names should represent the standard label of this element in the Label CamelCase Concatenation [LC3] convention21 unless it violates XML element naming rules.”

This validation rule has several problems acknowledged broadly in the XBRL community. The purpose of this rule is not clear, it is underspecified, references mentioned in the reporting manual are no longer available and it does not work properly for other languages than English.

Furthermore there is no clear guidance on how to implement this rule, leading to different implementations and validations among software vendors, making it impossible to create a version that is accepted by everyone.

This rule should always be ignored.

Please refer also to the Feedback to ESEF validations from XBRL Europe regarding this issue:

Guidance 3.2.5 Definition of abstract concepts in extension taxonomies

"In general, it is not required and ESMA therefore discourages issuers to define abstract concepts in their extension taxonomy. The abstract concepts included in the applicable taxonomy should be sufficient to structure the relationships in the presentation or definition linkbases. Nevertheless, should another grouping item be needed to better reflect the structures of elements used to tag information in the annual financial report, issuers might define abstract headers in the extension taxonomy."

The Tagger always uses existing abstract concepts wherever it is possible. However, bases on the filers needs, it does create its own abstracts element where necessary. This is valid with regards to the validation above.

One such example is the creation of a custom line items element for statements that have no such element in the ESEF taxonomy. This increases readability of the presentation linkbase and matches the structure in the ESEF taxonomy.

  • No labels