Validation, export, and submission issues
Troubleshooting for DORA feedback files after export: returned ZIP statuses, CSV outputs, resubmissions, timestamps, and file-name checks to match the right version and fix the next step.
What this issue group covers
This page covers the problems that usually appear once you move from record preparation into export, returned feedback, and corrected resubmission. It focuses on validation feedback, returned response zips, CSV files, timestamps, file naming, and version checks.
Use this page when the issue is about what happened after you tried to export or after feedback came back through the competent authority.
Related
Issues covered on this page
Export shows validation errors
What this usually means
The export has surfaced a validation problem that still needs correction. If feedback has already been returned, the most useful check is the returned zip name and the CSV files inside it.
What to check and how to fix it
Check whether you are still at the export step or whether a feedback zip has already been returned.
If a returned zip exists, use that package first.
Check the returned zip name.
If it includes _NOK_, _PEN_, or _RES_, match it to REJECTED, PENDING_FURTHER_VALIDATIONS, or VALIDATION_RESULTS before deciding what to fix.
Check whether the returned zip is VALIDATION_RESULTS (RES).
If it is, use detailed-feedback.csv as the findings list before creating a new package.
Check whether the returned zip is PENDING_FURTHER_VALIDATIONS (PEN).
If it is, no detailed-feedback.csv will be present, so do not treat that as a separate missing-file problem.
Check whether the returned zip is REJECTED (NOK).
If it is, correct the technical issue and recreate the package before resubmitting it.
Related issues
I do not understand this status (PENDING_FURTHER_VALIDATIONS)
What this usually means
This is the acknowledgment-of-receipt response. It is not the same as a validation-results file.
What to check and how to fix it
Check whether the returned zip name includes _PEN_.
If it does, you are looking at PENDING_FURTHER_VALIDATIONS (PEN).
Check the zip contents.
For this response, instance-status.csv is present and detailed-feedback.csv is not.
Check that you are comparing the correct file by matching the file name elements exactly:
ReportSubject, CON/.IND, Country, FrameworkCodeModuleVersion, Module, ReferenceDate, and CreationTimestamp.
Check whether the competent authority has shared any later feedback for that same file.
Until then, do not treat the pending response as the full validation result.
Related issues
I do not understand this status (REJECTED)
What this usually means
This means the submission did not pass the technical layer of checks applied on receipt. The file needs correction and resubmission.
What to check and how to fix it
Check whether the returned zip name includes _NOK_.
If it does, you are looking at REJECTED (NOK).
Check the technical requirements for the reporting package.
If the file did not meet those checks, correct the issue before resubmitting.
Check that you are working from the latest created package by comparing the CreationTimestamp in the file name.
Check that the corrected file is recreated as a new package before it is resubmitted through the competent authority.
Related issues
My submission is being treated as a resubmission
What this usually means
This is resubmission logic, not a separate acceptance result. A file is treated as a resubmission when it is received from the same competent authority, about the same ReportSubject.CON/.IND, and for the same ReferenceDate, with a different timestamp in the file name.
What to check and how to fix it
Check whether the earlier feedback had findings in VALIDATION_RESULTS (RES).
If it did, the file needs correction and resubmission within the timeline indicated by the competent authority.
Check whether the corrected file is being sent through the same competent authority.
If not, it does not match the resubmission condition.
Check whether the corrected file is about the same ReportSubject.CON/.IND and the same ReferenceDate.
If not, it is not a correction of the same reported file.
Check whether the file name follows the same naming convention as the reported file, but with a different CreationTimestamp.
Check that the corrected package is the one actually sent back, not an older version with an earlier timestamp.
I do not know why I need a new timestamp
What this usually means
A corrected resubmission keeps the same naming convention as the reported file, but it must have a different CreationTimestamp.
What to check and how to fix it
Check the original file name and keep the same reporting identity elements:
ReportSubject, CON/.IND, Country, FrameworkCodeModuleVersion, Module, and ReferenceDate.
Check the corrected file name and confirm that CreationTimestamp is different.
If it is not, recreate the package.
Check that you are correcting the same reported file, not creating a different one for another entity level or reference date.
Check that the corrected package is resubmitted through the same competent authority within the timeline it gives.
I do not know why feedback files are returned in CSV
What this usually means
CSV is the intended response format. It is used because it is easier to open and filter than JSON, and VALIDATION_RESULTS can list all findings rather than only a limited subset.
What to check and how to fix it
Check whether you were expecting JSON.
If you were, switch to reviewing the returned CSV files instead.
Check whether you can open the files in a spreadsheet tool.
If not, import them there rather than reading them as plain text.
Check whether you need to sort or filter the findings.
If you do, work from the CSV files rather than reading them row by row.
Check whether the problem is really the file format or the absence of detailed-feedback.csv.
If the detailed file is missing, first check whether the returned response is PENDING_FURTHER_VALIDATIONS (PEN).
Related issues
The submission does not include the records I expected
What this usually means
Start with a file-identity comparison before assuming there is a record-level problem. This page only covers that first check.
What to check and how to fix it
Check ReportSubject in the file name.
If it does not match the reporting financial entity you expected, you are comparing the wrong file.
Check CON/.IND.
If it differs, you are comparing a consolidated file with an individual one, or the reverse.
Check Country, FrameworkCodeModuleVersion, and Module.
If any of those differ, you are not comparing like with like.
Check ReferenceDate.
If it differs, you are looking at a different reporting period.
Check CreationTimestamp.
If it differs, you may be reviewing an older or newer version of the package than the one you intended to compare.
I do not understand why this export is not ready to export
What this usually means
This section applies when you can see the exact label Ready to export but still do not know what to check next. Use the label as a starting point only, not as the full explanation of the problem.
What to check and how to fix it
Check whether an export package has actually been created for the item you are reviewing.
If not, stay on the export step first.
Check whether the issue is really about export creation or about later returned feedback.
If a returned zip already exists for the same file, switch to the returned-feedback checks on this page.
Check the file identity you are working from:
ReportSubject, CON/.IND, Country, FrameworkCodeModuleVersion, Module, ReferenceDate, and CreationTimestamp.
If those do not match the file you expected, you may be troubleshooting the wrong version.
Check whether the export action itself is blocked.
If it is, move to I cannot complete the export.
Related issues
I do not understand what Accepted by regulator means
What this usually means
This section applies when you can see the exact label Accepted by regulator but do not know how to read it alongside other feedback. Do not use the label on its own to explain validation findings or to replace the returned feedback files.
What to check and how to fix it
Check that you are looking at the correct file version by matching ReportSubject, CON/.IND, Country, FrameworkCodeModuleVersion, Module, ReferenceDate, and CreationTimestamp.
Check whether there are returned feedback files or a correction request for that same file.
If there are, use those first to understand what still needs attention.
Check whether you are using the label on its own to assume there were no findings.
If you are, go back to the returned feedback package instead.
Check whether a later corrected file exists with a newer CreationTimestamp.
If it does, review the latest file version before deciding what the current position is.
What to do next
Start by identifying which stage you are in: export, returned response, or corrected resubmission. If feedback has already been returned, match the zip name and the file name elements exactly before you change anything.
If the response is REJECTED (NOK), correct the technical issue and recreate the package. If the response is PENDING_FURTHER_VALIDATIONS (PEN), treat it as acknowledgment of receipt, not as full validation results.
If the response is VALIDATION_RESULTS (RES), use detailed-feedback.csv to correct the file and resubmit it through the same competent authority, using the same naming convention and report identity conditions, but with a different CreationTimestamp.