In March, a sponsor walked a financial QoE on a $220 million B2B SaaS acquisition. Clean EBITDA. Reconciled revenue. The CFO defended every assumption. Three weeks after close, the operating partner asked for a forecast by region and customer cohort. The portco finance team delivered a spreadsheet with 14 tabs, three different customer IDs for the same account, and revenue recognition rules that lived in the head of one analyst who had just resigned. The QoE tested whether last quarter’s numbers were correct. It did not test whether this quarter’s numbers could be produced at all.
Data due diligence for private equity is not a deeper QoE. It is a separate workstream that asks whether the data infrastructure can support the value creation plan. A QoE auditor reconciles historical EBITDA. A data team flags that churn has no single source of truth, that customer master records duplicate across three systems, and that the forecast model the board will rely on cannot be rebuilt if the analyst leaves. These are not accounting problems. They are operational risks that reprice deals, delay integrations, and kill the 12-month EBITDA bridge the thesis depends on.
What data due diligence actually tests
A financial QoE verifies that reported numbers are accurate. Data DD verifies that the systems, definitions, and processes that produced those numbers can produce them again, reliably, at the cadence and granularity the new owner will demand. The QoE asks if last year’s $18 million in revenue is correct. Data DD asks if the company can tell you which products drove it, which customer cohorts are expanding, and whether next quarter’s forecast has any empirical foundation.
The work splits into five areas: data quality, system architecture, reporting capability, forecast reliability, and organizational ownership. A QoE team reconciles the P&L. A data team walks the revenue waterfall, pulls customer records, stress-tests the CRM-to-GL reconciliation, and asks the finance team to reproduce last month’s board deck without the analyst who built it. Where QoE finds a restatement risk, data DD finds an operating risk: the portco cannot answer the questions a PE owner will ask in the first 100 days.
Problem one: customer master duplication and no single source for churn
The most common data failure is customer identity. A portco sells through direct, partner, and enterprise channels. Each channel uses a different system. A single customer appears three times: once in Salesforce with the headquarters address, once in NetSuite under a subsidiary name, and once in the billing system under a reseller. When the operating partner asks for churn by customer segment, the finance team delivers a number no one can defend because no one knows which entity is the customer.
This is not a CRM problem. It is a revenue problem. Churn, expansion, cohort analysis, and LTV all depend on defining the customer consistently. A QoE reconciles revenue to the contract. Data DD asks whether the contract, the invoice, the CRM account, and the support ticket all refer to the same entity, and whether the company can produce a single, defensible churn figure next month when the new CFO asks for it.
The fix is not a migration. It is a customer master data model: a canonical customer ID, a set of matching rules, and a reconciliation process that runs before the board deck goes out. One $180 million portco we worked with had 11,000 customer records and 8,200 actual customers. The delta was costing them two points of reported churn because renewals were being classified as new business when the name did not match. The QoE caught none of this because the revenue figure was correct. The data review caught it in week two because the churn figure could not be reproduced.
Problem two: revenue recognition rules that live in spreadsheets
A SaaS company reports $40 million in ARR. The QoE verifies it. The data team asks how multi-year deals are recognized, how professional services are separated from subscription revenue, and how the company will comply with ASC 606 when the new owner consolidates financials. The answer is a spreadsheet the controller updates manually every month, with revenue allocation rules documented nowhere and a recognition timing assumption that three people interpret differently.
This survives QoE because the historical figures reconcile. It fails data DD because the process cannot scale, cannot be audited, and cannot be handed to a new finance team during integration. Revenue recognition is not a QoE reconciliation item when the rules are applied consistently. It becomes a data problem when the rules exist only in institutional knowledge and the spreadsheet that operationalizes them has no documentation, no version control, and no backup if the person who built it leaves.
The consequence is integration risk. A sponsor buying three SaaS companies to roll up cannot consolidate revenue if each portco calculates ARR differently and none of them can produce the calculation logic in a reproducible format. The value creation plan assumes clean, additive financials. The data reality is three spreadsheets, two of which break when you sort them.
Problem three: forecast models with no empirical foundation
The CFO presents a three-year forecast. Revenue grows 30% year one, 25% year two. EBITDA margins expand two points annually. The operating partner asks what drives the growth assumption. The CFO says pipeline. The data team pulls the CRM and finds that pipeline definitions changed twice in the last year, that win rates are calculated differently by region, and that the forecast model is a top-down wedge with no connection to product, customer cohort, or sales capacity.
A QoE does not test forecast reliability. It tests whether historical financials are correct. Data DD tests whether the forecast the board will govern by has any relationship to the operating levers the company can actually pull. If revenue growth assumes 40 new enterprise deals and the company has closed 12 enterprise deals in the last two years, the forecast is not a plan. It is a hope dressed in a spreadsheet.
Forecast reliability is the second-most-cited data problem in the 2025 Simon-Kucher PE study, after reporting lag. PE buyers care because covenant compliance, borrowing base calculations, and board credibility all depend on the CFO being able to defend the next quarter’s number. A forecast built on top-down assumptions and disconnected from customer behavior, sales capacity, and product roadmap is a valuation risk and an operating risk. It cannot be stress-tested, cannot be re-cut by scenario, and cannot give the operating partner confidence when revenue misses in month four.
Problem four: reporting lag and the 45-day close
The portco closes its books 28 days after month-end. The QoE finds no material issues. The data team asks why it takes 28 days and discovers that three systems do not talk to each other, that revenue is reconciled manually, that the close process depends on two people working 60-hour weeks, and that any request for a non-standard cut of the data adds another week. The new owner will want weekly revenue visibility, daily cash position, and board-ready financials in 10 days. The current process cannot deliver any of that.
Reporting lag is not an accounting problem. It is an architectural problem. A QoE audits the output. Data DD audits the process and the systems that produce the output, and asks whether the process can be compressed and whether the systems can deliver the cuts and the cadence a PE owner will demand. A 28-day close is fine for a founder-owned business. It is a deal risk for a sponsor who needs real-time visibility into cash, covenants, and operating metrics to manage the investment and report to LPs.
The fix is not hiring more accountants. It is automating reconciliation, integrating the billing-CRM-GL stack, and moving revenue recognition out of spreadsheets and into the ERP. One portco we reviewed had a 35-day close driven entirely by manual journal entries to allocate multi-entity revenue. The QoE passed it. The data review flagged it as the single largest integration risk because the sponsor’s other three portcos all closed in 10 days and the plan was to consolidate financials monthly.
Problem five: no ownership and no documentation
The data works because one person makes it work. The senior analyst knows which fields are reliable, which reports are broken, where the CRM duplicates customers, and how to interpret the churn figure the CEO presents to the board. That analyst is not documented. The knowledge is not codified. There is no data dictionary, no process manual, and no second person who can produce the board deck if the analyst is gone.
This is an organizational risk, not a technical one. A QoE does not test whether the company can reproduce its financials without key personnel. Data DD does, because a PE owner will replace the CFO, will ask the finance team to produce new cuts of the data, and will integrate the portco into a centralized FP&A function that does not have access to the analyst who has been doing this for four years. If the data process is institutionalized in one person and not in systems, documentation, and repeatable workflows, the value creation plan has a single point of failure the QoE never surfaced.
The test is simple: ask the finance team to reproduce last month’s revenue figure without the person who usually does it. If they cannot, or if it takes three days and produces a different number, the data process is not an asset. It is a dependency the buyer is inheriting and will have to rebuild in the first 100 days.
What it costs to fix and when it reprices the deal
Most data problems do not reprice deals. They reprice the integration timeline and the EBITDA confidence in year one. A sponsor buying a company with clean financials and broken data will not walk. It will budget six months and $400,000 to rebuild the revenue waterfall, hire a data engineer to integrate the CRM and ERP, and accept that the first two quarters of board reporting will be approximate while the new CFO fixes the infrastructure the QoE did not test.
The cost shows up in three places: time to value creation, day-one operating expense, and forecast reliability. A portco that cannot produce reliable churn, cannot forecast with confidence, and cannot close its books in under 20 days will not hit the 12-month EBITDA target the model assumes. The sponsor will spend the first year fixing data infrastructure instead of executing the revenue playbook, and the operating partner will spend board meetings explaining why the numbers are approximate instead of presenting the efficiency gains the thesis depends on.
Some findings do reprice. If customer data is so broken that cohort analysis is impossible, if revenue recognition does not comply with ASC 606 and a restatement is likely, or if the forecast has no empirical foundation and the CFO cannot defend it under questioning, the buyer has an information asymmetry problem. The seller presented financials the QoE verified, but the business cannot produce those financials going forward without a rebuild the model did not budget for. That is either a valuation adjustment or a walk-away.
Why this is separate from financial QoE
Financial QoE and data due diligence test different risks. QoE verifies that historical numbers are accurate and that there are no restatement, compliance, or fraud risks in the financials the seller presented. Data DD verifies that the company can continue to produce accurate numbers at the cadence, granularity, and reliability the buyer will require, and that the data infrastructure can support the questions the value creation plan will ask.
A QoE is backward-looking. It reconciles what happened. Data DD is forward-looking. It stress-tests whether what happened can be measured, reported, and forecast going forward. A QoE auditor signs off on last year’s EBITDA. A data auditor flags that next quarter’s EBITDA cannot be forecast with any confidence because the revenue model is a top-down wedge disconnected from pipeline reality and the churn figure has three different definitions depending on who you ask.
The two workstreams should run in parallel, not in sequence. Waiting until post-close to discover that the data is broken, that reporting takes 30 days, and that the forecast cannot be defended costs the buyer six months of value creation and forces the operating partner to spend the first 100 days rebuilding infrastructure instead of executing the plan. Running data DD during diligence surfaces the risk, quantifies the fix, and gives the buyer the option to adjust the model, renegotiate, or budget the rebuild into the integration timeline before the wire goes out.
Data due diligence for private equity is not a deeper audit of the P&L. It is an operational assessment of whether the business can produce the data, the reporting, and the forecast reliability a PE owner will demand in the first month of ownership. The five problems above survive financial QoE because they are not accounting problems. They are process, architecture, and organizational risks that only surface when someone asks the portco to produce a number it has never had to produce before. A QoE tests the past. Data DD tests the future. Both are necessary. Neither is sufficient alone.
Need a data infrastructure review before you close? DevriX runs embedded data and FP&A engagements for PE-backed portcos and operating partners who need reliable reporting, defensible forecasts, and integration-ready systems. We operate as an internal function, not a consulting project. See how we work.
What a data due diligence engagement looks like
A data DD workstream takes two to four weeks depending on the company’s scale, system count, and data complexity. The team interviews the CFO, controller, RevOps lead, head of analytics, and the teams who own CRM, ERP, billing, and product analytics. The goal is not to verify numbers—QoE does that—but to test whether the business can answer the questions a PE owner will ask in the first 90 days.
The workstream maps five operational areas:
Source systems and integration architecture. What systems hold customer, revenue, product, and operational data? How do they connect? Is there a single source of truth for customer ID, contract value, churn, and cohort assignment, or does every team define those terms differently? Can the business produce a unified customer view without manual reconciliation?
Reporting cadence and close process. How long does it take to close the books each month? Who produces the board deck, and how much of it is pulled directly from systems versus assembled in spreadsheets? If the buyer asks for weekly revenue reporting, daily sales pipeline visibility, or real-time product usage metrics, can the business deliver it, or does the request require a rebuild?
Forecast process and assumptions. Who owns the forecast, and what method do they use? Is revenue forecasted bottom-up from pipeline and historical close rates, or top-down from a target the CEO chose? Can the CFO defend the assumptions under questioning, or is the forecast a negotiated number that no single person can reproduce? If churn is 8%, where did that figure come from—cohort analysis, billing system reports, or the average of three contradictory definitions?
Data ownership and governance. Who decides what customer status means, how churn is calculated, or whether a contract renews automatically? Is there a data dictionary, or does every team use its own definitions? When two reports show different revenue figures, is there a process to reconcile them, or does the business pick the one that feels right?
Team capability and capacity. Does the company have the people to answer the questions above, or is the CFO also the controller, the FP&A lead, and the person who updates the board deck? If the buyer wants a weekly operating review with cohort-level metrics, ARR bridge detail, and pipeline coverage analysis, can the existing team produce it, or does the portco need to hire three people the model did not budget for?
The output is a memo that summarizes the five areas, flags the gaps that will block value creation, quantifies the fix, and recommends whether the issue reprices the deal, delays close, or gets budgeted into the first-year integration plan. It does not replace QoE. It complements it. QoE verifies the numbers are accurate. Data DD verifies the business can keep producing them.
When to run it
Data DD belongs in the diligence calendar alongside financial QoE, commercial DD, and technology review. It runs in parallel, not after. Waiting until post-close to discover that reporting takes 30 days, the forecast is a guess, and the revenue model cannot answer cohort-level questions costs the buyer the first six months of value creation and forces the operating partner into a defensive posture at the first board meeting.
The workstream should start after the LOI is signed and exclusivity is in place, but before the purchase agreement is finalized. That gives the buyer time to quantify the fix, adjust the model, or renegotiate if the data infrastructure is worse than the management presentation suggested. If the business cannot produce reliable reporting, cannot forecast with confidence, and does not have the team to fix it, the buyer has three options: walk, reprice, or budget the rebuild into year-one opex and accept that the revenue playbook will not execute on the original timeline.
None of those options are available post-close. At that point, the buyer owns the problem, and the operating partner’s job shifts from evaluating the risk to explaining to the deal team why the portco is burning budget on data infrastructure instead of executing the growth plan the model assumed would start on day one.
What good looks like
A passing data DD does not require perfection. It requires sufficiency. The business does not need a data warehouse, a semantic layer, or a team of analysts. It needs to close the books in under ten days, produce a board deck without manual reconciliation, forecast revenue from a method someone can defend, define metrics once and use them consistently, and staff the finance function well enough that a weekly operating review does not require the CFO to work weekends.
Specifically:
System architecture that supports reporting. The CRM, billing system, and ERP talk to each other without manual CSV exports. Revenue can be reported by product, customer segment, cohort, and geography without rebuilding the dataset each month. Customer status is a field, not an interpretation. When the operating partner asks for pipeline coverage by region, the answer arrives in hours, not weeks.
A close process that finishes in single digits. The books close in seven to nine days. The controller knows what will delay it and has a plan to fix it. The board deck pulls directly from financial systems for 70% of its content. The remaining 30%—commentary, variance explanation, forward outlook—is written by people who understand the business, not assembled by interns copying numbers between spreadsheets.
A forecast method someone can explain. Revenue is forecasted from pipeline, weighted by stage and historical close rates. Churn is calculated from cohorts, not averages. The assumptions are documented, the model is version-controlled, and the CFO can walk the board through the build without hedging. When actual results differ from forecast, the variance is explained with data, not narrative.
Metrics defined once and used everywhere. There is a data dictionary. Customer, churn, ARR, pipeline, and bookings mean the same thing in the CRM, the board deck, and the forecast model. When two reports show different numbers, the reconciliation is mechanical, not political.
A finance team sized for the operating model. If the business is $50 million ARR and the buyer’s playbook requires weekly operating reviews, cohort reporting, and pipeline analysis, the finance function has more than two people. The CFO is not also the controller. The controller is not also the person who updates Salesforce. There is enough capacity that a reasonable request does not become a month-long project.
That is the standard. Not cutting-edge. Not best-in-class. Just sufficient to execute the value creation plan the buyer is paying for.
What to do when it does not pass
When data DD surfaces gaps that will block execution, the buyer has three moves, and the choice depends on how bad the problem is, how much it costs to fix, and how much time it adds to the plan.
Reprice the deal. If the business cannot produce reliable reporting, cannot forecast with defendable assumptions, and does not have the team to fix it, the risk reprices the equity. The buyer is not buying a $50 million ARR SaaS business with 30% growth and a clear path to $100 million. The buyer is buying a $50 million revenue stream with a six-month data infrastructure project, a finance team rebuild, and a delayed start to the growth playbook. That is a different deal, and it should carry a different valuation.
Budget the fix into year one and adjust the model. If the gaps are fixable but material, the buyer accepts the problem and plans the rebuild. That means adding headcount the original model did not include—a controller, a rev ops lead, a senior analyst—and pushing the revenue playbook back by two quarters while the data foundation gets built. The deal still closes, but the EBITDA bridge changes, the timeline extends, and the operating partner’s first-year priorities shift from growth to infrastructure.
Walk. If the business cannot produce a defendable forecast, cannot explain where its numbers come from, and does not have the capability or the willingness to fix it, the deal does not close. Walking is rare, but it happens. A sponsor does not pay a software multiple for a business that operates like a services company with a subscription revenue line.
The decision comes down to cost, time, and risk. A $300,000 fix and a one-quarter delay is usually acceptable. A $2 million rebuild, a full-year delay, and a CFO who does not believe the problem exists is not. The point of data DD is to surface that distinction before the purchase agreement is signed, when the buyer still has leverage and options.
Why this matters now
Five years ago, a PE buyer could close a deal, discover the portco’s data was a mess, and spend six months fixing it without damaging the return. The hold period was five to seven years. Multiples were expanding. A late start on the value creation plan was recoverable.
That environment is gone. Today’s deals assume faster EBITDA growth, shorter hold periods, and tighter operating margins. The model does not have room for a six-month data rebuild that delays revenue execution and burns unbudgeted opex. The operating partner is expected to deliver results in the first twelve months, and the board will not accept “we are still building reporting” as an explanation for missed targets.
Data DD is not a new workstream. It is a recognition that the infrastructure questions that used to get deferred to post-close now determine whether the value creation plan is executable at all. Answering them during diligence, when the buyer can still reprice or walk, is cheaper and faster than discovering them at the first board meeting, when the only option left is explaining to the deal team why the portco is six months behind plan.