Company consolidation across every entity's own system
A group closes its books once, on data from subsidiaries that each run something different. Maesn connects every entity through one integration and returns their accounts and postings in the same shape, whichever system each one keeps.
- GermanyDATEV Rechnungswesen
- NetherlandsExact Online
- United KingdomXero
- SwedenFortnox
The two objects every entity in a mixed group can deliver.
One closing, and a different ledger in every entity
A group can only consolidate what all of its entities can deliver. That turns the usual question upside down: not how many systems support an object, but how few of them survive across the ones your customer's group actually runs.
- GermanyDATEV Unternehmen Online, DATEV Rechnungswesen, sevdesk, Lexware Office, BuchhaltungsButler, Xentral, Weclapp
- Switzerlandbexio, Abacus
- NetherlandsMoneybird, SnelStart
- FrancePennylane
- SpainHolded
- United KingdomFreeAgent
- SwedenFortnox
- DenmarkDinero
The reason a group is on several systems is rarely a decision anybody made. Statutory formats, tax rules, audit requirements and the language the local accountant works in are national, so the software is too. A subsidiary in another country is a subsidiary on another system, and an acquisition arrives with whatever it was already running. That is a permanent condition rather than a migration backlog.
- One entityDATEV RechnungswesenAccounts, Journal entries, Tax rates, Trial balance, Fiscal years5 of 8
- Plus the Dutch oneExact OnlineAccounts, Journal entries, Tax rates3 of 8
- Plus the UK oneXeroAccounts, Journal entries, Tax rates3 of 8
- Plus the Swedish oneFortnoxAccounts, Journal entries2 of 8
Every other integration question is a union. This one is an intersection, and the difference is not academic. A single strong system answers most of what a group report wants; the moment a second entity on a second system joins the closing, only what both can deliver counts, and the third and fourth entity subtract again. The consolidation is as capable as its least capable subsidiary.
What is left at the end is small and, fortunately, load-bearing: the chart of accounts and the postings. Everything a group report normally asks for on top of that, the balance per account, the journals, the segments, the fiscal year, is available on some entities and not on others, which for a consolidation is the same as not being available.
Building for the intersection rather than for the best entity is therefore not a compromise, it is the only version that produces a comparable group figure. A pipeline that reads balances where it can and postings where it cannot has two definitions of the same number, and reconciling those two is a worse problem than the one it set out to solve.
One integration, one connection per entity
Onboarding a subsidiary should cost an authentication rather than a project. That is the mechanism this use case runs on, and it depends on how the keys are shaped.
An account key identifies one entity in one system, so a group holds as many as it has authenticated pairs. Onboarding a subsidiary is one authentication flow, not an integration project, and that is the difference this use case turns on.
- 1Send the entity to the authentication flow
- 2They approve access in their own system
- 3Store the key that comes back, once
Several systems hold more than one company behind a single account, so the entity is selected rather than connected again. Maesn can run that selection as part of the authentication instead of you passing it on every call.
Documented for nine systems, listed as fourteen target identifiers: DATEV appears five times and Sage Active three, once per country.
Maesn treats that as the normal case. One key identifies your product, a second identifies one entity in one system, and adding the next subsidiary means running the authentication once more rather than writing an adapter. Where several entities live inside a single accounting installation, the entity is a selection instead, and that selection can be stored with the connection rather than repeated on every call. The object shapes that come back are the same regardless of which route an entity took, which is what the common data model is for, and the mechanics of the connection itself are described under unified authentication.
Volume is a group-shaped problem too, since a closing pulls a full period from every entity at once rather than a few records from one. Paginated, filterable reads keep that proportional, an incremental pull limits a refresh to what actually moved, and where a system answers a large read as a background job it arrives as a task you poll. The per-system differences that survive normalisation are the subject of customization handling.
Every entity's chart of accounts, and the field it arrives without
The group chart is where a consolidation is actually built. Here is what each entity hands over to map onto it, counted across the systems that publish their account fields.
- name15 of 19What the account is called
- code11 of 19The number you would map on
- class7 of 19Asset, liability, income or expense
- parentAccountId2 of 19Where it sits in the tree
What that costs is a design decision made early or made twice. A mapping interface that expects to inherit a tree and one that expects to assert it are different pieces of software: the first shows a structure and asks you to confirm it, the second asks you to build one and then holds every entity against it. Discovering which you need after the first two entities are live is the expensive order.
That is more work to specify and, in practice, better. A group chart is a decision about how the group wants to see itself, and inheriting four different national hierarchies would mean reconciling four opinions before producing one. What matters is knowing it in week one, because a mapping interface designed for inherited hierarchies is a different piece of software from one designed to assert them.
The same applies to periods. Fiscal years are readable on two systems, so for most entities the period boundary is a configuration your onboarding captures rather than a value the API returns. Once the accounts are mapped and the periods are aligned, summing postings per account per period reproduces the balance for every entity, which is why the two objects that survive the intersection are enough. What you do with the result is the subject of financial analysis and forecasting.
A multi-entity product already runs on this connection
Maesn assigns them this use case in its own customer mapping. What they built with it is theirs to describe, so that is all this says.
Read the case studyCustomers who have published a full account of what they built are collected on the case studies page.
What a group closing reads, counted per system
The objects a consolidation touches, taken from the per-system documentation rather than from a summary.
| What you need | Today | On demand | System cannot |
|---|---|---|---|
| Each entity's chart of accounts | 19 | 8 | 2 |
| The postings behind the figures | 10 | 12 | 7 |
| Receivables per entity | 13 | 14 | 2 |
| The rates each entity applies | 12 | 14 | 3 |
| How postings are grouped | 5 | 15 | 9 |
| Segments to report by | 3 | 17 | 9 |
| A balance per account | 2 | 7 | 20 |
| The period to compare on | 2 | 12 | 15 |
Read as a single-system list this table looks comfortable. Read as a group requirement it reads differently, and that is the shift this page exists to make. The chart of accounts at nineteen systems and the postings at ten are the two rows deep enough that a mixed group is likely to clear both. The balance per account at two and the period at two are not rows a group can plan around, however useful they are on the one entity that has them.
Two objects on this list also work in the other direction, which matters once a group wants its closing to end somewhere rather than only to be read. Postings can be written back as well as read, which is how a consolidated result gets recorded in a leading system, described under payment reconciliation, and the rates each entity applies are the subject of tax automation. Asking questions across all entities at once, rather than pulling each one, is what the MCP server is for.
The systems a European group meets most often on this route are worth reading before scoping, because their behaviour on the account and posting endpoints differs more than the summary suggests: DATEV Rechnungswesen, Exact Online, Twinfield, Xero and Microsoft Dynamics 365 Business Central.
We deliver each entity, you produce the group
Consolidation is a judgement about how a group wants to see itself. What this connection owes you is the same raw material from every entity, in one shape.
- One connection per entity
- Accounts and postings, one shape
- The rates each entity applies
- Paginated, incremental reads
- The group chart of accounts
- How each entity maps onto it
- Intercompany eliminations
- Currency and period alignment
There is no consolidation object in this model, and no mapping or elimination step either. That is a deliberate boundary rather than a gap: the eliminations, the translation and the statutory result are exactly the parts a group has an opinion about, and a connection that decided them would be wrong for most groups most of the time.
What it does mean is that the value of this route is measured in what does not have to be built. A group with entities across four countries does not need four integration projects, four authentication models and four maintenance commitments; it needs one, plus a mapping table it would have written anyway. Where the closing produces postings that have to land back in a leading system, that write path is the same one used everywhere else, and what a partial response looks like when an entity's system omits a field is unified error handling.
One boundary matters because the category name invites the opposite reading: nothing here produces a consolidated balance sheet. It produces the same accounts and journalEntries from every entity in the group, in one shape, on a schedule you choose. The statement is built on top, in your product or in the tool the group already owns, and how it is hosted and secured on the way through is described on the security page. Closing a group month on entities that each keep their own ledger is the work of financial teams, not of the systems underneath them.
Common questions
Does Maesn consolidate the group accounts?
How many connections does a group with ten entities need?
Some of our entities sit inside one accounting installation. Does that help?
Why do our subsidiaries run different systems in the first place?
What can we actually read from every entity, not just the best one?
Can we get each entity's trial balance instead of its postings?
Does the chart of accounts arrive with its hierarchy?
How do we line up periods across entities with different fiscal years?
Can we report by cost centre or segment across the group?
Is the data stored anywhere on the way through?
Build once on the Unified API.
See how company consolidation works for your integration, or dive into the technical reference.