What is post-acquisition software, and what is it not?

Post-acquisition software is the set of shared systems, integrations and governed AI that let a combined business report, decide and deliver in one way instead of two. The deal can close while the companies still do all three differently, and that gap is where the value of the deal leaks away.

If you searched for M&A software companies, split the market in two:

Before close After close
The job Source, assess, document and close a transaction Make two operations share reliable information
Typical tools Deal pipeline, virtual data room, valuation platform, diligence checklist Group reporting, cross-company workflows, operating knowledge
What to do Buy a proven specialist product Look at a custom build, where the value sits in your specific systems and exceptions

Deal software is a mature category, and most buyers should choose a proven product rather than commission a bespoke imitation. Operating integration is different. It begins with the systems and people each business already has. When the value sits in connecting those specific workflows, data definitions and exceptions, generic deal software cannot do the job, because the deal is no longer the job.

What goes wrong in systems and reporting after an acquisition?

Two companies on paper become two operating systems in practice. Six problems come up again and again:

  • Group reporting is rebuilt by hand because the companies use different definitions and systems.
  • Customer, supplier or project data is copied between tools, with no dependable group view.
  • An acquired business still depends on one person who knows how the work really moves.
  • Two capable software estates now overlap, but nobody can defend what should stay, connect or retire.
  • The integration plan is tracked, but the recurring operational work underneath it is still manual.
  • AI is on the value-creation plan before permissions, source data and ownership have been made reliable.

In a business turning over £1m to £50m, the cost shows up in ordinary places. A month-end close takes twice as long because two ledgers disagree. New starters from the acquired company wait a week for logins. Two supplier lists pay the same vendor two different prices.

Data protection belongs on this list too. If a merger or acquisition changes who controls personal data, the ICO expects you to treat data sharing as part of due diligence: establish what data is moving, why it was collected, your lawful basis for sharing it and whether any of that has changed, and consider when to tell the individuals involved (1). The ICO also advises taking technical advice before sharing data between different systems, because of the risk of loss, corruption or degradation (1). That page notes the guidance is under review following the Data (Use and Access) Act, so check it is current before relying on it.

What can be built after an acquisition?

Four shapes cover most of the useful work. They are shapes, not a pre-written package: the actual system depends on the constraint inside the combined business.

Before and after

The same four jobs, before and after the build

After close the work is still done twice, by hand. A shared layer makes each job run once, on agreed figures.

Before

After close, as found

  • Group figures rebuilt by hand each month
  • Hand-offs lost between two sets of tools
  • Know-how held by one long-serving person
  • Actions chased in a separate tracker

What changes: One shared layer.

After

After the build

  1. Agreed figures pulled with their source
  2. Hand-offs connected around the work
  3. Policies and procedures searchable
  4. Owners and actions in the working view
An illustration of the four builds described in this guide, not a measurement or a client result. The real list depends on the constraint found inside the combined business.

Post-acquisition reporting that does not need rebuilding. A governed layer pulls the agreed figures from each business, records where they came from and makes exceptions visible instead of burying them in a spreadsheet.

Cross-company workflows. The hand-offs between sales, operations, finance and delivery are connected around the work, even while the underlying companies still use different systems.

A usable operating knowledge layer. Policies, procedures and commercial knowledge become searchable, with clear permissions, source references and a named person responsible for the final decision. Our guide to retrieval without the jargon explains how that works.

Integration control that reaches the frontline. Owners, actions, dependencies and evidence sit in one working view, connected to the systems where the work happens rather than kept as a second reporting exercise.

How does the work run?

Diagnose before the combined business inherits another platform. The sequence has four steps:

  1. Name the operating constraint. Start with the point where the combined business loses time, control or usable information, not with a preferred platform.
  2. Trace both versions of the work. Follow the same job through each company, including the workarounds, exceptions, data definitions and the people holding it together. Audit the process before you automate it sets out the method.
  3. Choose the smallest useful intervention. Decide what should be kept, connected, rebuilt or left alone. A smaller reliable layer often beats a premature system replacement.
  4. Deploy against ordinary work. Put the system into live use, measure the agreed change and improve it with the operators who inherit the merged process.

Replacing everything at once creates cost and operational risk before the combined business has learned what it needs. That is why we look first for the smallest dependable connection or shared layer, then replace a system only where the evidence supports it.

Where does AI fit after an acquisition?

AI fits after the data, permissions, process and decision owner are clear. It can help classify, extract, compare and draft across a combined estate, for example matching the same supplier across two ledgers or drafting a first view of a policy difference. It should not be used to conceal disagreement about definitions, or to automate a process nobody owns.

That order matters because an AI layer built on two sets of unreconciled data will produce confident, inconsistent answers. Why AI pilots do not reach production covers the same failure in more detail.

When should you bring in AGMM, and when should you use a specialist?

This is a narrow use case, deliberately. Bring in a team like ours when:

  • The commercial value depends on two operations sharing reliable information.
  • The standard software is capable, but the hand-offs between it are not.
  • An owner, integration lead or portfolio operator can make the cross-company decisions.
  • The first useful deployment can be scoped around one measurable operating constraint.

Use a specialist product or adviser when:

  • You need a data room, deal pipeline, valuation tool or buyer database.
  • You need legal, tax, financial, cyber or formal technology due diligence.
  • The brief is a group-wide core-system replacement with no accountable process owner.
  • The problem is still simply finding an acquisition to buy.

AGMM is an AI consultancy whose founders, Sam and Adam, build what they recommend. Group reporting sits with finance and leadership, and the hand-offs sit with operations and sales: all departments we work in. The route in is a free 30-minute fit call, then a fixed £2,000, 14-day AI Constraint Audit. The audit looks for constraints, weak points and opportunities to save or earn serious money across the business, and a more extensive audit always follows and is included in the proposal. Builds are priced by proposal; see what it costs.

Frequently asked questions

Does AGMM sell M&A deal-management software?

No. If you need a virtual data room, buyer pipeline, valuation platform or transaction checklist, buy a product built for that job. AGMM builds the operating systems needed when two businesses, data sets or workflows have to function together.

Is this technology due diligence?

Not as an independent regulated or investment-committee opinion. We can inspect systems, data, dependencies and operating risks as part of scoping a build, but legal, financial, cyber and formal transaction assurance should remain with the appropriately qualified advisers.

Do both companies have to replace their existing software?

Usually not. Replacing everything at once creates cost and operational risk before the combined business has learned what it needs. We look first for the smallest dependable connection or shared layer, then replace a system only where the evidence supports it.

Can this work across a portfolio rather than one acquisition?

Yes, where there is an accountable owner and a repeatable operating problem across the group. The useful pattern is proven in one company first, documented, then adapted to the next rather than copied blindly.

If this was useful, these go further on the same ground:

Sources

The numbered citation in this guide links to the source below. It was fetched and read on 12 October 2026.

  1. Due diligence when sharing data following mergers and acquisitions, Information Commissioner’s Office, Data sharing: a code of practice.

Written by Sam Wall and Adam Gillett. The patterns in this guide come from how post-acquisition work tends to run; they are illustrations, not client results.

  1. Answers question 01
  2. Answers question 02
  3. Answers question 03
  4. Answers question 04
  5. Answers question 05
  6. Answers question 06