Seven rules from building a governed metric layer for a multi-entity group
Every reporting programme I have worked on eventually arrives at the same meeting. Two people have brought numbers for the same measure, for the same period, and the numbers disagree. Everyone in the room is competent. Everyone has done the work. And the next forty minutes go on establishing whose spreadsheet is right rather than what the business should do about the result.
The instinct is to blame the pipeline. It is almost never the pipeline.
The pipeline moved the data correctly. What failed is that nobody could say what the measure means, who agreed that meaning, when it last changed, or which file the figure came from. That is a governance gap, not an engineering one, and you cannot close it by adding another orchestration tool.
I spent this year building InventPulse 360, a governed financial and operational reporting platform consolidating eight P&L entities for month-end close and executive reporting. I wrote the BRD, PRD and solution blueprint, then built the thing and shipped it to production. Roughly 400 group and entity-level metrics, all governed.
What follows is what I would tell anyone starting the same work. It is less about tooling than you might expect.
1. A metric definition is an artefact, not a convention
In most organisations a KPI definition lives in three places: a slide from two years ago, a formula in a workbook, and the head of the analyst who built it. All three drift. None is authoritative.
Treat the definition as a versioned artefact instead. It has an identifier, a version number, an owner, a status, and a change history. When a figure is published, it names the definition version it was calculated under.
This sounds bureaucratic until the first restatement. When a number changes between cycles, you are no longer arguing about whether someone made a mistake. You are pointing at a version bump and explaining what changed and why. Restatement becomes explainable rather than embarrassing.
The rule I worked to: a KPI may only be published when its definition version, source coverage, reporting grain and quality status are all known. If any of the four is unknown, it does not publish. Not "publish with a caveat". It does not publish.
2. Definitions belong in configuration, not code
If changing "gross margin" requires a developer, a pull request and a release, two things happen. Changes get batched, so they arrive slowly. And someone eventually works around you in a spreadsheet, which is how you got here.
Hold definitions as configuration. A finance owner proposes a change, it moves through review, and it takes effect on the next run without a deployment. Engineering owns the engine; the business owns the definitions.
The certification workflow I used ran draft -> under review -> certified -> superseded -> retired. Only certified definitions can produce a published figure. Draft definitions can be calculated and inspected, so people can see what a proposed change would do before agreeing to it, which turns definition debates into evidence rather than opinion.
3. Never average a percentage
This is the most boring rule here and it causes more silent errors than anything else on the list.
If three entities report margins of 40%, 50% and 60%, the group margin is not 50%. It is total contribution over total revenue, and the answer depends entirely on their relative sizes. Averaging pre-aggregated ratios produces a number that looks plausible, sits in a board pack, and is simply wrong.
So: ratios and rates are always recomputed from additive numerators and denominators. Store the numerator and the denominator, carry both up through the aggregation, and divide at the point of presentation. Never carry the ratio itself and combine it.
Where an exception is genuinely required, such as a weighted average of something with no natural denominator, it must be declared explicitly in the definition, not assumed by whoever wrote the query.
4. Quarantine exceptions. Do not coerce them.
The tempting shortcut is to make bad records disappear. Null becomes zero, an unparseable date becomes the period start, an unmatched entity code gets dropped. The pipeline stays green and the report generates cleanly.
You have just made a silent accounting decision on behalf of the business.
Invalid records get quarantined and stay visible, with an owner and a status. They are never silently deleted or coerced. This means some runs surface fifty exceptions, and someone has to look at them. That is the correct outcome. Those fifty exceptions were always there; you were just hiding them inside a zero.
A related discipline: separately identify external, intercompany and related-party activity through every layer. If you cannot distinguish them at the point of ingestion, you will not be able to eliminate them correctly at consolidation, and the group number will overstate.
5. Lineage is a control, not a log
Most systems have logging. Very few have lineage.
The distinction: logging tells you what the system did. Lineage tells you where a specific published number came from. When a director points at a figure in a board pack and asks where it came from, the answer should be a query, not an investigation.
I captured provenance at ingestion (source file, checksum, receipt) and carried it through every transformation, so any figure resolves back along the chain to the file it originated in:
submission file -> checksum -> Bronze -> Silver -> Gold -> metric version -> certified figure
Every generated artefact is bound to one pipeline run, one configuration fingerprint and one metric-taxonomy version. Reproducibility is not a nice-to-have here. If you cannot regenerate last quarter's board pack exactly, you cannot defend last quarter's board pack.
6. One snapshot serves every output format
A dashboard, an Excel workbook and a PDF board pack that each calculate their own numbers will eventually disagree. Not because anyone is careless, but because three code paths cannot stay identical indefinitely.
Generate every output from a single certified Gold snapshot. The dashboard, the workbook and the PDF are then three renderings of the same figures, and reconciliation between them is structurally guaranteed rather than periodically checked.
This also solves a problem people underestimate: the executive who screenshots a dashboard on Tuesday and the analyst who exports on Wednesday are no longer holding two versions of the truth.
7. Access should mirror accountability
Role-based access usually gets treated as a security requirement bolted on near the end. In a governed reporting platform it is part of the governance model itself.
Who may submit data, who may certify a definition, and who may publish a figure are three different responsibilities and should be three different permissions. Six roles with per-entity row-level scoping, enforced in the API rather than the interface, because access control implemented only in the front end is not access control.
The test I applied: could a single person move a number from raw submission to published board pack without anyone else touching it? If yes, the model is wrong.
The uncomfortable part
Governance work is unglamorous and it is almost always deferred. The pipeline gets built first because it is visible and satisfying. The metric layer gets built later, under pressure, once people have already stopped trusting the outputs.
Doing it in that order costs more. Retrofitting lineage into a running platform means reprocessing history you no longer have provenance for. Retrofitting certification means asking people to ratify definitions that are already in board packs. Retrofitting quarantine means discovering how many silent coercions are baked into figures that have already been reported.
Build the governance in from discovery, and it costs a fraction. On InventPulse 360, over 90% of routine month-end reporting steps ended up automated with every published KPI mapped to a certified, versioned definition. The reason that was achievable was that the governance model sat in the BRD, not in a follow-up phase.
The actual measure of success is not the automation percentage. It is that the meeting I described at the top stopped happening.
One more thing, on how this got built
InventPulse 360 went from specification to production with a very small team, using AI-assisted development throughout. That deserves an honest note rather than a triumphant one.
AI assistance changed the economics of the parts that are labour-intensive but well-understood: connector implementations, test scaffolding, the long tail of validation rules. It did not change the parts that require judgement. Deciding that percentages must never be averaged, that exceptions get quarantined rather than coerced, that certification and publication are separate permissions: those are domain decisions, and they came from the specification work, not from the tooling.
Which is roughly the point of this article. The hard problem in data platforms was never moving the data. It is agreeing what the numbers mean and being able to prove it afterwards.
I am a product and platform consultant working on governed data and AI platforms, currently engaged fractionally with three clients across Ireland and the UK. I write the specification and then build against it. If you are wrestling with a metric layer that nobody trusts, I am always happy to compare notes.
Client, entity and vendor identities are omitted throughout. Figures referenced are architectural and acceptance facts.