Validation rule — why your submission was rejected
Validation rules are the part of a reporting framework that actually decides whether your file exists. They are published with the framework, they are part of the data point model rather than an add-on, and — critically for planning — they change more often than the framework itself. The European Banking Authority issues updated or small validation rule packages on a quarterly basis, which means a submission that passed last quarter can fail this one with no change to your data.
1. What they test
| Kind | What it checks | Typical cause of failure |
|---|---|---|
| Structural | The file is a valid instance of the taxonomy in force | A superseded taxonomy edition, or a module whose applicability has moved |
| Intra-template | Internal arithmetic — totals equal the sum of their parts | Rounding applied inconsistently, or a component mapped into the wrong dimension |
| Cross-template | The same data point reported in two places agrees | Two source queries built independently for what is one data point |
| Cross-period | Consistency against a prior reference date | A restatement that was applied to one period and not carried through |
| Plausibility | Values fall within expected ranges | A genuine business change — which needs explaining, not fixing |
2. The quarterly cycle, and what to do with it
Because validation rule packages are published quarterly, the rule set is a moving target inside a stable framework version. Three habits follow:
- Re-run last quarter’s accepted file against this quarter’s rules before building the new one. It is the cheapest possible early warning, and it separates “our data changed” from “the rules changed”.
- Track deactivated rules. Rules are sometimes withdrawn or corrected; a control built around a rule that no longer exists is a control that silently stopped working.
- Keep the failure log. The pattern of failures over time is the best available map of where your data model and the framework disagree.
3. National rules on top
The framework rules are a floor. National competent authorities routinely operate additional checks in their own collection systems, and those are the ones that generate the last-minute rejections, because they are not in the package a vendor tool ships with. A submission process that validates only against the framework rules will discover the national layer at the remittance deadline.
The practical answer is to validate twice: once against the framework rules, early, and once against the authority’s own channel as far ahead of the deadline as the channel allows — which for most collection systems means submitting a test file rather than waiting.
FAQ
Why did a file that passed last quarter fail this quarter?
Most often because the validation rule package changed. Updated or small packages are published quarterly, independently of the framework version.
Should every validation alert be resolved before submitting?
Blocking failures must be. Non-blocking ones may reflect a real business change, and the right response is a documented explanation rather than an adjustment.
Are the published rules the complete set?
No. National competent authorities commonly apply their own additional checks in their collection channels, which is why an early test submission is worth more than a late internal validation.
Related: Resubmissions and corrections · XBRL taxonomies · What is supervisory reporting
