Delfen
All articlesTechnical Due Diligence

Technical debt belongs in the purchase price, not the appendix

TSB's board decided how to hit Sabadell's promised £160 million in IT synergies: build the new platform through Sabadell's own delivery arm, never formally checked and never reassessed for two-plus years. The migration failed, and cost £330 million.

Jacques Domenie·18 July 2026·6 min read

Banco Sabadell's 2015 offer document for TSB Banking Group promised something specific: approximately £160 million a year in IT synergies by year three, once TSB's systems moved onto Sabadell's own core banking platform. In December 2015, TSB's board decided how to get there: build a UK-adapted version of that platform through SABIS, Sabadell's own IT-delivery subsidiary. Nobody formally assessed whether SABIS could actually deliver it — and over the next two-plus years, as the migration date approached, nobody went back to check either. Over the weekend of 20–22 April 2018, the migration happened, and failed catastrophically. Branch, telephone, online, and mobile banking all went down. By the time TSB finished counting, the cost had reached £330.2 million, growing to roughly £366 million by mid-2019, on top of a £48.65 million fine from the FCA and PRA in December 2022. The regulators didn't stop at the corporate fine — they separately fined TSB's former CIO, Carlos Abarca, £81,620 in April 2023, under the PRA's Senior Manager Conduct Rule 2, specifically for failing to obtain sufficient assurance from SABIS. Their finding wasn't that TSB's old systems were rotten. It was that nobody — not at the decision to proceed, and not once in the two-plus years that followed — had formally verified whether the entity building the platform could deliver it.

That's the part of technical due diligence almost nobody does — the fourth in a series on what technical due diligence keeps missing. Everyone checks what the target already runs, once, before signing. Almost nobody keeps checking the plan the acquirer is executing on top of it — especially once the delivery vehicle is somebody already inside the family, an affiliate everyone assumes is safe because it's "ours." That's exactly where TSB's scrutiny relaxed, and exactly where the next TSB gets made.

There's no line item for this

Financial due diligence has a settled taxonomy: deferred revenue, overdue payables, accrued PTO, tax liabilities — the standard "debt-like items" that flow straight into a net-debt or working-capital adjustment. Technology isn't on that list. I ran a mid-market accounting firm's own rundown of what typically gets bucketed as a debt-like item in an SPA, and IT or software remediation cost doesn't appear anywhere in it. That's not an oversight — it's a category that was never built. Financial debt has a century of accounting convention behind it. Technical debt has none, which means it defaults to a paragraph in the DD report's appendix instead of a number in the model, even though Deloitte puts the underlying cost at 21–40% of IT spend going to carry technical debt in a typical organization.

AI-assisted development won't shrink that number. An integration team leaning on AI coding assistants to hit a Day-100 deadline generates working code fast — new technical debt accumulates at the same pace, in a codebase the DD process already signed off on before any of it existed. The target you diligenced and the target six months into integration are not the same technical estate.

What a finding becomes, mechanically

When a finding gets priced, it becomes one of a small number of things, and which one depends on what kind of finding it is. The clearest framing comes from buy-side M&A practice itself: if an issue is certain and quantifiable, it becomes a straight price adjustment. If it's real but the amount or timing is uncertain, it becomes a specific indemnity, carved outside the general cap — not folded into the negotiated basket that covers unknowns. If it threatens closing and can be fixed before completion, it becomes a condition precedent. If it falls outside what representations-and-warranties insurance will cover — and RWI is underwritten to exclude known issues by design, not just as a blacklist — the seller has to provide protection directly to close that gap. Escrows show up in roughly nine of ten private deals for exactly this reason, commonly sized at 10% or more of price for 12–18 months, tied specifically to what diligence actually found. One specialist technical-DD advisory, Cloudskope, is blunt about how its own reports get used by PE sponsors: to justify a lower EBITDA multiple, negotiate a lower price, or set an escrow holdback. That's the mechanism a technical-debt finding should go through — and, absent a standard bucket for it, almost never does by default.

Locked-box kills your leverage the day you sign

Timing decides whether any of this is even possible. Under a locked-box structure — price fixed up front, against a historical balance sheet — the guidance to buyers is direct: once the agreement is signed, there's little room left to revisit price. A technical-debt finding either gets baked into that fixed number before signing, or it doesn't get priced at all, because it's unlikely to qualify as post-signing "leakage" — leakage covers value the seller extracts, not a pre-existing liability the buyer simply didn't find in time. Completion accounts give a second chance: a true-up after closing can still catch a finding characterized as a working-capital or debt-like item, but only if the agreement's own definition of those accounts explicitly captures it. Courts don't imply exclusions the parties failed to draft. Whichever structure applies, the finding has to exist, in writing, before the number that matters gets fixed.

It isn't a one-off

TSB isn't an isolated cautionary tale. The Co-operative Bank had already started replacing its core banking system before its 2009 merger with Britannia Building Society; the merger expanded that project's scope to cover both banks' legacy platforms at once. Cost estimates climbed from £184 million to a completion estimate near £950 million before the board finally cancelled it in 2013, booking a roughly £300 million write-down — about a fifth of the £1.5 billion capital shortfall that nearly took the bank down. Different decade, different bank, same shape: a technology integration plan that got bigger and riskier because of the deal, and that nobody re-diligenced when the deal changed its scope.

My test for whether a DD process is serious: ask for one artifact that almost no checklist requests — the acquirer's own integration delivery plan, reviewed with the same rigor as the target's system inventory — and ask who's re-checking it six months from now. TSB's board approved SABIS once, in December 2015, and the regulators found nobody went back to look until the migration was already failing. Ask the DD team one question: if the integration plan fails the way TSB's did, whose plan gets audited, and how recently was it last checked? If nobody can answer that, the technical debt in this deal isn't only sitting in the target's systems. It's sitting in your own integration plan, unpriced and unwatched.

Pricing an integration plan with the same rigor as a target's legacy systems is a due-diligence design decision, not an afterthought — that's a conversation worth having before signing, not after the migration weekend.

Sources & further reading

Continue reading

Get the next article in your inbox.

One deep-dive per week. Free. No pitch. Unsubscribe anytime.

Subscribe to the Delfen Briefing →
← Back to all articles