15. IT cost structure and budget due diligence

The deal model had IT savings in year one. Management showed a flat IT budget, low spend as a percentage of revenue, and a plan to “optimize vendors and cloud” after close.

The first cost pull looked clean. Then the buyer asked for a budget-to-cash bridge, contractor roles by system, and the cloud invoice split between production, projects, and credits.

The story changed. A managed service provider was running ERP interfaces through a business-unit budget. Cloud credits were masking the steady-state cost of customer analytics. Cyber remediation had been deferred for two years. The carve-out plan assumed the parent would keep providing identity, security operations, and end-user support for six months, but the TSA pricing covered only basic help desk.

None of those items was a dramatic technical failure. Together, they moved EBITDA, cash, and timing.

That is the real cost diligence question:

Does the reported IT budget represent true run-rate and support the EBITDA bridge, or does it hide stranded cost, contractor dependency, cloud spend, TSA replacement cost, or mandatory investment?

If you cannot answer that before signing, the buyer is not underwriting a cost base. The buyer is underwriting a budget format.

Why IT cost diligence changes the value case

IT cost issues matter when they change one of four deal economics:

• Run-rate EBITDA: recurring spend is higher than the reported budget once contractors, shared services, cloud usage, and required controls are normalized
• One-time cash: deferred upgrades, cyber remediation, TSA exit, data cleanup, and system stabilization become mandatory, not optional
• Synergy timing: savings depend on contract exits, platform consolidation, or operating model changes that cannot happen in the first year
• Stranded cost: a carve-out removes revenue but leaves licenses, people, infrastructure, or parent allocations behind

The trap is that IT budgets are often organized for internal management, not for deal underwriting. They mix capex and opex, project and run, allocated and direct, discretionary and mandatory. A clean budget can still be a poor view of cost.

The common mistake: treating reported budget as normalized run-rate

Deal teams often ask finance for the IT budget and ask the CIO whether it is enough. Both are useful. Neither is sufficient.

Reported IT cost can be low for five bad reasons:

1. spend is sitting outside IT, often in operations, finance, commercial, or product teams
2. contractors are doing run work but are booked as project or transformation cost
3. cloud credits, under-tagging, or shared accounts make current usage look cheaper than post-close usage
4. parent-provided services are allocated below market or not allocated at all
5. mandatory remediation has been delayed because the business has not had a control event yet

The diligence job is not to prove the budget is wrong. It is to build the bridge from reported cost to the cost the buyer will own.

A practical method: build the IT cost bridge

The fastest way to get signal is to separate IT cost into five buckets. Each bucket has a different underwriting treatment.

1) Reported IT run-rate

Start with the last 12 months of actuals, not the annual budget. Then reconcile to the forecast.

Ask for:

• IT budget vs actuals by month and cost center
• headcount and contractor cost by role and location
• top 20 IT vendors by spend, term, and renewal date
• capex vs opex classification policy for software, implementation, and infrastructure
• any costs booked outside IT that support technology operations

What usually breaks:

• finance reports vendor spend, but cannot tie vendors to systems or services
• software implementation cost is capitalized, while the run cost after go-live is missing from the forecast
• business teams own Salesforce admins, data engineers, plant systems support, or reporting scripts outside the IT budget

If the budget cannot be reconciled to cash and operating ownership, it is not a diligence baseline.

2) Hidden run cost

Hidden run cost is recurring work that keeps the business operating but is not visible as IT run-rate.

Look for:

• contractors maintaining ERP, integrations, reporting, security tooling, or cloud operations
• managed service fees embedded in application contracts
• business-owned SaaS tools that perform core workflow steps
• outsourced infrastructure, end-user support, and service desk costs booked under operations
• internal product or data teams supporting commercial systems

The test is simple: if the work must continue after close to keep the business running, it belongs in run-rate even if the accounting label says project, transformation, or business support.

3) Cloud and consumption spend

Cloud costs can make EBITDA look better or worse depending on timing, credits, tagging quality, and architecture.

Ask for:

• 12 months of billing exports, not summary invoices
• spend by account, subscription, environment, and service
• credits, committed discounts, and minimum commitments
• top workload owners and chargeback logic
• forecast assumptions tied to customer growth, data volumes, and retention policies

What usually breaks:

• production and non-production spend are mixed
• one-time migration or experimentation cost is treated as recurring, or recurring data and analytics cost is treated as temporary
• expiring credits make the current year look artificially low
• egress, observability, backup, and security costs sit outside the cloud line

If management cannot explain roughly 80-90% of cloud spend by workload and environment, do not accept a cloud savings line in the first-year EBITDA bridge without a funded cost-control sprint.

4) TSA and carve-out replacement cost

In carve-outs, the budget often reflects the seller’s operating model, not the standalone company’s cost.

Ask for:

• list of IT services provided by the parent: identity, email, network, endpoint, security operations, ERP support, data platforms, service desk
• TSA pricing by service and exit date
• stranded licenses or infrastructure that cannot be transferred cleanly
• one-time stand-up cost for tools, people, environments, and vendors
• target-state operating model for the first 12 months after close

What usually breaks:

• TSA fees cover service access but not the replacement build
• parent allocations are below the cost of buying the same service as a smaller company
• TSA exit requires security, identity, network, and application work that is not in the one-time plan
• seller retains volume discounts that the buyer cannot replicate

The right comparison is not current allocated cost vs TSA fee. It is current cost, plus TSA cost, plus replacement run-rate, plus exit one-time cash.

5) Mandatory investment

Some technology spend is framed as optional improvement when it is really a cost of owning the asset responsibly.

Common examples:

• ERP or database versions approaching end of support inside 12-24 months
• security controls required before the buyer can connect environments
• backup and disaster recovery work for systems that drive revenue or close reporting
• data quality remediation needed for the value plan or regulatory reporting
• license true-ups triggered by change of control, new users, or separation

The diligence question is whether the spend is avoidable. If avoiding it creates continuity, compliance, or deal-execution risk, it is mandatory cash and should sit in the base case.

Evidence asks that beat budget narratives

Strong cost diligence does not require a long discovery program. It requires the right evidence.

1) Budget-to-cash bridge

Ask finance and IT to reconcile:

• annual IT budget
• last 12 months of actual cash spend
• forecast for the next 12 months
• capex/opex split
• costs outside IT that support technology

Why it matters:

This exposes timing shifts, capitalization choices, and spend that will become buyer-owned run-rate.

2) Vendor and contract spend cube

Ask for the top 20-30 vendors with:

• annual spend
• contract owner
• system or service supported
• term, renewal date, minimums, and termination rights
• change-of-control clauses and transfer restrictions

Why it matters:

Vendor savings often depend on renewal windows and termination rights. A good rate card is not a synergy if the contract cannot be exited for 18 months.

3) Contractor dependency map

Ask for:

• contractors by role, vendor, day rate, and cost center
• systems supported
• whether the work is run, change, or project
• contract end dates and replacement plan

Why it matters:

Contractors often explain why the IT budget looks flexible. If they are running core systems, removing them is not cost reduction. It is operational risk.

4) Cloud and SaaS usage exports

Ask for:

• billing exports by account and service
• SaaS user counts, active users, and license tiers
• consumption trends for data, storage, compute, and observability
• upcoming renewals and true-up mechanisms

Why it matters:

Invoices show what was paid. Usage shows what will happen when users, data, controls, and integration activity change after close.

5) Deferred investment register

Ask management to list unfunded or delayed items across:

• cyber controls
• ERP and application upgrades
• infrastructure refresh
• data platform remediation
• end-user device replacement
• audit and compliance findings

Why it matters:

The strongest signal is not the list itself. It is whether each item has a consequence, date, and owner. A deferred item with no owner is usually an unpriced future surprise.

Decision triggers that should change price, terms, or timing

Cost findings are only useful if they force an explicit underwriting choice. These triggers create that discipline.

Trigger 1: IT cash spend cannot be reconciled to the reported budget

If the target cannot explain roughly 90% of IT cash spend across vendors, people, contractors, cloud, and business-owned technology, treat the EBITDA bridge as unproven.

What it changes:

• add a downside case for run-rate step-up
• require a cost true-up mechanism where possible
• delay early cost-reduction assumptions until the baseline is clean

Trigger 2: More than 25-30% of critical IT run work is contractor-led

If contractors maintain ERP, integrations, identity, security tooling, cloud operations, or revenue reporting, the cost base is less flexible than it looks.

What it changes:

• move contractor reduction out of year one unless backup ownership exists
• price retention, knowledge transfer, or managed service replacement
• treat conversion or backfill as run-rate, not one-time cleanup

Trigger 3: Cloud savings depend on visibility the target does not have

If cloud accounts are poorly tagged, production and non-production are mixed, or cost owners are unclear, any savings case should be haircut.

What it changes:

• fund tagging, account restructuring, and owner assignment before savings are counted
• separate waste removal from architecture change
• avoid committing first-year EBITDA to optimization that competes with Day-1 work

Trigger 4: TSA replacement cost exceeds the current allocation by more than 20%

If standalone services for identity, end-user support, security operations, network, and core applications cost materially more than the seller allocation, the carve-out model is understated.

What it changes:

• reset standalone run-rate before signing
• negotiate TSA scope and pricing with service-level detail
• fund the exit plan as mandatory one-time cash, not integration upside

Trigger 5: Mandatory remediation lands inside the hold period but outside the model

If ERP support, cyber controls, backup, audit findings, or license true-ups require action inside 12-24 months, they belong in the base case.

What it changes:

• separate mandatory cash from discretionary transformation
• move synergy timing behind remediation where capacity is constrained
• use deal protections if the cost cannot be sized before signing

What best teams do before signing

Best teams do not accept a budget summary and write “cost opportunity.” They force a cost posture the investment committee can underwrite.

1) Build a normalized IT run-rate bridge

The bridge should show:

• reported IT budget
• plus hidden run cost outside IT
• plus normalized cloud and SaaS consumption
• plus standalone or TSA replacement cost
• plus required run-rate step-ups from controls, support, or licensing
• less truly removable cost with a dated exit path

This bridge becomes the EBITDA baseline. Without it, the model is still using management reporting, not buyer economics.

2) Separate savings from mandatory spend

Cost reduction and mandatory investment should not share the same line. A vendor consolidation opportunity does not offset an ERP upgrade unless the timing, owner, and cash profile line up.

Use three labels:

• bankable savings: contractually actionable or execution-ready within the model period
• conditional upside: savings that require owner assignment, tooling visibility, or operating model change
• mandatory spend: required to protect continuity, controls, TSA exit, or legal/compliance obligations

This prevents the common mistake of netting uncertain upside against certain cash.

3) Tie each cost movement to a decision owner

Cost diligence fails when it produces a list of opportunities without decision rights.

Assign owners before signing:

• finance owns the EBITDA bridge and true-up logic
• CIO or CTO owns run-rate normalization and capacity assumptions
• integration or separation lead owns TSA exit and one-time cash
• procurement owns vendor timing and negotiation path
• security and infrastructure leads own mandatory control spend

If no owner can act on a cost line in the first 30 days after close, it should not be counted as early value.

Where teams get trapped after close

Three patterns create most IT cost leakage.

First, they cut visible spend and keep hidden risk. Contractors, monitoring tools, backup, and security support look easy to remove until the business needs a month-end close, a customer audit, or a failed integration recovered quickly.

Second, they count vendor overlap before checking exit rights. Two tools may look duplicative, but the contract may have minimum terms, data extraction fees, or implementation dependencies that move savings by several quarters.

Third, they let TSA economics drift. The TSA fee looks manageable at close. Then exit work slips, service extensions get repriced, and standalone replacement cost arrives at the same time as integration spend.

The fix is not more tracking. It is sharper classification before signing: what is run-rate, what is one-time, what is optional, and what is mandatory.

Monday-morning actions for the next 10 days

If the deal is live, make the IT cost case decision-ready before the investment committee discussion.

1. Build the normalized run-rate bridge (finance lead + tech DD lead). Reconcile budget, actuals, cash spend, cloud, contractors, and business-owned technology.
2. Create the contractor and vendor dependency map (CIO/CTO + procurement). Identify which savings are real, which require renewal timing, and which would break operations if removed.
3. Pull raw cloud and SaaS usage data (cloud lead + application owners). Separate recurring production usage from credits, projects, experiments, and non-production waste.
4. Size TSA and standalone replacement cost (separation lead + finance + seller IT). Include identity, endpoint, network, security operations, ERP support, service desk, and data platforms.
5. Classify every cost movement (deal lead + IC sponsor). Mark each line as bankable savings, conditional upside, or mandatory spend, then decide what stays in the EBITDA bridge.

The output should be one page: normalized IT run-rate, mandatory cash, bankable savings, conditional upside, and the timing gates that make each number real. If that page cannot be built, the reported IT budget should not be treated as the cost base for the deal.