Key Takeaways
- The data layer, not the tool, is the bottleneck. Multi-entity groups already own capable consolidation and BI tools. What slows them down is getting clean, comparable data out of every subsidiary's accounting and ERP system.
- You can't standardise every entity onto one ERP. Rolling the parent's SAP out to every small or international subsidiary is rarely realistic. Heterogeneity is a permanent state, not a transition phase.
- Heterogeneity, not headcount, is the real challenge. The difficulty is not the number of systems but that they are different systems — different APIs, authentication models, data formats and business logic — each demanding brittle, custom middleware.
- maesn normalises everything into one common data model. Customers, suppliers, invoices, transactions, journal entries, accounts and balances are standardised across 30+ systems through pre-built, maintained, pre-authenticated connectors.
- That unified data feeds either destination. Push it into your leading ERP or accounting system, or into a third-party BI, data-warehouse or consolidation layer — enterprise-compliant, ISO 27001 certified, and hosted in Germany.
Every Group Becomes a Multi-System Company — Whether It Plans To or Not
In any multi-entity organisation, system fragmentation is the default outcome of growth, not a planning failure. Groups accumulate accounting and ERP systems the same way they accumulate entities: through international expansion onto local-compliant software, through acquisitions that arrive with their own stack, and through the simple fact that a 12-person subsidiary and a 1,200-person division do not run on the same tools.
This pattern shows up across very different organisation types, all of which share the same underlying data problem:
- Corporate groups (Unternehmensgruppen) — a parent company with operating subsidiaries, each closing its books in its own system.
- Management and financial holdings — a centre that needs visibility across a set of otherwise independent companies.
- Private equity and VC portfolios — fund- and portfolio-level reporting that depends on data from dozens of independently operated companies.
- Buy-and-build and M&A roll-ups — serial acquirers where every new entity arrives on a different accounting or ERP platform.
- Multinational groups — subsidiaries running on country-specific systems for local statutory and tax compliance.
- Franchise and multi-location networks — many small units with decentralised bookkeeping.
- Family offices — consolidating across operating businesses and investment vehicles.
The common denominator is structural: the entities that make up the group were never designed to share a single data foundation. Multi-entity data consolidation is the work of building that foundation after the fact.
The Bottleneck Isn't the Consolidation Tool — It's the Data Layer Beneath It
Most groups already own a capable consolidation or analytics tool; the constraint is the quality and comparability of the data that reaches it. CFO offices invest in financial consolidation platforms such as LucaNet, OneStream or SAP Group Reporting, and in BI and data-warehouse stacks such as Power BI, Tableau, Snowflake or BigQuery. These tools are excellent at what they do — eliminations, group reporting, dashboards, forecasting. But every one of them operates on a simple principle: the output is only as good as the data fed in.
And the data feed is exactly where multi-entity groups struggle. Before any tool can consolidate or analyse, someone has to pull figures out of each subsidiary's accounting or ERP system, reconcile inconsistent formats, map accounts to a common structure, and refresh all of it on a recurring cycle. In practice that work is done with exports, spreadsheets, manual re-keying, and a patchwork of point integrations that break whenever a source system changes.
This is where it helps to be precise about roles. maesn is the connectivity and normalisation layer that feeds consolidation and analysis — not a consolidation engine. maesn does not perform statutory eliminations or produce your consolidated group accounts; your consolidation or BI tool does that. What maesn delivers is the clean, standardised, continuously updated data foundation those tools depend on — sourced directly from every entity's system. Solving the data layer is what makes the tool you already own actually work at group scale.
Why You Can't Just Put the Parent's SAP on Every Subsidiary
Forcing a single group-wide ERP onto every entity is, for most groups, neither realistic nor desirable. It is the instinctive answer — "standardise everyone onto one system and the data problem disappears" — but it collides with operational reality on several fronts:
- Cost and scale mismatch. Imposing the parent's enterprise ERP on a small subsidiary means licence, implementation and maintenance costs that dwarf the entity's needs. You don't put the group's full SAP on every ten-person company.
- Local compliance and language. International subsidiaries run on country-specific systems for good reasons — local tax law, statutory formats, audit requirements, language and accountant familiarity. A German entity on DATEV, a French one on Pennylane, a Dutch one on Exact Online: these are deliberate, compliant choices.
- Migration risk and time. Full ERP migrations take years and carry real operational risk. A buy-and-build platform acquiring several companies a year would never finish migrating before the next acquisition arrives.
- Resistance and disruption. Newly acquired teams are productive on their existing tools. Ripping those out is disruptive precisely when integration should be smooth.
The practical conclusion is that system heterogeneity is permanent. A modern group needs to consolidate data across a diverse, multi-system landscape — not consolidate the landscape itself down to one system.
The Real Challenge Is Heterogeneity, Not the Number of Systems
The difficulty of multi-entity consolidation comes from the variety of the source systems, not merely their count. Connecting to ten copies of the same system would be straightforward. Connecting to ten different systems — which is the norm for any internationally active or acquisitive group — is a fundamentally harder engineering problem, because each system differs along multiple axes at once:
- Different integration technologies. Some systems expose modern REST APIs; others rely on SOAP, file-based exchange via CSV or XML, or even direct database access for on-premise deployments. Each method demands different technical expertise.
- Different authentication models. OAuth flows, API keys, token exchanges, partner-gated access — every vendor handles access and consent differently, and each must be built and maintained separately.
- Different data formats and structures. The same business object looks different everywhere. An expense might be modelled as a virtual bank transaction in one system, a cash-ledger entry in another, a journal entry in a third, and a clearance account in a fourth. Chart-of-accounts logic, invoice structures and transaction models all vary.
- Different business logic and update cycles. How and when each system processes and exposes data is system-specific.
Europe makes this sharper than the UK or US, where a few dominant platforms (QuickBooks, Xero, Sage, FreeAgent) cover most of the market. The European landscape is far more fragmented: DATEV dominates Germany alongside Lexware Office, sevdesk, BuchhaltungsButler, Xentral and Microsoft Business Central; France runs on Pennylane, Sage and Cegid; the Netherlands on Exact Online, Twinfield, Moneybird and SnelStart; the Nordics on Fortnox and Visma; Spain and Italy on Sage Active, Holded and local leaders; Switzerland and Austria add bexio, Weclapp and DATEV variants. For a group spanning several of these markets, building and maintaining a custom integration per system would consume engineering capacity for years and still leave coverage gaps. (For a fuller picture, see our European ERP & accounting market overview.)
The result is that without a unifying layer, each new entity or country adds a fresh integration project — and every one of them becomes a permanent maintenance liability as source APIs evolve and break.
Maesn Normalises Every Entity's System Into One Common Data Model
maesn replaces dozens of bespoke integrations with a single connection to one standardised data model. Through one integration, a group connects to 30+ accounting and ERP systems across Europe, and the data from every one of them arrives in the same shape. For CTOs and CFO offices, that turns a multi-year integration programme into a configuration exercise.
Concretely, maesn provides:
- One integration, full European coverage. Connect once, then onboard entities on DATEV, sevdesk, Xero, QuickBooks, Lexware Office, Pennylane, Exact Online, Microsoft Dynamics 365 Business Central, Visma, Fortnox, Odoo, Twinfield and many more.
- The Maesn Common Data Model. Customers, suppliers, invoices, journal entries, transactions, accounts and balances are normalised across every system — so a journal entry from a German subsidiary on DATEV and one from a Dutch subsidiary on Exact Online are directly comparable, without per-entity reconciliation.
- Pre-built authentications for every system. maesn has already built and tested the authentication and connection logic for each supported system, including the international ones. Onboarding a new entity is fast and error-free, instead of a fresh auth-engineering project each time.
- Continuous, reliable sync. Webhooks and dependable change detection keep the group data base current, so consolidation and reporting run on live data rather than month-old exports.
- A raw data option where you need it. Beyond the normalised model, teams can access raw source data when a specific analysis demands maximum flexibility.
- Maintained connectors. maesn owns the vendor relationships, certifications, API updates and breaking changes. Your team consumes a stable interface instead of chasing 30+ moving targets.
In short, the heterogeneity that makes consolidation hard is absorbed by maesn before the data ever reaches you.
Two Consolidation Patterns: Into the Group's Core Finance System, or Into a Third-Party Analytics Layer
maesn supports both common consolidation targets, and the same normalised feed serves either one. Once subsidiary data is standardised into one model, where it lands is an architectural choice rather than another integration problem.
Pattern 1 — Consolidate into the group's core finance system. Here the normalised data from each subsidiary's system is pushed into the group's central financial accounting or ERP system, so the leading system holds a complete, comparable picture. This suits groups that have standardised their reporting on one core finance platform and want subsidiary data continuously folded into it.
Pattern 2 — Consolidate into a third-party analytics layer. Increasingly, groups route the unified feed into a dedicated layer for cross-entity reporting and decision-making — a BI tool such as Power BI or Tableau, a data warehouse such as Snowflake or BigQuery, or a financial consolidation platform such as LucaNet. maesn acts as the ingestion layer that keeps this base current and comparable across all entities, powering group-wide financial analysis and forecasting, KPI dashboards and management reporting. This pattern gives the CFO office the freedom to analyse without being constrained by any single subsidiary's accounting system.
In both patterns, the division of labour is the same: maesn delivers the standardised, continuously updated data; the eliminations, statutory consolidation, modelling and dashboards happen in the destination tool. maesn is the pipework and the common language — not the reporting engine on top.
Enterprise-Grade by Default: Compliant, Secure and Built to Scale
For a CTO or CFO office, the security and compliance posture of the data layer is a precondition, not a feature. Group financial data is among the most sensitive data an organisation holds, and any system that touches it across multiple entities and jurisdictions has to clear that bar before it can be approved. maesn is built for exactly that context:
- No-storage architecture. maesn does not persist your customers' or entities' data in its systems — data flows through, it is not warehoused. This materially reduces the attack surface and the compliance footprint.
- ISO 27001 certified. Information security is independently certified, not merely asserted.
- GDPR compliant. Built for European data-protection requirements from the ground up.
- Built and hosted in Germany. Data residency and hosting sit within the EU, which matters for regulated groups and for procurement.
- Scales across the whole group. One integration handles many entities and many concurrent connections, so coverage grows with the group rather than adding linear engineering cost per entity.
The effect is that the data foundation can be approved and scaled with confidence — the security posture is designed to satisfy the people who have to sign off on it.
From Fragmented Subsidiary Data to a Single, Current Group Data Base
The groups that get consolidation right treat subsidiary data as a live, unified feed rather than a quarterly collection exercise. The destination tools already exist and are mature. What has been missing is a reliable way to get standardised data out of every entity's system — across every market the group operates in — and keep it current.
That is the layer maesn provides. By normalising 30+ accounting and ERP systems into one common data model through pre-built, maintained, pre-authenticated connectors, maesn lets the CTO and CFO office stop maintaining integrations and start working with a single, comparable group data base — feeding it into the core finance system, the BI stack, or both. The consolidation problem stops being a data-plumbing problem and becomes what it should be: a question of how well you analyse and decide.
Talk to our experts to see how maesn's unified API powers multi-entity data consolidation across your group.




