Where IT due diligence stops and FDD begins: capitalised software, tech debt as post-close CapEx, and cyber as a contingent liability — a map for TS analysts.
A software target reports £14m of adjusted EBITDA. The IT due diligence team, sitting in a different room with a different partner, works out that roughly £2.5m of what the company calls "capitalised development" is really the salaries of engineers keeping the existing product alive. Nobody tells the FDD team. The deal prices off £14m. Six months post-close, the buyer discovers the real cash-generative EBITDA was closer to £11.5m — and that a £2.5m annual cost they thought was an investment is actually just running the business. That gap is the single most valuable reason a Transaction Services analyst should understand what IT DD does, and it is why this workstream deserves far more of your attention than the industry usually gives it.
Every deal of any size now carries an IT due diligence workstream, run by a separate specialist team. Most TS analysts never sit in on their calls, never read their report until the data room is closing, and treat their findings as somebody else's problem. That is a mistake. IT DD routinely surfaces issues that change the FDD numbers directly, and knowing where the two disciplines collide is a genuine differentiator — in the report and in the interview room.
IT DD assesses the target's technology estate independently of the financial statements. The core scope is consistent across firms even if the labels vary:
It is a technical and operational assessment. It speaks in system diagrams, uptime percentages, and severity scores. It is not, on its face, a financial exercise — which is precisely why the financial consequences of its findings so often go unbanked.
The obvious question is why IT DD is not simply a chapter in the FDD report. The answer is skills. Assessing whether a microservices architecture will scale, or whether a codebase carries dangerous single points of failure, requires engineers, not accountants. Bolting that onto an FDD team would dilute both. So the market splits the work: FDD owns the numbers and the FDD report structure, IT DD owns the technology, and the two are expected to reconcile at the edges.
The problem is that the edges are exactly where value leaks. FDD and IT DD run on parallel, siloed timelines, frequently for different teams inside the same firm — or different firms entirely — with a single joint call near the end if you are lucky. IT DD speaks in vulnerability scores; FDD speaks in EBITDA bridges; neither team is naturally fluent in the other's language. The analysts who add real value are the ones who proactively ask the IT team, "does anything you've found affect our adjustments?" rather than waiting for it to be flagged in a report nobody reads until Friday.
This is the big one. Under both IFRS (IAS 38) and US GAAP, certain internal software development costs can be capitalised — recorded as an asset on the balance sheet and amortised over time — rather than expensed through the P&L in the year they are incurred. The rule exists for good reason: building genuinely new functionality is investment. But it is one of the most reliably abused levers in software accounting, because capitalising a cost that should have been expensed lifts reported EBITDA and strengthens the balance sheet in a single move.
Where IT DD earns its fee is in telling you what the capitalised spend actually bought. If the engineers whose salaries were capitalised spent the year fixing bugs, refactoring, and keeping the lights on — routine maintenance — that cost belongs in the P&L, and any EBITDA built on top of it is overstated. This is a direct quality of earnings adjustment, and it is the kind of finding that only surfaces because two teams are looking at the same spend from different angles.
Here is a worked mini-example of how a single reclassification flows through to price.
| Line | As reported | Adjusted | Comment |
|---|---|---|---|
| Reported EBITDA | £14.0m | £14.0m | Starting point |
| Overcapitalised dev costs (maintenance) | — | (£2.5m) | Reclassified to opex per IT DD |
| Adjusted EBITDA | £14.0m | £11.5m | The number a buyer should lever |
| Entry multiple | 8.0x | 8.0x | Unchanged |
| Implied enterprise value | £112.0m | £92.0m | £20m swing |
A £2.5m reclassification moves enterprise value by £20m at an 8x multiple. No single FDD sampling exercise moves the deal that much. It only came to light because someone connected the IT team's view of the engineering headcount to the accounting treatment of their salaries. This is exactly the class of item covered in a broader EBITDA adjustments analysis, but with a technical fact pattern the FDD team cannot generate on its own.
Rule of thumb: if a software target's capitalisation policy is generous and its capitalised development balance is large relative to revenue, treat it as a red-flag QoE item until IT DD confirms what the money actually bought. The reclassification risk runs one way — always against the seller's EBITDA.
IT DD almost always produces an estimate of "must-spend" technology investment over the first 12–24 months post-close: a re-platform, a security remediation programme, an ERP migration, a cloud migration to retire ageing on-premise kit. This does not change historical EBITDA — the money has not been spent yet — but it belongs in the same conversation as your maintenance CapEx analysis, because it directly shapes the buyer's view of free cash flow after close.
The distinction to hold in your head is growth vs. maintenance. A re-platform that merely keeps the product viable is closer to maintenance CapEx: it is the cost of continuing to exist, and it should be netted against the cash the business appears to generate. A re-platform that unlocks a genuinely new revenue line is growth CapEx, discretionary and thesis-dependent. IT DD gives you the raw number; you decide, with the deal team, where it sits.
| Item | Amount | FDD treatment |
|---|---|---|
| Legacy ERP migration (mandatory) | £3.0m | Maintenance-like; erodes post-close free cash flow |
| Security remediation (mandatory) | £0.8m | Maintenance-like; often bundled into completion conditions |
| New analytics platform (thesis growth) | £2.2m | Growth CapEx; discretionary, sits with sponsor's plan |
| Total flagged by IT DD | £6.0m | Split £3.8m maintenance / £2.2m growth |
Reporting the total without splitting it is a rookie move. A sophisticated buyer wants to know how much of the £6.0m is the cost of standing still — because that portion behaves like a hidden recurring cost and quietly lowers the multiple they can justify.
A material historical breach — or an unremediated vulnerability the IT team rates as critical — can become a contingent liability disclosed in your report and factored into the net debt or completion-mechanism discussion. The financial records alone will rarely show it: a breach that has not yet triggered a regulatory fine or a customer claim leaves no line in the ledger. It lives only in the IT DD findings until someone sizes its financial consequence.
Your job is not to run the penetration test. It is to take "the customer database was exposed in 2024 and remediation is incomplete" and translate it into "potential regulatory exposure and remediation cost of £X, to be reflected as a specific indemnity or a net-debt-like item in the deal structure." That translation — technical fact to financial consequence to purchase-agreement mechanic — is the skill that makes cross-workstream findings actually count.
You do not need to become an IT specialist. You need a short, disciplined routine on every deal that has a technology dimension:
There is a fourth intersection that gets less attention but matters enormously for software and technology targets: the link between the technology estate and revenue quality. IT DD assesses whether the platform can retain and scale customers; FDD assesses whether the revenue those customers generate is high-quality and recurring. The two views should reconcile, and when they do not, something is wrong.
Consider a target boasting strong recurring revenue metrics while IT DD reports that the product is unstable, frequently down, and losing customers to outages. Those two stories cannot both be fully true. High reported retention on top of a failing platform usually means one of a few things: churn is lagged and about to spike, "recurring" revenue is being propped up by discounting or one-off concessions, or the retention definition is generous. This is where the FDD analyst should be reading the IT DD report not for its own sake but as a cross-check on the durability of the earnings the whole deal is priced on — the same instinct that drives a good revenue quality analysis. A platform's technical health is a leading indicator of its revenue's staying power, and a leveraged buyer relying on that revenue to service debt needs both stories to agree.
Interviewers love this topic because it separates candidates who understand FDD as a spreadsheet exercise from those who understand it as a commercial one. Expect: "How does IT due diligence affect the financial numbers you produce?"
"IT DD runs as a separate workstream, but it feeds FDD in three concrete ways. First, capitalised software — if IT DD tells me the engineers whose salaries were capitalised were actually doing maintenance rather than building new functionality, that spend should be expensed, and adjusted EBITDA comes down. On a £2.5m reclassification at an 8x multiple, that's a £20m swing in enterprise value, so it's material. Second, technical debt — IT DD sizes the must-spend investment post-close, like a re-platform or security remediation, and I'd split that into maintenance-like and growth CapEx, because the maintenance portion behaves like a hidden recurring cost that erodes free cash flow. Third, cybersecurity — a historical breach or unremediated vulnerability becomes a contingent liability, which I'd size with the IT team and reflect either as a specific indemnity in the SPA or as a net-debt-like item. The common thread is translation: my job is to turn a technical finding into a financial consequence the buyer can actually price."
That answer works because it is specific, it is numerate, and it demonstrates the cross-workstream instinct that partners are hoping to hear.
The technology in any modern target is where a growing share of both the value and the risk now lives, and it is the one area where the FDD team is structurally blind without help. An analyst who knows to ask whether an IT DD workstream exists, who scrutinises capitalised software as a matter of routine, and who can turn "the platform is end-of-life" into a number a buyer can price, is doing something a spreadsheet operator cannot. That is the analyst who gets pulled onto the interesting deals — and, in an interview, the one who sounds like they have already done the job.
The Transaction Services Interview Programme (€119.99, one-time) includes a full module on cross-workstream findings — capitalised software, technical-debt CapEx, and cyber as a contingent liability — with worked EBITDA and enterprise-value bridges you can defend on a call. Enrol today.
Hundreds of candidates prepared their interviews with this programme. Those who landed the role have one thing in common: they worked the cases before walking into the room.
