For Australian acquirers and mid market groups

Post Acquisition Systems Integration: What to Merge, What to Leave, and When

The deal completes and you inherit a second everything. A second accounting system, a second inventory system, possibly a second point of sale, a customer list that overlaps yours by an unknown amount, and a team who know how their systems work and are quietly worried about being told to stop using them.

The instinct is to consolidate quickly onto your platform. Sometimes that is right. Just as often it destroys the operating capability you paid for, at exactly the moment the business needs to keep trading. This page is about making that call deliberately, and sequencing the work so the group can report and operate long before the systems all match.

Book an Integration Planning Call (03) 9003 0111

Realistic ROI

Day one

When consolidated numbers are first asked for

Usually well before any system has been merged, so plan for reporting first

2 systems

The number you will run for a while

Coexistence is a design choice to be done well, not a failure to be rushed past

12 to 24 months

A realistic horizon for full consolidation

Rough guide for a mid market deal, longer where trading seasons constrain cutover

Every identifier

Will collide somewhere across the two systems

Customer codes, SKUs, order numbers and account codes all overlap by coincidence

Four Judgements That Decide How This Goes

Post acquisition integration fails on decisions, not on technology. These four get made in the first month whether you make them consciously or not.

Coexist or consolidate is a business decision, not an IT one

If the acquired business serves different customers, in a different way, with processes that are the reason it was worth buying, forcing it onto your platform can quietly remove the value. If it does substantially the same thing you do, running two systems permanently is expensive and confusing. The honest answer is usually to consolidate finance and reporting early, and to leave operational systems alone until there is a clear reason to move them.

Identifiers collide the moment you combine anything

Both businesses have a customer 1001, both have invoice numbers in the same range, both have product codes that happen to match but mean different things. Any attempt to combine data without a deliberate identifier strategy produces silent corruption that is very hard to unpick later. Decide early whether you prefix, renumber or hold a cross reference, and apply it to every entity before the first record moves.

The overlap in customers is smaller than you think and matters more

Two businesses in the same market share fewer customers than executives expect, but the ones they share are usually the largest. Merging customer records badly means duplicate statements, wrong credit limits, and a key account receiving two different prices. This has to be worked through record by record for the overlap, with a person deciding, not resolved by an automatic merge rule applied to the whole list.

Sequencing decides whether people cope

The acquired team is absorbing new ownership, new reporting and often new managers at the same time. Adding a system change in the first quarter is how good people leave. Sequence the work so the group gets what it genuinely needs first, which is normally consolidated financial reporting and a single view of shared customers, and leave the disruptive changes until the business has settled.

The Six Workstreams

Most post acquisition integration programmes reduce to these. They do not all run at once, and they should not.

Honest map

System and data inventory

Every system in the acquired business, including the ones not on the IT list: the spreadsheet that prices jobs, the mailbox that receives orders, the access database someone built in 2014. Who uses it, what it holds, what it connects to, and what happens if it stops. Due diligence rarely reaches this level of detail, so assume you are starting fresh.

Group numbers

Finance consolidation

Mapping the acquired chart of accounts to the group structure, agreeing how intercompany transactions are recorded and eliminated, and automating the periodic transfer of trial balance or transactional data so consolidated reporting works. This is normally the first workstream because it is what the board asks for immediately.

No collisions

Identifier and master data strategy

Deciding how customers, suppliers, products, orders and accounts are identified across the group. Prefixing, renumbering or cross referencing, chosen per entity and documented. Every later workstream depends on this being settled, which is why it is worth doing before anyone starts moving data.

One view

Customer and supplier deduplication

Identifying genuine overlaps using ABN, email domain, trading name and address together, then reviewing them with people who know the accounts. The output is a reviewed match list and a decision per record, not an automated merge. Credit limits, contract pricing and payment terms have to be reconciled deliberately for anyone who trades with both entities.

Working links

Operational integration

Where the two businesses actually need to work together: shared stock visibility, cross entity ordering, a single view for customer service, consolidated purchasing from a common supplier. Built as targeted integrations between the two stacks rather than a migration, so the value arrives without the disruption.

One platform

Consolidation or retirement

Where the decision is genuinely to move to one system, this is a replatforming project in its own right with parallel running, cutover planning and data migration. It belongs at the end of the sequence, once the group is stable and the case for it is proven, not in the first hundred days.

What the Group Actually Needs, and When

Task	Traditional	Planned Properly	Notes
Consolidated monthly reporting	Two exports merged in a spreadsheet	Automated group consolidation	Almost always the first thing asked for, and achievable without touching operational systems.
Knowing a customer trades with both	Discovered by accident	Matched and flagged across entities	Matters most for credit exposure, where the group risk is the sum, not the larger of the two.
Stock visible across both businesses	A phone call to the other warehouse	Read only cross entity visibility	Visibility is far cheaper than a merged stock pool and delivers most of the benefit.
Intercompany sales between the entities	Manual invoices, reconciled late	Raised and matched automatically	Needs the transfer pricing and GST treatment agreed with your accountant before build.
Group purchasing from a shared supplier	Two accounts, two prices	Combined volume, one agreement	Often one of the clearest synergies, and it is a data and process change more than a systems one.
Customer service across the group	Agents guess which system to check	One lookup across both	A read only aggregation view is usually enough and avoids a migration entirely.
Duplicate product across catalogues	Two codes, two cost prices	Cross referenced, one reporting view	Full catalogue harmonisation is a large project, so start with the lines that overlap.
Retiring the acquired system	Rushed in the first quarter	Sequenced once value is proven	The right answer sometimes turns out to be keeping it, and that is a legitimate outcome.

Where Post Acquisition Integration Goes Wrong

The acquired system is switched off before anyone understands it

Undocumented processes hold more of the operating capability than the org chart suggests. Before retiring anything, run a period where the acquired business keeps working normally while you observe what actually flows through the system, including the month end steps and the annual ones. Businesses have lost their pricing logic, their supplier terms and their compliance records this way, and the loss is usually found the following financial year.

Data is merged before identifiers are decided

Loading one customer list into another without a collision strategy is the most common and most expensive error in this work. Two records that both call themselves 1001 will overwrite each other or create a mismatched pair, and the damage spreads through orders, invoices and history before anyone notices. Settle the identifier approach for every entity type first, write it down, and hold to it even when a quick load is tempting.

Personal information moves without a proper basis

Combining customer databases across entities is a handling of personal information governed by the Privacy Act 1988 and the Australian Privacy Principles. What each business told its customers in its privacy policy still matters, marketing consent does not automatically transfer between entities, and the group needs to be able to honour access and deletion requests across every system it now holds. Work this through with your legal adviser before the databases meet, not after.

Nobody owns the integration inside the business

These programmes span finance, operations, IT and the acquired leadership, which means without a single named owner they stall at every boundary. The owner needs authority to make the coexist or consolidate call and to say no to scope that belongs in a later phase. Committees can advise on this work but they cannot run it, and the absence of an owner is usually visible within six weeks.

Consolidation is attempted during peak trading

Retail and wholesale groups have seasons where a systems change is simply indefensible. Cutting over an inventory or point of sale system in the lead up to Christmas, at end of financial year, or during a major promotion turns a manageable project into an incident. Map the trading calendar of both businesses at the outset and treat the closed windows as fixed constraints rather than negotiable ones.

Licensing, contracts and access are left as they were

The acquired business has software agreements, integration contracts and credentials that were scoped to its previous ownership. Some do not permit transfer, some are billed per entity, and some are administered by a former owner or a departed employee. Inventory the agreements and the administrative access early, because discovering that nobody in the group can administer a critical system is a problem best found deliberately rather than during an outage.

How Yes AI Approaches Post Acquisition Integration

We will tell you not to consolidate when that is the answer

Plenty of acquired systems should be left running for years, and some permanently. We assess it on what the business needs rather than on tidiness, and where coexistence is right we design it properly with clean interfaces instead of leaving it as an unmanaged gap.

Reporting first, disruption later

We prioritise the consolidated financial and customer reporting the group needs immediately, which can normally be delivered without changing how either business operates. That buys the time to make the harder decisions with evidence rather than under pressure.

Built, hosted and monitored by us

Cross entity flows run on a managed cloud automation layer we operate, with alerting and record level logging from day one. Neither business needs to take on new infrastructure while it is absorbing everything else that comes with a change of ownership.

Documented decisions you can hand over

Identifier strategy, account mappings, matching rules and the coexist or consolidate reasoning are written down as deliverables. When the group buys the next business, that document is the starting point rather than a memory of what someone decided.

From Completion to a Working Group

Five steps. Consolidated reporting normally lands in the first two months, well before any system is retired.

Inventory both stacks honestly

Every system, spreadsheet, mailbox and integration in the acquired business, with owners, dependencies and the annual processes that only run once. We interview the people who use them rather than working from the asset register.

Decide coexist or consolidate, per system

A documented recommendation for each system with the reasoning, the cost of each path and the trading calendar constraints. Your leadership makes the call and we record it so the decision does not get relitigated every quarter.

Settle identifiers and deliver group reporting

Identifier strategy agreed across every entity type, chart of accounts mapped, and automated consolidated reporting delivered. This gives the board what it needs while the operating businesses continue undisturbed.

Build the cross entity links that earn their keep

Shared customer visibility, cross entity stock views, intercompany transaction flows and group purchasing data, built as targeted integrations. Each one is justified on its own before it is built.

Consolidate where the case is proven

Where the decision is to move to one platform, it runs as a proper replatforming project with parallel running and a planned cutover, scheduled outside the trading windows both businesses depend on.

FAQ

Should we move the acquired business onto our systems straight away?

Rarely. The first hundred days are when the acquired business is least able to absorb change and when you understand it least, which is the worst possible combination for a system migration. The usual sequence is to deliver consolidated financial reporting quickly, because that is what the group genuinely needs, then build targeted links where the two businesses have to work together, and only consider full consolidation once you understand what the acquired systems actually do for the business.

How do we produce group numbers without merging the systems?

By mapping the acquired chart of accounts to the group structure and automating a periodic transfer of trial balance or transactional data into a consolidation. Both businesses keep operating as they are, and the group gets consistent reporting within weeks. The work is in agreeing the mapping, deciding how intercompany transactions and eliminations are handled with your accountant, and making the transfer reliable enough that nobody keeps a shadow spreadsheet.

What is the biggest technical risk?

Identifier collisions. Two businesses will independently have used the same customer numbers, product codes, invoice ranges and account codes for entirely different things. Combining any data without deciding first how each entity type will be identified across the group creates corruption that spreads through transaction history and is extremely difficult to reverse. Settling that strategy is a short piece of work that prevents a long and expensive one.

Can we merge the customer databases?

You can, but treat the overlap as a reviewed exercise rather than an automated one. Match candidates using ABN, email domain, trading name and delivery address together, then have people who know the accounts confirm each match, because the shared customers are usually your largest and the cost of getting one wrong is high. You also need to work through the privacy position with your legal adviser first, since what each business told its customers still applies and marketing consent does not automatically carry across entities.

How long does post acquisition integration take?

Consolidated reporting is commonly delivered in four to eight weeks. Cross entity operational links follow over the following months as each is justified. Full consolidation onto a single platform, where that is the decision, is typically a twelve to twenty four month horizon for a mid market deal, and it is often constrained less by the work than by the trading calendar, since retail and wholesale groups have seasons where a cutover cannot responsibly be attempted.

What if the acquired business runs an old system nobody supports?

That is common and it is not automatically a reason to replace it. An unsupported system that works can often be integrated through a file export, a database view or a scheduled extract, which buys you time to make the replacement decision properly. What does need urgent attention is the risk position: who can administer it, whether it is patched, where it is hosted, and what happens if the one person who understands it leaves. Deal with the risk first and the replacement on its own timetable.

Who should own this inside our business?

One named person with authority across finance, operations and the acquired leadership, and with a mandate to decide rather than to coordinate. It does not have to be an IT role, and in mid market groups it often sits with the CFO or a general manager. What matters is that they can make the coexist or consolidate call, defend the sequencing when someone wants their piece brought forward, and hold the trading calendar constraints. Programmes run by committee without that authority stall, and it usually shows within the first six weeks.

Integrate the Business You Bought, Without Breaking It

Book a call. We map both stacks, recommend what to merge and what to leave, and give you a sequenced plan with prices. The map and the recommendations are yours either way.