The pattern is so consistent it may as well be a calendar entry. A group FD asks on a Monday for one view of pipeline across all the trading companies. The implementation partner scopes it, quotes it at around £2,000, and delivers a fortnight later, by which point the board paper has gone out, the decision has been made on a spreadsheet someone hacked together on the Wednesday, and the report is opened once and never again. A single cross-entity report typically costs somewhere between £1,500 and £3,000 and takes one to two weeks, not because the build is hard, but because most of that fee and most of that time go on reconciling entities that were never designed to be compared. The cost of custom CRM reports in a multi-entity group is really the cost of that reconciliation, not the cost of the report itself. This piece explains why that fortnight exists at all, because the delay and the invoice have the same root cause.
TL;DR
A custom CRM report for a group of trading companies typically costs £1,500 to £3,000 and takes one to two weeks per request, because the underlying data model assumed a single company, so producing a group view is a reconciliation job rather than a query. Senior management ask for a report on the Monday, it is scoped at roughly £2k, and it lands two weeks later once the need has diminished. Most of those hours are not spent building the report: they go on scoping, mapping entities to each other, reconciling permissions so the wrong brand cannot see the wrong pipeline, QA against five sets of local conventions, and change requests when the first draft doesn't reconcile to anyone's numbers. The cost is predictable in advance, and the predictor is simple, count how many entity-level assumptions the report has to override. Nought or one, it's a query; four or more, it's a project, and no reporting tool bolted onto a single-entity data model will change that.
Why does the cost of custom CRM reports climb so quickly in a multi-entity group?
Because in a single-company CRM, a pipeline report is a query. Filter opportunities by stage, sum the value, group by owner. The data model already agrees with itself: one set of stages, one currency convention, one definition of an account, one permissions hierarchy running top-to-bottom.
In a group of trading entities running on one instance, or worse, several instances, a pipeline report is a reconciliation. Before anything can be summed, someone has to decide what "the same thing" means across companies that were never designed to be compared. That work is analytical, it involves human judgement, and judgement cannot be templated. So it gets billed by the hour.
This is not a CRM-specific pathology; it's what happens whenever you try to combine data from systems that were modelled separately. The National Audit Office made the point bluntly about central government in its 2019 report Challenges in using data across government, finding that the absence of common data models and standards within and between departments makes combining different data sources difficult and costly. A holding company with five trading brands is the same structural problem at a smaller scale, and it produces the same invoices.
You are not paying for a report. You are paying someone to decide, one field at a time, what "the same thing" means across companies that were never modelled together.
The reason the CRM never solved this for you is economic rather than technical. Mainstream CRMs are deliberately built to be generic and broadly applicable, because that is how you address the widest possible market. Steering to a wide audience means fitting no audience exactly, and multi-entity groups lose out most: they are a smaller addressable market with a longer, more drawn-out buying process, so the fundamentals they need never justify roadmap space. The result is that group-level structure is not in the foundations, it's expressed later, in configuration and in consulting hours. That's the same mechanism explored in more depth in our piece on why multi-entity CRM support is architectural rather than a bolt-on, which is also why cross-entity reporting for a group of trading companies never becomes a one-off cost you pay just once.
Why does a custom report take weeks instead of days?
Here is the honest decomposition, based on how these engagements are scoped and delivered in practice. The proportions vary; the line items rarely do.
| Line item | What the hours go on | Why a group makes it worse |
|---|---|---|
| Scoping and requirements | Working out what the FD actually meant by "pipeline", which stages count, whether it's weighted, and as at what date | Each entity's sales lead has a different answer, and the partner has to reconcile them before writing a line of code |
| Entity mapping | Deciding how companies, business units, teams and record ownership map onto a model that has one hierarchy | Shared accounts that span two brands have to be counted once at group level without breaking either entity's own number |
| Permissions reconciliation | Making sure the group view aggregates data the viewer is not permitted to see at record level, without leaking it | Most systems handle visibility within one brand and do it poorly; between brands it is close to impossible, so this becomes bespoke logic. The question of who should see what across group companies is exactly the design decision that turns a query into a project |
| Build | The actual report, dashboard or dataset | Often the smallest line on the invoice |
| QA and reconciliation | Proving the numbers tie back to each entity's own reporting and to the ledger | Five entities means five sets of local conventions to reconcile against, and every mismatch is investigated by a human |
| Change requests | The second and third versions after the FD sees the first | Each change re-opens the mapping and permissions decisions, so "just add last year" is not a small change |
Notice which line is smallest. The build is usually a fraction of the engagement. What you are buying is judgement about a data model that was never designed to answer your question, and judgement priced at professional-services day rates adds up quickly. Public sector procurement gives one of the few openly published anchors for what specialist data work costs in the UK: an Environment Agency requirement published on the government's Digital Marketplace set a maximum allowable day rate of £1,500 for data-centred delivery work. Commercial CRM partner rates vary widely and are rarely published, TODO(verify) if you want a market figure, but at anything in that broad range, £2k buys you a small number of specialist days, and most of them go on the rows above the build.
What happens when the requirement changes mid-build?
Take an illustrative group: a holding company with five trading entities, around 40 CRM users in total, two of the entities selling to overlapping customers. The FD asks on Monday for weighted pipeline by entity for the current quarter, plus a line showing revenue attributable to accounts that trade with more than one entity.
That one sentence contains at least five entity-level assumptions the CRM's data model has to be argued out of:
- Stages are comparable. They aren't. Entity A's "proposal" is Entity D's "qualified". Someone has to build a mapping table, and someone senior has to sign it off.
- Probability weighting is consistent. It isn't, because each entity's sales manager tuned it locally to make forecasting work for them.
- An account is one record. It isn't. The overlapping customer exists twice, under two brands, with two owners and possibly two spellings, exactly the duplication problem the NAO described when it noted that the same individual can be recorded differently in each system.
- Everyone who can see the total can see the parts. They can't, and mustn't. The group view has to aggregate across brands that are deliberately walled off from each other, which means the aggregation logic has to be trusted with data the requester's own login is not.
- Quarter end is the same date. For a group with an acquired entity on a different financial year, it may not be.
Each of those is a decision, a build task and a QA task. That is the fortnight. It is not slowness, it is five reconciliations, a permissions design, and two rounds of "that doesn't match my number" before anyone can be confident enough to put it in front of a board. Change the requirement after scoping starts, by adding a comparison year or a new entity, and each of those five reconciliations reopens, which is why a change request rarely counts as a small change on the invoice.
How can you predict the cost of a custom CRM report before you commission it?
There is a test, and it takes ten minutes. It doesn't require you to understand the CRM's data model, only to count the places where your question disagrees with it.
- 01Write the request as one sentence. Exactly as you'd say it to the board. "Weighted pipeline by entity for Q3, with cross-entity accounts identified." Don't pre-negotiate it down; the full request is what you're pricing.
- 02Count the entity-level assumptions it overrides. Every place the report needs entities to agree, stages, weighting, account identity, ownership, currency, period end, product taxonomy, where in reality they don't. That count is your cost driver.
- 03Count the permission boundaries it crosses. Does the finished report aggregate any record the requester cannot open individually? If yes, the engagement includes a bespoke visibility design, which is the most expensive and most fragile line on the invoice.
- 04Ask who signs off each mapping. If the answer is "the five entity MDs would need to agree", the delivery date is set by their diaries, not the partner's developer. This is usually where the two weeks actually goes.
- 05Ask whether the mapping is reusable. If the stage-mapping and account-matching logic lives inside this one report, you will pay for it again next quarter. If it lives in the platform's configuration, you won't. This single question separates a one-off cost from an annuity.
As a rough heuristic from watching these scopes get written: nought or one overridden assumption and no permission boundary crossed is a query someone in-house can build the same day. Two or three is a small build with a QA cycle. Four or more, or any bespoke cross-brand visibility logic, and you have a project, with a change-request tail, because the first version will not reconcile.
What are the realistic routes to consolidated group reporting?
| Route | What drives the cost | Typical latency | Who owns it afterwards | Main failure mode |
|---|---|---|---|---|
| Partner-built custom report | Scoping, mapping and permissions hours, plus change requests | Days to weeks per request | The partner, you re-commission for each variation | Arrives after the decision; logic is trapped inside one report |
| In-house BI tool on top of the CRM | Building and maintaining the semantic layer that the CRM doesn't provide | Weeks to build, then fast per query | An internal analyst, if you have one | Reproduces the entity mapping outside the CRM, so the two drift apart |
| Data warehouse consolidation | Pipelines, modelling, ongoing schema maintenance | Months to stand up | Data engineering capability you may not have | Real answer for large groups; heavy fixed cost for a five-entity group |
| Spreadsheet consolidation | Someone's Monday and Tuesday, every month | Fast, and wrong in a new way each time | Whoever built it, until they leave | No audit trail; the group's real reporting layer becomes an unversioned file |
| Multi-entity-native CRM | Configuration, not consulting, the entity model and visibility rules are in the foundations | Same-day, self-serve | The group, in-house | Only works if the permission model is genuinely built in, not bolted on |
There is no route on that list that makes cross-entity reporting free. What differs is whether you pay once, in configuration, or repeatedly, in consulting hours, and whether the reconciliation logic ends up as an asset the group owns or as a line item you re-buy every quarter.
What actually fixes it
The fundamental that has to exist in the foundations is configurable permission and visibility control at a fine-grained level, both within a brand and between brands. Get that right and a group report becomes a query again, because the system already knows which entity a record belongs to, who may see it, and how it rolls up. Get it wrong, or bolt it on afterwards, and every group report is a bespoke reconciliation, forever.
That is the honest reason we build Atrium around the entity model rather than around a reporting module. But be clear about what software cannot fix: if your five entities genuinely disagree about what a qualified opportunity is, no platform will resolve that for you. It will only stop you paying £2k to re-litigate the question every time someone asks a new one. The related problem, reports that are technically correct and still ignored, a common cause of CRM adoption failure among sales teams who don't trust the numbers, is covered in our piece on why CRM adoption fails, and the pricing dynamics that push functionality into the consulting channel in the first place are in how SaaS pricing models shape what gets built. For the wider argument about what consolidated group reporting should look like across a multi-company group, start with the group reporting hub. If the reporting cost is making you question the underlying structure, our piece on deciding between one CRM or one per company sets out how to think about that choice before you commission another custom report.
Frequently Asked Questions
Why does a custom CRM report take two weeks when the build is only a day?
Because most of the elapsed time is not development. It is scoping calls with each entity, agreeing how stages and accounts map across companies, designing what the viewer is permitted to see, and then reconciling the output against each entity's own numbers. Those steps depend on other people's availability, which is why the calendar time is dominated by sign-off rather than by coding.
Is £2k a normal price for a custom CRM report?
As a figure from selling and account-managing enterprise CRM, around £2k is a familiar scope for a single cross-entity report from an implementation partner, and roughly a fortnight is a familiar lead time. It is not a published rate card and it will vary by partner, group complexity and how many entities have to be reconciled, treat it as an order of magnitude, and price your own request using the five-step test above.
Can a BI tool remove the cost of custom CRM reports?
It moves the cost rather than removing it. A BI layer can query fast once someone has defined how the entities map to each other, but that definition still has to be built and maintained somewhere, and if it lives in the BI tool rather than the CRM, the two versions of the truth will drift. A BI tool is a good answer to "we need more reports"; it is not an answer to "our data model assumes one company".
How do we stop the group report arriving after the decision?
Shorten the sign-off chain, not the build. Agree the cross-entity definitions once, stages, account identity, period ends, who may see what, and record them as configuration rather than inside a single report. Once those decisions are made and reusable, most board-level pipeline questions become same-day, and only genuinely new questions need commissioning.
What should a group FD ask a CRM vendor about reporting before buying?
Ask them to demonstrate, live, a pipeline view across two entities where the viewer is not permitted to open the underlying records in one of them. Then ask who builds it: you, in configuration, or their services partner, on a statement of work. The answer to that second question tells you what your reporting will cost for the next five years.
Should a group build reports in-house, pay for a one-off custom build, or retain a partner?
A one-off custom build suits a single, rarely-changing question and carries the lowest upfront cost, but the mapping logic is trapped inside that report and gets rebuilt, and rebilled, the next time the question changes. Retained partner hours suit groups with frequent new questions and no in-house resource, but the cost recurs indefinitely because the entity-mapping decisions are never owned internally. An internal build, whether inside the CRM's own configuration or a BI layer, carries higher upfront cost and requires someone capable of maintaining it, but turns the reconciliation logic into a reusable asset rather than a line item repeated every quarter. Which route is cheapest depends entirely on how often the underlying question changes, not on the price of any single report.