Financial and legal due diligence are standard. Technology due diligence usually is not, and the result is a deal priced on numbers from a system nobody checked, with integration costs nobody estimated. What to look at, what the red flags are, and what it should change about the price.
When a business is bought, the lawyers go through the contracts and the accountants go through the numbers. Technology gets a line in the information memorandum ("the company operates a modern ERP system") and a question in the data room, and that is usually it. Then completion happens, the integration starts, and the acquirer discovers that the modern ERP is a heavily customised 2014 install that nobody can upgrade, the numbers in the IM came out of a spreadsheet, and the one person who understands the integrations handed in their notice in week two.
This happens constantly. It is avoidable for a few days of effort before the price is agreed. Here is what technology due diligence looks like for a mid-sized acquisition, and why it belongs in the deal timetable alongside the financial and legal work.
Four questions. Can the numbers be trusted? Can the business keep running? What will it cost to integrate or fix? And what is about to go wrong?
The financial due diligence takes the management accounts as its starting point. Technology due diligence asks where they came from. Specifically: does the ERP produce the P&L, balance sheet and stock valuation directly, or are they assembled in spreadsheets from exports? How much manual adjustment happens at month-end, and who does it? Is stock valued by the system or by a count and a formula? Are there intercompany balances that do not eliminate? Is revenue recognised by the system or by hand?
A business whose numbers are assembled in spreadsheets is not necessarily misreporting. But its numbers carry a risk that the financial DD will not see, and it is a business that will need its systems fixed before it can be integrated or sold again. That is a cost, and it goes in the price.
If the acquirer intends to put the business on its own systems, the question is migration: how clean is the data, how many customisations encode processes the business depends on, how many integrations have to be rebuilt. If the business is to stand alone, the question is what has to be fixed to make it saleable again. Either way the output is a costed, phased plan with a number on it, and that number should be in the model before the price is agreed, not discovered in the first hundred days.
The most common surprise: integrations. The web shop, the EDI link to the largest customer, the warehouse scanners, the payroll feed, the courier interface. Each one was built once, by someone, for one version of the system. Each one has to be rebuilt or re-pointed, and the business cannot trade without them. Count them, and cost them.
The technology equivalent of a contingent liability. A vendor end-of-life date in the next two years. A contract renewal that will double because the business is about to lose a discount. A partner who has been "about to upgrade" for eighteen months. A customer who has said they will require EDI or a portal the business cannot provide. A GDPR or sector-regulatory exposure (pharma validation, PCI, government security standards) that the business is not meeting and has not been asked about yet.
Sometimes nothing: the business is well run, the systems are current, and the DD confirms it, which is itself worth having. More often it changes one of three things: the price (a costed remediation plan is a negotiating position), the structure (a warranty, an escrow, a retention tied to a key person or a system milestone), or the hundred-day plan (the integration cost is known on day one instead of day ninety). Occasionally it changes the decision.
For a mid-sized business, three to five days of a senior person who has run these systems: a day in the data room, a day on site with the finance and operations teams, a day with the systems and the partner, and a day to write it up as a one-page summary, a risk list with costs, and a remediation plan. It fits inside a normal DD timetable and it costs a fraction of what the first surprise would.
It is also, from the other side, exactly what a seller should do eighteen months before going to market; we wrote that up in Preparing the ERP for an exit. If you have a deal in progress, our portfolio and investor services page covers what we do, and the conversation starts with a call.
