The Portco Finance Stack Problem in Lower-Middle-Market PE

The Aziell Investor Desk contributor network has cumulatively built or helped build more than a dozen internal “portfolio dashboard” projects across emerging and mid-market PE firms. Most of them eventually failed for the same reason. The failure mode is universal enough that every emerging-fund GP should understand it before they attempt one more.

The symptom every fund notices first is workload. Around portco four, the time cost of the monthly reporting cycle stops being linear. Five portcos don’t take 25% more partner time than four; they take 60% more. Eight portcos double it again. The reason is not the volume of numbers — every portco is only a few dozen line items. The reason is reconciliation.

Why portco reporting breaks at scale

Each portco’s finance function is built on its own sediment of decisions. Controller A started in 2019, before the platform acquisition, using QuickBooks Desktop with a flat chart of accounts. Controller B arrived post-close with strong NetSuite opinions. Controller C still prefers Excel for the monthly pack because that’s what the last lender asked for. None of this is wrong at the portco level. At the portfolio level it’s catastrophic.

Three specific patterns recur:

• Chart-of-accounts divergence. Portco A has “Labor” and “Payroll taxes” on separate rows. Portco B has one “Wages and benefits” line. Apples-to-apples is already broken before you’ve started.
• Revenue recognition drift. One portco books memberships up-front, another on a monthly accrual, a third on cash. The EBITDA margin comparison is meaningless until you normalize, and nobody at the fund has time to do that monthly.
• Branch / class tagging inconsistency. Some portcos use QuickBooks Location, some use Class, some use neither and tag via vendor naming conventions. Branch-level rollups require a human translator.

The dollar cost of the status quo

Let me quantify what four years of watching this problem cost my prior firm. Assume a nine-portco fund with a two-partner + one- analyst operations team. The status quo cycle:

That $420k is only the direct labor. The cost that doesn’t appear on any invoice is the decision latency. When the monthly pack lands three weeks after close, the levers you can actually pull at portco level (pricing, staffing, covenant conversations) have already slipped past their window. You’re reporting on a quarter you can no longer influence.

Why building it internally almost always fails

Every fund that feels this pain attempts some version of the same fix: a BI consultant, a Looker or Sigma dashboard wired to each portco’s QuickBooks, a fractional controller coordinating the data flow. Over time this yields a dashboard that looks impressive to LPs and tells the GP nothing they didn’t already know.

The reason is that the dashboard is solving the wrong layer. The hard problem is not visualization. It’s the source-level normalization — getting every portco to classify, time-phase, and dimension their numbers the same way. That happens inside each portco’s books, not in the dashboard sitting on top. If you don’t fix it at the source, every dashboard update reintroduces the drift.

The operator-first fix

The approach that actually works inverts the problem. Instead of pulling portco data into a fund dashboard, you put every portco on the same operator-grade FP&A platform. The fund view becomes a derivative of operator views that are already consistent with each other — because they all run the same driver model, the same auto-classified chart of accounts, the same branch tagging rules.

This is what Aziell’s investor product does, and why we built it operator-first rather than fund-first. Operators adopt it because they get a real FP&A product. Funds get consistent portfolio intelligence as a byproduct, not as an extraction. The incentive alignment is what makes it stick where internal builds don’t.

What changes when the stack is fixed

Three things shift, fast:

1. Monthly close-to-LP-pack goes from 3 weeks to 5 days. Because every portco’s numbers are already in portfolio shape, the pack assembles itself.
2. Cross-portfolio benchmarking becomes possible. Once portcos are comparable, your top-quartile operator becomes the operating benchmark for the bottom quartile. See cross-portfolio benchmarking.
3. Covenant surprises disappear. Continuous evaluation replaces monthly snapshots. You see a DSCR trend approaching a covenant two months before it breaches. See covenant monitoring at portfolio scale.

If you’re about to build it yourself

Before you brief the BI consultant, do this one thing: visit two of your portcos and ask their controllers to print the GL in their preferred format. Lay the two side by side. Count the number of times the same economic concept (labor, rent, revenue) is expressed differently. If the count is above ten, a dashboard won’t save you. You need to change what happens in the books, not what happens above them.

That’s the argument for operator-first portfolio tooling, in one sentence.