# The most common data problems acquirers discover post-close Data problems discovered post-close cost PE-backed businesses months of value creation. Here are the issues acquirers miss most — and how to fix them fast. Published: 2025-05-21 Author: Rodan Analytics There is a version of this story most PE firms have lived through at least once. The deal closes. The hundred-day plan starts. And within the first few weeks of working inside the business, the operating team realises that the data underpinning the investment thesis does not quite match reality. Not because anyone deceived them. But because the business never had clean, reliable data to begin with — and nobody thought to look hard enough during diligence. The most common mistake at this stage is assuming that a well-run finance function means well-run data. It does not. A company can produce accurate monthly management accounts while running on spreadsheets, disconnected systems and tribal knowledge that lives in the heads of three people who may or may not still work there post-close. This article covers the data problems that surface most frequently after acquisition, why they are consistently missed during diligence, and what operating partners can do about them before they start costing real money. --- ## The finance function looks clean. The data layer underneath does not. The diligence process is good at finding accounting risk. It is poor at finding data infrastructure risk. These are different things. A business turning over £600m may have a CFO who produces reliable board packs, a clean audit trail and a coherent narrative on revenue by segment. What that same business may lack is any reliable way to reproduce those numbers from source systems, any consistent data definitions across departments, or any meaningful integration between its CRM, ERP and finance platforms. Consider a distribution business acquired by a mid-market PE fund. Revenue by customer looked clean in the management accounts. But when the operating team tried to build a churn model post-close, they discovered that "customer" was defined differently in every system. The ERP counted billing entities. The CRM counted contacts. The finance team had been manually reconciling the two for years in Excel, and the analyst who did it had left three weeks after close. This is not unusual. It is close to the median experience. The practical test during diligence is not "can the business produce accurate reports?" but "can the business reproduce those reports from raw data, consistently, without a specific person doing it manually?" Most businesses at the £500m–£1bn scale cannot. That gap matters enormously once you are trying to run value creation initiatives that depend on segmentation, pricing analysis or operational forecasting. --- ## Customer data is almost always worse than it appears Revenue concentration analysis is standard in diligence. Customer data quality is not — and the two are different questions. Understanding that your top ten customers represent 40% of revenue is straightforward. Understanding the actual health, behaviour and trajectory of those customer relationships requires clean, longitudinal data at the transaction level. That data is frequently messy, incomplete or structured in ways that make analysis unreliable. Common problems include: duplicate customer records created every time an account changes ownership or contact; revenue attributed to holding companies rather than operating entities, making true concentration analysis impossible; transaction histories that stop cleanly at a system migration point with no bridging logic; and product or SKU data so inconsistent that like-for-like analysis across periods is guesswork. A SaaS business acquired at a revenue multiple will often have ARR figures that look defensible in the CIM. Post-close, when the operating partner tries to build a proper cohort analysis, they find that the ARR calculation was done manually by the VP of Finance, using a methodology that was never documented, and changed at least once during the period in question. The number was not wrong, exactly. But it cannot be reproduced reliably going forward, which means the business cannot manage to it. Customer data problems delay or derail pricing work, upsell analysis, churn modelling and retention programmes — all of which are standard levers in a PE value creation plan. The cost is not a line item. It is six to twelve months of lost initiative momentum while the data gets rebuilt. --- ## Reporting infrastructure breaks under the pressure of new ownership Pre-acquisition, a management team runs a business. Post-acquisition, they run a business while also responding to a new set of reporting requirements from an owner who wants more granularity, faster, on different dimensions than the previous owner cared about. Most businesses are not set up for this. Their reporting infrastructure was built to serve internal management, not external stakeholders with specific value creation hypotheses. The result is that finance and ops teams spend an enormous amount of time in the first six to twelve months post-close producing reports manually — time they should be spending running the business. The deeper problem is that manual reporting creates compounding data quality issues. Every time a human touches a number to move it between systems, there is scope for error, inconsistency or undocumented adjustment. When those reports start informing decisions — on headcount, on capex, on pricing — the errors travel downstream. An industrials business three months post-close might find its operating partner requesting weekly gross margin by product line, by region, by channel. The finance team can produce it. But it takes two people two days each week, pulling from four systems, applying a margin allocation methodology that is partially in a spreadsheet and partially understood only by the FD. One of those people is also closing the month. Something gives. The right response is not to ask for less data. It is to build the reporting infrastructure properly — ideally before close, or in the first thirty days after it. --- ## Tech stack complexity is underestimated in almost every deal Acquirers look at technology through a cost and capability lens during diligence. How much does it cost? Does it do what the business needs? Is there obvious technical debt? These are necessary questions. They are not sufficient. The question that gets missed is integration quality. A business can have a perfectly functional ERP and a perfectly functional CRM and a perfectly functional data warehouse, and still have a data environment that is effectively broken — because the integrations between those systems were built cheaply, are poorly documented and have never been properly tested under load or change. Post-close, when the operating team wants to connect new tools, build new reporting or run new analytical workstreams, they discover that the integrations are brittle. A field name change in one system breaks a pipeline in another. A new product category does not map correctly to the chart of accounts. Historical data sits in a system that is being deprecated with no migration plan. A business that has grown through acquisition is particularly vulnerable to this. Each acquired entity brings its own systems. Each integration was built to solve an immediate problem. Nobody ever went back to build a coherent data architecture across the combined entity. This is not a technology failure in isolation. It is a governance failure. No one owned the data layer at the enterprise level, so it grew organically in ways that serve no one particularly well. For operating partners running buy-and-build strategies, this compounds with every add-on. Each new acquisition that sits on a different data architecture makes the eventual consolidation harder and more expensive. --- ## What good diligence looks like — and what to do post-close when you missed it A data and technology due diligence should answer five specific questions before close: - Can the business reproduce its key commercial metrics from source data, without manual intervention? - Are data definitions consistent across systems and departments? - Is the reporting infrastructure dependent on specific individuals or documented in process? - What is the integration quality between core systems, and what breaks when those systems change? - Is there a data ownership structure — someone accountable for data quality at the enterprise level? If the answer to more than two of these is "no" or "we don't know", that is a post-close workstream, not a nice-to-have. Post-close, the priority is sequencing. Fix the reporting infrastructure first — the business cannot make good decisions without reliable numbers. Then address customer data, because that is where most value creation levers sit. Tech stack consolidation comes last, because it takes longest and carries the most operational risk. Rodan's diagnostic engagements are designed specifically for this moment — a structured assessment of data infrastructure, reporting quality and analytical capability, delivered in two to three weeks for a fixed fee, with a clear prioritised remediation roadmap. It is the fastest way to understand what you are actually working with before committing to a larger transformation programme. --- ## The cost of finding out late Every month that passes with unreliable data is a month where decisions are being made on a foundation that has not been properly tested. Pricing decisions. Headcount decisions. Capex decisions. Value creation initiatives that may be solving the wrong problem because the data supporting them is not clean. The businesses that get this right treat data infrastructure as part of the asset, not as an IT problem. They build it into diligence. They resource it in the hundred-day plan. They appoint someone to own it. The businesses that get it wrong spend the first year of ownership firefighting reporting requests, rebuilding customer data from scratch and wondering why their operating model assumptions are not playing out as expected. If you have recently closed a deal, or are in the hundred-day window now, the right move is a structured assessment before you commit resource to value creation initiatives that depend on data you have not yet validated. [Book a diagnostic with Rodan](https://rodan.io) to understand exactly what you are working with. --- **Meta description:** Data problems discovered post-close cost PE-backed businesses months of value creation. Here are the issues acquirers miss most — and how to fix them fast. HTML: https://rodan.io/insights/the-most-common-data-problems-acquirers-discover-post-close