The reporting operating model — roles that work
Reporting functions fail organisationally more often than technically, and almost always in the same way: one person understands the whole chain. That person builds the return, decides what the numbers mean, signs it off and answers the queries. It works until they are on leave during a deadline, or until they leave altogether — and it is a control weakness long before it is an incident.
1. Four capabilities, not four people
| Capability | Answers | Sits with |
|---|---|---|
| Obligation ownership | What do we owe, to whom, on what trigger | Compliance or a reporting lead |
| Content ownership | What does this figure mean, and is it right | The business function that generates it — finance, credit, financial crime |
| Production | How is the file built and submitted | Reporting or engineering |
| Assurance | How do we know it is right | Someone other than the builder |
In a small firm these are four hats, not four headcount. What matters is that the hats are visibly distinct, and that the assurance hat is worn by someone who did not build the return.
2. Content ownership is the missing role
This is the capability most commonly absent. A statistical return describing customer funds has a content owner in finance; a credit register return has one in credit; a fraud return has one in financial crime. Their job is not to build anything — it is to look at the output and say whether it describes the business they run.
Where that role does not exist, the reporting team ends up asserting things about a business it does not operate, which is exactly the position that produces a confident sign-off on a wrong number. The fix is cheap: a named reviewer per return, reviewing the output and not the file, on a defined cadence.
3. What to centralise, and what not to
For a group operating in several markets, the split that works is consistent:
- Centralise the data model and the pipeline. One intermediate model, rendered per market. This is where the economies are, and it is what makes cross-return reconciliation possible.
- Centralise the obligations register and the framework-release process, because both benefit from one view.
- Localise the perimeter assessment. Whether an obligation applies depends on national law and national supervisory practice, and it needs someone reading the national text.
- Localise the supervisory relationship and — where the market requires it — the language. Filings and correspondence in Germany, Italy and France proceed in the local language, which is a resourcing dependency rather than a preference.
The failure mode at each extreme is predictable. Fully centralised produces a group function that files confidently against a perimeter it has misread. Fully localised produces five pipelines that disagree with each other and no ability to reconcile.
4. Capacity planning nobody does
Two planning inputs are worth making explicit because they are invisible in a headcount model:
- Deadline clustering. Several returns falling in the same week is a capacity problem even when each is individually manageable — and the constraint is usually the approver, not the builder.
- Framework releases. A release is a project with an externally set date and no option to descope. Treating it as business-as-usual work absorbed by the same team is how releases arrive late.
Mapping the calendar by approver rather than by return exposes the first immediately, and it is a five-minute exercise that frequently reveals one person on the critical path for six returns in a single week.
5. A worked case
Facts: a firm’s entire reporting capability rests with one experienced analyst who built every return, holds every credential and answers every query.
What the exposure is: not competence — the analyst is good — but concentration. There is no assurance, because the builder assures their own work. There is no continuity, because the mapping exists as code and knowledge rather than as a document. And there is no capacity resilience for a deadline that collides with an absence.
What the practitioner does, in order: writes the mapping down, because it is the artefact that makes everything else transferable; names a content owner per return in the business function that generates the figures; moves credentials so at least two people can submit; and gives assurance to someone else, even if that is a single reviewer looking at output rather than a formal second line. None of that requires a hire.
FAQ
Do we need four people?
No — four capabilities. In a small firm they are hats, provided the assurance hat is worn by someone who did not build the return.
What is usually missing?
Content ownership. Someone in the business function that generates the figures who reviews the output and says whether it describes the business they run.
What should be centralised in a group?
The data model, the pipeline, the obligations register and the release process. Perimeter assessment, the supervisory relationship and local language capacity stay local.
Related: Reporting governance and sign-off · Outsourcing reporting · Building a reporting pipeline


