Group-level sales reporting means consolidating pipeline, revenue and activity from every trading entity in a group into one permissioned view, so a holding company FD sees group totals without waiting on a consultant to reconcile spreadsheets. Most chief executives of larger multi-company groups never log into the CRM. They open it for one thing: reports.
It matters most to FDs, group CEOs and anyone accountable for a board pack, because they are the ones asking for a number today and getting it in a fortnight. Getting it right depends on how entities and permissions were modelled underneath the reporting layer, not on which dashboard tool sits on top.
That single fact should shape how a group evaluates a system, and it almost never does. The people choosing the platform are rarely the people who depend on its output, and the mismatch is a direct consequence of how multi-entity CRM gets bought and built in the first place.
What must a group report actually contain?
A usable group report needs three things: consolidated revenue and pipeline by entity, a group total that does not double-count inter-company deals, and a permission layer that lets a subsidiary manager see only their own entity while the FD sees everything. Miss any one of the three and the report either misleads the board or exposes data it should not.
Consider a group with three trading entities. Entity A reports £1.2m of pipeline, Entity B £800k, and Entity C £400k, giving a naive sum of £2.4m. But £150k of that sits in an inter-company deal between A and B, counted on both sides. The correct group figure is £2.25m. A system that treats each entity as a disconnected instance will not catch that automatically; someone has to find it, flag it and adjust the number by hand, every reporting cycle.
Why can't I see one pipeline across entities?
The pattern is familiar to anyone who has worked on one of these implementations. Senior management ask for a report on the Monday. It goes to an implementation partner. It costs a couple of thousand pounds to build, a recurring line item worth examining on its own; see the true cost of custom CRM reports and how that cost compounds every time a differently shaped question comes in. It is delivered a fortnight later, by which point the question that prompted it has either been answered another way or stopped mattering.
Nobody behaves badly in that story. The report is well built and correctly priced for the work involved. The problem is upstream: consolidating across entities is genuinely hard work in a system that was not designed to do it, so every question of that shape becomes a project.
And the second-order effect is worse than the cost. When answers take two weeks, people stop asking. The questions that would actually change a decision never get raised, because everyone knows what asking involves.
Who is commissioning these reports today?
In practice, it is almost never the person who most needs the number. The FD or group CEO asks a question; a sales operations lead or an external implementation partner builds the answer. That gap between the person with the question and the person who can query the data is precisely why the fortnight happens, and why the decision about how a group's multi-entity CRM is structured belongs several layers above whoever administers it day to day.
What has to be true instead
Reports at group level need to be simple, flexible, and reliable, and available when the question is asked, not two weeks later. That is not a reporting-tool problem you can solve by bolting analytics on top. It depends on whether entities, ownership and permissions across group companies were modelled coherently underneath, including the decision of whether the group runs one CRM or one per company in the first place. If they were not, every roll-up is a reconciliation.
The commercial case is straightforward once the fortnight is counted properly. A £2,000 report delivered two weeks late does not just cost £2,000; it costs whatever decision waited on it, plus the same fee again the next time someone in the group asks a differently shaped question. An instant, self-serve view removes both the fee and the wait, which is why the build decision belongs with the FD asking the questions, not only with whoever administers the CRM.
What this article covers
What makes cross-entity reporting expensive; how to consolidate data that lives in several systems; which questions a group should be able to answer instantly; and how to evaluate reporting during a selection process rather than discovering its limits afterwards. For the broader argument about why multi-entity groups are underserved by mainstream CRM, see the multi-entity CRM hub.
Figure
Where a £2,000 report actually goes
- 01
Question raised
FD asks for a consolidated pipeline view
Day 1
- 02
Sent to implementation partner
Report specified and scoped
Day 2
- 03
Report built
Entities reconciled manually, inter-company deals flagged
Days 3-12
- 04
Report delivered
Costs roughly £2,000; question may no longer be live
Day 14
Illustrative reporting cycle for a three-entity group
Source: Gartner, Sales Technology Survey
FAQ
What is a group-level roll-up in CRM reporting? A roll-up combines pipeline, revenue and activity data from every trading entity in a group into one consolidated view, so a holding company FD or CEO can see group totals without opening each entity's system separately.
Can permissioned reporting show group totals without exposing entity-level deal detail? Yes, where entities and roles are modelled correctly at the data layer. A group CEO can see consolidated figures while a subsidiary sales manager sees only their own entity's records, provided the permission model was built into the system's foundations rather than layered on afterwards.
How should inter-company deals be reported when two entities in the same group are on either side of a transaction? Inter-company deals need to be flagged and reconciled so they are not double-counted in group revenue, while still being visible to each entity involved in its own pipeline. Systems that treat every entity as a separate, disconnected instance typically require this to be done manually, entity by entity.
How much does a custom group-level report typically cost to build? Costs vary by scope and provider, but a single bespoke consolidated report commissioned from an implementation partner typically runs into the low thousands of pounds, and the same fee recurs each time a differently shaped question is asked. See the cost of custom CRM reports for a fuller breakdown.
Who should decide how group reporting is built: the FD or the CRM administrator? The decision typically sits best with whoever is accountable for the board pack, usually the FD or group CEO, because they bear the cost of delay when a report takes a fortnight. The CRM administrator implements the structure but should not be the sole decision-maker on what the group needs to see.