Making a mapping durable across periods and releases.

Why the mapping is the asset

A reporting file is a derivative product: given the source data and the mapping, it can be regenerated at any time. The mapping cannot. It encodes months of decisions about which source field means which reported concept, how your breakdowns aggregate to the framework’s, and how ambiguous instructions were read.

Everything that follows comes from taking that seriously. Fix defects in the mapping rather than in the file. Never hand-edit an output. And treat the mapping as something that is versioned, reviewed and owned rather than as configuration someone adjusts in place.

The three pressures

Versioning against releases

A mapping belongs to a framework release, not to a calendar. Version it with the release identifier, and record for every submitted package which mapping version and which framework version produced it. That single record answers most of the questions that arise months later, and it costs nothing to capture at run time.

Keeping past periods amendable

Amendments to a past reference date are made against the framework that applied to that date. If the mapping was upgraded in place, that framework version is no longer runnable and the amendment cannot be produced without reconstructing a mapping from memory.

The defence is simple and rarely implemented: keep superseded mapping versions runnable rather than only archived. Test that assumption occasionally by regenerating an old package and comparing it to what was submitted — if it does not reproduce, the ability to amend is already gone.

What to document

• Aggregations. Where your breakdown is finer than the framework’s, what was summed into what.
• Allocations. Where yours is coarser, how the split was derived and on what basis.
• Vocabulary choices. Which framework value was chosen for each of your values, and why — particularly where nothing fit well.
• Sign and scale decisions. Where the framework instruction differs from the ledger convention.
• Exclusions. Source records deliberately not reported, and the reasoning.
• Open questions. Readings you are not certain of, so a later reviewer inherits the uncertainty rather than the appearance of confidence.

Surviving a framework release

1. Diff the release against the version in use — tables, dimensions, rules and closed lists.
2. Run the existing mapping against the new framework with a known dataset, and read every finding rather than only the blocking ones.
3. Treat new tables as scope questions first, mapping questions second. A new table may not apply to you at all.
4. Re-derive frequency and thresholds, which releases also change.
5. Compare outputs between the old and new mapping on the same data, and explain every difference. An unexplained difference is a defect in one of them.
6. Cut a new mapping version and keep the old one runnable.

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.