Learn
📋 What you'll get from this article: A clear explanation of the five-stage NCA portal validation sequence, the specific error categories that account for most rejections, aplain-language breakdown of what each error type means and how to fix it, and a pre-submission checklist you can run before every filing to catch the most common failures before your regulator does.
You submitted. You waited. Then the email arrived — not a confirmation, but a rejection notice with an error code you'd never seen before. If you're reading this, there's a good chance it happened more than once.
The DORA Register of Information has a rejection rate that surprised even seasoned compliance professionals across the EU in 2025. Teams that had spent months populating the ESA Excel template — carefully filling every tab, cross-checking every field — still hit the NCA portal wall. The reason almost never comes down to effort. It comes down to a handful of structural, technical, and data integrity issues that Excel hides from you right up until the moment of submission.
This article covers what the EBA's validation engine actually checks, which errors account for the majority of rejections, and what you need to fix before you resubmit.
📌 Jump to section
⚡ TL;DR
Most DORA RoI rejections fall into five buckets: broken foreign key links between tables, invalid or lapsed LEI codes, non-compliant controlled values, incorrect ZIP packaging and file naming, and mandatory fields that are technically populated but fail format validation. Almost all of them are invisible in Excel and only surface when the EBA's 117-rule engine runs against your submission.
What Actually Happens When You Submit
Your submission is a ZIP archive containing multiple xBRL-CSV files — one for each of the 15 interconnected tables in the Register of Information data model. When the NCA portal receives this package, it runs a multi-stage validation sequence before anything is accepted. A failure at any stage produces a rejection. The later the stage where you fail, the harder the error is to diagnose.
1
Package validation
The portal checks that your ZIP contains the correct file structure, that filenames match the required naming convention, and that the package includes all mandatory table files. This is a Stage 1 failure — fast to diagnose, preventable with a checklist.
2
Taxonomy conformance
Each CSV file is validated against the XBRL taxonomy — field names must match exactly, data types must conform, and column ordering matters more than most people realise.
3
Referential integrity checks
Every relationship between tables is verified. If a contract record references a provider ID that doesn't exist in the providers table, the submission fails — even if every other field is perfect.
4
Controlled value validation
Fields that require values from predefined code lists are checked against the EBA's published enumerations. A value that looks correct to a human may still fail if it doesn't exactly match the taxonomy's controlled vocabulary.
5
Business rule validation
The EBA's 117 specific business rules are applied — logical consistency checks, mandatory field dependencies, date range validations, and cross-table consistency requirements that go beyond simple format checking.
⚠️ The feedback file problem
When a submission fails, NCAs return a feedback file containing EBA rule codes for each error. These codes reference the taxonomy directly rather than providing plain-language descriptions. Many compliance teams spend more time decoding the feedback file than they did building the register in the first place.
The Five Main Rejection Categories
Based on patterns from the first submission cycle in 2025 and the issues regulators have published in their feedback, rejections cluster into five primary categories. Here is how frequently each appears and what drives it.
| # | Category | Frequency | Root cause |
|---|---|---|---|
| 1 | Foreign key violations | 🔴🔴🔴🔴🔴 Very high | Managing provider-contract-service links across separate Excel tabs with manual ID matching |
| 2 | LEI and legal entity errors | 🔴🔴🔴🔴 High | Invalid, expired, or mismatched LEI codes; entity names not matching GLEIF records |
| 3 | Controlled value failures | 🔴🔴🔴 Moderate–high | Country codes, currency codes, and classification values entered as free text rather than from the taxonomy's enumeration lists |
| 4 | ZIP packaging and file naming | 🔴🔴 Moderate | Wrong file naming convention, missing files in the ZIP, incorrect folder structure inside the archive |
| 5 | Mandatory fields failing despite appearing filled | 🔴🔴 Moderate | Fields populated with values that don't meet format, length, or conditional dependency requirements in the taxonomy |
Foreign Key Violations — The Silent Killer
This is the single most common cause of rejection and the hardest to catch manually. The DORA Register of Information is a relational data structure. Its 15 tables reference each other through identifier fields. A contract record in Table B02 must reference a provider ID that exists in Table B01. A service record in Table B03 must reference a contract ID that exists in B02. And so on across every table in the structure.
In the ESA Excel template, these relationships are maintained manually. There is no referential integrity enforcement. No warning fires if you change a provider name in one tab but forget to update the ID reference in three others. No alert appears when a copy-paste error introduces a trailing space that makes PROVIDER_001 and PROVIDER_001 look identical to you and completely different to the validation engine.
🔴 Real example
A payment institution submits their register. In Table B01, their cloud provider has identifier ICT_PROV_AWS_001. Midway through the project, a team member renamed it AWS_ICT_001 to match a new naming convention. The B03 service records were never updated.
Result: every service record referencing the old ID fails with a foreign key violation. The EBA feedback file returns a taxonomy rule code. The team spends four hours decoding it before someone notices the ID mismatch on a second read-through.
Which relationships generate the most violations
| Relationship | Tables | Why it breaks |
|---|---|---|
| Provider → Contract | B01 → B02 | Provider ID edited in B01 after B02 was populated; naming convention changed mid-project |
| Contract → Service | B02 → B03 | Services added after contracts were finalised; contract ID not propagated correctly |
| Service → Function | B03 → B06 | Internal function IDs defined late in the project; services mapped before IDs were stable |
| Provider → Sub-contractor | B01 → B04 | Sub-outsourcing data gathered separately by a different team; IDs assigned inconsistently |
| Entity → All tables | B00 → all | Multi-entity submissions where each entity's data is populated by different teams without a shared ID namespace |
How to fix it
- Freeze your ID schema before populating any table. Every provider, contract, service, and internal function needs a stable identifier assigned at the start — not changed mid-project.
- Run a referential integrity check before you export. In Excel, this means VLOOKUP or MATCH formulas to verify every foreign key reference resolves to a record in the parent table.
- Watch for whitespace and case sensitivity. The validation engine is exact-match. Use Excel's TRIM() and EXACT() functions to check every ID field.
- Every time you update an ID anywhere, search every tab for that value before saving. A global find-and-replace, done carefully, is safer than manual hunting.
LEI and Legal Entity Errors
The Legal Entity Identifier (LEI) is a 20-character alphanumeric code required for your own entity and for ICT third-party providers where one exists. LEI errors appear in three distinct forms, each with a different fix.
❌
Invalid LEI format
An LEI must be exactly 20 characters. Any deviation in length or character type fails immediately. Most common causes: transposing two characters while typing, copying from a PDF where OCR misread a character, or using an old LEI that has been transferred and renumbered.
⏰
Expired or lapsed LEI
LEIs must be renewed annually. An LEI with a status of "LAPSED" in the GLEIF database fails validation even if the code is structurally correct. This catches teams off guard when a third-party provider hasn't renewed their LEI — something outside your direct control. Check LEI status at gleif.org for every provider before submission, not just your own entity.
🔤
Entity name mismatch
When you provide both an LEI and a legal entity name, some NCA systems cross-reference the name against the GLEIF registry. If your entry says "Amazon Web Services" but the LEI resolves to "Amazon Web Services, Inc." — the legally registered name — this flags as an identity mismatch. Always use the exact legal name from the GLEIF record, not the trading name you use internally.
💡 Quick fix: Before every submission, run all LEI codes through the GLEIF API or the GLEIF search tool. Thirty minutes of LEI checking eliminates both format errors and lapsed status issues before the NCA portal finds them for you.
Controlled Value Failures
The DORA xBRL taxonomy uses controlled vocabularies for many fields — meaning certain fields only accept values from a predefined list. The list is case-sensitive, format-specific, and tied to the taxonomy version you are submitting under. Excel is dangerous here because it allows any value in any cell. A dropdown may suggest the right options but nothing stops a user from typing a free-text value, pasting with different casing, or selecting an option from an older template version that has since been updated.
| Field type | Common mistake | What the taxonomy requires |
|---|---|---|
| Country codes | Entering "Netherlands" or "The Netherlands" | ISO 3166-1 alpha-2 — "NL", "DE", "FR" exactly as defined in the taxonomy enumeration |
| Currency codes | Using "Euros" or "EUR " with a trailing space | ISO 4217 three-letter codes, exact case |
| ICT service type | Using a description like "Cloud Infrastructure" | EBA-defined alphanumeric codes from the ICT service type enumeration list |
| Criticality assessment | Entering "Yes/No" or "Critical/Non-critical" | Boolean or enumeration values as defined in the taxonomy for the specific field |
| Date formats | Excel auto-formatting dates as "01/01/2025" | "2025-01-01" — ISO 8601 only. Excel's regional date formatting is a notorious source of silent CSV corruption. |
⚠️ The Excel date export trap
When you save an Excel file as CSV, Excel converts date cells to whatever regional date format is set on your operating system — not ISO 8601. If your OS is set to UK locale, you get "01/01/2025". US locale gives "1/1/2025". Neither is accepted. Before exporting any CSV, format all date columns as text with explicit YYYY-MM-DD values, then verify the exported file in a plain text editor before packaging it into the ZIP.
ZIP Packaging and File Naming Mistakes
These are Stage 1 failures — the portal rejects the package before reading your data. Entirely preventable once you know the rules, but the rules are not obvious and the ESA documentation does not always present them clearly in one place.
File naming convention
Each xBRL-CSV file inside your ZIP must follow a precise naming pattern that encodes the reporting period, the reporting entity LEI, and the table identifier. A single extra character, wrong separator, or incorrect date format in the filename produces an immediate rejection.
Expected filename structure (example):
ROI_{LEI}_{YYYY-MM-DD}_{TABLE_IDENTIFIER}.csv
Every component — separator characters, date format, table identifier codes — must match the taxonomy specification exactly. Check your NCA's technical guidance as conventions can vary slightly by jurisdiction.
ZIP structure requirements
- All CSV files must sit at the root level of the ZIP — not inside a subfolder. Many zip utilities create a containing folder by default. Open the archive and check before submitting.
- The ZIP itself must follow a specific naming convention that includes your LEI and the reporting period. A ZIP named "DORA_submission_final_v3.zip" will fail immediately.
- No additional files. No README, no cover sheet, no backup CSV versions. The portal validates the exact set of files it expects and rejects anything extra.
- File encoding must be UTF-8. CSV exports from older Excel versions on Windows can produce UTF-16 or ANSI encoding, which the parser may misread or reject entirely.
Mandatory Fields That Fail Even When You Think They're Filled
This category produces the most frustrating rejections because everything looks correct in the spreadsheet. The field has a value. The column exists. But the submission still fails. Three things are usually going on.
Conditional mandatory fields
Many RoI fields are mandatory only when another field has a specific value. If Field A is set to "Yes" and Field B becomes mandatory as a result, leaving Field B empty — or populated with a placeholder — causes a failure the validation engine attributes to Field B, not to Field A. These dependencies are documented in the ESA template but easy to miss when different team members populate different sections.
Format-valid but content-invalid values
Some fields accept a value type but have additional content constraints. A contract value field might require a positive number — so entering "0" as a placeholder passes format validation but fails a business rule requiring the value to be greater than zero. A date field might accept "2020-01-01" but fail a rule requiring the date to fall within the reporting period range.
Empty string vs. null
In CSV files, a truly empty cell and a cell containing an empty string are technically different. Some DORA fields that should be absent when not applicable must be truly absent — not present with an empty value. Excel's CSV export sometimes fills optional fields with empty strings that the validator reads as malformed entries rather than omissions.
Pre-Submission Checklist
Run this before every RoI submission. It won't catch every possible error — only running all 117 EBA validation rules will do that — but it catches the most common ones before you waste a submission attempt.
Data integrity
☐All provider IDs in B01 are unique, stable, and unchanged since B02–B04 were populated
☐Every B02 contract record references a provider ID that exists in B01 — verified with VLOOKUP
☐Every B03 service record references a contract ID that exists in B02
☐B04 sub-outsourcing records reference provider IDs that exist in B01
☐All ID fields across all tables checked for trailing spaces using TRIM()
☐All ID fields checked for case consistency — no mixing upper and lower case for the same identifier
LEI validation
☐Reporting entity LEI verified in GLEIF — status is "ISSUED", not "LAPSED" or "RETIRED"
☐All third-party provider LEIs verified in GLEIF — status checked, not just format
☐All LEIs are exactly 20 characters
☐Legal entity names match the GLEIF-registered legal name exactly — not trading names or abbreviations
Controlled values
☐All country fields use ISO 3166-1 alpha-2 codes from the taxonomy enumeration
☐All currency fields use ISO 4217 three-letter codes
☐All classification fields use EBA-defined enumeration codes — no free-text descriptions
☐All date fields in exported CSVs are in YYYY-MM-DD format — verified in a text editor, not in Excel
Packaging
☐ZIP filename matches the required naming convention including your LEI and reporting period
☐All CSV filenames inside the ZIP match the required naming convention for each table
☐CSV files are at the root of the ZIP — not inside a subfolder
☐No extra files included — no README, no backup CSVs, no cover documents
☐All CSV files are UTF-8 encoded — verified using a text editor, not inferred from Excel
When Rejection Signals a Deeper Problem
If you have fixed the errors above and are still getting rejected — or if the same errors keep returning after correction — the problem is usually not execution. It is architecture.
The DORA Register of Information is a relational database problem that compliance teams have been asked to solve with a spreadsheet. Excel has no foreign key enforcement, no entity-relationship model, no validation engine, and no version control for identifier schemas. Every manual process on top of it compounds as the register grows. A register with 20 providers and 40 contracts is manageable with discipline. A register with 80 providers, 200 contracts, 400 services, and sub-outsourcing chains across three legal entities is not a spreadsheet problem anymore.
| Challenge | Excel approach | Purpose-built platform |
|---|---|---|
| Foreign key integrity | Manual VLOOKUP checks; breaks silently on any ID change | Enforced automatically; ID changes propagate to all linked records |
| LEI validation | Manual GLEIF lookup per provider; easy to miss lapsed status | Automated GLEIF API validation at data entry; lapsed LEIs flagged immediately |
| Controlled value enforcement | Excel dropdowns that users can bypass; free text allowed | Hard constraints from taxonomy enumerations; invalid values rejected at input |
| xBRL-CSV export | Manual conversion, date format issues, encoding problems | One-click export that passes all 117 EBA validation checks before submission |
| Error diagnosis | Cryptic EBA rule codes require manual lookup in taxonomy documentation | Errors surfaced in plain language before export; pre-submission validation matches EBA rules |
Stop the resubmission loop.
Venvera runs all 117 EBA validation checks on your Register of Information before you submit — surfacing errors in plain language, not taxonomy rule codes. See it working with your actual data.
Book a demo → Venvera.comFrequently Asked Questions
How many times can you resubmit a rejected DORA Register of Information?
This varies by NCA and jurisdiction. Most NCAs allow resubmission but track submission history. Repeated rejections can attract regulatory attention beyond the submission itself, and some portals temporarily restrict access after multiple rapid failures. Check your NCA's portal guidance for the rules that apply to your entity type.
What do the EBA rule codes in the feedback file actually mean?
EBA rule codes reference specific validation rules in the DORA xBRL taxonomy. Each code follows a pattern that identifies the table and the specific check that failed. The EBA publishes the full validation rule set alongside the taxonomy documentation — you'll need to cross-reference the code against that document to understand the specific failure in plain terms.
Can I test my xBRL-CSV package before submitting to the NCA portal?
Some NCAs provide a test environment for pre-submission validation — check your NCA's portal documentation for availability. If a test environment isn't available, the most reliable approach is to run the EBA's published validation rules against your package yourself before submission, either manually against the taxonomy specification or using a platform that automates this step.
What if a third-party provider doesn't have an LEI?
Not all ICT third-party providers are required to have an LEI. The DORA taxonomy provides for cases where an LEI is not available or applicable — in these situations you use the alternative identifier fields specified in the taxonomy rather than leaving the LEI field empty or entering a placeholder. A placeholder in an LEI field causes a format validation failure.
Does every DORA-subject entity need to submit the full Register of Information?
The proportionality principle under DORA allows micro-enterprises to benefit from simplified obligations, but the Register of Information requirements apply broadly across in-scope financial entities. Groups may submit at individual, sub-consolidated, or consolidated level depending on their structure. Check the ESA's technical guidance for your entity type before scoping your submission.
Written by the Venvera compliance team. Venvera is a purpose-built DORA compliance platform for European financial entities. Last updated: February 2026.
