Bramvia — Business Central Experts

We just acquired a company. Now we have two ERPs — what to do in the first 100 days

Running two ERP instances after a deal compounds reporting and reconciliation overhead every month. The four options, how to choose between them in the first 100 days, and why the decision is about the next acquisition, not this one.

Short answer: the deal closed and you now run two systems. Every month costs you a manual consolidation, two charts of accounts that don't reconcile, duplicate customers and suppliers with different codes, and intercompany transactions nobody can trace. Running multiple ERP instances after an acquisition compounds reporting and reconciliation overhead — and the overhead grows, because each month of divergence makes the eventual merge harder. You have four options, and the right one depends less on this acquisition than on whether there will be another. Platform strategies fail when the ERP can't absorb the second or third bolt-on: selecting a system that can't scale past the first acquisition forces costly re-platforming mid-hold. Decide in the first 100 days; execute over 6-18 months.

The four options

1. Leave both running. Legitimate as a deliberate, time-boxed decision — if the acquired business is genuinely independent, has its own customers and suppliers, and consolidation is only a finance exercise. It stops being legitimate the moment you share customers, inventory or people. Cost: a manual close, every month, forever.

2. Migrate the acquired company onto yours. The usual answer when your system is modern, multi-entity and can absorb them. Cheapest if true. The test: can your system handle another legal entity, currency, tax jurisdiction and intercompany flow without a project? If yes, this is your path.

3. Migrate yours onto theirs. Uncomfortable but sometimes correct — if they run a modern cloud system and you run a legacy one. Ego is the main obstacle; the cost difference usually isn't close.

4. Both onto a third platform. Right when neither system can carry the combined business, or when a roll-up strategy means several more acquisitions are coming and you want the target architecture in place before them. Most expensive up front, cheapest across three or four deals.

How to choose, in seven questions

1. Will there be more acquisitions? If yes, design for the fourth deal, not this one. This single question decides most cases.
2. Do the two businesses share anything operational? Shared customers, shared inventory, shared suppliers, cross-selling — any of those and separate systems will hurt within a year.
3. Is either system unsupported or unpatchable? If so, it's not a candidate to survive, and it's also an insurance and diligence exposure.
4. Can the surviving system handle multi-entity natively? Intercompany posting, consolidation, multi-currency, tax by jurisdiction — in the product, not in a spreadsheet.
5. How much custom code is in each? Heavy customisation on the candidate system is a reason to reconsider it, not a reason to keep it.
6. What does the sponsor's timeline require? If a PE thesis needs consolidated reporting by a given quarter, that is a hard constraint on scope, not a preference.
7. Who will own it? A consolidation with no named internal owner is the classic stalled project.

The first 100 days, specifically

Days 1-15 — stop the divergence. Freeze new customisations on both systems. Agree who produces the consolidated numbers and how, even if it's manual. Get admin access to the acquired system in your own name, not the previous owner's.

Days 15-45 — the inventory. Both systems: versions and support status, custom objects, integrations, master data volumes and quality, and how each one closes the month. This is the document the decision rests on; without it you're choosing on preference.

Days 45-70 — the master data map. Customers, suppliers and items that exist in both, with different codes. This is where consolidations actually fail. Decide the surviving coding convention now, because everything downstream depends on it.

Days 70-100 — the decision and the plan. One of the four options, in writing, with phases, acceptance criteria per phase and a date. Then the sequence: chart of accounts alignment first, then master data, then transactions, then the cutover.

What makes these projects go wrong

• Merging charts of accounts late. It's the foundation. Do it first or reconcile forever.
• Migrating full transaction history from both. Masters, balances and open items move. History is archived read-only in the retiring system. Migrating everything is the most common way to double the budget.
• Ignoring intercompany. If the two entities now trade with each other, that has to be designed, not discovered at the first close.
• Keeping both integration stacks. Two connections to the same carrier, two Shopify links, two EDI setups — consolidate them or you keep two maintenance bills.
• No dimension strategy. Post-merge you'll want to report by entity, site, product line and channel. Getting dimensions right at the start is nearly free; retrofitting is not.

Why Business Central suits roll-ups specifically

Not a pitch, a structural point: multiple companies live in one tenant with intercompany posting and consolidation built in, a new entity is a configuration exercise rather than a new installation, and extensions carry across without modifying the standard — so the fourth acquisition costs a fraction of the first. That's the property PE-backed platforms need, and the reason "can it absorb another entity without a project?" is the question worth asking of any candidate system.

If the surviving system is already yours and it can do this, the cheapest answer is option 2 and we'll tell you so.

How we help

We do the 100-day inventory and the decision document as a fixed-scope engagement, and the consolidation itself in phases with each part invoiced only after you accept it — which matters when a sponsor is watching milestones. For the analysis of what's actually inside both systems, including duplicate masters and data quality, the Profit Leak Audit works on either or both platforms regardless of vendor.

FAQ

How long does consolidating two ERPs take? 6-18 months depending on entity count, customisation and data quality. The decision should take 100 days; the execution is phased.

Can we consolidate reporting without consolidating systems? Yes, as an interim step — a consolidation layer in Power BI over both systems buys you visibility while you plan. It doesn't fix duplicate masters or intercompany.

What if the acquired company's team resists? Usually they're right about something specific. The inventory surfaces what their system does that yours doesn't, and that goes into scope rather than into an argument.

We're mid-carve-out on a TSA. Different clock: separation milestones have penalties, and extensions are expensive. That plan should start before close, not after.

Two systems and a close that takes three weeks? Free assessment, no commitment — first reply within one working day.

Bramvia · bramvia.net