The DORA xBRL-CSV format, explained
Why an Excel register can't be filed as-is, what actually sits inside an xBRL-CSV package, and which EBA taxonomy rules decide whether your submission goes through — or bounces.
In short — xBRL-CSV is the EBA's mandated submission format for the DORA Register of Information: structured .csv tables built against a published taxonomy and a DPM (Data Point Model) dictionary, packaged together with their metadata. Converting Excel to CSV is the easy part — matching every value to the DPM dictionary is what actually decides whether the package is accepted.
What the xBRL-CSV format is
XBRL is the international standard for structured regulatory reporting. Its xBRL-CSV variant carries the same structured data in .csv files — lighter than the XML instance documents used elsewhere in XBRL — organised against a taxonomy and a DPM (Data Point Model) data dictionary published by the EBA. This is the format the DORA Register of Information must be submitted in.
In practice, that means your register isn't "an Excel file" that gets exported once. It's a set of normalised tables that have to match, field for field, what the taxonomy defines — column names, data types, allowed value lists, and the cross-references between tables.
Why the EBA chose this format
xBRL-CSV lets supervisors automate validation at scale: every field carries a declared type, a closed set of allowed values, and defined relationships to other templates. That makes processing reliable on the regulator's side — but unforgiving on yours. Anything that doesn't conform is rejected by the machine, with no room for interpretation and no manual override at the intake stage.
It isn't judged only on what the register says — it's judged on the exact way it's coded.
What's inside an xBRL-CSV package
A submission isn't a single file — it's a structured archive. Schematically, a DORA package looks like this:
├─ META-INF/ — report metadata
├─ report.json — entry point (EBA DORA module)
├─ b_01.01.csv — reporting entity
├─ b_05.01.csv — ICT third-party providers
└─ … — the other templates, present even when empty if required
The file naming, the folder tree, the report.json entry point, and the entity identifier (in the form rs:{LEI}.IND, or .CON for a consolidated submission) all have to be exact. One file missing or misnamed and the whole package is invalid — even before the taxonomy engine looks at a single value. The 15 templates that make up the register are described in full in the tables of the DORA register.
The taxonomy and the DPM dictionary
The DPM (Data Point Model) is the dictionary that defines, for every column, the list of allowed values. A country isn't written out as "France" — it's coded as the DPM member matching the ISO code FR. The same closed-list logic applies to arrangement types, the criticality of a service, or the nature of a provider: free text is never valid where the taxonomy expects a code.
The full reference of allowed values, mapped table by table, is kept in the DPM values of the DORA register.
What causes a package to be rejected
- Encoding that isn't
UTF-8(broken accented characters, an unexpected BOM); - DPM value out of range — free text where a closed list is expected;
- Date format that isn't ISO (31/12/2026 instead of 2026-12-31);
- an invalid LEI, or one that's lapsed in the GLEIF register;
- a mandatory template missing or incorrectly named;
- cross-template inconsistency — a provider or arrangement referenced on one side and absent on the other.
At the EU dry run, only about 6.5% (ESAs, 2024) of registers passed on the first attempt — almost never because of substance, but because of exactly these technical details. Full breakdown of the causes: why registers get rejected.
Check conformity before you generate the package
DoraReady checks your register against the EBA's 116 validation rules, shows you plainly what would be rejected and how to fix it, then generates a conformant xBRL-CSV package. Everything runs in your browser: your register is never sent to a server.
Run the free diagnosticConverting a register from Excel to xBRL-CSV
Converting the shape — Excel rows into structured CSV files — is the easy part, and several free tools will do it. The real difficulty is content conformity: DPM values, cross-table consistency, completeness. A package that's "well converted" but carries invalid values gets rejected exactly like a badly converted one. That's where checking against the EBA's validation rules before you generate the package makes the difference — catching it before submission, not after a rejection notice.