Consolidating multiple ledgers without a consolidated overview: how to get a grip

Short answer. You consolidate multiple ledgers by agreeing on a fixed export structure per entity and merging those centrally, with automatic elimination of intercompany transactions. That can happen inside your accounting package or in a layer built on top of it, so you have a real-time consolidated overview instead of an Excel you rebuild every month.

Three entities, three separate logins, and at month-end an Excel that nobody fully trusts. That is the pattern I see again and again at groups with multiple entities. The overview you actually need, the total picture across all companies, exists only in the head of the person who merges the exports. And when that person is on holiday, it briefly stops existing.

What you really want is control, not a tidier Excel

The goal is not "fewer clicks". The goal is that at any moment you can see how the group stands as a whole, with numbers you are willing to put your name behind. That means a consolidated picture in which the intercompany transactions between your companies have been stripped out, because otherwise you double-count an internal recharge or a loan between two entities. Consolidation is more than adding up. The mutual receivables and balances between companies must be eliminated, otherwise the total is wrong (Sumatra Software).

The second thing you want is speed. A consolidated overview that is only correct three weeks after month-end is a history book, not a steering instrument. And the third is less manual work, because every manual step is a place where an error creeps in. Excel was not designed for financial consolidation and lacks the functions to reliably safeguard eliminations and consistency (Sumatra Software).

First examine the process, then build

Before I build anything, I lay the current process completely bare. Who exports what, in which format, at which moment, and which manual corrections does that person make afterwards? At groups that have grown organically, there is often surprisingly much hidden here.

Sometimes it turns out that two of the three ledgers are already in the same package and can therefore be linked without an export. Sometimes it turns out that the monthly Excel correction is actually a recurring entry you can solve structurally at the source. And sometimes it turns out you need no legally required consolidation at all, because you fall under the exemption for small groups under article 2:407 of the Dutch Civil Code (Tijdschrift Familiebedrijven). That changes what you have to file, but not your need for an internal steering overview.

This step is deliberate. I strip out what can be done smarter or removed, so that afterwards I only build what is truly needed. A built solution that automates a messy process also automates the mess.

Building the smarter solution where the package stops

Standard packages can handle consolidation. In AFAS you add an empty consolidation project, link a consolidation structure to it, and the system combines the balance sheets of the linked ledgers (AFAS Help Center). Exact Online, Twinfield and Business Central have comparable functions. If all your entities run in one such package and your consolidation needs are standard, that is often the answer. I am honest about that.

It gets tight the moment your entities sit in different packages, one in Exact Online, the other in Moneybird or SnelStart, or when your consolidation logic does not fit a standard structure. Think of a holding with foreign currencies, deviating financial years, or eliminations that run differently per intercompany relationship. That is when I build the layer in between.

Concretely that means: I pull the trial balance and general ledger movements from each ledger via the accounting packages' APIs, map them into a standardized chart of accounts, run the intercompany eliminations automatically based on flagged contra accounts, and deliver the result as a single real-time dashboard. No export, no copy-pasting, no version 7 of the Excel. The numbers refresh themselves the moment something changes in one of the sources.

That is exactly the kind of work where build-vs-buy is the deciding factor. Buying a standard package is cheaper if your situation is standard. The moment your structure is unique, and at groups with multiple entities that is more often the rule than the exception, the built layer is the difference between numbers you trust and a monthly fight with Excel.