Separate three kinds of problem
A file can fail because of its packaging or required structure, because values or relationships violate a validation rule, or because the business information is inaccurate. These problems require different owners. Renaming a file does not repair a missing contract relationship. Passing a technical rule does not establish that the supplier inventory is complete.
The EBA publishes reporting resources, technical checks and validation material. Use the version applicable to the reference date and the instructions of the authority receiving your submission. Do not assume the newest framework number applies to every module. Keep the downloaded rule set with the submitted version so another reviewer can reproduce the result.
For the underlying scope and template relationships, see our DORA register guide. The example below is a small reasoning exercise, not a replacement for the official templates.
A fictional broken reference
Suppose a contract inventory identifies an arrangement as DEMO-014. A separate service row refers to DEMO-041. The exercise intentionally uses simplified column names and fictional identifiers; these are not official field labels, real LEIs or an upload-ready DORA file.
| Record | Before correction | Verified source | After correction |
|---|---|---|---|
| Contract inventory | DEMO-014 | Reviewed agreement | DEMO-014 |
| Service reference | DEMO-041 | Same agreement | DEMO-014 |
| Internal error log | Reference unresolved | Investigation note | Corrected and rechecked |
The tempting fix is to add a new DEMO-041 contract to make the relationship resolve. That would create a record without a business basis. The proper investigation asks whether there are actually two agreements, whether the service belongs elsewhere, or whether the reference was mistyped. Only the supporting agreement can settle that question.
Trace the correction to its owner
Record the rule identifier exactly as received, the affected template and row, the reference date and the package version. Then trace the value to the source that owns it: procurement, legal, a service inventory or an entity register. Keep the initial error text rather than replacing it with your interpretation.
Agree the correction with that source owner. If an identifier is wrong in the procurement system, changing only the export leaves the defect ready to return next month. If the source is correct but the export transformation is wrong, fixing the business record would introduce a new error. This distinction belongs in the correction log.
An unavailable identifier is not a licence to invent one. Establish the permitted identifier type and the applicable instructions. Where information remains missing, record the owner, the request and the consequence for submission. Do not silently populate plausible-looking values to satisfy a non-empty check.
Recheck the whole chain
After the source or transformation is corrected, generate the package again and run the applicable checks. Compare the new error list with the previous one. A disappearing error can reflect a deleted service row as well as a genuine repair, so reconcile the entity, arrangement and service counts with the intended coverage.
Keep the exact submitted files, the validation output, the reviewer and the transmission receipt. Distinguish local validation, successful transmission and acceptance by the receiving authority. They are separate events. Where a warning can be accepted, record the reason and the authorised decision instead of calling the entire register clean.
A compact review before resubmission
Check that the reference date is correct, required relationships resolve, duplicate keys are understood and the included arrangements match the agreed perimeter. Ask the business owner to confirm the substance after the technical reviewer checks the structure. The same person may perform both roles in a small team, but both questions still need answers.
Download the worked reference example and correction log. It includes before-and-after rows and fields for the received error, source owner, correction and acceptance status. Its simplified data is for training; use the authority's actual reporting format for submission.
What a focused review should deliver
A useful engagement identifies the cause of the rejection, the responsible source, the change made and the evidence of revalidation. It should also state what was not checked. Reviewing a sample of contracts cannot substantiate completeness of every ICT arrangement in a group.
Dyasol can agree this work within the DORA evidence and readiness scope, with systems, records and submission responsibilities defined in advance. The scope page explains how additional work is agreed. Technical acceptance remains one part of an accurate and maintainable register.