Quantifying Technical Debt for the Deal Model

Dollars, or It Did Not Happen

Set the rule before the scope is signed. Any technology finding that does not resolve to a dollar figure and a timeline does not go in the report. Not a severity rating, not a maturity score, not a count of findings. A number, a method, and a duration.

This is a rule of engagement with your diligence provider, and it will meet resistance, because producing a defensible cost estimate is harder and slower than producing a rating. Hold the line anyway. A report that says the target's identity architecture is "immature" produces nothing. A report that says migrating 340 service accounts off shared credentials and onto managed identities is eleven engineer-months of work, 181,500 dollars fully loaded, and a prerequisite for the SOC 2 the enterprise pipeline needs, produces a negotiation.

The Three Components of a Remediation Estimate

Build the number from three parts, and show all three separately. Sellers attack aggregated numbers and concede itemized ones.

Engineering effort. Decompose the work into named workstreams, each with a defined deliverable and an end state somebody will sign their name to. Estimate each in engineer-months. Then apply a fully loaded cost, not a salary. Fully loaded means base compensation plus employer taxes, benefits, equipment, software seats, allocated engineering management, and amortized recruiting cost. For United States mid-market software businesses this commonly runs 1.25 to 1.4 times base. If the work will be done offshore or nearshore, the blended rate changes materially and you must state the assumption in the report, because the seller will challenge it and a stated assumption survives the challenge.

Contingency, applied openly. Remediation estimates sourced from the target's own engineering leadership are systematically optimistic. This is not dishonesty. The person producing the estimate is usually the person who accumulated the debt, knows the estimate will be read as a judgment on their tenure, and has never been asked to do this work under a deadline someone else set. Apply a multiplier and disclose it. A defensible working convention, and it is a convention rather than a measured statistic: 1.4 to 1.5 times on estimates sourced from target management, 1.2 to 1.25 times on estimates derived independently from code and infrastructure review. State which you used per line.

Non-labor cost. Licenses, tooling, professional services, audit fees, parallel-run infrastructure during a migration, one-time data egress charges, third-party penetration testing, and any specialist contractor the internal team cannot replace. Watch for items that look one-time but are not. A security tool deployed during remediation carries an annual subscription forever. Split the deployment from the subscription and classify them differently.

Deferred roadmap. The hardest component and the one most often omitted, which is unfortunate, because it is frequently larger than the other two combined. If six of twenty-two engineers are committed to remediation for fourteen months, the product roadmap moves. Quantify it against the revenue plan rather than in the abstract: identify which features in the underwriting model sit on that roadmap, what pipeline or expansion revenue is attached to them, and how far the delay pushes them. If the model assumes a usage-based pricing launch in year two that generates 1.9 million dollars of incremental ARR, and the metering work is queued behind the platform rebuild, that is a revenue timing issue in the model, not a technology finding.

Build It as a Table, Not a Narrative

Component	What to collect	Common error
Engineering effort	Named workstreams, engineer-months per workstream, loaded cost per engineer-month, contingency multiplier and its basis	Using salary instead of loaded cost. Understates by 25 to 40 percent.
Non-labor one-time	Professional services, audit fees, migration tooling, parallel-run infrastructure, egress, contractors	Bundling a perpetual subscription into a one-time deployment line.
Non-labor recurring	New subscriptions, elevated infrastructure run rate, support contracts on unsupported platforms	Treating it as one-time because it appears once in the remediation plan.
Deferred roadmap	Features in the revenue model that sit behind the remediation queue, attached ARR, months of delay	Omitting it entirely, then wondering why year two revenue missed.
Headcount delta	Engineers required indefinitely after remediation completes, versus today	Assuming remediation returns headcount to zero. It rarely does.

Where the Numbers Actually Come From

A cost estimate is only as defensible as the artifacts behind it, and the artifacts are specific. Request them by name, early, and treat slow delivery as information in its own right.

• Thirty-six months of engineering headcount by allocation. Not the org chart. Who was assigned to what, by quarter. This is the document that settles the capital-versus-permanent argument and almost nobody asks for it.
• Two years of issue tracker exports with labels intact. Volume, age, and category of open items, plus the close rate on anything tagged as infrastructure, stability, or security. A backlog that grows at a constant rate is a staffing finding, not a code finding.
• Dependency and licence inventory for the production codebase. Direct and transitive, with licence identifiers. This is where copyleft obligations and end-of-support components surface, and it takes an afternoon to generate if anyone has ever generated one before.
• Every infrastructure and software contract with its renewal date and escalation terms. Support agreements on unsupported platforms, cloud commitment instruments, and per-seat tooling that scales with headcount.
• The engineering roadmap as presented to the target's own board, for the last two years. Compare what was committed against what shipped. The gap is the best available measure of the organization's actual delivery capacity, and it is the number you should use when estimating how long remediation will take.
• Interviews with two engineers who are not the CTO. Conducted separately, under the diligence protocol, asking what they would fix first and what they have been asking for. The answers are consistently more accurate than the estimates produced for the data room.

If the target cannot produce headcount allocation history or a dependency inventory, that is itself a finding. It means nobody has been measuring the thing you are about to buy.

What Not to Count

Discipline on exclusions is what makes the inclusions credible. A report that prices everything gets discounted entirely.

Debt nobody will ever touch. A service written in a language the current team does not use, running stably, not in the roadmap, not in a regulated data path, not blocking an integration, is a hiring inconvenience rather than a deal item. It will appear in the engineering team's list of grievances. It does not belong in the bridge.

Architectural preference. Engineers will tell you the monolith should be decomposed into services. Sometimes that is a genuine constraint on the plan. Usually it is a professional aesthetic. The test is not whether a better design exists. The test is whether the current design prevents something the model requires.

Anything the operating plan already funds. This is the double count, and it is the error that costs a buyer credibility on the items that are real. If your value creation plan already carries a one million dollar platform investment in year one, you cannot also deduct that million from the price. Reconcile the technology diligence output against the operating plan line by line before a single number goes to the seller. Sellers find double counting, and once they find one, every other line gets challenged.

Apply a single filter to everything that survives. Does the item block a revenue or margin line in the model, create a liability with a regulator or a customer or an insurer, or structurally raise the cost of running the business? If the answer to all three is no, write it down as an observation and give it a zero.

The Classification Is Worth More Than the Number

Once every finding has a dollar figure, sort them into two buckets. This sort is the single highest-value hour in the entire technology diligence workstream.

Below the Line, or Through the Multiple

One-time capital. A platform rebuild. A data centre exit. A cloud migration. A remediation program with a defined scope and an end date. A SOC 2 readiness project and first-year audit. An identity architecture rebuild. These are finite. They argue for a purchase price reduction equal to the cost, dollar for dollar, or for an escrow released on completion. They do not touch the multiple, because they do not change what the business earns once the work is finished.

Permanent operating cost. Engineering headcount required indefinitely to keep something running. Structurally elevated infrastructure spend the architecture guarantees. A compliance function the target does not have and cannot operate without. A security capability that has to exist every year forever. A support contract on an end-of-life platform renewing annually at escalating cost. These reduce run-rate EBITDA. Enterprise value moves by the amount times the multiple.

The arithmetic is not subtle and it is worth writing out, because deal teams who know it in the abstract still fail to apply it in a live negotiation.

• 500,000 dollars of one-time remediation, at any multiple, is a 500,000 dollar adjustment.
• 500,000 dollars of permanent annual cost, at 11.0 times EBITDA, is a 5,500,000 dollar adjustment.
• The same 500,000 dollars at 14.0 times is a 7,000,000 dollar adjustment.

An order of magnitude, decided entirely by which bucket the item lands in.

This is why a seller will happily concede a larger one-time number to avoid a smaller permanent one, and why a buyer who has not drawn the distinction in advance will take that trade and think they won. A seller offering to fund a 900,000 dollar remediation program in exchange for the buyer dropping a 400,000 dollar annual headcount argument has just moved 3.5 million dollars of enterprise value in their own favor while appearing to give ground.

The Seller's Arguments, and the Evidence That Defeats Them

There are three of them, and they arrive in this order.

"That is a one-time remediation." The defeat is recurrence evidence. Pull three years of engineering headcount allocation. If four engineers have been assigned to platform stability for three consecutive years and the stability backlog has not shrunk, that is not a project with an end date. That is a function. Functions are opex. Ask for the ticket history, the sprint allocation, and the headcount plan, and read them against each other.

"That is a normalized adjustment." This one usually appears in the quality of earnings work rather than the technology report, which is exactly why technology and QoE have to reconcile. A seller presenting an EBITDA add-back for engineering efficiency expected after a modernization the seller has not funded and will not be around to execute is asking the buyer to pay for a synergy the buyer has to create. Reject the add-back, or accept it only if the seller funds the modernization that produces it. Do not do both.

"A buyer would make that investment anyway." The sharpest of the three, because it is sometimes true, and because conceding it once destroys the line. The answer has two parts. If the investment is already in the buyer's operating plan, the seller is right and the item is a zero, which is why the double-count reconciliation happens before the conversation. If the investment is required to sustain the business as currently modeled, rather than to grow it beyond the model, it is a cost of the existing earnings stream and belongs in the price regardless of who would have made it.

The working discipline is simple. Every item classified as capital must have a defined end state and a named owner willing to state on the record that the spend stops. Every item classified as permanent must have either three years of history showing recurrence or a structural reason it cannot stop, such as an architecture that guarantees the run rate or a regulatory requirement with no end date.

A Worked Example

Illustrative only. The figures below are constructed to demonstrate the method and are not drawn from any specific transaction.

Target: business-to-business vertical software company. 14.0 million dollars of ARR. 4.2 million dollars of seller-adjusted EBITDA. Proposed multiple 11.0 times. Headline enterprise value 46.2 million dollars. Thesis is enterprise upmarket expansion plus three tuck-in acquisitions over a four-year hold.

Loaded cost assumption throughout: 16,500 dollars per engineer-month, or 198,000 dollars per engineer-year.

Finding	Calculation	Classification	Amount
Payments and authentication modules on an end-of-support framework; rebuild required	26 engineer-months at 16,500, contingency 1.4 (target-sourced estimate)	One-time capital	600,600
No SOC 2; enterprise pipeline in the model requires it. Readiness, Type I, first Type II, tooling	Professional services and audit fees	One-time capital	185,000
Ongoing control operation, evidence collection, annual Type II audit, 0.5 FTE compliance owner	Recurring annual	Permanent opex	145,000 per year
Seller add-back for engineering efficiency after modernization the seller has not funded	2.5 engineer-years reallocated, 495,000	Rejected add-back; reduces EBITDA	495,000 per year
Cloud spend 2.1 million growing 34 percent against 19 percent revenue growth; single-tenant per-customer instances	Residual structurally elevated run rate after the rebuild in line one	Permanent opex	260,000 per year
No internal security function; MSP contract at 84,000 with no detection capability	Security lead, endpoint detection, log management at 310,000 gross, less 84,000 already in the P&L	Permanent opex	226,000 per year
Deployment knowledge held by one named engineer; no runbooks, no infrastructure as code	9 engineer-months at 16,500, contingency 1.25 (independently derived)	One-time capital	185,625
Endpoint and logging deployment, one-time	Implementation and rollout	One-time capital	95,000

Totals. One-time capital: 1,066,225 dollars. Permanent EBITDA impact: 145,000 plus 495,000 plus 260,000 plus 226,000, or 1,126,000 dollars per year.

Now run both positions through the model.

• Seller's position. Concede the one-time capital, reject everything else as normal course investment a buyer would make anyway. 46.2 million less 1.07 million equals 45.1 million dollars.
• Buyer's position. Adjusted EBITDA of 4.2 million less 1.126 million equals 3.074 million. At 11.0 times, 33.8 million. Less the 1.07 million of one-time capital equals 32.7 million dollars.

Twelve point four million dollars of spread on an identical set of facts. Nobody disputed a single finding. Nobody argued about whether the framework is end of support or whether the SOC 2 is required. The entire gap is classification, and the party that arrives with the classification already drawn and evidenced controls where it lands.

The landing zone will not be either end. It never is. But a buyer who opens at 45.1 million because the diligence report said "significant technical debt" has conceded 12.4 million dollars before the conversation started, and will never know it.

One honest caveat on the same example. If the thesis is enterprise upmarket expansion, the SOC 2 and the security function are costs of the thesis, not defects of the target. The right treatment may be to leave them in the operating plan rather than in the price, provided the plan actually carried them and the return still clears the fund's hurdle with them included. That is a judgment, and it should be made explicitly rather than by omission. What is not defensible is claiming them in the price and funding them again in the plan.

Thesis Risk, Cloud Trajectory, and the Investment Committee

Separating Debt That Threatens the Thesis From Debt That Is Merely Present

Every software company of any age has technical debt. Maturity models will always return amber. The question is not whether the target is at level three of five. The question is whether any of it stops the plan you underwrote.

Test each surviving item against the value creation plan with four questions.

• Does it block a revenue line in the model? Enterprise upmarket motion blocked by the absence of single sign-on, role-based access control, audit logging, or a SOC 2. International expansion blocked by a single-region architecture with no data residency option. A pricing change blocked by an inability to meter usage. These are revenue findings that happen to live in the technology report.
• Does it block the integration or the add-on strategy? If the thesis is six tuck-ins over four years and the platform cannot onboard an acquired company's customers without a bespoke twelve-month migration, the model is wrong, not the platform. Buy-and-build theses die on integration capability more often than on sourcing. See Post-Close Technology Integration.
• Does it create a liability with a regulator, a customer, or an insurer? Regulated data in an environment without access controls. A copyleft licence obligation in the core product. No software bill of materials in a business selling to federal or critical infrastructure customers, where customers increasingly contract for one. An open compliance matter the target has not disclosed. See What Is an SBOM and What Is Third-Party Risk Management.
• Does it structurally raise the cost of serving a customer? Gross margin that compresses as volume grows is a different problem from a fixed cost. It gets worse exactly when the thesis is working.

Items that fail all four are observations. Write them in an appendix, assign them zero, and say so plainly. A diligence report that assigns zero to some findings is far more persuasive on the ones it prices.

Recovery capability deserves its own note here, because it fails the maturity-model test and passes the thesis test. A target with no tested recovery procedure is not carrying a technical debt item, it is carrying an uncosted downside scenario. Establish the actual recovery point and recovery time objectives, not the documented ones, and price the gap. See RPO vs RTO.

Cloud Cost Trajectory Is Its Own Line

Cloud spend falls between two diligence workstreams and is regularly missed by both. Quality of earnings treats it as a known cost sitting in the P&L. Technology diligence treats it as a finance question. Nobody models the trajectory, and the trajectory is where the money is.

Collect four things, and none of them are the current monthly bill.

• Twenty-four to thirty-six months of monthly spend broken out by service. Compute, storage, data transfer, and managed services behave differently and you need to see which is growing.
• Every commitment instrument and its expiry date. Reserved instances, savings plans, committed use discounts, and any enterprise discount agreement negotiated with the provider. Get the contract, not a summary.
• Spend per unit of revenue and per customer, plotted over time. A flat ratio is a cost. A rising ratio is a margin trajectory.
• The architectural reason for the shape of the curve. Single-tenant instances per customer, absence of autoscaling, everything running on-demand, cross-region data transfer, no lifecycle policy on object storage. Each has a specific fix and a specific cost.

Three findings break models, and all three are invisible in a current-month bill.

The first is a discount agreement expiring inside the hold period. An enterprise discount that ends in month fourteen post-close produces a step change to list pricing that nobody modeled, and it is permanent. It is also completely knowable at diligence, because it is a contract with a date on it.

The second is spend growing faster than revenue. Cloud at 34 percent growth against 19 percent revenue growth compresses gross margin every year of the hold. Model it forward five years and look at what you are selling at exit. A business with a deteriorating margin profile sells at a lower multiple than the one you bought, which converts an operating problem into an exit problem.

The third is that the fix and the saving cannot both be claimed. If a rearchitecture is priced as one-time capital and the model also assumes cloud spend flattens, those are the same event counted twice. Model cloud as a percentage of revenue across the hold under two scenarios, existing architecture and funded rearchitecture, and show both to the committee. Where they diverge, the capital is buying the operating outcome, and the two cannot be taken separately.

Putting the Number in Front of an Investment Committee

One page. Committees do not read technology reports and have never made a decision from a heat map.

Lead with three numbers: the one-time capital requirement, the permanent annual EBITDA impact, and the enterprise value effect at the deal multiple. Then a five-line bridge: headline enterprise value, less one-time capital, less permanent EBITDA impact times the multiple, equals the adjusted view, with the delta stated in both dollars and turns.

Then the classification defense, one sentence per permanent item. Not the analysis, the evidence. "Four engineers have been allocated to platform stability for three consecutive years with no reduction in the backlog." That sentence is what survives contact with the seller.

Then the ask, item by item: which findings go to price, which to escrow, which become closing conditions, which are accepted and funded in the operating plan. A finding without a proposed instrument is a complaint. For how each instrument works and when to use it, see Turning Diligence Findings Into Deal Terms.

Then the sensitivity, which is the part most technology reports omit and the part a deal partner needs most. Show what happens if the seller wins the classification argument on every disputed item. In the illustrative example above, that is the difference between 32.7 million and 45.1 million dollars. A committee that knows the width of the negotiation makes better decisions about how hard to push and when to walk than one handed a point estimate.

Leave out CVSS scores, maturity ratings, finding counts, and anything with a red, amber, and green legend. If a finding matters, it has a dollar value and an instrument. If it has neither, it is an appendix. For what the full deliverable should contain, see The Technology Due Diligence Report.

The Reconciliation That Has to Happen Before Anything Goes to the Seller

Three documents must agree before the number leaves the building: the technology diligence findings, the quality of earnings adjustments, and the operating plan. Any item appearing in two of them is a double count. Any add-back in the QoE that depends on work priced in the technology report is a synergy the buyer has to fund and should not be paying the seller for. Any spend in the operating plan that also appears as a price deduction has to come out of one of them.

This reconciliation takes an afternoon and it is the difference between a credible retrade and a rejected one.

Related Reading

• Technology Due Diligence: The Complete Guide for Private Equity
• Technology Due Diligence Checklist
• Technology Due Diligence Red Flags
• Carve-Out Technology Separation
• What Is Cyber Due Diligence
• When Diligence Finds an Active Compromise

Frequently Asked Questions

Why does classifying technical debt as capex or opex matter so much?

Because one is worth its face value and the other is worth its face value times the multiple. A one-time remediation program is a below-the-line adjustment arguing for a dollar-for-dollar price reduction. A permanent operating cost reduces run-rate EBITDA, and enterprise value moves by that amount times the deal multiple. At 11.0 times, 500,000 dollars of permanent annual cost is a 5.5 million dollar valuation issue. The same 500,000 dollars as a one-time program is a 500,000 dollar issue. Sellers understand this arithmetic and will trade a larger one-time number for a smaller permanent one.

How do you estimate the cost of remediating technical debt?

Decompose the work into named workstreams with defined end states. Estimate each in engineer-months. Apply fully loaded cost rather than salary, which typically runs 1.25 to 1.4 times base in the United States mid-market. Apply a disclosed contingency multiplier, higher for estimates sourced from target management because they are systematically optimistic. Add non-labor cost, separating one-time deployment from perpetual subscription. Then add the opportunity cost of deferred roadmap, measured against features in the revenue model rather than in the abstract. Show all components separately, because sellers concede itemized numbers and attack aggregated ones.

What evidence defeats the seller's claim that a cost is one-time?

Recurrence history and structural necessity. Pull three years of engineering headcount allocation and ticket data. If four engineers have been assigned to platform stability for three consecutive years and the backlog has not shrunk, that is a function, not a project. For infrastructure, show that spend per unit of revenue is structurally elevated because of the architecture, and that it stays elevated unless the architecture changes. For compliance, split the one-time audit from the permanent control operation. Every capital classification should have a named owner willing to state that the spend stops.

Is it legitimate to deduct technology remediation from the purchase price if the buyer would have invested anyway?

It depends on whether the investment sustains the existing earnings stream or grows beyond it, and on whether the operating plan already funds it. Spend required to keep the business operating as currently modeled is a cost of those earnings and belongs in the price. Spend that expands the business past the model is a cost of the thesis and belongs in the plan. What is never defensible is claiming the same dollar in both places. Reconcile the technology findings against the quality of earnings adjustments and the operating plan before anything goes to the seller.

How should cloud cost be treated in a deal model?

As its own line with a trajectory, not as a current monthly bill. Collect twenty-four to thirty-six months of spend by service, every commitment instrument with its expiry date, spend per unit of revenue plotted over time, and the architectural reason for the shape of the curve. Three findings break models: an enterprise discount agreement expiring inside the hold period, which produces a permanent step change to list pricing; spend growing faster than revenue, which compresses gross margin every year and damages the exit multiple; and a rearchitecture whose capital cost and operating saving are both claimed, which is the same event counted twice.

Which technical debt items should be ignored?

Anything that fails all three tests: it does not block a revenue or margin line in the model, it does not create a liability with a regulator or customer or insurer, and it does not structurally raise the cost of running the business. A stable service written in an unfashionable language with no roadmap dependency is a hiring inconvenience, not a deal item. Architectural preference is not a liability unless the current design prevents something the plan requires. A report that explicitly assigns zero to some findings is considerably more persuasive on the ones it prices.

How should technical debt be presented to an investment committee?

On one page, leading with three numbers: one-time capital required, permanent annual EBITDA impact, and enterprise value effect at the deal multiple. Follow with a five-line bridge from headline enterprise value to adjusted view, stated in both dollars and turns. Then one sentence of evidence per permanent item. Then the proposed instrument for each finding: price, escrow, closing condition, or accepted and funded in the plan. Then a sensitivity showing what happens if the seller wins every classification argument. Leave out maturity ratings, finding counts, and heat maps.

Does technical debt ever justify walking away rather than repricing?

Repricing handles most of it. Walking is warranted when the debt makes the thesis unachievable rather than expensive. A buy-and-build platform that cannot onboard an acquired company's customers without a bespoke multi-quarter migration breaks a tuck-in strategy regardless of price. Code the company cannot demonstrate it owns, or a copyleft obligation attached to the core product, changes what is being bought rather than what it costs. So does a regulated-data compliance failure with an open regulator matter. The test is whether money and time fix it inside the hold period.

TSB and Sabadell: When the Migration Was the Debt

Banco Sabadell acquired TSB in 2015 for approximately 1.7 billion pounds. TSB had been carved out of Lloyds Banking Group and, critically, it was still running on Lloyds systems under a transitional arrangement. TSB paid Lloyds for the platform.

That arrangement is the clearest example in public record of technology debt sitting inside a deal model as a permanent operating cost with a capital program attached to removing it. The platform fee to Lloyds was recurring opex. Migrating onto Sabadell's own core banking system, a programme called Proteo4UK, was the one-time capital required to stop paying it. Both numbers were knowable at signing, because both were written into contracts with dates on them.

The migration went live in April 2018. It failed. Roughly 1.9 million customers were locked out of their accounts, some customers were shown other customers' account information, and the disruption ran across a five-day outage affecting the entire branch network.

The financial consequences were not the ones in the business case. TSB reported post-migration costs of approximately 330 million pounds in its 2018 full-year results, including roughly 32.7 million pounds of customer redress, and posted a statutory pre-tax loss for the year. Chief Executive Paul Pester resigned in September 2018. In December 2022 the Financial Conduct Authority and the Prudential Regulation Authority jointly fined TSB 48.65 million pounds for operational resilience failings, finding that TSB had failed to organise and control the IT migration programme adequately and had mismanaged operational risk with its critical third-party supplier.

Three lessons carry across to a mid-market sponsor deal, and none of them require a bank.

First, the classification was correct and the execution risk was not priced. Someone at Sabadell correctly identified the Lloyds platform fee as permanent opex and correctly identified the migration as the capital program that removes it. What the model did not carry was a probability-weighted cost of the migration failing. A one-time capital number is only a one-time capital number if the program lands. The contingency multiplier discussed above exists for exactly this reason, and 1.4 times would not have covered it.

Second, the debt was inherited, not created. TSB's dependency on a seller's platform was a condition of the carve-out. Any buyer acquiring a business that runs on a parent's infrastructure under a transitional services agreement is buying the same structure: a recurring cost with a contractual end date and a capital program standing between the company and independence. Price all three, the fee, the program, and the failure case. See Carve-Out Technology Separation.

Third, a failed migration does not stay one-time. Redress, regulatory penalty, remediation, customer attrition, and a leadership change are not capital items that stop when the program ends. They change the cost base and the earnings profile of the business, which is the definition of the expensive bucket.