• Revathy Ramanan, XBRL International Inc.
  • Paul Warren, XBRL International Inc.


  • Paul Hulst, De Nederlandsche Bank
  • Eric Jarry, formerly Banque de France
  • Karla Mckenna, Global Legal Entity Identifier Foundation

Table of Contents

1 Introduction

The Legal Entity Identifier (LEI) is a 20-character, alpha-numeric code based on the ISO 17442 standard. It provides a globally unique identifier for legal entities, such as companies. The Global Legal Entity Identifier Foundation (GLEIF) administers LEI identifiers. The Global Legal Entity Identifier (LEI) Index provides a daily update on all name and address data for companies with Legal Entity Identifiers (LEIs).

LEIs enable uniform and unique identification of legal entities, and provide particular value when used in conjunction with structured, electronic reporting formats such as XBRL. In collaboration with the GLEIF, XBRL International has released the LEI Taxonomy to facilitate the consistent use of LEIs in XBRL reports.

The primary audience for this guidance are taxonomy architects, taxonomy authors and collectors intending to use LEIs in an XBRL reporting framework.

2 Why use the LEI Taxonomy

The LEI taxonomy provides a consistent and tested approach for incorporating LEIs in XBRL reports. The prebuilt validations ensure LEI values adhere to the prescribed format. Adopting a consistent approach to the inclusion of LEIs increases the value of the data to consumers.

3 How LEIs can be reported in XBRL reports using the LEI Taxonomy

This section explains how XBRL reports can use the LEI Taxonomy to incorporate the LEI as a primary, secondary or related entity identifier.

3.1 LEI as a primary identifier

Facts in XBRL reports specify an entity to which they relate, which is referred to as the Primary Identifier. This is done using the XBRL "entity" < >, which combines an identifier for the entity with a URI identifying a scheme from which that identifier is taken.

Where an LEI is used as the Primary Identifier, the recommended scheme value is http://standards.iso.org/iso/17442 and the identifier value would be the LEI. XBRL best practice recommends using the "entity" built-in dimension to identify the "preparer of the XBRL report". XBRL does not constrain the content of the entity built-in dimension to be a taxonomy concept, therefore, to use the LEI as a Primary Identifier, no modelling is required to be done in the taxonomy.

3.2 LEI as a Fact (secondary identifier)

There can be scenarios in which an XBRL reporting framework mandates the preparer to use a local identifier, such as a national company number, as the primary identifier, but allows the preparer to disclose their LEI where available. In such cases the LEI can be included as a secondary identifier in XBRL reports. This can be done using a standardised concept defined in the LEI Taxonomy.

Business reports often require disclosure of information about other entities. For example, financial reports often include the identification of subsidiaries or related parties. LEI can be used to unambiguously identify related entities. The LEI concept in combination with a taxonomy-defined explicit or typed dimension that identifies the nature of the relationship with the preparer can be used to report the LEI of related entities.

The LEI taxonomy defines a specific concept, LEI, for capturing LEI values. The datatype used in this concept constrains the value captured according to the 20-character alpha-numeric pattern for LEI.

The LEI Taxonomy also provides a standard XBRL datatype, leiItemType, for representing LEIs. Taxonomy authors can use the datatype to create their own concepts. For example, taxonomies may define concepts such as Subsidiary LEI, Parent LEI etc. which capture the LEI of these specific entities. The LEI datatype can thus be used to model related entities as fact values. Re-using the LEI datatype for custom LEI concepts ensures that built-in taxonomy validations for the LEI format can be leveraged.

3.4 LEI as a typed dimension value

Business reports capturing information about related entities may use a typed dimension in the taxonomy. The LEI can be used as a typed dimension value to differentiate information pertaining to each specific related entity.

The LEI taxonomy defines an XML element for use where LEIs are used as the dimension value for a typed taxonomy-defined dimension. The standard LEI typed domain element is named LEIDomain. The LEI typed domain element ensures that the reported LEI matches the 20-character alpha-numeric pattern, however it does not enforce the checksum validation for the last 2 digits. Implementers should define their own XBRL formula rules using the standard LEI checksum functions to validate the checksum.

Table 1 gives an example of counterparty exposure disclosure in which the counterparties (related entities) are identified by their LEI.

Table 1: Counterparty Exposure Disclosure in USD Millions
Counterparty LEI Direct Exposures Indirect Exposures
815600755C5D8DA6AF31 125 30
529900VVQ4470YJ67K25 40 15
969500GNQRRLTUWX6774 75 25

This disclosure could be modelled in the taxonomy as a typed dimension since the number of counterparties is unknown at the time of taxonomy creation. In this case the standard LEI typed domain element can be used to construct a typed dimension (e.g. Counterparty), which can then be included in a cube with concepts to report the direct and indirect exposures for each entity.

A separate guidance document is available with recommendations on incorporating multiple entities in XBRL.

4 Methods of LEI Validation

There are different methods of validation that can be applied to an LEI, ranging from local syntactic verification that it is a 20-character string, all the way up to remote accessing a database of LEIs from an LEI issuer or GLEIF. The LEI taxonomy seeks to provide as much validation as is possible without reference to an external database.

The validations are incorporated in the LEI taxonomy using XML schema data types and XBRL formula rules. The XBRL formula rules in the LEI taxonomy are built in a modular fashion, allowing taxonomy authors to use the components applicable to them. XBRL processors may validate an LEI depending on how the XBRL report uses the LEI. Table 2 gives different modelling approaches and the built-in validations they provide.

Table 2: LEI Taxonomy built-in validations.
Modelling approaches Report uses only the LEI identifier scheme 20-character LEI pattern validation LEI checksum digit validation

LEI as Primary Identifier



LEI as Fact



LEI as Typed Dimension Value


(Additional XBRL formula rules using LEI checksum functions can be incorporated by implementers in their taxonomy)

Only LEI checksum functions imported
(LEI concept or data type not used)



(Custom datatype or validations needs to be incorporated by the implementers)


(Additional XBRL formula rules using LEI checksum functions can be incorporated by the implementers in their taxonomy)

4.1 LEI checksum functions

The authoritative way to check if an LEI is valid is to consult the global LEI index maintained by GLEIF. This will check if a given LEI has been issued, and is still current, and will provide information about the entity to which it was issued.

In some situations, it may not be practical or desirable to do an online lookup. In this case, it is possible to check that the LEI is syntactically valid by ensuring that it conforms to the prescribed pattern (18 alphanumeric characters followed by two digits) and that the last two digits are a valid checksum for the preceding 18. Whilst a valid checksum does not guarantee that an identifier is a valid LEI, it provides a useful check against accidental modification of the digits within the LEI.

Due to an ambiguity in the description of the checksum mechanism used by LEIs, there are a small number of valid LEIs in use that do not strictly conform to the checksum calculation. For this reason, the checksum implementation in the taxonomy has been split into two parts. The validate-checksum function should return true for all valid LEIs. The validate-checksum-invalid-digits additionally checks that the last two digits are not "00", "01" or "99". Although these digits are technically prohibited by the checksum process, a small number of valid LEIs do use these digits.

It is recommended that the validate-checksum function, and the corresponding lei-fact-checksum and lei-identifier-checksum assertions are treated as required validation rules, whereas and the validate-checksum-invalid-digits function, and lei-fact-checksum-digits and lei-identifier-checksum-digits assertions are used as warning-level checks. Implementers may wish to consider maintaining a whitelist of LEIs that are valid but which to not conform to this check.

4.2 Report uses LEI identifier scheme

In addition to the format validation, the LEI taxonomy also has an optional validation rule to ensure that all facts in an XBRL report use the identifier scheme http://standards.iso.org/iso/17442. The evaluation of this rule will depend on the entry point chosen (see LEI taxonomy entry points section for details).

5 LEI Taxonomy entry points

The LEI taxonomy provides three taxonomy entry points, allowing taxonomy authors to select which components and validations they wish to re-use. Table 3 explains the LEI taxonomy components available for each entry point.

Table 3. LEI Taxonomy entry points contents
LEI Taxonomy Components:


Legal Entity Identifier


LEI formula functions


Legal Entity Identifier (required primary identifier)

LEI concept


LEI data type


LEI typed domain content


LEI format validations


LEI checksum functions

Ensure all facts in the XBRL report are reported using an LEI with the correct scheme


XBRL International recommends using the lei-required.xsd entry point wherever possible so as to enforce the use of a valid LEI as the primary identifier for all facts in the report.

6 LEI taxonomy Link

The LEI Taxonomy can be found in the XBRL Taxonomy Registry.

  • Use an LEI as the primary identifier wherever possible, and enforce this using the lei-required entry point.
  • Where LEIs are used as a secondary identifier, use the LEI concept.
  • Where LEIs are used to identify third parties, use either the LEI concept with a dimension, the LEI datatype on a concept, or the LEI Domain type to create a typed dimension.
  • Where the LEI Domain type is used, create formula rules using the LEI checksum functions to validate the value.

  1. Inclusion of this rule will depend on the entry point chosen. Refer to LEI taxonomy entry points for details. 

This document was produced by the Legal Identity in XBRL Working Group.

Published on 2020-07-21.

Was this article helpful?

Related Articles


Would you like
to learn more?

Join our Newsletter mailing list to
stay plugged in to the latest
information about XBRL around the world.

By clicking submit you agree to the XBRL International privacy policy which can be found at xbrl.org/privacy