It has been over a month since the ESMA iXBRL mandate kicked in. In case you haven’t yet prepared yourself for your first iXBRL Filing, you can click here to help you get started.
In this series of blogs, we want to help you in preparing and submitting accurate and valid iXBRL documents. In our first blog we spoke about the Guidelines issued by ESMA. These Guidelines aim at helping the Issuers and Software providers create an iXBRL document as per the mandate. We would now like to shift your focus to validating the iXBRL document that you have prepared.
What do you mean by validating?
ESMA has built-in few validation rules within the ESEF taxonomy using the formula linkbase. (Please click here to understand more about Formula Linkbase). These rules will be run on your iXBRL file when you submit it to your regulator. While these rules will be run on submission, you may also run these checks beforehand depending on whether your software has this functionality.
Validation Rules are of two types i.e. Errors and Warnings. This classification has been done by ESMA within the taxonomy itself. If a Validation Rule has been classified as an Error, it means that your iXBRL submission will be rejected if such an error is present. In case a Validation Rule has been classified as a Warning, it means that you can successfully submit your iXBRL document even with the presence of such Warnings. These Validation Rules are taxonomy specific, which means
that with every release there could be changes in the Validation Rules and even in the classification. Hence it would be good to check out the updates as and when a new version of the taxonomy is released. It is also highly recommended that you ensure the software you have opted for is quick to adopt the updated versions of the taxonomy as and when released and has the capability to both create and validate iXBRL documents as per the latest requirements.
ESMA updated the taxonomy on 20th December 2019, in a version known as ESMA ESEF taxonomy 2019. As per this taxonomy, there are in all 477 validation rules. Of these, 9 validation rules pertain to ensuring that the entity for which the iXBRL document is submitted is clearly identified. These 9 validations have been set at a severity level of Errors.
The 9 Validation Errors are explained briefly:
What does this mean?
The Name of the reporting entity or other means of identification needs to be mandatorily tagged. This means that if the said tag is not present in your iXBRL document then your submission shall be rejected. Please ensure you tag the name of your reporting entity.
Validation Error 2: According to the Regulatory Technical Standards on the European Single Electronic Format, all issuers shall ensure that the Inline XBRL instance document contains data of a single issuer. Therefore all entity identifiers in contexts shall have identical content. Please make sure all XBRL context entity identifiers are provided with identical values.
What does this mean?
While preparing your iXBRL document, you are required to capture the data of only one issuer. The way this is checked is through the use of the Legal Entity Identifier (LEI). The LEI is a unique global identifier of legal entities. The identifier is formatted as a 20-character, alpha-numeric code based on the ISO 17442 standard developed by the International Organization for Standardization (ISO).
It connects to the key reference information that enables a clear and unique identification of legal entities participating in financial transactions. What ESMA is saying here is that you should be using the same LEI identifier throughout your iXBRL document. You cannot have more than one LEI in your iXBRL document.
Validation Error 3: According to the Regulatory Technical Standards on the European Single Electronic Format, all issuers shall identify themselves using ISO 17442 legal entity identifiers on the XBRL context entity identifiers and schemes. Please make sure all XBRL context entity identifier schemes are provided with the value “http://standards.iso.org/iso/17442”.
What does this mean?
A context entity identifier is a reference that identifies the reporting entity. An XBRL context entity identifier consists of two parts. The first part shows the registration scheme or identifier with which the entity is associated. Or, in simple English, the first part shows the authority which allocates the entity’s unique identifier.
In this case, it is http://standards.iso.org/iso/17442. The second part is the entity’s unique identifier (in this case, the LEI) within that registration scheme. The ESMA wants you to use the registration scheme http://standards.iso.org/iso/17442 throughout the iXBRL document, as part of the context entity identifier. Since the ESEF taxonomy has adopted LEI as the unique company/entity identifier, it has also adopted the validation errors as defined in the LEI taxonomy. The next six validation errors outline these.
Validation Error 4: The entity identifier scheme associated with this fact (‘{ xfi:identifier-scheme(xfi:entity-identifier(xfi:entity($v))) }’) is not the standard LEI scheme (‘http://standards.iso.org/iso/17442’)
What does this mean?
All facts that are tagged using an identifier scheme other than “http://standards.iso.org/iso/17442” will be displayed as an error, which you need to resolve for successfully filing with your regulator.
Validation Error 5: The identifier ‘{ xfi:identifier-value(xfi:entity-identifier(xfi:entity($v))) }’ associated with this fact has a scheme ‘{ xfi:identifier-scheme(xfi:entity-identifier(xfi:entity($v))) }’ but is not a valid Legal Entity Identifier (invalid format)
What does this mean?
The 20-character LEI can be broken into three parts as follows:
- Characters 1-4: Prefix is used to ensure the uniqueness among codes from LEI issuers (Local Operating Units or LOUs).
- Characters 5-18: Entity-specific part of the code generated and assigned by LOUs according to transparent, sound, and robust allocation policies as required by ISO 17442. It contains no embedded intelligence.
- Characters 19-20: Two check digits as described in the ISO 17442 standard.
The first 18 characters can be numeric [0-9] or alphabetical [A-Z]; however, the last 2 digits must be numeric [0-9] only. If the value of the LEI does not match the above format, then you will get this error.
Some incorrect values would be:
-
- 123400GHJUT8WJD96IAB: Last two digits are non-numeric
- 123400GHJUT8WJD96I0: There are 19 characters
- 123400GHJUT8WJD96I011: There are 21 characters
Validation Error 6: The identifier ‘{ xfi:identifier-value(xfi:entity-identifier(xfi:entity($v))) }’ associated with this fact has scheme ‘{ xfi:identifier-scheme(xfi:entity-identifier(xfi:entity($v))) }’ but is not a valid Legal Entity Identifier (invalid checksum)
What does this mean?
A checksum is a sequence of numbers and letters used to check data for errors. The LEI taxonomy contains a check wherein it is verified whether the value of the LEI captured in the iXBRL document is valid. This is done by using the checksum function. You will get this error if the checksum function gives a negative output meaning that the value of LEI captured in the Context Identifier is not correct.
Validation Error 7: The identifier ‘{ xfi:identifier-value(xfi:entity-identifier(xfi:entity($v))) }’ associated with this fact has scheme ‘{ xfi:identifier-scheme(xfi:entity-identifier(xfi:entity($v))) }’ but is not a valid Legal Entity Identifier (contains invalid check digits 00, 01, or 99)
What does this mean?
As mentioned above LEI is a 20-character alpha-numeric code. The last two digits of this code are known as check digits which are calculated from the scheme as defined in the ISO 17442 standard. These check digits are used to verify the value of LEI captured in the Context Identifier. These check digits MUST NOT be 00, 01 or 99.
Validation Error 8: The value ‘{ $v }’ is not a valid Legal Entity Identifier (invalid checksum)}
What does this mean?
The value of LEI is captured in two ways in any iXBRL document that has been prepared as per the ESMA 2020 Mandate. The first way is as part of the Entity Context Identifiers as discussed above. The second way is by way of capturing the value of LEI by way of an XBRL tag i.e. lei: LEI. This rule looks at the value of the tag alone and runs a checksum function on it.
Validation Error 9: The value ‘{ $v }’ is not a valid Legal Entity Identifier (contains invalid check digits 00, 01, or 99)
What does this mean?
This rule looks at the last 2 digits (check digits) alone of the value of the XBRL tag lei: LEI. If the last two digits are 00, 01, or 99, then you will get this error.
Do keep an eye for these errors when you review your iXBRL document to ensure there are no last-minute hurdles on submission. In our next blog, we shall explain those Validation Rules which have been classified as warnings. While selecting your Software, ensure that it meets all the specifications as well as the ESEF Validation rules. Look for an XII-certified validator in the solution.
