The Rollup Data Problem That Surfaces at Exit
Five acquisitions in. Ten ERPs running in parallel. No common definition of revenue, margin, or what counts as an active customer. The exit window is two years out and the LPs are starting to ask about it.
This is the rollup data problem. And it does not surface as a data problem.
It surfaces eighteen months before exit, when the buyer’s diligence team asks for a coherent business story across the platform — and the sponsor cannot tell it. Not because the story is not there. Because the data was never built to tell it.
I have had this conversation with eight different independent sponsors over the last four months. Different industries, same arc. The thesis everyone believed: buy at a four-multiple, professionalize, scale, exit at eight. The thesis is sound. The execution is not. By acquisition three or four, none of them can produce a unified P&L without a six-week sprint and a junior analyst rebuilding spreadsheets from scratch.
It compounds quietly until it does not.
The Rollup Promise vs. The Data Reality
The pitch is clean. Buy a $3M EBITDA company. Bolt on three more. Suddenly you have a $15M platform with cross-sell, vendor consolidation, shared services. The multiple expands because the buyer at exit is buying scale, not pieces.
The pitch deck does not model what each of those acquired companies actually runs on.
Acquisition one runs a vertical SaaS that works fine but exports nothing cleanly. Acquisition two has an on-prem Sage install the founder’s daughter runs with a side spreadsheet. Acquisition three brought NetSuite on a completely different chart of accounts. Acquisition four was on QuickBooks with an Airtable bolted on.
Each system has its own definition of revenue. Its own concept of a customer. Its own margin calculation that sometimes includes shipping, sometimes does not. Its own opinion on whether a refund is contra-revenue or an expense.
Grant Kornman at Align Collaborate has a phrase for it: “Buying or investing in your first company. You get kind of target blindness. You’re just focused on the deal. Well, that’s really getting you to the starting line. What you do after that is what’s going to determine whether you win or you don’t.”
Target blindness is real. The deal is the artifact you stare at for three months. The integration is the artifact you live with for three years. Nobody on the deal team thinks about how the new acquisition’s metric layer reconciles with the platform’s — because there is no platform metric layer yet. Just spreadsheets the CFO ties out by hand at month-end.
The Compounding Chaos Problem
Here is the part most independent sponsors miss: each acquisition does not add to the data problem. It multiplies it.
We’ve covered the single-company version of this — what happens when you can’t measure unit economics on Day 1. Rollups take that same gap and multiply it by every acquired entity, every chart of accounts, every set of seller-defined definitions. Two ERPs is not twice as hard as one. It is exponentially harder. By five ERPs, you have ten translation pairs, twenty inconsistencies in how the same event gets recorded, and one CFO who is starting to dream about chart-of-accounts mapping.
What gets inherited at most sub-$5M EBITDA acquisitions is functionally piles of paper moving through the office — sales to orders to customer service to invoicing. Sometimes literal paper. More often spreadsheets, or a bookkeeper who “knows the system.” Information that lives in a person’s head, or in a process built to just work, not to scale.
You can survive that with one company. The CFO talks to the bookkeeper. Numbers get reconciled by Tuesday. The wheels start turning.
You cannot survive it with five companies. Not because any one is broken, but because nothing connects. Each acquired team is still doing their thing the way they always have. The platform CFO rolls five of those things into one number for the board. The number gets produced. It is wrong by single-digit percentages in either direction depending on which assumptions held that month.
This is the messy middle of a rollup. The thesis is working at the company level — revenue growing, margins intact. But at the platform level, nobody can tell you whether the rollup is delivering what the model promised, because no two acquired companies define “the platform” the same way.
Why Most Third-Party Fixes Fall Short
When the operator finally sees the problem, the instinct is to hire help. A fractional CFO. A BI vendor. A Tableau instance. Someone to build dashboards.
Most of these projects fall short. Not because the people are bad at their jobs. The framing is wrong.
Vendors arrive and start with the data that exists. They build extracts from each ERP, drop them in a warehouse, throw a dashboard on top. Three months later the dashboard shows that revenue by company across five entities does not add up to the consolidated number the CFO has been reporting for six months. The dashboard is the diagnostic, not the fix. The problem was never that nobody had built dashboards. The problem was that nobody had agreed on what to measure.
Michael Curry, a serial operator, captured this in a different context: “When we decided pricing was our most important lever, we found pricing was being done by our admin staff at 4:45 on Fridays.”
That is a metric creation problem, not a data problem. Nobody had decided what mattered, so it defaulted to whoever was free at 4:45 on a Friday. The dashboard cannot fix that. It can only show you the pricing is inconsistent.
Metric creation is the harder lift. Deciding what a customer is, what counts as churn, which margins go in the rollup P&L, how to treat add-back EBITDA — these are business-model decisions, not technical ones. They require somebody who understands the business well enough to say: this is what we call revenue going forward. Here is the definition. Here is how we enforce it across all five companies.
That work is unglamorous. It does not demo well in a board deck. But without it, every dashboard you build is a more expensive version of the disagreement that already existed.
The Exit Readiness Problem
Here is why this stops being an operations inconvenience and becomes a valuation problem.
When the operator goes to market in year four or five, the buyer’s diligence team asks for the unified data set. Trended P&L by month, by acquired company, consistent definitions. Customer cohort analysis across the platform. Margin walk that explains how the consolidated 22% turned into 22%. KPI trends — retention, sales velocity, working capital — at the platform level, not each company telling its own story.
The operator carrying the integration debt cannot produce that in the time diligence allows. The team rebuilds spreadsheets for six weeks, the buyer’s analysts find inconsistencies, the diligence period extends, the seller’s narrative starts to slip.
Walt Freese, who has run multiple rollups, put it this way: “More roll-ups fail as a result of culture than fail as a result of we just got the numbers wrong.”
Culture is the leading cause of rollup failure. Fair. But data chaos creates a quieter failure mode: not that the numbers are wrong, but that nobody can tell a coherent story about what they mean. Buyers discount what they cannot verify. Diligence extends. Multiples compress. The valuation haircut shows up as a thousand small concessions during the process, not a single line item. (For the integration-side mechanics — what actually breaks when you try to merge five back offices on one platform — see the rollup integration playbook.)
There is an additional layer now. Every acquirer of a rollup in 2026 is asking about AI readiness — which functionally means, “Is your data architected such that we could plug an LLM into it and get useful answers?” The operator with fifteen ERPs and no metric layer will not score well there.
What makes the rollup data problem different from a normal data quality problem: the messiness has a deadline. The exit clock is running.
What Getting Ahead of It Looks Like
The fix is not glamorous. It does not involve buying NetSuite at acquisition one when the company has $2M EBITDA. Justin Turner at Traction Capital Partners addressed that exact tradeoff: “The business had $2 million in EBITDA. Probably didn’t need NetSuite. But we knew that if we executed on where we were going, a $100 million dollar business probably does need something like NetSuite.”
That is the operating principle. Build for the platform you are creating, not the company you are buying.
In practice, the early discipline looks like this:
Define the metric layer at acquisition one or two. Not at acquisition five, after chaos has compounded. What does the platform call revenue? What is a customer? What is the margin definition the board sees? Write it down. Make it the integration deliverable, not an afterthought.
Make data architecture an integration deliverable. Every 100-day plan includes “map this company’s chart of accounts to the platform standard” and “establish the data feed to the platform warehouse.” A closing deliverable, not a future project.
Standardize the operational tooling, not just the reporting layer. A real fix is embedded in the workflow — sales reps quoting in real time with pricing parameters and margin guardrails baked into the tooling, flexing without calling head office. That is platform discipline. Not a dashboard bolted on after the fact.
This is definitional work, not dashboard delivery. A BI shop builds what you spec — wrong definitions get faithfully reproduced at scale. Someone has to decide what the platform actually measures and stay accountable when those definitions drift at acquisition four. That person can be a fractional analytics partner or an outside advisor embedded in the integration — not delivering a tool, but owning the metric layer alongside the team. The vendor builds the pipes. They cannot decide what flows through them.
Operators who do this from acquisition one are not faster at integration. They are integrating in a way that compounds in their favor. Each acquisition slots into a defined platform structure. The chaos does not get to multiply.
The ones who do not end up running a six-week emergency project at exit prep, building retroactively what should have been built incrementally. Some get it done in time. Some do not.
Stakes
If you are two acquisitions in and have not defined the unified metric layer, you are accumulating technical debt that will surface at exit prep. As longer diligence cycles. As buyer skepticism about the consolidated story. As a multiple that comes in a half-turn lower than the model assumed. None of it will be labeled “the data problem.” That is what it is.
The work is not exotic. Treat the metric layer with the same discipline you treat the chart of accounts. Define what the platform measures and enforce it at every acquisition.
If you are running an IS rollup and can see this problem coming, that is exactly the kind of work I do.
Alex Escoriaza helps independent sponsors and PE-backed operators build the data architecture that holds up under exit diligence. If you are running a rollup and the data chaos is starting to look like an exit problem, let’s talk.