Resources·for PE firms
Portfolio monitoring: build vs. buy
Every fund answers this question eventually, usually around the sixth or seventh portfolio company, when the consolidation spreadsheet a senior associate maintains starts taking a full day each month. This is a framework for making that decision deliberately, not by default.
Portfolio monitoring rarely gets designed. It accretes. The first portfolio company sends a monthly P&L by email. The second sends one in a slightly different format. By the fourth or fifth, someone on the deal team has built a master spreadsheet that pulls figures from each portco's file into a single tab, and that spreadsheet quietly becomes the fund's only source of portfolio-wide truth.
This works until it doesn't. The trigger is usually one of three things: a portfolio company changes its reporting format and breaks the consolidation formulas, an LP asks for a portfolio KPI the spreadsheet was never built to produce, or the person who maintains it leaves. At that point, the fund faces an actual decision. It's worth treating it as one, rather than defaulting to whichever option is easiest to start.
Three paths, not two
"Build vs. buy" implies two options. In practice, most funds are choosing between three. The third is the one that actually solves the underlying problem.
path 1
Keep consolidating manually
Each portco sends its own file, in its own format, on its own schedule. Someone at the fund re-keys or re-maps the numbers into a master sheet every month. Cheapest to keep running, most expensive in analyst time, and the one most exposed to a single point of failure.
path 2
Build or buy a GP-only tool
The fund commissions an internal BI dashboard, or licenses a purpose-built portfolio-monitoring platform, either way usually fed by the same portco exports as before. Solves the presentation problem for the GP. Does nothing about how the data gets in. Portcos still export, someone still maps fields, still by hand.
path 3
A shared reporting layer
Portfolio companies use the same platform for their own day-to-day reporting, such as budgets, cash, and covenants. The fund's portfolio view is a byproduct of that, not a separate deliverable. No export, no re-keying, no second system to keep in sync.
What "build" actually costs
The upfront quote for an internal dashboard is rarely the real cost. The recurring costs are what determine whether the project is worth it three years in.
| Cost category | What it actually looks like |
|---|---|
| Initial build | Analyst or contractor time to design the data model, build the dashboard, and wire up the first few portcos, typically weeks, not days. |
| Per-portco onboarding | Every new acquisition needs its chart of accounts mapped and its export format understood before it appears in the dashboard, a recurring cost, not a one-off. |
| Ongoing maintenance | Portcos change accounting software, add a new revenue line, or restructure their P&L. Someone has to notice and update the mapping each time. |
| Key-person risk | The analyst who built the data model understands its quirks. When they move on, the fund inherits a system nobody fully understands. |
| Opportunity cost | Every hour spent reconciling data formats is an hour not spent on portfolio value creation, the actual job. |
The trap inside "buy"
Not every "buy" decision solves the problem. A tool that gives the GP a nicer dashboard, but still expects each portco to export a file into it every month, has moved the spreadsheet, not removed it.
still the old problem
A GP-only dashboard
The portco has no reason to use the tool day-to-day. It exists purely to feed the fund's view. Data still arrives via export, on the portco's schedule, in whatever state their own bookkeeping happens to be in. Reconciliation calls don't go away; they just happen inside nicer software.
actually solves it
A shared reporting layer
The portco's CFO uses the platform for their own budget, cash, and covenant tracking. It's their tool first. The fund's portfolio-wide view is generated from that same live data, with no separate export step and no second version of the numbers to reconcile.
The trade-off worth naming directly: a shared layer only works if portfolio companies actually adopt it for their own day-to-day reporting, not just to satisfy the fund. A portco with an established finance stack, and a CFO who didn't choose this tool, has real switching costs and a learning curve to work through first. That's a bigger ask than "buy" implies, and it's worth planning for at onboarding rather than assuming it away.
One question cuts through most vendor pitches quickly: does the portco log in to use this tool for its own reporting, or does it only export data into it? If the answer is the latter, the fund has bought a nicer front end for the same old spreadsheet problem.
A decision framework
No single answer fits every fund. These five factors tend to determine which path is worth pursuing.
| Factor | Favors manual / status quo | Favors a shared layer |
|---|---|---|
| Portfolio size | 3-4 companies, low turnover | 6+ companies, or growing via add-ons |
| Remaining hold period | Exiting within 12 months | 3+ years of holding and reporting ahead |
| Portco finance maturity | Sophisticated in-house finance teams already | Lean finance functions that need the structure anyway |
| Exit preparation | No near-term diligence expected | Clean, consistent portfolio data materially helps an exit process |
| Portco tooling inertia | Portcos are entrenched in their own systems, with a CFO who won't welcome a mandated switch | Portcos are newly acquired or pre-scale, and open to standardizing at onboarding |
The question underneath the question
Whichever path a fund leans toward, one test cuts through the framing: does this reduce the total amount of data entry happening across the portfolio, or does it just relocate the spreadsheet into a nicer chart for the GP?
If a portfolio company still has to maintain its own model and then separately populate the fund's system, the fund has added a second job for the portco's finance team rather than removed the first one. The options that actually reduce total effort are the ones where the portco's own reporting is the fund's reporting, not a downstream copy of it.
AHQ is built as the shared layer, not a GP-only dashboard
Portfolio companies run AHQ Financials for their own budgeting, cash tracking, and covenant compliance. AHQ Insights andAHQ Financials read from the same underlying data model, so your fund's portfolio view updates the moment a portco saves a number, not on a nightly sync or a batch export. No export step, no separate mapping project, no reconciliation between two versions of the numbers.