Why your register was rejected, and how to fix errors 805, 806 and 807

Sources checked 18 October 2026. Rule texts are the EBA’s, from its rule list of 28 April 2025 (the EBA spells 807 “contraints”; we have corrected it). Severities are as the EBA and the CSSF published them in April and May 2025. Nothing here is legal advice.

Categories and rule texts: EBA rule list, 28 April 2025. Rejection or warning: EBA observations, April 2025 and CSSF guidance, 15 May 2025.

How the ESAs validate a register, and what “rejected” means

The EBA’s explanation of the validation feedback (10 February 2025) describes four categories of checks: technical validations, DPM technical checks, DPM business validation rules, and EUID and LEI checks. They run in sequence. First comes data reception, where the technical checks run on the package: file name, zip structure, UTF-8 encoding, the three metadata files, table headers, keys and foreign keys. A failure there ends in a reject (NOK) and nothing further is run. A file that passes is acknowledged, and then the DPM technical checks, the DPM business validation rules and the LEI and EUID checks run on it, and their findings are returned as validation results.

The response is built twice at most. A rejected file gets one zip whose name ends in _NOK_. An accepted file first gets an acknowledgement ending in _PEN_ (pending further validations), then the results ending in _RES_. Each zip holds a folder of the same name with instance-status.csv and, except for the PEN acknowledgement, detailed-feedback.csv. The detailed file has the header templateCode,rowCode/rowNumber,columnCode,ruleCode,message,offendingValue, with template codes in lower case and an underscore, such as b_05_01.

Which tab of the EBA’s rule workbook (28 April 2025) a rule sits in therefore decides its consequence. The CSSF states it plainly in its guidance of 15 May 2025: messages in the “Technical checks” tab are errors and result in rejection; messages in the “DPM Business Validation Rules” and “LEI-EUID checks” tabs are warnings that do not reject the register, although entities are expected to fix them and resubmit. In that workbook 805 and 807 are in the Technical checks tab, under the heading “Additional Plain-csv”, together with 801, 802, 808 and 809. 806 is in the DPM Technical Checks tab, with 305, 330, 331 and 503.

The EBA adds a caveat worth keeping in mind: its observations deck says the checks and messages implemented by national competent authorities in their own collection portals may differ from the EBA’s. A portal can refuse a file on a check the EBA treats as a warning. The order below is the EBA’s; your authority’s portal may be stricter, never looser.

Error 805: a key column is empty

What it says. “For open tables, the key columns values cannot be empty.” In the feedback file it appears as [table],[row],[column],805,For open tables, the key columns values cannot be empty,None, one line per empty key cell (CSSF, 15 May 2025).

What it means. Every template in the register is an “open table”: a list of rows that you define rather than a fixed grid. Each has a primary key, one column or a combination of columns, that identifies a row. A row with an empty key cannot be stored, so the EBA engine cannot load the table, and because it is a technical check the whole package is rejected. The EBA’s observations deck adds the consequence that catches people out: when a table fails to load on 805 (or 801), every other table that refers to it fails its foreign keys too, so one empty key column can arrive as a page of 807s.

Which columns are keys. The key columns are set in the EBA’s Data Model for the DORA RoI (shown in bold there) and in the taxonomy. This is the full list, from the EBA taxonomy 4.0, DORA module 1.1.0 (errata 5):

B_99.01 has no key. B_02.02 has eight key columns; it is also the template where the dry run found the largest share of missing information, 60% of it (ESA 2024 35, paragraph 32).

The causes we see most

1. The country keys in B_02.02 left blank. Columns c0130 (country of provision), c0150 (location of data at rest) and c0160 (location of data management) are key fields, so they cannot be empty. The CSSF’s instruction: where the value is not known, use the code eba_GA:qx2007, which stands for “Not applicable”; and never the country name: Ireland is eba_GA:IE, not “Ireland”.
2. A provider or parent with no identifier. B_05.01 c0010 is a key. Where a third-country provider or its ultimate parent has no LEI, the ESAs FAQ (Q40, quoted in the CSSF guidance) says to populate the field with any relevant identifier the provider has so the file is not rejected on referential integrity; the use of such an identifier is flagged as a data-quality warning, not a rejection. Declare the code type in c0020.
3. A function row without a function identifier, or a B_07.01 row without a service type. These usually come from a spreadsheet export where a merged cell or a filtered row left the key column empty on one line. The row looks complete to a person because the identifier is on the line above.
4. Empty rows at the end of a table. Sweden’s Finansinspektionen lists rows that are blank, or contain nothing but commas, as a cause of 805: the usual result of exporting a spreadsheet with formatted but empty lines. Delete those rows (FI, 4 March 2026).

How to fix 805

1. Read the templateCode, rowCode/rowNumber and columnCode on each 805 line. The CSSF’s examples quote line numbers of the CSV file, so open the file as text to find the row, not the spreadsheet it came from.
2. For each table in the list above, filter on an empty value in each key column. Do this in the CSV, not in the spreadsheet you exported it from.
3. Fill the cell with the correct value or the sanctioned placeholder (eba_GA:qx2007 for the three country keys; an alternative identifier for a provider with no LEI). Never delete the row to make the error go away unless the row is genuinely a duplicate or empty.
4. Re-run the keys check before looking at any 807: many of them will have been caused by the table not loading.

Error 806: two rows share the same key

What it says. “For open tables, you cannot have multiple rows with identical key values.” The feedback carries one line per offending row, with the key value in offendingValue; the CSSF’s example is a b_05.01 where lines 2 and 37 carry the same LEI, and since c0010 is the only key of that table, the value cannot appear twice.

What it means. The key of a table is the whole tuple of its key columns. For B_05.01 that is one column, so one provider gets one row, whatever name variants or contracts it has. For B_02.02 the key is eight columns: the same contract, entity, provider, function and service type at the same country of provision, data-at-rest location and data-management location. Two rows that match on all eight are a duplicate; two rows that differ on any one of them are not, and are frequently legitimate (the same service provided from two countries, for instance).

Does it reject? The official documents disagree. The EBA’s rule workbook of 28 April 2025 places 806 in the DPM Technical Checks tab, not in the Technical checks tab whose failures reject. The most-common-errors table in the EBA’s observations deck marks it “Leads to reject: NO”, and the CSSF guidance calls it a warning message, adding that financial entities are nevertheless requested to fix the issue and resubmit. Yet the 806 slide in that same EBA deck says that if a user reports the same key twice “it will be rejected with 806”. Add the EBA’s own caveat that national portals may run different checks, and the only safe reading is: clear every 806 before you submit.

The causes we see most

• One provider, several spellings. The provider list was built by appending contract extracts, so the same LEI appears with “Ltd”, “Limited” and “LTD”. The LEI is the key; the name is not. Keep one row.
• The signing table built from the service table. B_03.02 has the key (contract, provider). A contract with five service rows in B_02.02 produces five identical signing rows if the export is not de-duplicated. The same happens to B_07.01, keyed on (contract, provider, service type).
• A group register merged from entity registers. Each subsidiary listed the shared cloud provider and the shared parent; the consolidated B_05.01 then has them three times.

How to fix 806

1. Take the key tuple for the table from the list above and group the rows on exactly those columns.
2. Where a group has more than one row and the non-key columns agree, keep one.
3. Where the non-key columns disagree (two expense figures for one provider, two headquarters countries), the duplicate is hiding a data question. Resolve it against the contract or the provider’s GLEIF record; do not keep the first row by default.
4. If the rows differ because they should differ, one of the key columns is wrong, not the rule. A service delivered from two countries is two B_02.02 rows with different c0130, not one row twice.

Error 807: a reference points at a row that does not exist

What it says. “The reported data must follow the key-foreign key constraints defined in the DPM.” The feedback line names the source: the table, row and column that holds the value, and the value itself in offendingValue. It does not name the destination table; you find that from the Data Model, or from the list below.

What it means. The fifteen templates are one relational database. The taxonomy declares twenty-two foreign-key references: each value in a referencing column (or pair of columns) must exist as a primary key in another table, or in the same table. The match is exact: a value with an extra space does not match (FI, 4 March 2026), and the CSSF notes that a table not encoded in UTF-8 can trigger a high number of 807s. The CSSF separates the two kinds. “Across tables”: a contract reference in B_07.01 that is not in B_02.01. “Self-reference”: an overarching contract reference in B_02.01 c0030 that has no row in B_02.01 c0010, or an ultimate parent code in B_05.01 c0110 that has no row in B_05.01 c0010. Both are rejections.

All twenty-two references, grouped by what must exist

Reference numbers R1 to R22 are the taxonomy’s own (EBA taxonomy 4.0, DORA module 1.1.0).

The six pairs that fail most often

The CSSF lists the source and destination columns that most frequently trigger 807 in the registers it forwarded. Read each row as: every value in the source column must exist in the destination column.

CSSF guidance, 15 May 2025, rule code 807, examples table.

Why the ultimate parent is the usual culprit

B_05.01 asks for each provider’s ultimate parent undertaking in c0110, and the taxonomy declares that column a foreign key to c0010 of the same table (R18). So the parent is not just a name you write down against the subsidiary: it must have its own full row in B_05.01, with its own identification code, code type, legal name, type of person and country. A provider list built from “who do we pay” never includes the parent, because nobody pays it, so it never gets a row. The fix is one row per parent, and if the parent has no LEI, an alternative identifier declared in c0020 and used consistently. Two newer checks bear on c0110. Business rule v8855_m returns a warning when c0110 is empty on a row that has other values. The ESAs’ 2026 checks (E005, CAA annex, 15 April 2026) reject placeholder parent codes and say that where the parent is not known or does not apply, the field should be left blank. A blank warning is better than a placeholder that fails. Since 2026 the parent code is also compared with the ultimate parent GLEIF holds for a provider with an LEI (E018).

How to fix 807

1. First clear every 306, 801, 805 and 809 in the feedback. Each of those stops a table loading, and a table that did not load fails every reference to it. The EBA introduced 809 in May 2025 for exactly this reason.
2. Sort the remaining 807 lines by templateCode and columnCode. Match each pair to its destination in the list above.
3. For each offending value, decide which side is wrong. A contract reference with a typo is fixed at the source. A parent with no row is fixed at the destination by adding the row. A function identifier that B_06.01 defines for a different entity LEI is fixed by adding the function for that entity or by correcting c0020 in B_02.02.
4. Check the trailing and leading spaces, case and quotes on both sides. The comparison is exact; C-2023-014 and C-2023-014 are different keys.
5. If a B_02.01 row has type “subsequent or associated arrangement” (eba_CO:x3), c0030 must hold the overarching contract’s reference, and that contract must be a row of its own. If the type is standalone, leave c0030 empty rather than typing a filler, because any filler is a reference and will be checked.

A worked example, from feedback file to fix

A fictional bank, Veldhaven Bank N.V., submits for its group. The LEIs below are synthetic: they carry valid ISO 17442 check digits, and GLEIF returns “not found” for them. The provider and its parent are invented. Four things in the package are wrong.

c0010,c0020,c0030,c0040,c0050,c0060,c0070,c0080,c0090,c0100,c0110,c0120
7245009KESSELVOSCL89,eba_qCO:qx2000,,,Kesselvos Cloud B.V.,Kesselvos Cloud B.V.,eba_CT:x212,eba_GA:NL,eba_CU:EUR,1840000,7245009KESSELVOSHL44,eba_qCO:qx2000
7245009KESSELVOSCL89,eba_qCO:qx2000,,,Kesselvos Cloud BV,Kesselvos Cloud BV,eba_CT:x212,eba_GA:NL,eba_CU:EUR,1840000,7245009KESSELVOSHL44,eba_qCO:qx2000

c0010,c0020,c0030,c0050,c0060,c0130,c0150,c0160
C-2023-014,7245009VELDHAVENBK96,7245009KESSELVOSCL89,F7,eba_TA:S18,eba_GA:NL,eba_GA:IE,
C-2023-015,7245009VELDHAVENBK96,7245009KESSELVOSCL89,F9,eba_TA:S02,eba_GA:NL,eba_GA:NL,eba_GA:NL

The EBA’s engine returns a NOK zip. Its detailed-feedback.csv, constructed here from the EBA’s header and the message texts the CSSF documents (the EBA does not publish how it numbers rows or orders lines), would read:

templateCode,rowCode/rowNumber,columnCode,ruleCode,message,offendingValue
b_02_02,1,c0160,805,"For open tables, the key columns values cannot be empty",None
b_05_01,1,c0110,807,The reported data must follow the key-foreign key constraints defined in the DPM,7245009KESSELVOSHL44
b_05_01,2,c0110,807,The reported data must follow the key-foreign key constraints defined in the DPM,7245009KESSELVOSHL44
b_02_02,2,c0050,807,The reported data must follow the key-foreign key constraints defined in the DPM,F9

Reading it line by line:

1. 805 on b_02_02 row 1, c0160. The location of data management was left empty on the first service row. It is a key. The data is managed in Ireland, so the value is eba_GA:IE; had it genuinely not applied, eba_GA:qx2007.
2. 807 on b_05_01 c0110, twice. Kesselvos Holding is named as the ultimate parent in c0110 but has no row of its own. Add it:

   7245009KESSELVOSHL44,eba_qCO:qx2000,,,Kesselvos Holding B.V.,Kesselvos Holding B.V.,eba_CT:x212,eba_GA:NL,,,,

   The holding has no parent above it, so its own c0110 and c0120 are left blank, which the 2026 checks prefer to a placeholder; v8855_m may return that blank as a warning, which does not reject. c0090 and c0100 are empty because nothing is paid to the holding directly; the CSSF’s note on rule 305 says the annual expense in c0100 is expected where the provider is a direct provider, which the holding is not. The rest of the row must be complete, or v8850_m and the other mandatory-value rules will come back as warnings.
3. 807 on b_02_02 row 2, c0050. Function F9 is used but B_06.01 defines no F9 for the bank’s LEI. Either the identifier is a typo for F7, or the function was never added to B_06.01. Check the function list; the fix is on whichever side is wrong.

The fourth fault is not in the NOK file. B_05.01 lists Kesselvos Cloud twice, under the same LEI with two spellings of the name. That is an 806, and 806 is listed among the DPM technical checks, which on the EBA’s documented sequence run only after a file has passed reception. So on that sequence it surfaces in the RES file after the other faults are fixed, not now. A national portal may catch it earlier, and the EBA’s own deck is inconsistent on whether it rejects (see above). Remove the second row now: the LEI is the key, and names that differ only in punctuation make this a de-duplication, not a data question.

Two of the four lines in the NOK file come from one missing row. After the fixes the package passes the technical checks, is acknowledged with PEN, and the RES file then reports whatever warnings remain.

The resubmission procedure, in order

1. Read instance-status.csv first. feedbackMain tells you whether this is a rejection (REJECTED), an acknowledgement (PENDING_FURTHER_VALIDATIONS) or results (VALIDATION_RESULTS). Only a rejection means the register was not accepted.
2. Group detailed-feedback.csv by ruleCode. A register with one systematic mistake produces thousands of identical lines. Count them per rule and template before reading any of them.
3. Fix in loading order. Package and encoding (103, 306, 714, 720, 723, 724), then headers and rows (801, 802, 809), then filing indicators (808), then empty keys (805), then references (807), then duplicates (806). Each layer can mask the next; the EBA says a table that fails 801 or 805 makes the 807s that follow “expected behaviour”.
4. Re-run the checks locally before you upload. The rules are public and deterministic. The DORA Register Checker runs the EBA’s package, header, key, foreign-key, closed-list and format rules on your zip or CSVs in your browser, under the EBA’s own rule codes, and exports its findings with the detailed-feedback.csv columns plus a severity column, so the two files can be compared line for line.
5. Rebuild the package, do not patch it. A new zip with a new creation timestamp in the file name, the same entityID and reference date in parameters.csv, all fifteen templates declared true in FilingIndicators.csv, every file UTF-8.
6. Resubmit to your competent authority, which forwards the file to the ESAs. Then wait for the RES file and work through the warnings: they do not reject, but they are what the authority will ask about.

What happens if it is still wrong: the 2026 cycle

The register is collected once a year by each competent authority and forwarded to the ESAs. In the 2026 cycle the data was as at 31 December 2025, and the authorities we checked set these windows (as of 18 October 2026):

• Luxembourg (CSSF), communiqué of 17 March 2026: submission by 31 March 2026 (30 June 2026 on a best-effort basis for third-country branches of credit institutions). The ESAs perform additional quality control checks throughout April 2026; an entity whose register fails them must fix the errors and resubmit to the CSSF, which forwards it again to the ESAs before the end of April. As of 16 March, only 40% of the entities required to submit had done so.
• Ireland (Central Bank of Ireland), page updated 29 January 2026: data as at 31 December 2025, submission window 2 to 31 March 2026 via the Central Bank Portal; technical validation in March, then the EBA runs data-quality checks on all registers in April, which can lead to a request to resubmit.
• Malta (MFSA), circular of 5 March 2026: reporting period 1 January to 21 March 2026; the ESAs’ additional checks in April 2026 can produce feedback on a register that already shows “Accepted” on the portal, with resubmission expected by 30 April 2026.

Three things follow. A rejection in the last week of the window leaves you no time to correct and resubmit inside it. “Accepted” at the portal is the technical stage only; the April checks come afterwards. And the April checks in 2026 went beyond the 2025 rule list. The MFSA circular’s annex gives examples, and the annex to the CAA note of 15 April 2026 lists the full set, codes E001 to E023. They include a generic value such as “not applicable” or “LTD” as a provider name (E001, E002); a code containing DUMMY, INVALID or NOTAPPLICABLE, or equal to 0, NONE, TRUE or FALSE, as a provider or ultimate parent code (E003, E005), such as 9999999DUMMY99999999; an identifier reported with its type inside the code, such as “GB_CRN_…” or “US EIN#…” (E006, E009); a code shorter than five characters (E012); an LEI that does not correspond to the provider name reported (E013); an ultimate parent code that does not match the parent GLEIF holds for that LEI (E018); and the same non-LEI code used for providers with different names (E022). The placeholder that gets you past 805 and 807 is now checked for being a placeholder.

The next window is set by your authority’s communiqué for that year; the dates above are the ones we have verified for 2026, so check your authority’s current notice. The obligation itself is Article 28(3) of Regulation (EU) 2022/2554; the templates and their keys are Implementing Regulation (EU) 2024/2956.