Reporting governance — who signs, and on what basis
Most reporting sign-offs certify that a return was submitted. Almost none certify that it is right — and the difference is the entire point of the control. A supervisor examining a reporting function does not ask whether files went out on time; that is visible from their own records. It asks how the firm knows the figures are correct, who decided that, and on what evidence.
1. What each line actually owns
| Line | Owns | Failure mode |
|---|---|---|
| First — reporting team | Production, mapping, validation, submission and the archive | Owning the numbers and the assurance over them |
| Second — risk or compliance | The framework: that obligations are identified, owned and controlled | Reviewing outputs rather than the control design |
| Third — internal audit | Periodic independent testing of the whole chain | Testing timeliness because it is measurable, not accuracy because it is not |
2. What a sign-off should certify
A useful sign-off is specific about what is being asserted. Four statements, each capable of being evidenced:
- the return was built from a pinned extract at the correct reference date, against the framework version applicable to it;
- the validation results are clean, or the exceptions are listed with explanations;
- the reconciliations ran, and the reconciling items are attributed;
- known data gaps affecting the return are listed, with their effect described.
That fourth item is the one most firms omit and the one supervisors value most. A return filed with a disclosed, quantified limitation is a controlled outcome. The same return filed silently is a finding waiting to happen — and the difference is entirely in whether somebody wrote the limitation down before submitting.
3. The obligations register is the foundation
Everything above assumes you know what you owe. The register that supports it needs five columns, and the third is the one that goes stale:
- the obligation and its legal source;
- the trigger type — calendar, threshold, lifecycle event, suspicion, or a maintained state;
- the perimeter test that puts you in scope, and when it was last checked;
- the owner, named individually;
- the channel, and the status of the enrolment.
Reviewing the perimeter column annually is more valuable than reviewing the whole register, because the obligations are stable and what changes is whether you are inside them. A new product, a new market or a new customer segment can move a firm into a return without anything in the return itself changing.
4. Controls that match the trigger
A single control model cannot serve every obligation, because the ways they fail differ:
- Calendar obligations fail by lateness — control: a due-date monitor plus acknowledgement matching.
- Threshold and lifecycle obligations fail by omission — control: a reconciliation between the population that should have generated a filing and the population that did.
- Maintained registers and connections fail by decay — control: periodic completeness reconciliation against an independent source, and for a connection, an availability check.
- Suspicion obligations fail by non-escalation — control: evidence that assessments are recorded, including those that concluded no report was needed.
5. What an inspection actually asks
Facts: a supervisor selects one figure from a return filed a year ago and asks how it was derived.
What answering it requires: the submitted file and its acknowledgement, the pinned extract behind it, the mapping version in force at that reference date, the validation output, and the sign-off record. Five artefacts, all of which exist as a by-product of a well-designed process and none of which can be reconstructed convincingly after the fact.
What the practitioner does: archives those five together, keyed to the reference date rather than the submission date — because every query, correction and restatement arrives addressed to a reference date. An archive organised by when you filed cannot answer a question about what you filed for, which is the only question anyone ever asks.
FAQ
What should a reporting sign-off certify?
That the return was built from a pinned extract at the right reference date and framework version, that validation is clean or exceptions are explained, that reconciliations ran and items are attributed, and that known data gaps are disclosed.
Is it acceptable to file with a known limitation?
Filing with a disclosed and quantified limitation is a controlled outcome. Filing with an undisclosed one is the finding.
What should be reviewed annually?
The perimeter column of the obligations register. The obligations are stable; what changes is whether the business is inside them.
Who should not sign the return?
The person who built it, acting alone. Where one function builds, validates and signs, there is no independent challenge anywhere in the chain.
6. Escalation, before it is needed
One further element belongs in the framework and is almost always written after the first incident rather than before it: a defined route for the decision not to file on time, or to file with a known error.
Both situations arise. A source system fails in the submission window; a material error is found the day before a deadline. The question in each case is the same — file late and correct, or file on time and restate — and it is a judgement with supervisory consequences either way. Deciding it under time pressure, without an agreed route or a named decision-maker, produces the worst of both: a late decision that nobody owns and no record of why it was taken.
Related: Building a reporting pipeline · Reconciling returns · Reporting channels compared
