If your group has grown through acquisition, you almost certainly have plants running different ERPs. One site is on Business Central, another on NetSuite, a third still on the legacy system that came with the deal. The production MIS — CERM or something equivalent — sits across all of them, modeling the shop floor in its own language. Somewhere between the MIS and the consolidation layer, your group finance team is doing work that shouldn't need to be done manually.
The question isn't whether ERP heterogeneity is ideal. It isn't, and everyone knows it. The question is more practical: which specific divergences are quietly corrupting your consolidated numbers, and which ones are just local color that your consolidation layer can absorb without drama?
The answer matters because ERP harmonization projects are expensive, disruptive, and slow — and converters are being acquired faster than harmonization timelines allow. Treating every difference as equally urgent is how you end up rebuilding everything and fixing nothing that was actually broken.
---
The divergences that genuinely break consolidation
Chart of accounts and cost center structure
This is the most consequential divergence, and it's also the one that's hardest to fix without choosing a winner. When one plant's ERP records press-center overhead as a direct manufacturing cost and another's rolls the same expense into a facility overhead pool, your consolidated margin by product line is wrong — not approximate, wrong. The plants are describing the same economic reality in incompatible ways, and no amount of mapping logic recovers the distinction after the fact.
For converters specifically, the mismatch is structural. A production MIS models cost at the level of press centers, substrate waste pools, and tooling amortization — objects that reflect how a job actually consumes resources. A generic financial ERP models cost by department or location, because that's how most businesses are organized. Those two models don't align naturally. When the MIS feeds actuals to an ERP, something gets lost in translation, and the thing that gets lost is usually the detail that would tell you whether a product line is profitable.
If your per-plant ERPs have diverged at the level of cost center structure, you cannot produce a meaningful group-level cost analysis without a documented mapping that someone maintains and audits. That mapping is a control, not a convenience.
Item master classifications
The same substrate or component arriving at two plants will frequently carry different item codes, different descriptions, and — critically — different classifications. One plant's ERP records it as a raw material. Another records it as a semi-finished good. The difference isn't cosmetic. It affects where the item sits on the balance sheet, how it flows through BOM structures, and whether your group-level inventory reconciles.
For operations, the immediate consequence is broken BOM linkage across the consolidation layer — you can't roll up a group-wide bill of materials when the components aren't recognized as the same thing. For finance, the consequence is misstated inventory categories in the consolidated balance sheet.
There's a newer consequence worth naming: if your group is working toward carbon accounting — and the direction of travel in packaging is clearly that way — item master divergence corrupts compliance outputs by construction. Carbon-accounting modules that pull from ERP item masters will assign different emissions factors to what is physically the same material, simply because the master data disagrees about what that material is. You can't correct this in the reporting layer; you have to correct it in the item master.
Period-boundary misalignment
Month-end close is where divergent fiscal calendars go from being an administrative nuisance to being an accounting problem. If a plant ERP closes its fiscal period on the 28th but the production MIS accepts job completions through the 31st, you have jobs that are financially closed in one system but operationally open in the other. The revenue and cost associated with those jobs will land in different periods depending on which system you're reading.
At one plant, in one month, the exposure is manageable. Across four plants with four different close calendars, it accumulates into a material variance that your consolidation team will spend days reconciling — assuming they find it at all.
Real-time synchronization across multiple ERPs is not a realistic solution here. The practitioner standard is sub-hourly eventual consistency, not true real-time sync. The practical control is a daily reconciliation that specifically flags period-boundary mismatches: jobs that changed status near a period close in either system. That reconciliation needs to be a formal control, not something that runs when someone remembers to check.
---
The divergences that are mostly harmless
Local GL segment structure below the consolidation mapping
If Plant A uses a five-segment GL string and Plant B uses a three-segment string, that's a local configuration difference. As long as both can produce a trial balance that maps to your group chart of accounts at the consolidation layer, the internal structure doesn't matter for group reporting. Finance teams sometimes spend significant effort trying to standardize segment structures across plants when the consolidation mapping is already working. That effort is usually better spent elsewhere.
Vendor naming conventions
One of the more common failure modes in multi-ERP environments is the same supplier existing under three different spellings, with no group-level answer to a simple spend question without exporting spreadsheets. A canonical-model integration layer — one that maps all ERP spokes to a unified data shape — solves this for reporting and spend consolidation. The underlying ERP records don't need to change; the consolidation layer handles the matching. This is real work, but it's integration work, not ERP harmonization work.
Unit of measure conventions for internal reporting
Plants often maintain local UoM conventions that reflect how they run — linear feet versus square meters, sheets versus thousand impressions. These create noise in consolidated reporting if the conversion factors aren't maintained, but they're not structurally broken. A well-maintained UoM conversion at the integration layer handles this. The risk is that the conversions drift and no one notices; the control is periodic verification, not standardization of local conventions.
Close calendar timing within the same fiscal month
If all plants close within the same calendar month and the consolidation adjustment window accounts for the spread, the exact close date is an operational difference, not a financial one. The problem described above — period-boundary misalignment — is specifically about jobs that cross a fiscal period boundary, not about plants that close on the 28th versus the 31st of the same month.
---
What actually governs whether a divergence is harmful
The pattern is straightforward once you see it: a divergence breaks consolidated reporting when it changes *how a transaction is classified*, not just *how it is labeled*. Cost center structure, item master classification, and period boundaries all determine classification. Vendor name formats and GL segment conventions are labels.
The second governing factor is whether there is a master data authority. Without a hub-and-spoke master data discipline — a central record that each ERP spoke consumes and publishes changes to asynchronously — item master divergences compound over time. Every acquisition adds another instance. Every instance drifts. Practitioners with experience in this space consistently advise establishing an integration governance function before the integrations become unmaintainable, but converters that grew through acquisition rarely have this in place before the pain forces the conversation.
The third factor is the reconciliation discipline around period boundaries specifically. Integration architectures that work well in steady state will still produce period-boundary mismatches, because the nature of month-end is that timing differences are compressed and visible. Daily reconciliation controls that flag those mismatches are not a sign that the integration is broken; they are the normal operating procedure for a well-run multi-ERP environment.
---
A starting point for prioritization
If you're working through which divergences to address first, the ordering that emerges from the above is roughly this:
1. Document the cost center structure mapping between each plant ERP and your consolidation chart of accounts, and assign someone to maintain it. If the mapping doesn't exist, the consolidated P&L is not reliable. 2. Audit item master classifications for shared substrates and components across plants. Where the same physical item carries different classifications, decide on the authoritative classification and propagate it. 3. Build or formalize the period-boundary reconciliation control. It should run daily near month-end and flag any job that changed status in either the MIS or the ERP within 72 hours of a close boundary. 4. Assess vendor master duplication. If spend consolidation requires manual spreadsheet work, an iPaaS canonical-model layer will solve it without touching per-plant ERPs.
The divergences that don't fall into those four categories are worth tracking but rarely worth a harmonization project on their own.
If any of this maps to a reconciliation problem your team is already living with, we're glad to talk through how others have structured it — no pitch, just the conversation.