Consolidating multiple companies – even across different ERP systems

Few groups are designed from the outset. They evolve. One company is acquired, another is started in Norway, a third is spun off for its own product line. Each company brings along its own ERP system, its own chart of accounts, its own item numbers and its own routines.

Operationally, this works perfectly well. Each company runs its day-to-day business in a system suited to that particular operation. The problem arises one level up, when someone has to answer questions about the whole:

How much do we actually sell to this customer – in total? What volume do we have with this supplier if we count every company? Which company has the best gross margin on the same product group, and why?

When organisations grow through acquisitions, international expansion or restructuring, the complexity of financial reporting rises quickly: data has to be gathered from several companies, often with different ERP systems, currencies and reporting principles (Attollo). In practice, this is often handled manually in spreadsheets or via separate solutions per company – time-consuming, error-prone and hard to scale (Evexo, 2026).

It's worth separating two things that are often lumped together.

Financial consolidation

Group accounting. Elimination of intra-group transactions, ownership shares and minority interests, translation of foreign subsidiaries into the group currency under K3 or IFRS, and the requirement that group accounts are prepared using common and uniform principles (Koncernredovisning.biz).

There are plenty of good tools on the market for this. Vellox does not replace them, and shouldn't.

Operational consolidation

The second kind of consolidation is about what sits beneath the income statement: orders, invoice lines, items, customers, suppliers, purchase prices, stock balances and margins.

This is where most tools run out of road, for one simple reason: they start from the general ledger or the SIE file. The general ledger knows the group sold for SEK 412 million. It doesn't know that 38 of those went to the same customer – via three different companies, on three different price lists, with two different discount structures.

Adding up figures is trivial. What makes consolidation across multiple systems difficult is that the same reality is described differently in every company:

• The chart of accounts. Company A posts freight to 4010, company B to 5710. Without a common group chart of accounts, cost types can't be compared.
• The customer. The same group customer has different names and different customer numbers in three systems. Nobody sees the combined business.
• The item. The same product has different item numbers, different units and different product group classifications in each company.
• The currency. Companies report in SEK, NOK and EUR. Income and expenses must be translated at average rates and balance sheet items at closing-date rates (Koncernredovisning.biz).
• The period. Non-calendar financial years, different period structures, different closing routines.
• The definitions. In one company, sales are counted on delivery; in another, on invoicing. Same KPI, different meaning.

This mapping is where consolidation projects usually get stuck – and it is at the same time the only work that is genuinely unique to your group. Everything else recurs.

The starting point is that the model already exists. Vellox has ready-made integrations per ERP system – Business Central, Jeeves, Monitor, Pyramid and Visma Business – and each integration loads the company's data into the same model structure.

That means a Jeeves company and a Business Central company end up in the same semantic model, with the same concepts for customer, item, order and transaction. Consolidation isn't an extra layer on top of five separate solutions – it's how the model is built.

On top of that sit four things:

Company as a dimension. Everything can be broken down by company. You start at group level and click your way down to company, customer and item without switching report or solution.

Common concepts through mapping. The local chart of accounts is mapped to a group chart of accounts, customer numbers are linked to a shared customer group, items to a shared hierarchy. The mapping is done once and maintained over time.

Currency handling. Each company's amounts remain in local currency while the group currency is calculated alongside, so a managing director and a group management team can look at the same report and both see the right figure.

Intercompany trade flagged. Transactions between group companies are identified and can be filtered out, so the group's external sales aren't inflated by internal invoicing.

KPIs are defined once, at group level. Change the definition of gross margin and it takes effect across all companies at the same time – which is a prerequisite for comparisons between companies to mean anything.

The traditional route to group-wide analysis across multiple ERP systems looks much the same every time: a pre-study, a requirements specification, a data warehouse built from scratch, source systems mapped one at a time, a semantic model developed to order. Months of work and a consulting budget that often exceeds the future licence cost by a comfortable margin.

It's no surprise it looks that way. Building an integration to Monitor's data model, understanding Jeeves' order structure or handling Business Central's value entries is real work – the first time.

The point is that it only needs to be done once, not once per customer. When the integrations and model structure already exist per ERP system, by far the largest part of the project disappears. What remains is what genuinely requires your knowledge of your group: how the charts of accounts should be mapped, which companies belong in which structures, what the customer groups look like and which KPIs management wants to steer by.

That's the difference between a development project and a configuration.

Once the companies are in the same model, questions open up that previously required someone to spend a day in Excel:

The combined customer relationship. A customer that buys from three of your companies appears as one customer. You see the total volume, the total margin and who actually makes money on the relationship.

Your negotiating position with suppliers. The same supplier delivers to several companies, often without anyone adding up the volume. It's hard to negotiate on data you don't have.

Comparison between companies. Same KPIs, same definitions, same period. Companies that look different in their own reporting become comparable – and the differences become something to investigate rather than a dispute about the numbers.

Cross-selling. Which customers buy only from one company's range, even though a sister company sells something they clearly need?

Inventory and tied-up capital across the whole group. Where are the goods, and are they in the right place?

On top of that comes the ability to query the data directly. With Vellox MCP, Claude or ChatGPT connects to the semantic model, letting a group controller ask questions in plain English and get answers based on the same consolidated figures as the reports. More examples can be found in ten questions you can ask your own business data.

Start with two companies in different ERP systems – preferably the two that are hardest to compare today. Set up the integrations, map the chart of accounts and customer structure, and run one month live. After that, each additional company in a system you already have in place takes a fraction of the effort.

Book a demo or get in touch directly, and we'll look at what your group structure actually looks like.