My file failed validation
Troubleshoot validation failures by checking the response ZIP, fixing flagged rows and key values, then resubmitting a fresh export with the correct file naming.
What this usually means
Your file did not pass one of the checks applied during submission.
You may see three response states. A REJECTED (NOK) response means the file failed a technical check and was not taken forward. A VALIDATION_RESULTS (RES) response means the file passed the initial technical stage but failed later validation checks on the reported data. A PENDING_FURTHER_VALIDATIONS (PEN) response is an acknowledgement stage and may not yet include detailed findings.
Why this happens
-
The submitted file failed a technical check.
-
A key value is empty.
-
A reported value uses the wrong format or code.
-
An extra row was added for another valid value, but the added row is incomplete or duplicates key values.
-
A linked identifier is inconsistent across templates.
What to check and how to fix it
Check the response type in the ZIP first.
If it is REJECTED (NOK), treat it as a technical failure.
If it is VALIDATION_RESULTS (RES), open instance-status.csv and detailed-feedback.csv and work from the findings listed there.
If it is PENDING_FURTHER_VALIDATIONS (PEN), use it as an acknowledgement that later checks are still pending.
In that case the ZIP may not include detailed-feedback.csv.
In detailed-feedback.csv or instance-status.csv, start with the exact template, field code, and row named in the finding.
Then check that same data point in your record or export.
If the finding points to a missing value, wrong code, or wrong format, correct that specific value first before reviewing wider template logic.
Check blank values against the field rules.
Mandatory non-key fields may be left blank unless the field instructions or published Q&A say otherwise, but those blanks can still appear as data quality issues.
Key fields cannot be empty. If you cannot provide a value for a field identified as a primary key in the data model, report Not Applicable in that field.
Check added rows only where the instructions allow more than one value.
If you added another row for another valid country or relationship, complete the whole added row, not just the changed field. Then check that the added row does not duplicate key values.
If it does, it can be flagged in the data quality feedback as duplicate values.
If the issue is REJECTED (NOK), check the rejected package against the required technical submission setup.
Confirm that you exported a reporting ZIP and that the ZIP name follows the required convention for report subject, consolidation level, country, framework code, reference date, and creation timestamp.
Check linked identifiers wherever the same record is reused.
In particular, compare the Contractual arrangement reference number, Identification code of ICT third-party service provider, Type of code to identify the ICT third-party service provider, and Function Identifier across the affected templates.
If one of those values is missing or inconsistent in one template, fix it there and export again.
After correcting the flagged issues, submit a fresh export.
Where the feedback contains VALIDATION_RESULTS findings, the resubmission should follow the same naming convention as the reported file, with a different timestamp in the file name.
What happens next
Once the corrected file is resubmitted, it should either pass the earlier failed check or return more specific findings that narrow the next fix. No findings at this stage is useful, but it does not mean the register is fully accepted for every later use or analysis.