LEI Code: Format, Structure and Validation Rules
You are filling in onboarding documents, preparing a vendor record, or checking data for a regulatory submission, and then one field slows everything down: the LEI code. Someone pasted a 20-character identifier into a spreadsheet, but you are not sure whether it is valid, whether it belongs to the right legal entity, or whether the formatting is even correct. That is a common problem, especially if your team works across compliance, finance, procurement, or operations.
The good news is that the LEI code is not random. It follows a defined structure, specific validation logic, and clear global standards. Once you understand how it is built, you can spot obvious issues much faster and reduce mistakes before they spread through contracts, reports, or internal systems.
This article explains the lei code in plain English: what it looks like, how its 20 characters are structured, what validation rules matter, and what you should actually check in practice. If you are working with regulated entities, supplier records, or reporting workflows, that clarity can save a surprising amount of time. Tools and workflows in DORApp also reflect this need for structured entity data, especially where LEI validation and enrichment support DORA-related recordkeeping.
What a LEI code actually is
An LEI code is a globally standardized identifier used to uniquely identify legally distinct entities involved in financial and business transactions. LEI stands for Legal Entity Identifier. If you want the broader foundation first, you can start with Dorapp’s overview of what is lei or its explainer on the legal entity identifier.
Think of it as a unique ID card for a company, fund, bank, insurer, or other organization. It is not meant for individuals. It is assigned to legal entities and linked to reference data, such as the official entity name, registration status, and jurisdiction.
The reality is that many teams treat LEI fields as just another compliance box to tick. But the code only becomes useful if the structure is understood and the underlying reference record is kept accurate. A correct-looking 20-character string is helpful, but it is only part of the picture.
If you want a wider map of the topic, Dorapp’s main lei hub is a useful starting point.
Why LEIs exist, and why that matters
It helps to know the “why” behind LEIs, because it explains why the standard is so strict and why so many workflows depend on it. After the 2008 financial crisis, regulators and market participants ran into a basic but serious problem: it was difficult to map exposures and understand who was actually involved in complex chains of trades, financing, and contractual obligations. In plain English, too many datasets could not reliably answer “who is who” across borders, languages, and corporate structures.
LEIs were designed to solve that problem with a single, global identifier that points to one legally distinct entity. The idea is straightforward: if you can uniquely identify entities, you can typically aggregate risk more consistently, reconcile reporting across systems, and reduce ambiguity in onboarding and counterparty checks.
What many people overlook is that LEI reference data is meant to be a “public good” in the sense that it supports transparency and consistent identification across markets. You do not need to know the institutional history to benefit from it. The practical takeaway is that LEIs give you a shared language for entity identity across jurisdictions and group structures, which is exactly where names and internal IDs tend to break down.
For day-to-day data work, this background matters because it changes how you treat an LEI field. It is not just a reporting add-on. It is a key that lets multiple teams, systems, and external parties talk about the same entity without guessing.
How the LEI code format is built
The lei code format always contains 20 alphanumeric characters. That length is fixed. A valid LEI uses uppercase letters and numbers, and it follows ISO 17442, the international standard behind LEI issuance and structure.
The 20-character structure, broken down simply
Here is the practical structure:
That means the code is not just a random label generated by a system. It contains components with defined roles. From a practical standpoint, this helps you separate formatting checks from deeper entity verification.
What the structure does not tell you
Here’s the thing: the LEI structure does not tell you whether the entity is active, lapsed, merged, or otherwise suitable for your purpose. It also does not tell you whether the legal name in your spreadsheet matches the official record. For that, you need a proper lei search or lei lookup against authoritative data sources.
So yes, structure matters, but structure alone is not enough.
What you can learn from the LEI record
An LEI is more than a 20-character string. In most cases, the real value comes from the reference data attached to it. That reference record is what allows your team, and external parties, to confirm you are talking about the correct legal entity.
Typically, an LEI record includes core fields such as the official legal name, legal address, headquarters address, jurisdiction of formation, and registration authority details. It also usually includes important operational signals like entity status and registration status, plus key dates such as initial registration date, last update date, and next renewal date or lapsed indicators depending on the data source.
Now, when it comes to group structures, there is another angle that often matters in vendor and counterparty matching: “who owns whom.” LEI datasets may also include relationship data that can show direct and ultimate parent relationships, where those relationships are reported. This is not just a nice-to-have. If you are onboarding a subsidiary that signs the contract, but your team stores the parent’s LEI, you can end up with clean-looking data that is wrong for reporting, third-party inventories, or internal approvals.
From a practical standpoint, this is where you can upgrade your validation flow. Alongside format checks and basic lookup, consider adding a short set of record checks:
Think of it this way: the LEI code helps you point to a record, but the record helps you confirm identity, recency, and context.
Validation rules that matter in practice
If you are checking lei codes in a CRM, spreadsheet, reporting tool, or onboarding process, there are two levels of validation to think about: format validation and record validation.
1. Format validation
This is the first pass. You check whether the LEI code has 20 characters, uses valid uppercase alphanumeric characters, includes 00 in positions 5 and 6, and passes the check-digit logic defined by the standard.
In practice, this means a code can be rejected immediately if it is too short, too long, contains symbols, or fails the mathematical checksum. That is useful for screening obvious data entry errors before they reach a reviewer.
2. Record validation
This second layer checks whether the LEI actually exists in the relevant LEI database and whether the associated entity details are current. A structurally valid code could still refer to an entity with lapsed registration status, outdated legal name data, or a different jurisdiction than you expected.
What many people overlook is that business risk usually sits in this second layer. The code may pass the format test and still be wrong for the entity record you are maintaining.
Why check digits matter
The last two characters in the LEI code are check digits. They help detect input errors, especially transposition mistakes and mistyped characters. If someone swaps a digit or enters one wrong character, the code may fail checksum validation even if it still “looks right” to a human reviewer.
This is one reason structured validation is much more reliable than visual review alone.
Common formatting mistakes and data quality issues
If you work with imports, spreadsheets, or copied records from emails and PDFs, you will see the same mistakes repeatedly. Most problems are not complicated. They are boring, repetitive data quality issues that waste time because nobody catches them early.
Common LEI code mistakes
Consider this: a procurement team may have the right vendor name in a contract file but the wrong LEI in the master record because the code was copied from a group entity, not the service-providing legal entity. That kind of mismatch can create issues in reporting and third-party oversight.
Formatting consistency matters more than it seems
Even small inconsistencies can break matching logic during imports or automated checks. In DORApp, for example, LEI-related enrichment and validation workflows are designed around structured entity records, which helps reduce manual cleanup when teams are preparing DORA-related datasets. DORApp also provides a Help Center at https://dorapp.eu/help/ for users working with templates and structured imports.
How to check an LEI code the right way
If your goal is reliable entity data, do not stop at “it has 20 characters.” A better workflow is simple and repeatable.
A practical validation sequence
In practice, this means you should treat the LEI as part of entity verification, not as a standalone field. A good process links code validation to legal name checks, jurisdiction checks, and record ownership.
When a manual check is enough, and when it is not
For a one-off onboarding case, a manual search may be enough. For recurring reporting, vendor inventories, or regulated workflows, manual checking becomes fragile very quickly. That is where structured data workflows, imports, and validation rules become more valuable than simple copy-paste administration.
If your work also touches resilience and regulated operations, Dorapp’s cross-topic article on what is digital resilience adds helpful context on why data quality and system reliability matter beyond a single identifier.
Why LEI structure matters for compliance and reporting
Now, when it comes to compliance, the LEI code matters because structured identifiers reduce ambiguity. Regulators, counterparties, financial institutions, and internal control teams need a dependable way to distinguish one legal entity from another. Names alone are often not enough, especially across jurisdictions and group structures.
This becomes more important in environments where entity records feed regulatory reports, outsourcing registers, third-party risk files, or XBRL-based submissions. If your team works in that space, Dorapp’s XBRL category and articles like DORA Pillars Explained: Complete Breakdown (2026) and DORA European Commission Timeline and History (2026) can help connect identifier quality with broader reporting obligations.
Under DORA-related workflows, poor legal entity data may create friction in the Register of Information, provider mapping, and third-party documentation. That does not mean every LEI issue becomes a regulatory breach. It does mean poor identifier hygiene tends to spread into more visible compliance problems later.
Where LEIs are required, and who typically needs one
Requirements around LEIs depend on the use case. They can vary by jurisdiction, regulator, and the specific reporting or onboarding context. So the most accurate answer is usually: it depends on what you are doing, where you operate, and what your counterparties or supervisors expect. If you work in a regulated sector, it is smart to confirm requirements with your legal and compliance teams rather than treating any blog article as a rules checklist.
With that said, LEIs commonly show up in a few recurring scenarios:
Another practical complication is deciding which “thing” needs the LEI. In most day-to-day operations, you are dealing with a mix of legal entities, branches, subsidiaries, and sometimes funds or special purpose vehicles. The difference often comes down to contracting and reporting responsibility. A branch is not always a separate legal entity, while a subsidiary typically is. A fund structure may have its own legal identity in some setups, but not in others. This is why the “use the parent company LEI” shortcut tends to create trouble.
For most small business owners and entrepreneurs, the internal decision is less about the code itself and more about ownership of the process. Decide who will obtain the LEI, who will maintain it, and how renewal and record updates will be tracked. Treat LEI maintenance as an ongoing data governance task, not a one-time onboarding step, because corporate changes and lapsed registrations can quietly turn a once-correct identifier into a future mismatch.
How DORApp fits into structured entity data workflows
DORApp was built for EU financial institutions working through DORA-related operational and reporting tasks, and one of its confirmed practical strengths is automatic LEI validation and enrichment from public data sources embedded directly into record creation and import workflows. That is relevant here because LEI quality is rarely a standalone problem. It usually appears inside larger data collection and reporting processes.
According to the verified product and documentation data provided, DORApp supports Excel and CSV imports, applies validation during import, enriches matching records from public LEI data, and maintains audit-friendly change tracking. For teams managing entity records at scale, that kind of structure may reduce manual cleanup and improve consistency before export.
If you want to explore the platform itself, you can review DORApp Functions, see Why DORApp, or request a conversation through Book a Demo. Dorapp’s founder-led perspective, shaped by Matevž Rostaher’s FinTech, InsurTech, and RegTech background, is one reason the blog tends to focus on practical data problems rather than abstract theory.
For readers still building their foundation, the LEI category is worth bookmarking.
Disclaimer: The information in this article is intended for general informational and educational purposes only. It does not constitute professional technical, legal, financial, or regulatory advice. Website performance outcomes, platform capabilities, and business results will vary depending on your specific circumstances, goals, and implementation. Always evaluate tools and platforms based on your own needs and, where relevant, seek professional guidance.
This article is for informational purposes only and does not constitute financial, legal, or regulatory advice. Requirements related to LEI usage, regulated reporting, and DORA-adjacent compliance workflows may vary based on your institution type, jurisdiction, and supervisory expectations. If you operate in a regulated sector, consult qualified legal, financial, and compliance professionals for guidance specific to your situation.
Frequently Asked Questions
What is the correct length of an LEI code?
An LEI code is always 20 characters long. That length does not change by country, entity type, or issuer. If a code has 19 characters, 21 characters, or includes extra spaces that push it out of format, it is not valid in its presented form. That said, length alone is only the first check. A 20-character value can still be wrong if it fails checksum validation or if it belongs to a different legal entity than the one in your records. So treat 20 characters as the minimum starting point, not the full validation process.
Are LEI codes always numeric?
No. LEI codes are alphanumeric, which means they can contain both letters and numbers. They are typically presented in uppercase. If you see symbols, punctuation, or formatting characters mixed into the code, that should raise a flag. One practical issue is that users often confuse the letter O with the number 0, or the letter I with the number 1. In manual reviews, those errors are easy to miss. That is why checksum and database validation are much more dependable than simply reading the code visually.
What do the last two characters of an LEI code mean?
The final two characters are check digits. Their role is to support formal validation of the LEI code and help detect typing errors or character transpositions. In plain English, they act as a built-in error check. If someone enters one character incorrectly, the code may fail checksum validation even though it still appears similar to the original. This is especially useful in spreadsheets, forms, and imports where manual review is unreliable. It is one of the reasons LEI formatting rules are more structured than a simple internal reference number.
Does a valid LEI format mean the entity data is correct?
No. A code can be structurally valid and still be wrong for your use case. It may belong to a different company in the same group, refer to a lapsed registration, or be linked to outdated entity details. This is a common misunderstanding. Format validation tells you the code follows the technical rules. It does not confirm that the legal name, country, registration status, or contracting entity matches your records. For real-world use, especially in compliance or reporting, you should combine format checks with an authoritative lookup of the underlying entity record.
Can two entities share the same LEI code?
No. An LEI is intended to uniquely identify one legal entity. If two records in your internal systems appear to share the same LEI, that usually points to a data quality problem rather than a valid scenario. The issue may come from duplicate records, copy-paste errors, or the mistaken use of a parent entity’s LEI for subsidiaries or branches. From a practical standpoint, this is exactly why identifier governance matters. Once one wrong LEI enters a master dataset, it can spread quickly into contracts, onboarding files, and regulatory reporting outputs.
Is an LEI code enough for vendor or counterparty verification?
Usually not by itself. The LEI is a strong identifier, but it works best as part of a broader verification process. You should typically also confirm the legal entity name, jurisdiction, registration status, and the actual role of that entity in the transaction or contract. For example, the invoicing entity, contracting entity, and ultimate parent may not be the same. Relying on the LEI alone can create false confidence if your business process depends on the exact legal party involved. The LEI helps reduce ambiguity, but it does not eliminate the need for context.
What is the difference between an LEI search and an LEI lookup?
In everyday use, people often mean similar things by both terms, but there is a slight practical difference. An LEI search usually starts with partial information, such as an entity name, and aims to find the matching record. An LEI lookup usually starts with a known LEI code and checks the underlying entity details. Both are useful. Search helps when you are trying to identify the right entity. Lookup helps when you already have a code and want to confirm it is current and correctly matched. Good workflows often use both at different stages.
Why do LEI formatting errors show up so often in spreadsheets?
Spreadsheets are flexible, which is exactly why they create risk. They may trim leading characters visually, preserve hidden spaces, allow mixed case, or accept copied values without enforcing validation rules. Add multiple contributors and version changes, and small errors become very common. The problem usually is not the LEI standard itself. It is the lack of controls around data entry and review. If your team uses spreadsheets for imports or master data maintenance, simple checks for length, character set, and duplicate detection can already remove many avoidable mistakes before they escalate.
When should a business automate LEI validation instead of checking manually?
If you only verify a few entity records each year, manual checks may be fine. Once you are dealing with recurring onboarding, supplier inventories, regulated reporting, or large imports, automation becomes much more valuable. The tipping point usually comes when mistakes start repeating across systems or when validation delays slow down approvals and submissions. Automation may help you apply the same logic every time, enrich missing fields, and flag mismatches earlier. That does not replace human judgment, but it typically improves consistency and reduces the amount of avoidable rework.
Who needs an LEI code?
It depends on the scenario. In many cases, an LEI is needed by legal entities that participate in regulated financial transactions or reporting, or by organizations that are asked to provide one by a bank, broker, trading venue, or large counterparty during onboarding. Requirements can vary by jurisdiction and activity, so the safest approach is to confirm with your compliance or legal team what applies to your entity and use case. From a practical standpoint, if you are entering contracts, being reported in third-party registers, or appearing in transaction reporting flows, you should expect LEI questions to come up.
How much does an LEI code cost?
LEI issuance and renewal typically involve a fee that can vary depending on the issuing organization, the service model, and whether you are registering for one year or multiple years. Because pricing can change and differs across providers, it is best to check current fees directly with the issuing channel you plan to use. Also remember to account for renewal as an ongoing cost, not just initial registration, since a lapsed status can create downstream friction in onboarding and reporting.
Where can I find my LEI code?
If your organization already has an LEI, you can typically find it in onboarding files, regulatory reporting outputs, or internal vendor and counterparty records. If you need to confirm it, the most reliable approach is to use an authoritative lookup process and match your legal entity name and jurisdiction to the official LEI record. This is especially helpful if your group has multiple entities with similar names, or if there have been recent corporate changes.
Is an LEI number legitimate?
An LEI is legitimate if it exists in the official LEI dataset and the associated record matches your entity. In practice, legitimacy checks are the same as good record validation: confirm the code appears in an authoritative database, check the registration status, and compare the legal name and jurisdiction. If someone sends you an LEI in an email or a PDF, do not rely on the string alone. Verify the underlying record, and if the entity is part of a larger group, consider checking parent relationships as well to reduce the risk of using the wrong group entity.
Key Takeaways
Conclusion
The LEI code looks simple on the surface, but it carries more structure and practical importance than many teams realize. Once you know how the 20-character format works, what the check digits do, and where basic formatting checks stop being enough, you can review entity data with much more confidence. That is useful whether you are cleaning up spreadsheets, validating suppliers, or preparing data for more formal reporting processes.
Think of it this way: the goal is not just to collect an LEI code. It is to maintain reliable entity data that holds up when your business actually depends on it. For teams operating in regulated environments, that often means connecting identifiers, validation, and reporting into one cleaner workflow.
If you want more practical explainers like this, explore the Dorapp blog’s LEI resources and related compliance topics. If your team is dealing with DORA-related entity records and structured reporting, DORApp is also worth exploring to see how it approaches LEI enrichment, validation, and data management in practice.
About the Author
Matevž Rostaher is Co-Founder and Product Owner of DORApp. He brings deep experience in building secure and compliant ICT solutions for the financial sector and is positioned by DORApp as an expert trusted by financial institutions on complex regulatory and operational challenges. DORApp’s own webinar materials list him as CEO and Co-Founder of Skupina Novum d.o.o. and CEO and Co-Founder of FJA OdaTeam d.o.o. His articles should carry the voice of someone who understands not just compliance requirements, but the systems and delivery realities behind them.