top of page

Buy-and-Build ERP - Bringing Acquisitions onto One System Without Stopping the Business

Writer: John Hannan
John Hannan
Oct 5
6 min read

A buy-and-build platform makes one promise to its investors that depends on systems more than any other, and that's that the companies it buys will run as one business. Shared purchasing, cross-selling, one close, one set of numbers for the board and, at exit, one company a buyer can diligence in a week. Every add-on arrives with its own accounting package, its own item numbers and its own way of invoicing. If each acquisition becomes its own ERP project, the platform spends its hold period implementing software instead of integrating businesses.


This guide is for operating partners, platform CFOs and COOs, and the integration leads at manufacturers and distributors that are buying companies. It covers why the first decision is the platform's own system, what that system has to do, what to standardize and what to leave alone, a repeatable onboarding playbook, and how to select the system and the implementation partner once, with the acquisition roadmap in view.


The first decision is the platform system, not the add-on's

Each add-on's software is a fact to be dealt with, not a candidate. The question that matters is whether the platform's current ERP can carry the next five acquisitions - more legal entities, more locations, consolidation with eliminations, a company template that can be stamped out, and reporting the deal team expects. That is a check to run, not an assumption to make; our guide to assessing your system and partner before a replacement describes it. If the answer is no, select once, early in the hold period, before the add-ons pile up on systems that will all have to be replaced anyway.


Two situations deserve care. When the first add-on is larger or better run than the platform company, its system can look like the obvious choice. Evaluate it as one finalist among several, against the roadmap, not as the default. And when the platform's system is adequate but its implementation partner is not, the fix may be a new partner and a re-implementation of the template rather than a new system.


What the platform ERP has to do

  • Multi-entity and consolidation - Many legal entities on one instance, intercompany transactions, eliminations and a consolidated close that does not depend on spreadsheets.

  • A company template - A chart of accounts, item and customer conventions, pricing structures, approval workflows and reports that a new entity inherits on day one.

  • Onboarding speed - A new legal entity configured in days, a data migration kit for customers, items, vendors, open balances and open orders, and role-based training that can be repeated.

  • Shared services - Accounts payable, purchasing, credit and collections and, often, customer service run centrally across entities while operations stay local.

  • Reporting the deal team expects - Revenue and margin by entity and by product line, synergy tracking, covenant reporting and a board pack produced from the system.

  • Headroom to the exit - Users, entities, locations and transaction volumes at the size the platform intends to be when it is sold, not the size it is today.

  • A partner with a repeatable kit - An implementation partner that has onboarded acquisitions for other platforms, with a method, templates and named people.


What to standardize, and what to leave alone

Standardize what makes the companies one business - finance, purchasing, master data conventions, credit policy and reporting. Leave alone, at first, the local process that is the reason the company was bought - a route delivery model, a shop-floor flow, a quoting method customers value. Those should be understood before they are changed, and some should never be changed. Write every exception down with its owner and its cost, because exceptions are where template programs quietly turn into custom ones.


The onboarding playbook

Each acquisition follows the same steps. The dates move; the sequence does not.

  1. Before close - Inventory the acquired company's systems, data and integrations. Map its chart of accounts and item numbering to the platform template. Decide the cutover month, normally a quarter end that allows a parallel close.

  2. Days 1 to 30 - Keep the acquired system running. Set up the new legal entity from the template. Agree what is standardized and what is an exception, with the acquired management team in the room.

  3. Days 30 to 90 - Clean and convert customers, items, vendors, open receivables and payables, open orders and inventory. Train by role. Test the end-to-end scenarios that matter to that business, including the exceptions.

  4. Cutover - Go live at a month end with a parallel close, so the first set of numbers from the platform system can be reconciled to the last set from the old one.

  5. After cutover - Decommission the old system, retain its history in a form that can be queried, and record what took longer than planned so the next onboarding is faster.


Our guide to ERP in the first 100 days after an acquisition covers the decisions in the first phase in more detail.


Selecting the system and the partner once

A selection for a buy-and-build platform is a standard ERP software selection with the roadmap written into it.

  • Requirements include the roadmap - How many acquisitions, of what kind and size, in which geographies, and whether any are likely to be carved out or sold.

  • The demonstrations include an onboarding - Every finalist creates a new entity from the template, migrates a sample of an acquired company's data and runs an intercompany transaction and a consolidated close, on your data, in front of your people.

  • The cost comparison covers the hold period - A five-year cost of ownership that includes the cost of onboarding each planned acquisition, not only the platform's own implementation.

  • The partner is scored on repeatability - A documented onboarding kit, references from other platforms, and the named people who will run the first two onboardings.


Demonstration scenarios that expose a weak fit

  1. New entity from the template - A legal entity created with the chart of accounts, workflows and reports inherited, and the time it took recorded.

  2. Acquired data in - Customers, items, vendors and open orders from a sample file, with the exceptions report.

  3. Intercompany - A sale between two entities, the intercompany invoices, and the elimination on consolidation.

  4. Consolidated close - Six entities with different fiscal calendars or currencies closed and consolidated, end to end.

  5. Shared purchasing - One vendor agreement applied across entities, with the spend visible by entity and in total.

  6. The board pack - Revenue, margin and synergy measures by entity, produced from the system without a spreadsheet.


Common mistakes

  • Adopting the largest add-on's system by default - It was built for one company, not for a platform.

  • Letting each add-on keep its system "for now" - Every quarter it stays, the close gets harder and the exit story gets weaker.

  • Onboarding without a template - Each acquisition becomes a custom implementation, and the fifth one takes as long as the first.

  • Cutting over mid-quarter - A cutover without a parallel close leaves finance unable to prove the first numbers.

  • Treating master data as an IT task - How the companies will describe the same products, customers and vendors is a business decision that takes months.

  • A finance-only sponsor - The platform CFO funds the program, but the operating executives of each company have to own their onboarding, or the exceptions multiply.


Where an independent adviser helps

We do not sell software or take referral fees, so the selection can end with "keep the platform system and change the partner" as easily as with a new system. We run the selection with the roadmap in view, select the implementation partner on repeatability, and run the decision check before the contract and statement of work are signed. For selection clients, the follow-on is client-side program leadership for the first onboarding waves, until the platform's own team can run them.


Frequently asked questions

Should every acquisition move to the platform ERP? Almost always, and within the first year of ownership. The exceptions are businesses that will be sold separately or that are so different that integration would destroy what was bought.

How soon after close should the onboarding start? Planning starts before close. The system work starts in the first month, and most acquisitions can be on the platform system within a quarter or two, depending on data quality and the cutover calendar.

What if the acquired company's ERP is better than ours? Evaluate it as a finalist against the roadmap, with the other finalists, in scripted demonstrations. "Better for one company" and "right for the platform" are different tests.

How long does the selection take? Twelve to twenty weeks for the system and the partner together. Running it early in the hold period is what makes the onboardings that follow fast.

Who should own the ERP program in a buy-and-build? The platform, with an executive sponsor who runs operations, a program manager who stays through the hold period, and each acquired company's leadership owning its own onboarding.

What does a selection program cost? It depends on the number of entities and locations, the roadmap, and whether implementation-partner selection is included. We quote a fixed scope after a first conversation.


If you are building a platform and the systems question is on the table, talk to John about your ERP program.


bottom of page