Amended returns and resubmission in EBA XBRL frameworks.

Package replacement, not record correction

In the automatic exchange frameworks a correction points at an earlier record and replaces it. Supervisory reporting under the implementing technical standards works differently: the artefact is a report package for one entity, one level and one reference date, and an amendment is a fresh package for that same combination which supersedes the previous one.

Three consequences follow. Every amendment carries the full population, not a delta — so an error in one cell means regenerating everything. Nothing in the package identifies which figures changed, so the audit trail has to live in your own records. And the receiving system decides how it treats a second submission for the same key, which is a national portal behaviour rather than a framework one.

What triggers a resubmission

• An error found internally — a mapping defect, a source data correction, or a misapplied instruction.
• A finding raised by the authority, either from its own validation or from a supervisory query.
• A restatement in the underlying accounting or risk figures.
• A reinterpretation of an instruction that changes how a figure should have been derived for a past date.
• A scope correction — a template filed that should not have been, or omitted when it should have been filed.

What must stay stable

The taxonomy version question

Framework releases add, remove and redefine tables and rules. An amendment to an earlier reference date is made against the framework that applied to that date, which means the mapping for a superseded version has to remain runnable after the current version has moved on. Teams that upgrade a single mapping in place lose the ability to amend anything historic — a problem that only surfaces the first time an authority asks for a restatement.

Keep mappings versioned alongside the framework releases they belong to, and record which version each submitted package was built against.

Cross-period consequences

Some rules compare a reference date with its neighbours — opening balances against prior closing balances, movements against reported flows. Amending one period can therefore create findings in the next, which was consistent with the original figures and is no longer consistent with the corrected ones.

Before resubmitting, run the amended period and the following one, and decide deliberately whether the later period also needs amending. Fixing one period and leaving a contradiction in the next is worse than the original error, because it is now a visible inconsistency rather than a hidden one.

An operating process that holds

1. Log the defect with its cause classified as source data, mapping, instruction interpretation or scope.
2. Fix at the level the cause sits at — not in the generated package, which is discarded on the next run.
3. Regenerate against the original taxonomy version, preserving entity, level, reference date and row identifiers.
4. Revalidate, and run the adjacent period to see what the correction disturbs.
5. Record what changed, at figure level, in your own change log — the package will not tell you.
6. Confirm the portal’s treatment of a repeat submission for the same key before sending, particularly for a first amendment.
7. Retain both packages and both validation reports. The superseded one is part of the filing history.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.