Home/PE Portfolio Software/Standardising Fund Diligence
PE Portfolio Software

Standardising software diligence for a fund.

Make one method the default operating procedure across every acquisition the fund makes.

Standardising software diligence for a fund means writing down one method, one request list and one deliverable, then mandating that every deal team uses it. It is the institutional version of the buy side playbook. Where the playbook describes how to run diligence on a single deal, standardisation makes that method the default operating procedure across every acquisition the fund makes.

The case for a fund level standard is simple. Software risk is systematic, not idiosyncratic. The same publishers, the same metrics and the same clauses create exposure across every target. A fund that addresses this once, centrally, captures the benefit on every future deal. A fund that leaves it to individual deal teams pays to relearn it each time.

What standardising software diligence for a fund involves

A fund standard has four written components. The first is a scope definition that states which publishers are always in scope, what triggers deeper review, and where the line sits between diligence and full estate analysis. The second is the request list, the fixed set of artefacts every target must provide. The third is the analysis method, including how the effective license position is calculated, how true up exposure is modelled, and how change of control clauses are registered. The fourth is the deliverable template, so every deal partner reads the same report in the same shape.

Around those four sits governance: who commissions the work, at what point in the deal, who reviews it, and how findings feed the investment committee. Standardisation fails when it is a document no one is required to use. It works when commissioning software diligence is a gate the deal cannot pass without.

The four components of a fund diligence standardA standard built from scope, request list, analysis method and deliverable, held together by governance.Four written components plus governance1ScopedefinitionAlways in scope2Fixed requestlistDay one artefacts3Analysis methodELP and true up4DeliverabletemplateOne report shape5Governance gateIC submission
A standard built from scope, request list, analysis method and deliverable, held together by governance.

Embedding the standard so it actually runs

The most reliable way to embed a standard is to tie it to the investment process the fund already enforces. If the investment committee will not approve a deal without a quality of earnings report, attaching a software exposure summary to the same submission makes the diligence non optional without adding a new process to police. Over time the standard improves itself, because each deal adds data and each audit outcome refines the request list and the model.

The payoff is comparability and speed. Every target is measured the same way, so the investment committee can weigh software risk across deals on a like for like basis, and every deal team starts from a built method rather than a blank page. The same standard then becomes the baseline for ownership, where vendor management and audit defence draw on the diligence dataset.

A fund diligence standard versus ad hoc deal by deal diligence
DimensionAd hoc per dealFund standard
ComparabilityNone, each deal differsLike for like across the fund
SpeedRebuilt each timeMethod already built
CoverageDepends on the teamSame publishers every time
DefensibilityVariableDocumented and consistent
After close useLostSeeds vendor management

Key takeaways

  • Software risk is systematic, so a fund captures the benefit of solving it once, centrally.
  • A fund standard has four written parts: scope, request list, analysis method and deliverable template.
  • Standardisation only works when commissioning diligence is a gate the deal cannot pass without.
  • Tying the standard to the existing investment committee process makes it non optional without new policing.
  • The standard becomes the baseline for vendor management and audit defence after close.

Recommendations for buyers

  1. Write the four components down: scope, request list, analysis method, deliverable template.
  2. Attach a software exposure summary to the investment committee submission so it cannot be skipped.
  3. Define who commissions the work and at what point in the deal calendar.
  4. Refine the request list and model after every audit outcome.
  5. Store the standardised dataset centrally so ownership teams can draw on it.

From method to operating procedure

Standardising software diligence is what turns a good method into an institutional advantage. For the full approach see the PE portfolio software advisory hub and the PE portfolio advisory service. Related reading includes repeatable software diligence across a portfolio, the PE buy side software diligence playbook, and software governance for PE portfolio companies. This is commercial and licensing advisory, not legal advice.

Who owns the standard and how it is governed

A standard without an owner decays. The most durable arrangement gives the standard a clear home, usually within the operating partner or value creation function rather than any single deal team, so it survives the people who built it. That owner maintains the request list, updates the scoring model as publishers change their licensing, and ensures every deal team is trained on the method. They also hold the institutional memory of what software risk has cost the fund, which is what gives the standard authority when a deal team is tempted to skip it under time pressure.

Governance works best when it rides on a process the fund already enforces rather than creating a new one. The investment committee submission is the natural gate. If the committee will not approve a deal without quality of earnings, attaching a software exposure summary to the same pack makes the diligence effectively mandatory without anyone having to police it separately. The standard becomes part of how the fund does deals, not an extra step that competes for attention.

Rolling the standard out across an existing portfolio

Standardisation usually starts with new deals, because that is where the method is cleanest to apply. The larger prize, though, is applying it backward across the companies the fund already owns. Most portfolios contain companies acquired before any software standard existed, carrying unmeasured exposure and unrealised savings. A retrospective sweep, running the same request list and scoring model across the existing portfolio, surfaces the audit risks that were never diligenced and the savings that were never captured. It is often where the standard pays for itself fastest, because the exposure has had years to accumulate.

The rollout should be prioritised by risk and renewal. Companies with large Oracle, SAP or VMware footprints, or with major renewals approaching, go first, because they carry the most exposure and the nearest opportunity to act on it. Smaller, simpler estates can follow. Within a year a fund can move from no standard to a measured, comparable view of software risk across its entire portfolio, with a remediation and savings plan attached to each company.

The end state is an institutional capability rather than a series of engagements. The fund knows its software risk the way it knows its leverage or its revenue concentration, as a managed number that informs every investment and exit decision. That is what separates standardisation from simply doing good diligence on each deal.

Common reasons a standard fails to stick

Standards fail for predictable reasons. They fail when no one owns them, so they drift out of date as publishers change licensing. They fail when they are voluntary, so busy deal teams skip them under time pressure. They fail when the deliverable is too long for the investment committee to read, so the findings never reach the decision. And they fail when they are commissioned too late in the deal, so even good findings cannot move terms.

Each failure has a fix: give the standard an owner in the operating function, tie it to a gate the deal cannot pass, keep the headline deliverable to a page or two, and commission it the day exclusivity begins. A standard that is owned, mandatory, concise and early is one that survives contact with a live deal.

Frequently asked questions

What does standardising software diligence for a fund mean?
It means writing down one method, one request list and one deliverable, then requiring every deal team to use them, so every acquisition is measured for software risk the same way.
What are the components of a fund diligence standard?
Four written parts plus governance: a scope definition, a fixed request list, an analysis method, a deliverable template, and a governance gate that ties commissioning the work to the investment process.
How do you make a standard actually get used?
Tie it to a gate the deal already cannot pass, such as the investment committee submission. Attaching a software exposure summary to that submission makes diligence non optional without a new process to police.
Does standardisation help after close?
Yes. The standardised dataset becomes the baseline for vendor management, renewal planning and audit defence across the portfolio.
How is a fund standard different from the buy side playbook?
The playbook describes how to run diligence on one deal. The standard makes that method the default operating procedure across every deal the fund makes.

Make software diligence a fund standard

Book a confidential software M&A risk assessment and we will help you embed a diligence standard in your investment process.

Book a confidential call