A guide to making the right architectural decision for private market firms.
It sounds like a simple question, but where a report lives is one of the most important architectural decisions a growing firm can make.
As organisations increase their technical maturity, investing in a broader ecosystem of tools (PM, FA, ESG, CRM, AI and data infrastructure), reporting stops being a feature and becomes a strategy.
Many firms default to building reports inside the platform or moving everything into Power BI. Both approaches overlook a key reality: reporting architecture needs to evolve alongside the business. The right answer depends on data latency, complexity, governance, audience, and long-term maintainability.
When we review a client’s reporting architecture, we start with four practical questions.
- Does the report require live data?
- Does it combine data from multiple systems?
- How complex is the logic?
- Who is the audience?
1. Does the report require live data?
If a report requires real-time transactional accuracy, intraday position monitoring, live cash balances, trade execution tracking, then platform-native reporting is usually the right choice. It sits inside the system of record, eliminates ETL latency, and lets operational users drill directly into underlying transactions.
However, the term “live” is often used more loosely than necessary. It helps to distinguish between true real-time (sub-minute, event-driven), near real-time (refreshed every few minutes), and batch (hourly or daily). Modern data platform architectures can support near real-time pipelines, so if the business can tolerate a small delay, more scalable reporting approaches become viable.
2. Does it combine data from multiple systems?
Single-system reporting is straightforward. Cross-system reporting is not. If a report pulls from portfolio management data, fund administrator records, CRM pipelines, accounting entries, and external benchmarks, it should almost always sit on a consolidated data layer. Increasingly, relevant data also lives in unstructured formats, PDFs, side letters, and investor documents, making document management and data extraction part of the infrastructure picture too.
Trying to replicate external datasets into a single SaaS platform, or rebuilding the same logic across multiple systems, leads to duplication, inconsistency, and governance risk. A centralised data platform provides a single source of truth, standardised transformation logic, cross-functional visibility, and controlled data lineage, all of which become essential for compliance, investor, and board reporting.
3. How complex is the logic?
A simple operational extract is very different from a regulatory return or a performance attribution model. Modern data infrastructure is designed to handle large historical datasets, multi-step transformations, complex aggregations, waterfall calculations, and regulatory models.
By contrast, embedded SaaS reporting engines are typically optimised for convenience rather than complexity. They often limit transformation depth, struggle with large datasets, store logic in proprietary formats, and provide limited version control. Over time, business-critical calculations embedded inside these platforms become harder to audit, difficult to reuse, and dependent on vendor release cycles.
As a general rule: if a calculation is complex, reused across multiple reports, material to investor or regulatory outputs, or subject to audit, it belongs in a governed, central transformation layer.
4. Who is the audience?
The audience dictates the location.
Operational users work daily inside the platform. For them, in-platform reporting is more efficient and intuitive; they can drill into granular detail and pull reports faster.
Senior leadership needs cross-functional, aggregated views with curated KPIs. Asking them to access multiple SaaS tools is not feasible. Executive dashboards belong in a central BI environment built on consolidated data.
External stakeholders such as investors, regulators and auditors require reports with consistent methodology, clear data lineage, documented logic, and version control. These reports must be reproducible.
Beyond the four questions: scaling, governance, and ownership
Choosing where a report lives is only the first step. As firms grow, three additional factors become critical.
Scalability
Embedded SaaS reporting may feel sufficient at £1bn AUM, but growth changes the equation. Transaction volumes increase, historical retention requirements deepen, and regulatory obligations expand. Most embedded reporting engines are not architected for scale; heavy workloads can slow down dashboards and even compete with live transactional processing. Modern data platform architectures separate storage from compute, allowing firms to scale processing power independently. Architecture decisions made at £1bn may not hold at £10bn.
Governance
One of the most common issues we encounter is calculation logic scattered across multiple systems. A single metric might exist in a portfolio platform, a CRM, an accounting export, and a BI dashboard, each technically correct, but collectively creating fragmentation. When logic is scattered, numbers stop matching, ownership becomes unclear, and tracing how metrics are derived gets difficult. Centralising transformation logic within a governed data layer introduces version control, structured testing, peer review, and clear ownership of metrics.
Ownership
Short-term convenience often leads teams to embed logic wherever is easiest. But the right questions to ask are: how often does the logic change? Who maintains it? What happens if a vendor changes functionality? Can it be reused? Embedding complex logic inside SaaS tools may deliver quick results initially, but it can become expensive to unwind later. Deliberate placement of reporting logic reduces technical debt and keeps the architecture adaptable.
The bigger picture
When organisations start asking “Where should our reports live?”, it’s rarely just a reporting question. It signals that the operating model is evolving, the data estate is expanding, and the architecture needs to catch up. Handled well, it becomes an opportunity to reduce technical debt, strengthen governance, and build a reporting ecosystem that supports future growth.
A well-designed reporting architecture doesn’t just answer today’s questions. It ensures the business can continue answering the next ones.
If you’re reviewing your reporting architecture, redesigning your data stack, or simply unsure whether your current setup will scale, we’d be happy to help. Contact us to discuss your reporting strategy and ensure your architecture is built not just for today, but for where you’re heading next.
Authors
Alex Kitson
Principal Consultant
Maria Monton
Director, Data Strategy
