Finance Systems Assessment After an Acquisition: Roadmap

A case: can the acquired company’s systems carry the numbers the new owners need?

A finance systems assessment after acquisition answers a question due diligence usually leaves open: can the systems the company runs on today support the business the new owners are planning? This case follows a common post-acquisition sequence for a private-equity-backed portfolio company, focused on the systems finance depends on: the accounting system, consolidation, payroll, banking and reporting tools. It sets out how the current state was documented, how risks and gaps were ranked, how technology investments were prioritised, and how the findings were presented to the investors. The case is representative, not a named company. NEO Expertise supports finance teams through the finance side of assessments like this one.

The Situation

The acquired company has grown through three sites in two countries. Its systems grew with it, one decision at a time: an accounting package bought a decade ago, a separate payroll provider in each country, monthly reporting assembled in spreadsheets, and bank payments authorised through a small number of personal tokens.

The investment plan assumes monthly reporting to the investors within ten working days, two further acquisitions, and a doubling of transaction volumes over four years. The owners ask for an assessment of whether the current systems can support that plan, where the risks are, and what investment is needed.

Step 1: Document the Current State

The assessment started with an inventory of every system that touches the financial numbers, and how data moves between them. For each system, finance recorded:

• What it does, who uses it, and which process step depends on it
• The version, support status and hosting arrangement
• Interfaces: automatic, file-based or manually rekeyed
• Who holds administrator access, and who can approve payments
• Which reports are produced in the system and which are rebuilt in spreadsheets

The most useful single artefact was a data-flow map of the month-end close, showing every point where numbers leave one system and are rekeyed or uploaded into another. Each of those points is a place where the close slows down and errors enter.

Step 2: Understand What the Business Needs

Stakeholder interviews covered finance, operations, sales, HR and the site managers. The aim was to understand the reporting each function needs today, and what the growth plan will require of it. Interviews were checked against evidence: a claim that “the system produces margin by customer” was verified by running the report.

The key finance requirements that came out of this step were group consolidation across legal entities, a faster close, budget and forecast in one tool, and payment controls that do not depend on one person’s token. Each was mapped to the business priority it supports, so the technology discussion stayed tied to the investment plan rather than to preferences.

Step 3: Risks and Gaps

Risks were scored on business impact and urgency. Illustrative scoring from this case:

Finding	Impact (1 to 5)	Urgency (1 to 5)	Score
Accounting system on an unsupported version	5	4	20
Bank payments approved by one token holder	5	5	25
Consolidation built in spreadsheets	4	4	16
Payroll data rekeyed into the ledger	3	3	9
No single customer master across sites	3	2	6

The payment control finding scored highest because it combined fraud exposure with a single point of failure: if the token holder left, the company could not pay its suppliers. It was fixed within a fortnight, before any wider investment decision.

The gap analysis then compared current capabilities with the requirements from step 2. The sharpest gap was scalability: the accounting system could not hold more than one legal entity, so each planned acquisition would add another standalone ledger and another manual consolidation.

A smaller gap showed how these findings are usually hidden. Payroll for the two countries arrived as provider reports in different formats, and an accountant rekeyed the totals into the ledger each month. The ledger balanced, so nothing looked wrong. But the payroll cost by site in management reporting did not agree to the provider reports in 4 of the previous 12 months, because corrections made by the provider after the first report never reached the ledger. The fix was an agreed journal file from each provider, uploaded rather than rekeyed, and a monthly reconciliation of payroll cost to provider totals.

Step 4: Prioritised Investments and the Roadmap

Investments were separated into critical items that protect the business now and improvements that support the growth plan later. Critical items came first regardless of cost: payment controls, moving the accounting system to a supported version, and documented access rights.

The future-state design described how finance systems should work once the plan is delivered: one multi-entity ledger, a consolidation and planning tool, automated payroll journals, and a single customer and supplier master. The roadmap set out each initiative with its dependencies, milestones and timeline. One dependency drove the sequence: no system migration before the balances to be migrated are reconciled, which put a data cleanup workstream ahead of any go-live, of the kind described in our post-acquisition data check.

Replacing a system also means deciding what happens to the old one. Accounting records must remain available for the statutory retention period, which under section 388 of the UK Companies Act 2006 is six years for a public company and three years for a private one. Payroll and HR data moving between systems also has to meet the security requirements of the General Data Protection Regulation.

Step 5: The Decision Paper for the Owners

The findings were presented first to the portfolio company’s leadership and then to the private equity owners, as a short decision paper: the risks fixed already, the critical investments needing approval now, the growth investments for later phases, and the cost and timing of each. The paper asked for decisions, not comments.

Finance’s role in the paper was to put numbers on the options: implementation cost, running cost, internal time required, and the cost of not acting, expressed as extra days in the close or manual hours per month. That turned a technology discussion into an investment decision the owners could make.

The assessment fits into the wider post-deal sequence in the first 100 days finance integration roadmap, and its consolidation findings feed directly into preparing subsidiaries for group reporting.

Where Systems Assessments Go Wrong

• Assessing systems without the process. A system that looks adequate on paper can still sit behind a close that takes fifteen days because of rekeying between tools.
• Leading with the replacement. Starting from a preferred new system skips the risk and gap work, and the owners approve an investment without knowing what it fixes.
• Ignoring the quick fixes. Access rights and payment approvals rarely need a new system. Waiting for the roadmap leaves the highest risks open for months.

This approach assumes the company will stay broadly in its current shape. If the owners plan to merge it into an existing platform within a year, a full future-state design is wasted effort. Fix the critical risks, and plan the migration onto the platform’s systems instead.

The Finance Systems Assessment Checklist

Use this as a working checklist. Each item is a check to complete, not a topic to consider.

Current state

• ☐ Inventory every system that touches the financial numbers
• ☐ Record version, support status and hosting for each
• ☐ Map the data flow through the month-end close, including every rekeying point
• ☐ List administrator access and who can approve payments

Requirements

• ☐ Interview finance, operations, sales, HR and site managers
• ☐ Verify every reporting claim by running the report
• ☐ Map each requirement to the business priority it supports

Risks and gaps

• ☐ Score findings by business impact and urgency
• ☐ Fix payment approval and access risks immediately, without waiting for the roadmap
• ☐ Identify scalability gaps such as single-entity ledgers and spreadsheet consolidation

Roadmap and decisions

• ☐ Separate critical fixes from growth investments
• ☐ Reconcile balances before any migration
• ☐ Plan legacy data retention for the statutory period
• ☐ Confirm data protection requirements for payroll and HR data
• ☐ Present cost, running cost, internal time and the cost of not acting

Frequently Asked Questions

What does a finance systems assessment after an acquisition cover?

It inventories every system that touches the financial numbers, maps how data moves through the close, interviews stakeholders about reporting needs, scores risks by impact and urgency, compares capabilities with the growth plan, and produces a prioritised roadmap and a decision paper for the owners.

Which finance system risks should be fixed first?

Payment controls, access rights and unsupported system versions usually come first, because they combine fraud exposure or business interruption with a quick fix. They rarely require new software. Consolidation, planning tools and system replacement follow once the critical risks are closed.

Should balances be cleaned up before migrating to a new accounting system?

Yes. Migrating unreconciled balances carries every existing error into the new system and removes the audit trail that explains them. Reconcile and document the balances to be migrated first, then migrate, then reconcile the opening balances in the new system to the old one.