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, and it starts before the ink dries.
I led a finance systems integration following an acquisition at a mid-size European scale-up. The acquired entity brought 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 is not 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. Until they are 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 determine your entire data model, and getting them wrong means rebuilding from scratch six months later. I learned this the hard way when chart of accounts decisions were deferred to "after go-live" and then consumed the entire hypercare period.
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 is a legal obligation, not a nice-to-have.
In one integration I led, 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 those two requirements drove most of our architectural decisions and nearly doubled the complexity of the reporting layer. Nobody had modelled for this in the original integration plan.
3. The Shadow Systems Nobody Admitted Existed
Every finance team has spreadsheets doing work the official system cannot 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 will not sign off on go-live until their workaround is either replicated or replaced. Discovering them in week ten of a twelve-week programme is not a good experience.
What Good Integration Governance Looks Like
The integrations I have 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.