Learn
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 (RoI) has a rejection rate that surprised even seasoned compliance professionals 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 the Excel template hides from you right up until the moment of submission.
This article is going to give you the full picture: what the EBA's validation engine actually checks, which errors account for the majority of rejections, and — most importantly — what you need to fix before you resubmit. By the end, you'll have a concrete checklist you can run through yourself, plus a clear understanding of which problems require a structural rethink of how you're building the register in the first place.
📋 What this article covers: The most common technical and structural reasons DORA RoI submissions get rejected by NCAs, the EBA validation rules behind each rejection type, a pre-submission checklist to run before your next filing, and when a rejected submission signals a deeper data architecture problem — not just a typo.
📌 Jump to section
- What actually happens when you submit
- The top reasons for RoI rejection
- Foreign key violations — the silent killer
- LEI and legal entity errors
- Controlled value failures (country codes, classifications)
- ZIP packaging and naming convention mistakes
- Mandatory fields that fail even when filled
- Pre-submission checklist
- When rejection signals a deeper problem
⚡ TL;DR
The majority of DORA RoI rejections fall into five categories: broken foreign key links between tables, invalid LEI codes, non-compliant controlled values, incorrect ZIP packaging and file naming, and mandatory fields that are technically populated but fail format validation. Most of these are invisible in Excel and only surface when the EBA's 117-rule validation engine processes your submission.
What Actually Happens When You Submit
Before diagnosing what went wrong, it helps to understand what the NCA portal actually does with your file when it arrives.
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 portal receives this package, it runs a multi-stage validation process before anything is accepted:
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.
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 (foreign key) 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 — country codes, currency codes, entity type classifications — 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.
A failure at any stage produces a rejection. Stage 1 and 2 failures are relatively easy to diagnose. Stage 3, 4, and 5 failures — the ones that require understanding the data model itself — are where most teams get stuck in a resubmission loop.
⚠️ The feedback file problem
When a submission fails, NCAs return a feedback file (often in XBRL format itself) containing EBA rule codes for each error. These codes are cryptic by design — they reference the taxonomy directly, not plain-language descriptions. Many compliance teams spend more time decoding the feedback file than they did building the register. We cover how to read these codes efficiently in our companion article on DORA RoI feedback files explained.
The Top Reasons for RoI Rejection
Based on patterns from the first submission cycle in 2025 and the issues regulators have published in their public feedback, rejections cluster into five primary categories. Here's how frequently each appears and what drives it:
| # | Rejection Category | Relative Frequency | Root Cause |
|---|---|---|---|
| 1 | Foreign key / referential integrity violations | 🔴🔴🔴🔴🔴 Very high | Managing provider-contract-service links across separate Excel tabs with manual ID matching |
| 2 | LEI and legal entity data errors | 🔴🔴🔴🔴 High | Invalid, expired, or mismatched LEI codes; entity names not matching GLEIF records |
| 3 | Controlled value / code list 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 errors | 🔴🔴 Moderate | Incorrect file naming convention, missing files in the ZIP, wrong folder structure inside the archive |
| 5 | Mandatory fields that fail despite appearing filled | 🔴🔴 Moderate | Fields populated with values that don't meet format, length, or conditional dependency requirements defined in the taxonomy |
Let's go through each one in detail.
Foreign Key Violations — The Silent Killer
This is the single most common cause of rejection, and the one that's hardest to catch manually. Here's why it happens and why Excel makes it almost inevitable.
The DORA Register of Information is a relational data structure. The 15 tables that make up the register are not independent — they reference each other through identifier fields (foreign keys). 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 Table B02. And so on, across every table in the structure.
In the ESA Excel template, these relationships are maintained manually — you type or paste an ID in one tab and hope it matches exactly what you entered in another tab. There is no referential integrity enforcement in Excel. 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 the human eye but different to the validation engine.
🔴 Real example of a foreign key failure
A payment institution submits their register. In Table B01 (ICT Third-Party Service Providers), they have a provider with identifier ICT_PROV_AWS_001.
In Table B03 (ICT Services), several service records reference this provider — but a previous edit renamed the identifier to AWS_ICT_001 to match a new internal naming convention. The B03 records were never updated.
Result: Every service record in B03 that references the old ID fails with a foreign key violation. The EBA feedback file returns a rule code that references the taxonomy path rather than explaining this in plain language. The team spends four hours trying to understand the error before a colleague notices the ID mismatch on a second review.
Which table relationships generate the most foreign key violations?
| Relationship | Tables involved | Why it breaks |
|---|---|---|
| Provider → Contract | B01 → B02 | Provider ID edited in B01 after B02 was populated; ID format changed mid-project |
| Contract → Service | B02 → B03 | Services added after contracts were finalised; contract ID not propagated correctly |
| Service → Internal 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; IDs assigned inconsistently |
| Entity → Reporting entity | B00 → All tables | Multi-entity submissions where each entity has its own data 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 using VLOOKUP or MATCH formulas to verify every foreign key reference resolves to a record in the parent table. It's tedious. It's necessary.
- Watch for whitespace and case sensitivity. The validation engine is exact-match. "AWS_001" and "aws_001" are different. "PROVIDER_A " (trailing space) and "PROVIDER_A" are different. Use Excel's TRIM() and EXACT() functions to check.
- Any 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 that uniquely identifies legal entities. DORA's Register of Information requires LEI codes for your own entity and for ICT third-party providers where LEI codes exist.
LEI errors appear in three forms, each with a different fix:
❌
Invalid LEI format
An LEI must be exactly 20 characters. Characters 1–4 are the LOU prefix (alphabetic), characters 5–18 are the entity-specific code, characters 19–20 are check digits. Any deviation in length or character type fails immediately. The most common causes: transposing two characters while typing, copying from a PDF where characters were OCR-misread, 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 itself 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, not just your own entity, before submission.
🔤
Entity name mismatch
When you provide both an LEI and a legal entity name, the validation engine cross-references 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), some NCA systems flag this as an identity mismatch. Use the exact legal name from the GLEIF record, not the trading name or brand name you use internally.
💡 Quick fix: Before every submission, run all LEI codes through the GLEIF API or the GLEIF search tool. It takes 30 minutes and catches both format errors and lapsed status issues before the NCA portal does it for you.
Controlled Value Failures — What Country Codes and Classifications Actually Require
The DORA xBRL taxonomy uses controlled vocabularies for many fields. This means certain fields only accept values from a predefined list — and the list is case-sensitive, format-specific, and tied to the taxonomy version you're submitting under.
Excel is particularly dangerous here because it allows any value in any cell. A dropdown might suggest the right options, but nothing stops a user from typing a free-text value, pasting a value with different casing, or selecting an option that was valid in an older version of the template but has since been updated.
The most common controlled value mistakes:
| Field type | Common mistake | What the taxonomy requires |
|---|---|---|
| Country codes | Entering "Netherlands" or "NL" instead of the required ISO 3166-1 alpha-2 code | ISO 3166-1 alpha-2 ("NL", "DE", "FR") — must match the taxonomy's country code enumeration exactly |
| Currency codes | Using "Euros" or "EUR " (with trailing space) instead of "EUR" | ISO 4217 three-letter codes, exact case as defined in the taxonomy |
| ICT service type classification | Using a description like "Cloud Infrastructure" instead of the taxonomy code | EBA-defined alphanumeric codes from the ICT service type enumeration list |
| Criticality / importance assessment | Entering "Yes/No" or "Critical/Non-critical" instead of the required codes | Boolean or enumeration values as defined in the taxonomy for the specific field |
| Date formats | Excel auto-formatting dates as "01/01/2025" instead of ISO 8601 | "2025-01-01" — ISO 8601 format only. Excel's date formatting is a notorious source of silent corruption in CSV exports. |
⚠️ The Excel date export trap
This one catches people repeatedly. 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, "01/01/2025" appears. If it's US locale, "1/1/2025" appears. Neither is accepted. Before exporting any CSV, format all date columns as text with explicit "YYYY-MM-DD" values, or use a macro to force ISO 8601 output. Better yet, validate the exported CSV in a 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 it even reads your data. The good news is they're entirely preventable once you know the rules. The bad news is the rules are not obvious and the ESA documentation doesn't always present them clearly in one place.
File naming convention
The xBRL-CSV files inside your ZIP must follow a specific naming pattern. The convention encodes the reporting period, the reporting entity LEI, and the table identifier — all in a precise format with no deviations permitted. 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 document as conventions can vary slightly by jurisdiction.
ZIP structure requirements
- All CSV files must sit at the root level of the ZIP archive — not inside a subfolder. Many zip utilities create a containing folder by default. Check the archive structure before submission.
- The ZIP itself must also 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 should be included — no README, no cover sheet, no legacy CSV versions. The portal validates the exact set of files it expects.
- File encoding must be UTF-8. If your CSV export creates UTF-16 or ANSI encoding (common with older Excel versions on Windows), the parser may misread or reject the file.
Mandatory Fields That Fail Even When You Think They're Filled
This category produces some of the most frustrating rejection experiences because everything looks fine in the spreadsheet. The field has a value. The column exists. But the submission still fails. Here's what's actually happening:
Conditional mandatory fields
Many DORA RoI fields are mandatory only when another field has a specific value. The ESA template documents these dependencies, but they're easy to miss — especially when one team member populates one section and another team member populates a dependent section. 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 that the validation engine attributes to Field B, not to Field A.
Format-valid but content-invalid values
Some fields accept a value type (like a number or a date) but have additional content constraints. A contract value field might require a positive number — so entering "0" or "-1" as a placeholder passes format validation but fails a business rule that requires the value to be greater than zero. A date field might technically accept "2020-01-01" but fail a business rule that requires the date to be within a specific range relative to the reporting period.
Empty string vs. null
In CSV files, an empty cell and a cell containing an empty string ("") are technically different representations of "no value." Some DORA fields that should be absent from a record 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 interprets as malformed entries rather than omissions.
Pre-Submission Checklist: Run This Before Every Filing
Use this checklist before every RoI submission. It won't catch every possible error — only running the full 117 EBA validation rules will do that — but it will catch the most common ones before you waste a submission attempt.
📋 Data Integrity
☐All provider IDs in the ICT provider table (B01) are unique and stable — no duplicates, no recent changes
☐Every contract record (B02) references a provider ID that exists in B01 — verified with VLOOKUP or equivalent
☐Every service record (B03) references a contract ID that exists in B02
☐Sub-outsourcing records (B04) 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 of 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 — no more, no fewer
☐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 — not free-text descriptions
☐All date fields in exported CSVs are in ISO 8601 format (YYYY-MM-DD) — verify 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 in the ZIP (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've fixed the errors above and you're still getting rejected — or if the same errors keep coming back after you correct them — the problem usually isn't execution. It's architecture.
The DORA Register of Information is fundamentally a relational database problem that compliance teams have been asked to solve with spreadsheet tools. Excel has no foreign key enforcement. It has no entity-relationship model. It has no validation engine. It has no version control for identifier schemas. Every manual process that sits on top of it — ID maintenance, cross-tab consistency, controlled value lookups — is a risk that compounds as the register grows.
A register with 20 ICT providers and 40 contracts might be manageable in Excel with rigorous discipline. A register with 80 providers, 200 contracts, 400 services, and sub-outsourcing chains across three legal entities is not a spreadsheet problem anymore. It's a data management problem that requires a data management solution.
| Challenge | Excel / Manual approach | Purpose-built RoI platform |
|---|---|---|
| Foreign key integrity | Manual VLOOKUP checks; breaks silently on ID changes | 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 enumeration; 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 |
| Ongoing maintenance | Provider changes require manual updates across multiple tabs; high error risk | Single source of truth; updates propagate through the relational model automatically |
The firms that are cycling through repeated rejections aren't doing bad compliance work. They're using a tool that was never designed for this problem — and absorbing the cost in resubmission cycles, NCA portal access lockouts, staff time, and regulatory attention.
If your organisation has more than 30–40 ICT third-party providers, operates across multiple legal entities, or has already failed a submission twice, it's worth evaluating whether the spreadsheet approach is still the right tool for this job — or whether the time spent on manual validation would be better invested in a platform built around DORA's actual data model.
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 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 and supervisory follow-up beyond the submission itself. There are also cases where portal access is temporarily restricted after multiple failed attempts in rapid succession. Check your specific NCA's portal guidance for the rules that apply to you.
What do the EBA rule codes in the feedback file 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. We cover how to read feedback files efficiently in the companion article in this series.
Can I test my xBRL-CSV package before submitting to the NCA portal?
Some NCAs provide a test or sandbox environment for pre-submission validation. Check your NCA's portal documentation for availability. If a test environment isn't available, the most effective 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 validation step.
What if a third-party provider doesn't have an LEI?
Not all ICT third-party providers are required to have an LEI — LEI codes are primarily associated with legal entities that participate in financial transactions. The DORA taxonomy provides for cases where an LEI is not available or applicable. In these cases, you use the alternative identifier fields specified in the taxonomy, rather than leaving the LEI field empty or entering a placeholder. Entering a placeholder or dummy value 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. However, the Register of Information requirements apply broadly across in-scope financial entities. Groups may submit at the individual entity level, sub-consolidated level, or consolidated level depending on their structure — and the reporting scope affects which tables are mandatory. Check the ESA's technical guidance for your entity type and structure 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.
