Working note

Instrumenting the IT Layer

Where integration value leaks, and how to watch it

Most M&A value models treat IT integration as a cost line. Practitioners know it as the layer where deal value quietly leaks.

This note proposes a three class taxonomy of IT layer value leakage, and describes the mechanism that makes the leaks visible. The taxonomy is a hypothesis, not a finding. It is written so that a survey of practitioners can prove it wrong. If the data collapses the three classes into two, or ranks them differently, or demands a fourth, that is a result worth publishing and this note changes accordingly.

The layer the value model forgot

Deal models price synergies with real rigour. Almost none price the IT layer's capacity to deliver or destroy them.

This is not an oversight of attention. It is an oversight of sequence. Diligence budget is spent where the price is decided, and the price is decided before signing. The outcome, however, is decided after it. Every number in the synergy model becomes real or fails to become real during integration, and most of that runs through systems, data, contracts and access.

Price the deal wrong and you overpay once, visibly, and everybody knows within a quarter. Get the integration wrong and you underdeliver quietly, for years, and it gets attributed to the market. One failure has an author. The other has an excuse.

The pattern that recurs across the operator population is material applications still running on the seller estate long after close. It is tempting to read that as an integration failure. It is usually not. It is an ownership vacuum. Nobody was ever named against the obligation to end it, and an obligation with no name attached does not fail loudly. It simply persists.

Three leak classes

The classes are distinguished by when the value was lost, not by which system was involved. That is the distinction that makes them useful, because each class has a different detection point and therefore a different remedy.

The diligence leak, in detail

This is the hardest class to see, and the reason is structural rather than human. You cannot show a variance against a number that never existed. A diligence pack describes the estate. It does not measure it, and it does not forecast what the estate becomes once the deal closes. The three get treated as one artifact and they are not.

The gap opens in three predictable places. Undocumented dependencies, where systems are connected by arrangements nobody wrote down. Informal ownership, where the person who actually operates a critical system is not the person named against it in any document. The estate as it is rather than as it is documented, where a data room describes an architecture a site abandoned three years ago.

Two observations from practice, offered because they cut against the intuitive answer.

First, identity and access is largely a solved problem at scale, and it absorbs a disproportionate share of diligence attention because it is legible. A well run acquirer can issue standard accounts and knowledge worker access to an acquired population quickly. That is not where the estate breaks.

It breaks on legacy application ownership and cross platform dependencies, which carry the acquired team's actual daily work, are rarely enumerated in diligence, and surface weeks into delivery when somebody cannot do their job. The sharpest form of it is a single local owner holding several unrelated functions at once, never flagged as key person risk, who leaves with knowledge that was never written anywhere.

Second, the physical estate hides the same defect. Sites can be absent from the asset picture entirely and surface only after signing, and co shared premises are the common case, because staff of the acquired business sit inside a third party's building and no asset register carries a line for a place the target does not own. Recovery in those cases typically depends on a working relationship with someone on the seller side who is willing to hold a door open past the point at which they are obliged to.

The recovery is not the lesson. The lesson is that the recovery depended on goodwill, and goodwill is not a control.

The sequence leak, in detail

Every step in a mistimed programme looks reasonable at the moment it is taken. That is what makes this class so durable. Nobody makes an obviously wrong decision; the decisions are simply ordered in a way that lets the clock win.

Transitional service agreements are where the symptom becomes visible. A programme scoped to a planned term can run instead to its contractual ceiling. The interesting question is never whether a TSA extends, it is which of four causes did it, because they have different owners: buyer standalone build slower than planned, separation scope discovered late, a commercial choice where extending was cheaper than accelerating, or seller delivery capacity.

There is a fifth, and it was named by a reviewer as the one the other four miss. Seller delivery MOTIVATION, which is a different failure from capacity. Target staff shift allegiance from seller to buyer during the term, and the asset becomes, in her phrase, an unloved child. The people who must deliver the transitional service no longer identify with the party obliged to deliver it. This is why TSAs decay rather than merely run long, and no amount of capacity planning detects it, because the capacity is present and the will is not.

Two of the first four are diligence leaks presenting late. A taxonomy that cannot distinguish a sequencing failure from a baseline failure discovered late will misattribute both.

The ratchet is a different object again, and it belongs in the instrument rather than in the driver list. Many agreements carry escalating charges designed to force the buyer off the seller's systems. It is not a cause of extension. It is what extension costs, and it is a designed incentive rather than an accident. The failure mode is specific and common: integration leads discover the ratchet exists at the moment it fires. A team that cannot state its own ratchet schedule from memory has not read its own exit economics.

There is a second, quieter form that instruments rarely capture: the runway between signing and closing, left empty. It is the one period where the buyer has certainty about the deal and no operational responsibility for the asset, and it is routinely spent waiting rather than preparing.

The instrument leak, in detail

Stranded costs are the canonical case: contracts and licences that keep billing after the business they served has left. A material recurring annual cost can survive an entire separation and be removed only at exit, and a large share of it typically sits in lines owned directly by the person running the separation. That is the detail that matters, because it means the largest recoveries are not exotic discoveries. They are in plain sight, in the portfolio of the person best placed to see them, and they survive anyway.

The remedy is contractual, and it has a window. A licence whose served business is leaving can be split, novated or renegotiated during separation, while both parties still need something from each other and the counterparty is already at the table. After exit the same line becomes a cancellation conversation with a supplier who has no reason to help and a renewal clause that has already ticked over. The instrument is not only there to find the cost. It is there to find it while the leverage to remove it still exists.

The class has two limbs and only one of them was previously stated. That was a reviewer's finding and it is correct. The seller asks "what are we still paying for that no longer serves a business we own?" Stranded cost, in the classic sense. The buyer's question has the same shape and a different answer: "are we going to exit the transitional services on schedule, and what does each month of overrun cost us?" The money is not sitting in a forgotten licence; it is sitting in a clock, and it accrues to a counterparty who is currently supplying you. A buyer who tracks only stranded cost is watching the seller's version of the leak and missing his own.

Instrument leaks are rarely hidden. They are unassigned. The information exists, distributed across contracts, invoices and people, and no query is ever run against it because running the query is nobody's job.

The transmission mechanism: where the value actually goes

The taxonomy explains where value leaks. It has never explained what the leak is worth, to whom, or when they find out. That gap was named by a reviewer, and closing it changes what the instrument is for. The mechanism below is hers; the framing is joint.

The leak does not present as a loss. It presents as something else, later, to someone who was not in the room when it happened. It takes two forms, and they are structurally different.

The sponsor owned asset: the loss crystallises at exit

An unintegrated estate accumulates integration debt: systems not joined, so data that does not reconcile, so reporting that cannot be trusted at the speed a decision needs.

When the asset is next sold, the incoming buyer performs their own diligence and sees it. They are not looking at a technology problem. They are pricing the work they will have to do, and the risk that it is larger than it looks. So they discount, they chip the price during negotiation, or in the worst case they walk.

The loss is real, it is large, and it lands years after the decision that caused it, on a different owner, in a different document. This is the best explanation of why the fix goes unfunded: the person who would pay for it is never the person who bears the loss.

The corporate owned asset: the loss never crystallises at all

Where the acquirer is a corporate rather than a sponsor, there is no exit event, so there is no moment at which the debt is priced.

The cost is still paid, continuously and invisibly: decisions slowed because the data is poor, and capable people spending their time reconciling systems instead of on work that would have moved the business. It appears in no variance report, because there is no baseline it deviates from.

Note the shape, because it recurs across everything this note describes: the cost is real and the event is absent or delayed. An obligation with no owner does not fail loudly. A dependency with no record does not announce itself. And a loss with no crystallising event is never counted at all. The absence of an event is not the absence of a cost. It is the absence of a sensor.

What instrumented means

If the three classes share a cause, it is that the estate is not readable. The remedy is therefore not more documentation. Documentation is what already failed.

Systems, contracts, transitional services, sites, entities and owners as nodes. Dependencies, licences, data flows and exit obligations as typed edges.

Documents remain the record. The graph is the index.

This distinction is the whole design. Nobody is being asked to replace their contract repository or their configuration management database. They are being asked to make the relationships between those artifacts queryable, so that a question can be answered in an afternoon rather than reconstructed over three weeks by whoever happens to remember.

The four queries that decide value capture

1. Day 1 breakage. What stops working at close, and who is affected?
2. Ownership vacuum. Which obligations have no named owner?
3. Cross boundary single points of failure. What depends on a person, system or site that will sit on the other side of the transaction?
4. Stranded cost radar. What are we still paying for that no longer serves a business we own?

The discipline rule

Every exit obligation carries one named owner and one date, or it does not exist.

The rule is deliberately absolute, because the failure mode is always a partial version of it. An obligation with an owning team but no person is unowned. An obligation with a person but no date is unscheduled. The pair is what makes an obligation auditable rather than merely written down.

The counterweight: define what you do not touch

Integration doctrine has an inbuilt bias toward action, and the bias is expensive. Degrees of non integration are a deliberate instrument choice, not an omission.

Some differences between acquirer and target are load bearing: they carry a regulatory position, a customer relationship, or the operational reason the asset was worth buying. Standardising them destroys value while reporting progress, which is the most dangerous combination available to a programme, because the destruction is invisible on the same dashboard that shows the win.

A standard that only tells you what to integrate is half a standard.

There is an objection practitioners raise every time, and it deserves a direct answer. Execution is bespoke and should be. Every estate is different, and a standard that dictates the plan deserves to be ignored. Measurement is where the bespoke argument stops paying. If two deals cannot be scored the same way, nothing carries from one to the next, no benchmark can exist, and every programme starts from zero while calling it tailoring. This note standardises the measure and leaves the plan to the practitioner.

The agentic horizon

The case for instrumentation does not depend on artificial intelligence. It is, however, sharpened considerably by it.

AI agents can only act on estates they can read. An uninstrumented estate is unreadable. Not difficult, not slow. Unreadable, in the specific sense that the relationships an agent would need to reason over exist only in documents and in people's heads.

An agent deployed onto an unreadable estate does not produce a faster integration. It produces confident output with nothing underneath it, which is worse than a slow answer because it is harder to challenge.

There is a measurement version of the same problem, and it generalises past M&A: you cannot baseline a process step that exists only in one person's head. Where the baseline is fiction, the return calculation is fiction, and the initiative dies at first review without anyone learning why.

The second axis: which agent is reading it

Everything above concerns the estate's readability. There is a second question the readability argument does not reach, and in an M&A context it is the more urgent of the two.

A buyer inherits the target's agent estate along with everything else.

The tooling has made this immediate rather than theoretical. Open source agent bundles now ship as portable, multi runtime packs carrying tens of agents and hundreds of skills, installable in a single step. The cost of putting an agent into a business process has collapsed to approximately nothing, which means agents now appear in an estate the way departmental software subscriptions did a decade ago: quickly, locally, and without passing through anyone who would have written them down.

So the diligence question is no longer only can this estate be read. It is: which agents are running, and who built them? On whose runtime, under which credentials, at what permission scope? What data can they reach, and what can they change rather than merely read? Who is accountable when one acts wrongly, and does that person still work here after close?

None of that is in a standard data room, and on Day 1 the buyer owns all of it.

The parallel with the diligence leak is exact, and it is the same defect a decade later. Undocumented system dependencies were never hidden; they were unrecorded, because they were created by people solving a local problem without passing through an inventory. Agents are being created the same way, faster, and with the ability to act rather than only to integrate. An agent with credentials is a dependency that can take decisions, and the informal ownership problem now has an execution layer attached to it.

This is not an argument for prohibition. It is an argument that agent provenance and permission scope belong in the instrumented estate as first class objects, alongside systems, contracts and exit obligations, each carrying a named owner and a date like everything else.

Foundation first, then agents. And know which agents you already have before you add more.

Toward an open standard

This note is offered as the seed of an IT M&A instrumentation standard within the Global M&A Standard family: open, published, peer reviewed and practitioner led. Nothing is gated behind payment and nothing is sold.

A note argues. A standard specifies. Each requirement in the eventual standard carries five parts: the requirement, stated so it can be assessed rather than admired; the evidence an organisation produces to demonstrate compliance, because a requirement with no defined evidence is an aspiration; a corrective action log carrying a named owner, a target date and a next action; a continuous improvement plan, on the reasoning that a standard testing only a point in time measures compliance theatre rather than capability; and a risk assessment covering both pre and post merger phases.

The intent is to connect rather than to reinvent. Where an existing standard already specifies something well, this one cites it. Where it deviates, it will say so explicitly and give the reason. Deviation is expected in at least one respect: security standards are written for a steady state estate under single ownership, and an estate in transition has two owners, a clock, and a defined end state.