Resubmission — correcting a return without breaking it
Nobody plans a resubmission process, and every reporting function eventually needs one. A resubmission is a corrected file for a reference date already reported. The mechanics differ by regime and by collection channel, but the decisions are the same everywhere: what to replace, how far back to go, which framework version to build against, and what to tell the authority.
1. Two models: replacement and delta
| Full replacement | Delta / incremental | |
|---|---|---|
| What you send | The complete return for that reference date, superseding the previous file | Only the records that changed, with an action indicator |
| Typical of | Template-based prudential returns | Granular record-level statistical collections |
| Main risk | Reintroducing a stale figure elsewhere in the return by rebuilding from a changed source | Orphaned records — a correction that updates a child without its parent, or deletes without a matching key |
2. How far back, and which version
Two rules cover most cases:
- Restate every affected reference date, in order. Cross-period validation rules compare consecutive reference dates, so correcting one period in isolation typically breaks the next one — which then looks like a new error rather than a consequence.
- Build against the framework version applicable to the reference date being corrected, not the current one. The applicable framework follows the reference date; a correction produced with today’s taxonomy for an older period will fail structurally.
Where the correction spans a framework change, that is a genuine complication rather than an edge case, and it is the reason to keep a per-reference-date record of the version and rule package used.
3. Telling the authority
A resubmission is a supervisory communication, not just a file transfer. Three things are usually worth sending or recording alongside it, even where the channel does not demand them:
- What changed and why — the figure, the cause, and whether it was a source error, a mapping error or a genuine restatement.
- The periods affected, and confirmation that all of them have been corrected.
- What has changed in the control environment so it does not recur. This is the part supervisors remember, and the part that distinguishes an error from a weakness.
Materiality thresholds and correction windows are set by the collecting authority rather than uniformly across the EU, so the local rule governs whether a small difference is corrected now, corrected in the next cycle, or logged and left. That is a question to settle with the authority in advance of needing it — not in the week you do.
FAQ
Do we resubmit the whole return or just the change?
It depends on the regime. Template-based prudential returns are typically replaced in full; granular record-level collections usually accept incremental corrections with action indicators.
Which framework version do we build a correction against?
The one applicable to the reference date being corrected. The applicable framework follows the reference date, not the submission date.
Should we correct an immaterial difference?
Materiality thresholds and correction windows are set by the collecting authority. Agreeing the threshold with them before you need it is far easier than negotiating it during an incident.
Related: Reference date vs remittance date · Validation rules · Nil returns
