3. Buy-side vs sell-side tech due diligence: different objectives, different truths

The seller ran a tight process. They hired a reputable firm, produced a vendor tech diligence report, and told bidders they expected “confirmatory diligence only.”

The report said the target’s IT costs were $9.5M run-rate, the ERP was “stable,” and the customer data was “good enough for cross-sell.” The deal model assumed $22M of EBITDA uplift from pricing and sales coverage starting in quarter two. A buyer bid aggressively.

Three weeks later, the buyer tried to re-trade.

Not because the vendor report was wrong, but because it answered the seller’s question (“Are we broadly credible?”) and not the buyer’s question (“Can we execute this value timing with the constraints we’re inheriting?”). The buyer’s team found:

• $2.1M of annualized contractor spend sitting outside the IT budget (critical integration support)
• a “run-rate” cloud bill that was temporarily low because credits expired 60 days after close
• a single CRM instance that looked unified, but ran on three incompatible quoting flows by region

The seller felt blindsided. They had “done diligence.” The buyer insisted they had to underwrite execution risk and timing.

The primary decision is this: do you treat sell-side tech diligence as a substitute for buy-side diligence, or as a way to narrow and accelerate it? Confusing the two is how good processes turn into slow ones—and how clean stories turn into ugly surprises after signing.

Buy-side and sell-side diligence optimize for different outcomes

Both sides use the same words: “run-rate,” “technical debt,” “good systems.” They mean different things.

Buy-side diligence is underwriting and planning

Buy-side tech DD is meant to change decisions the buyer will own:

1. Price and structure: Are there risks that should show up as a haircut, a holdback, or specific protections?
2. Timing of value: When do technology gates open for the programs in the model?
3. Day-1 and Day-100 design: What must not break, what must be stood up, and what cannot be attempted early?

Buy-side diligence is not “tell me about your IT.” It is “tell me what will slow value capture or force cash spend, and how quickly we can make it safe.”

Sell-side diligence is de-risking the process and protecting value

Sell-side diligence has a different job:

1. Reduce surprises: surface issues early enough that bidders price them in, not weaponize them late.
2. Maintain competitive tension: give bidders enough confidence to stay in the process without demanding bespoke diligence for weeks.
3. Protect management bandwidth: create a repeatable answer set so the company can keep running while it sells.

The best sell-side work doesn’t “make the company look good.” It makes the process run faster and reduces the odds of a re-trade.

The “different truths” problem

Even with high-integrity advisors, the same fact set gets framed differently because incentives differ.

Truth #1: “Run-rate IT cost” is not a single number

Sellers often present what is easiest to defend: the IT budget, the current run-rate invoices, the chart of accounts view. Buyers need a normalized view that matches how they will run the asset.

Common deltas buyers find late:

• Contractors and project spend that behave like run-rate. If the target requires 10–15 contractors to keep integrations running, that is steady-state cost until something changes.
• Corporate allocations that won’t come with the business. Some costs vanish at close; others get replaced with new costs (security tools, service desks, identity platforms).
• Cloud spend distorted by one-offs. Credits, reserved instance timing, and one-time migrations can make a quarter look cheaper than the next year.

Decision trigger: If “run-rate” is presented as a single line item without a bridge (budget → actuals → normalized run-rate), assume it will get re-opened. The re-open will happen at the worst time: when bids are due or when purchase agreement terms are being set.

Truth #2: “Good enough” depends on the buyer’s thesis

Data quality and architecture are not absolute. They’re gating items against the buyer’s plan.

“Customer data is good” is meaningless unless you specify the use case:

• good enough to run the business as-is
• good enough to implement pricing discipline inside two quarters
• good enough to unify sales coverage across both companies

Each of those has a different bar.

Decision trigger: If the buyer’s thesis includes revenue synergy in the first two quarters, diligence must test customer, product, and pricing data as a gate—not as a maturity score. A clean stack with messy master data still fails the revenue plan.

Truth #3: “No major risks” is often code for “no one asked the Day-1 questions”

Sellers and vendor diligence teams usually don’t know the buyer’s Day-1 posture. Buyers often assume they can “connect the networks” and “share identity” quickly.

The Day-1 reality is driven by buyer constraints:

• security policy (tools required, controls required, audit evidence required)
• integration posture (connected vs separate early)
• regulated data handling (where data can live, who can access it)

A report can be accurate and still miss the only question that matters: can the buyer operate safely on Day 1 without extending TSAs or building a parallel environment?

Three ways diligence goes wrong (and the mechanism)

Pattern 1: Sell-side diligence that reads like marketing

The report is polished. Risk language is softened. Evidence is thin. The intent is to reduce friction, but the effect is the opposite: buyers don’t trust it, so they expand diligence.

You see it in the questions:

• “Can you provide the raw cloud billing exports?”
• “Can we speak to the security lead directly?”
• “Can you share the incident log for the last 12 months?”

Buyers ask because the report did not make falsifiable claims with evidence attached.

What good looks like: a sell-side “evidence pack,” not just a narrative. Include a simple index that points to the raw artifacts buyers will ask for anyway (contracts, cloud bills, incident history, close calendar, key system diagrams). You don’t need to show everything. You need to show enough that buyers stop guessing.

Pattern 2: Buy-side teams that run a template, not a thesis

Buyers often start with a standard diligence questionnaire. It produces volume, not insight. The seller spends two weeks answering 200 questions, and the buyer still can’t answer the IC’s three questions: price, timing, Day-1.

The fix is simple and uncomfortable: start by killing scope.

What good looks like: a “value gate first” sequence:

1. Identify the 3–5 value levers the deal model actually depends on.
2. For each lever, define the technology condition that must be true by a date (“gate”).
3. Spend the first diligence cycle proving or disproving those gates with evidence and owner interviews.

Everything else is optional until the gates are clear.

Pattern 3: The scope mismatch: sell-side diligence covers IT; buy-side needs execution

Sell-side diligence often answers “What do they have?” Buyers need “What do we have to do?”

That mismatch is most expensive in three situations:

• Carve-outs and shared services: separation complexity and TSA dependence dominate timing and one-time cash.
• Deals with early revenue synergy: data and workflow interoperability dominate timing.
• Deals with new security posture: the buyer’s controls dominate Day-1 design and cost.

Decision trigger: If the buyer expects to exit a TSA or connect environments inside 6–9 months, diligence must treat identity, network boundaries, and interface inventory as first-class topics. If those are “out of scope,” the plan is fiction.

A practical alignment: treat sell-side DD as a narrowing tool

When sell-side and buy-side diligence work together, the process is faster and outcomes improve. The trick is to be explicit about what sell-side diligence can and cannot do.

What sell-side tech diligence should deliver (if you want buyers to move fast)

Aim for five outputs that are decision-shaped:

1. A one-page “tech value gates” summary. The few system/data conditions that would change value timing (with dates and owners).
2. A run-rate IT cost bridge. Budget vs actual vs normalized run-rate, with the big drivers (contractors, cloud, licenses, shared services).
3. A Day-1 dependency map. What the business relies on daily (identity, network, core apps, data feeds) and where the dependencies sit.
4. A “known issues ledger.” The problems you already know, how they show up, and what it takes to fix them (cash, time, people).
5. An evidence index. A short list of raw artifacts buyers can self-serve to validate the story.

This is not more work than a traditional report. It is different work. It forces you to decide what matters.

What buyers should still do (even with great sell-side diligence)

Buyers cannot outsource underwriting. But they can narrow their work if the sell-side package is strong:

• Validate the gates, don’t re-inventory the world. Sample evidence that proves the gate is real (or not).
• Recalculate the economics in the buyer’s terms. Normalize run-rate costs against the buyer’s control requirements and operating model.
• Design Day-1 posture early. Decide what will be connected vs separate and pressure-test it against security and operational constraints.

Done well, this cuts diligence time without cutting confidence.

What to do in the next two weeks

If you’re preparing a sale process:

1. Write the “tech value gates” page (seller corp dev + CIO/CTO). If you can’t name the 5 gates that change timing or cash, buyers will find them late and re-trade.
2. Build the run-rate bridge from evidence (seller finance + IT finance). Make contractors, cloud variability, and shared services explicit.
3. Create an evidence index and pre-clear sharing (seller legal + IT). Decide what you will share, to whom, and when—before bidders force the issue under time pressure.

If you’re a buyer entering diligence:

1. Start with gates and dates (deal lead + integration lead). Write the 3–5 gates the model assumes and make diligence prove them.
2. Ask for three raw artifacts on day one (diligence lead). Cloud billing exports, incident history, and the close calendar will tell you more than 100 questionnaire answers.
3. Decide Day-1 posture explicitly (CIO/security lead). Connected vs separate, and what controls are non-negotiable. If you don’t choose, the schedule will choose for you.

Buy-side and sell-side diligence should not be adversarial. But they should never be confused. One is built to run a process. The other is built to live with the consequences.