When a company acquires another, the deal team talks about EBITDA multiples, market share, and talent retention. The product team should be in that room too. What happens after close is a product problem of the highest order.
I led a finance systems integration following an M&A activity that brought in an entity with its own ERP instance, its own chart of accounts, its own intercompany elimination logic, and its own payroll system. None of these mapped cleanly to the acquiring entity's setup. All of them were load-bearing: the acquired company's finance team was still running live operations on these systems on day one of the integration programme.
The Three Problems Nobody Plans For
1. The Chart of Accounts Clash
Two companies, two different ways of categorising revenue, cost, and liability. Merging these isn't just a technical mapping exercise. It requires fundamental decisions about how the combined entity wants to see its financial performance. Those decisions involve the CFO, the Controller, and often the board. They take time. And until they're made, the integration is blocked.
The product lesson: get a finance domain expert embedded in the integration team from week one. Not just a business analyst. The chart of accounts decisions will determine your entire data model, and getting them wrong means rebuilding from scratch six months in.
2. Regulatory Fragmentation
If the acquired entity operated in a different jurisdiction, it had different tax rules, different statutory reporting requirements, and possibly different currencies. Your combined platform needs to handle all of them simultaneously. This isn't a nice-to-have. It's a legal obligation.
In that integration, we had to maintain separate statutory reporting for the acquired entity's home jurisdiction while simultaneously consolidating into the parent company's group accounts. The interplay between these two requirements drove most of our architectural decisions and nearly doubled the complexity of the reporting layer.
3. The Shadow Systems Nobody Admitted Existed
Every finance team has spreadsheets that are doing work the official system can't do. These are the allocation models, the variance analyses, the management reporting packs. They exist because the ERP was never configured to handle them. In an integration, these spreadsheets become critical path. The team running them won't sign off on go-live until their workaround is either replicated or replaced.
What Good Integration Governance Looks Like
The integrations I've seen succeed share three structural features. First, a dedicated integration product owner: someone whose only job is the integration, not a senior PM with three other workstreams. Second, a clear data ownership register: for every system and dataset, there is a named person accountable for its accuracy during the transition. Third, a parallel-run period where both systems run simultaneously with daily reconciliation before the legacy system is decommissioned. This is expensive and uncomfortable. It is also the only reliable way to catch the edge cases that automated testing misses.
M&A integration is where finance platform strategy and product execution collide at the worst possible time. The companies that handle it well are the ones that treat it as a product programme, not an IT project.