Skip to main content
FAQ
EBA RF 4.0 / DORA module 4.0

Start here if you need to know what we handle, what you keep, and how the workflow gets a workbook over the line.

Practical answers in plain language for teams preparing, validating, and packaging a DORA filing. The first answers focus on scope, responsibilities, pricing logic, and support; the later ones go deeper into rules, package details, and operational questions. When you need more detail, the product links findings back to the source behind the decision.

We handle workbook structure checks, official value lists, published DORA rules, FAQ clarifications, cross-template links, identifier hygiene, country consistency, package checks, and plain-language findings. Optional online GLEIF and VIES checks add live registry evidence where those identifier types are used. That means your team can stay in Excel while we take care of the validation and package mechanics that normally need specialist tooling.

The active ruleset is shown in the product, findings are grouped by template and field, and each finding is labeled by source category so your team can review what was checked and why. The workflow is designed to be understandable, not opaque.

Your team remains responsible for the workbook content, the business decisions behind the data, reviewing warnings, and submitting the final package through the regulator's portal. We take over the validation, explanation, and package-generation mechanics around that process.

The workspace is activated once per workbook. After that, you can upload fixes and validate again as often as needed. The workspace includes one xBRL-CSV package build. If the AFM rejects your submission, you get a free rebuild.

Uploaded workbooks are processed only for the active session. We do not keep workbook data in a database, and the workflow is designed around data minimization and storage limitation. The generated package is held only as a temporary, time-limited download and is removed when that link expires. If you ask us to email the package to you, that address is used only to send that one message and is not stored.

Yes. Use the contact page if you want a quick go/no-go check before buying, help before upload, support after validation, or a second pair of eyes close to a filing deadline.

No. We generate and validate the package, but submission still happens through your regulator's own portal. We get the file ready; your team keeps control of the final submission.

It is the ZIP package regulators expect for DORA submissions. We generate the CSV files, report metadata, and package structure from the workbook so your team does not need XBRL tooling to produce the required output.

All 15 templates from B_01.01 through B_07.01 plus B_99.01 are supported. We validate each template and the links between them against the EBA Reporting Framework 4.0 taxonomy.

We show the live DORA ruleset this service validates against: EBA RF 4.0 / DORA module 4.0. The EBA's Reporting Framework pages describe later framework releases, but DORA remains on its current production track until the next applicable release is ready.

When online checks are enabled, we verify LEIs against GLEIF for existence, status, legal name, and country consistency, and VAT numbers against VIES where relevant. We also check identifier format, EUID and VAT country-prefix consistency, placeholder values, whitespace, and cross-template name or country mismatches.

You can upload corrections and validate again as often as needed within the same workspace. When the workbook is ready, you generate one xBRL-CSV package build. If the AFM rejects your submission, contact us for a free rebuild.

We check workbook structure, required fields, official values, data formats, max lengths, identifier hygiene, country consistency, cross-template links, FAQ clarifications, optional online checks, and the published DORA rule inventory. In total that means 58 published rules plus 103 locally enforceable checks, with each finding labeled by source.

Warnings usually do not block package generation, so your team can keep moving, but they should still be reviewed before submission, especially when they relate to coverage or live registry checks.

This service is operated publicly through dora-convert.com. The aim is to make validation decisions understandable, not opaque.

We accept .xlsx, .xlsm, and .xlsb workbooks. Starting from the supported .xlsx template available on this site is the safest option.

If the AFM rejects your submitted package, you are entitled to one free rebuild after a brief phone consultation with our team. Use the contact form, select 'Rejected AFM build' as the reason, and we will reach out within 24 hours to discuss the rejection and prepare a corrected package at no extra cost.

The package is returned as a temporary download in the active session. Download it and submit it through your regulator's portal. You can also optionally have it emailed to you from the download step. It is attached when small enough, otherwise the email contains a temporary download link. If you need it again later, generate a new package.

Arelle checks xBRL-CSV technical conformance: taxonomy dimensions, datatype formats, filing indicators. That is the final layer. But most rejections and rework come from data content: wrong codes, missing cross-references, inconsistent countries, incomplete fields. We check 58 published DORA business rules, 103 locally enforceable checks, cross-template links, identifier hygiene, and live registry evidence, before the package is even built. Arelle-only tools tell you "your package is invalid." We tell you which field, in which template, breaks which rule, and what to do next.

Technical xBRL validation covers roughly 10–15% of what can go wrong. The rest (business rules, cross-template consistency, identifier existence, required-field completeness, country logic) is invisible to Arelle. We cover both layers: data quality at the Excel level and package integrity at the archive level. If your current tool only runs Arelle, you are flying blind on the content.

Free tools typically convert without checking. They will produce a ZIP that opens, but will not catch a LEI that does not exist, a contract reference that points nowhere, or a country code that contradicts the entity's registration. Our validation engine runs 103+ checks with source-backed findings before a single package file is written. For a filing this consequential, the risk of submitting a package that looks valid but gets rejected is the expensive part.