You don't need to consolidate ERPs to get consolidated reporting. But you do need a shared data layer above them: one place where every entity's orders, shipments, and financials land in a common shape, on the schedule you control. The ERPs stay where they are, doing their jobs. And, you can stand the first slice up inside the value-creation window, in weeks to a couple of months (instead of the years a full consolidation would eat).
Here’s the setup, maybe this will feel familiar. The big deal closed last week and now you own 3 companies running 4 ERPs. You weren’t there when any of those purchase decisions were made. That 4th one exists because one of the companies started a migration a few years back and couldn’t stick the landing; the half-finished project came with the deal just like the trucks and the buildings.
The board wants a real view of the whole platform by the first quarterly meeting. Revenue by entity, cash, and backlog. Right now those numbers live and transmit via a series of emails to and between 3 controllers and a CFO that’s madder than a hornet at the end of each month.
Nobody screwed up here. Each company bought the system that fit its size and needs at the moment; the manufacturer runs a heavyweight ERP with an MES bolted on because the plant demanded it, and the distribution business lives happily in something lighter. The mismatch is what independent histories look like when they collide at close. If you're living with a stack like that right now, you're not alone.
Why the first 100 days create a reporting gap
The value-creation plan assumed you could actually see the business. Cost targets, working capital, and pricing moves across entities all presume that a consolidated set of numbers exists somewhere. But on zero day the platform's "consolidated financials" turn out to be 5 exports stapled together with a footnote explaining why intercompany revenue doesn't tie. Odds are decent the quality-of-earnings model from diligence is still moonlighting as the reporting template because nothing better exists yet.
The gap doesn't live inside any particular system. Each entity's numbers are right, locally; the machining company's ERP knows exactly what it shipped last week. The gap lives in between the systems: different charts of accounts, different item masters, and 3 definitions of "on time." The connective tissue doesn’t exist because until the deal nobody needed it.
Meanwhile you’re being measured against a timeline that your data can’t deliver. Board meetings arrive whether the numbers reconcile or not, and in most 100-day plans the systems work sits at priority 6 of 7, waiting for a quiet month. How many quiet months have you had since close? There's your problem.
The trap of starting with an ERP consolidation
"Shouldn't we just pick one ERP and put everybody on it?" It's the first suggestion in almost every post-close systems conversation. It’s not a dumb question. One system does eventually mean one version of the truth...eventually.
Look at what the decision costs first, though. An ERP consolidation, the kind that gets its own steering committee and a code name, is an 18-to-24-month program with the riskiest moment, the cutover, saved for the very end. It demands change management from workforces that are already nervous about being acquired, and the disruption hits hardest on the controllers and admins who know how everything actually works, right when they're the easiest people to lose.
Migration costs you scale with every customization the deal book politely called "configurable." And, through all of it, the visibility problem stays right where it was, because the reporting gap doesn't narrow until the last entity migrates.
Sometimes consolidation is the right long-term call. A true integration play, one brand and one order-to-cash flow, probably does beg for a single instance eventually. But, eventually is a year-2 decision you make when you have real operating data in hand. As a day-1 reflex it's one of the most expensive instincts in a post-close life. You sequence your slowest, riskiest project first, to produce a report you could have had by the second board meeting.
There's a more subtle problem too. When a consolidation decision is made too early the pull is to default to the platform company's ERP. That’s political gravity, not fit. If your thesis includes more acquisitions, every new deal joins the back of the migration queue; a data layer can absorb a new deal 4 in weeks, while a single-instance mandate turns deal 4 into another years-long project.
Visibility first, consolidation later, maybe never
A shared data layer is less exotic than it sounds. A cloud warehouse sits above the operational systems. Pipelines pull from each ERP nightly, or faster when it matters. A mapping layer conforms the mess: this entity's chart of accounts to the platform's, that plant's part numbers to a common item master, and 3 customer records to the one customer they all describe. On top of that you get to define each metric once, so revenue means one thing everywhere. So does margin. So does on-time. So does backlog.
The ERPs remain the systems of record. Orders still enter where they always did and invoices still leave via the same door. What the platform gains is a system of report, and nobody at the opcos has to change how they work to make it real. Ninety days into an ownership change that matters more than it sounds.
There's an organizational reason this works too, beyond the technical one. A consolidation forces every acquired team to defend its system, its process, and its way of counting, in a fight that somebody has to lose. A shared layer doesn't ask anybody to lose. Each entity keeps its tools and the platform gains truth. You'd be surprised how much goodwill that buys you at day 60.
You don't build the whole thing at once either. Start with the 3 or 4 numbers the board asks about every single time. Revenue by entity. Cash. Backlog. Debt service. Land those, get them tying together, put them in front of the board, then widen out. It's the same pay-down logic that governs any integration debt, highest-interest item first.
And, if a handful of new pipelines sounds like taking on more code to support rather than less, look at the kind you're adding. These connections are owned, monitored, and documented, a deliberate layer replacing the point-to-point mesh instead of adding strands to it. That's what paying the debt down looks like in practice. The layer you stand up for reporting is also the same foundation the AI projects on your 100-day value creation plan will eventually need, because you don’t want models reading from 4 ERPs either.
What this looks like in a multi-plant manufacturer
Say the platform has 3 plants across 2 of the acquired companies. Two ERPs, an MES at the largest plant, and an item master problem that stinks so bad you can smell it from the parking lot. The same casting carries 3 different part numbers depending on which building answers the phone. "What did we ship last week, and at what margin" is currently a plant-by-plant phone tree that takes 2 days to run.
The first slice of the layer encompasses shipments, production orders, and standard costs nightly from both ERPs, builds the part-number crosswalk, and defines OTIF one way for everybody. The ops review this week opens on a number that nobody has to defend, and the hour can instead go to decisions rather than reconciliation. Consolidating those 2 ERPs wouldn't have gotten you there faster; it would have gotten you there in 2028.
And in a logistics rollup
Roll up 4 regional carriers or 3PLs and you inherit a different flavor of the same mess. Two TMS platforms, a WMS customized so heavily the vendor refuses to support it anymore, EDI feeds of varying levels of honesty, and at least one terminal that dispatches off a shared spreadsheet. The board question here is usually profitability. Which lanes make money? Which customers only look mid-size because their volume splits across entities that don't share a customer record?
The first slice here delivers load details, shipments, invoices, and accessorials in one shape, then does the tedious work of de-duplicating customers across entities. That account that ships with 2 of your opcos stops looking like a pair of decent customers and starts looking like the top-5 account it actually is. Lane margin gets one definition. Pricing conversations get shorter.
What to flag before you sign the deal
Everything above is cheaper to learn before the wire clears on the deal. Standard technical diligence handles the what and the how. Which systems exist, which versions, how they connect, what they cost to run. What it doesn't always uncover is the why and the how well. Why that migration stalled halfway. How well each entity's numbers hold up when you lean on them. Some threads worth pulling on:
- Count the systems of record. How many places does an order, an item, or an invoice live? The number in the CIM is usually smaller than the number in the building.
- Ask about the last migration. An unfinished one (see the 4th ERP) tells you plenty about appetite, budget, and what the data looks like mid-flight.
- Check data access. Can you pull full extracts, or is one ERP a vendor-hosted instance where every report is a ticket and an invoice?
- Probe customization depth. "Highly configured" in the deck reads as "migration multiplier" in the plan.
- Find the human dependencies. If the monthly pack exists because one person knows where everything hides, price that in.
- If it's a carve-out, read the TSA as a countdown. A transition services agreement means the seller is still running some of your systems, on borrowed time, with fee escalators waiting at the end of it.
This is the boring version of technical due diligence, and it's the version that pays dividends through discovered risk. What you're buying is a read on how fast the platform will be able to see itself after the deal. Done right, the punch list it produces becomes the first 90 days of data engineering work. If you want a structured measure of how far each entity has to travel, that's what the Integration Maturity Index inside our Data Readiness Assessment measures. It’s diagnostic, not judgmental.
The 3 companies and 4 ERPs was never the problem. The problem was flying blind. You inherited the systems but you didn't inherit an obligation to make them singular. Put the layer over the top, give the board and your operators a live view of the businesses it just bought, and make the consolidation call next year when you have real numbers in hand, or skip it entirely. As for that 4th ERP, the one that's been mid-migration since before your deal was a deal? Once you can see what it actually does, you'll know whether to finish the job or retire it with honors.
Frequently asked questions
Do we have to consolidate ERPs to get one set of numbers?
No. Consolidated reporting needs a shared data layer above the ERPs, not a single ERP underneath everything. Consolidation is a separate decision you can make later with operating data in hand, or skip entirely if the thesis doesn't demand it.
How fast can we get cross-entity visibility after a deal?
A focused first slice covering a handful of board-level metrics (revenue by entity, cash, and backlog) typically takes weeks to a couple of months, and coverage widens from there. The multi-year timelines belong to ERP migrations, not to reporting layers.
What is a shared data layer?
A cloud data warehouse fed by pipelines from each entity's operational systems, with mappings that bring charts of accounts, item masters, and customer records into one shape, and metric definitions applied once for the whole platform. The ERPs stay the systems of record and the layer becomes the system of report.
Who owns this work, our team or a partner?
Either can build it, but somebody senior has to own the mappings and the metric definitions, because that's where the truth lives. Plenty of platforms pair a small internal team with outside data engineering help, and some borrow senior technology leadership through a fractional arrangement until they're ready to hire.