A finance system for an acquisitive group is three layers, not one product: the ledger each company posts to, the layer that combines those companies into group numbers, and the layer your board and your lender read. Deciding when to change your accounting system after an acquisition means deciding which of those three to change.
The route to that question is familiar. You have bought three or four businesses, each arrived with its own accounting system, and the month-end has quietly become a data project. Nobody decided that. It accumulated.
The finance system for acquisitive groups is a sequencing problem. Which layer to change, when in the deal calendar to change it, and what a platform purchase does and does not solve: that is the order this page works in.
When should you change your accounting system after an acquisition? Between deals, anchored to a period boundary, and only once you know which layer is failing. Those three conditions do most of the work, and groups that skip the third one buy a platform to solve a problem the platform does not touch.
One boundary first, because the two questions get run together. Whether to consolidate the wider operational stack at all, and how deep to go, is a scope decision we work through in when to consolidate ERP systems after a merger . This page is narrower: the finance ledger, the three layers above it, and where in the deal calendar each one can move.
That period-boundary rule is not finance-specific, and we set it out for the whole system estate in system migration essentials : year end is ideal if the timeline permits, and month or quarter end cutovers are typical. Mid period is how a migration turns into a restatement.
Picking the week inside that boundary is the operational half of the same problem, and the post-acquisition system migration guide covers it: schedule into a low-activity period, and ask the acquired team when theirs is, because they are the ones who know.
What is specific to the ledger is the comparative. Cut over at a year end and last year's numbers are fixed before you move; cut over mid year and every board pack for the next twelve months carries a join in it.
Do not migrate an entity inside its own integration window. A company in its first ninety days after a deal has a finance team learning a new owner's reporting calendar while still closing its books to the old one, and a ledger cutover on top of that is how you lose both. We set out what that window should hold in the first 90 days of post-acquisition financial integration .
Then look at the pipeline, where the 90-day guidance linked above lands in the same place: an acquirer that expects to keep buying should think hard before putting every target onto one instance. If you expect to close two more acquisitions in the next six months, a group-wide platform programme will be running straight through both of them, so either staff it for that or do the cheaper layer now and the platform later.
The three layers of a group finance system, and which one is failing The layer to change is the one that breaks first when you test them in order. Ask whether each entity can close its own books, whether you can combine them, and whether anyone can read the group result without a spreadsheet.
A multi-entity finance system has three layers, and most of the confusion in this decision comes from treating them as one. The first, the system of record , is where each entity's transactions are posted, where its statutory accounts come from, and where its auditors look.
The second, the consolidation layer , is where those entities are combined into one set of group numbers, with intercompany balances eliminated and currencies translated to a single reporting currency. The third, the reporting layer , is where the board, the lender, and the operators read the result.
An acquisitive group can change any one of those three without touching the other two, and the costs are not comparable. Replacing a system of record is a migration. Changing how you consolidate and report is usually configuration.
Layer What it is What changing it involves When it is the right move 1. System of record Each entity's ledger, where transactions are posted and statutory accounts come from A migration per entity: data, chart of accounts, training, cutover, parallel running The ledger itself has stopped coping, or has no usable API to report out of 2. Consolidation Where entities are combined: group chart of accounts, currency translation, intercompany eliminations Mapping and rules work, usually without touching a ledger The numbers exist but combining them eats days every month 3. Reporting What the board, lender and operators read Configuration and connection, reversible, no cutover You can close the books but nobody can see the group without a spreadsheet
Read the three layers as a cost ladder. Layer 3, reporting, is the cheapest thing you can change, layer 2, consolidation, sits in the middle, and layer 1, the system of record, costs far more than either. That ladder is why the diagnosis deserves your first week.
The failure mode is a group that buys at layer 1 to fix a pain at layer 3. The ledger replacement lands, the estate stays mixed because only some entities moved, and the board pack is still assembled by hand.
Do you need one accounting system for all your companies? No. Running one accounting system across every company is one valid architecture, not the default, and for a group that is still buying it is seldom the right first move.
The wider version of this question, how far to absorb an acquired business across brand, back office and systems, is the integration level decision we set out in choosing your integration level . What follows is only the finance ledger part of it.
The argument for standardising is real. One chart of accounts, one close calendar, one set of controls, one place to train new finance staff, and every acquisition after the standard exists gets cheaper to absorb.
Timing is what usually stops it. Migrating a company's ledger while it is also absorbing new ownership, new reporting, and often new management lands a lot of change on one small finance team at once. That team is rarely the one with slack in it.
These are ledger shapes. The equivalent decision one layer up, how to architect the reporting itself, is in post-acquisition reporting consolidation . There are four workable ledger shapes:
A. Reporting layer only. Leave every entity on its own ledger and add a group reporting layer above them. It is the finance slice of the low-touch integration scope , where you connect what consolidation and compliance need and leave the target's ERP largely untouched.B. One cloud ledger. Standardise on a single product, Xero or QuickBooks or similar, with a separate file per company.C. One multi-entity platform. Move the whole group onto one system that holds each company as a subsidiary.D. Hybrid. Platform on the two or three companies that carry most of the revenue, everything else left on its own ledger and read upward.Which of those suits you depends on entity count, currencies and intercompany volume, and we have already worked that comparison through by complexity tier in which multi-entity accounting software fits your entity count . Start there for the model choice, then come back for the timing and the layer.
Option D is the one worth naming, because nobody sells it. No ledger vendor's interest is served by telling you to move half your estate.
If you are choosing between these shapes for a company you have just bought, the version that belongs inside the integration window is in the 90-day financial integration sequence , which sets it against the chart of accounts work. What follows here is the same choice made from outside that window, by a group setting its standing architecture rather than handling one deal.
The reason the hybrid works is that the newest acquisition is usually the worst candidate for a migration. It is the entity you understand least, staffed by people who have just changed employer, so leaving it on its own ledger for a year and pulling its numbers upward is both faster and safer than a cutover.
If option B is where you are heading, two common routes already have their own guides: the Sage to Xero migration guide for entities coming off a desktop ledger, and the QuickBooks to Xero migration route where the estate is split across two cloud products.
What does a multi-entity platform automate? It automates the mechanical parts of consolidation and none of the judgement. Currency translation, differing charts of accounts, differing fiscal years, and the movement of data between companies are handled for you. Deciding which intercompany transactions to eliminate stays with your finance team, and in some products, Microsoft's Business Central among them, so does posting the elimination journals.
Microsoft's own documentation for consolidating companies in Dynamics 365 Business Central sets out the automated half plainly. It consolidates “across companies that have different charts of accounts”, and the same page extends that to companies on different fiscal years and currencies, to a percentage of a company's figures rather than the full amount, and to companies sitting in other accounting products or in separate Business Central environments.
That is a serious amount of plumbing you no longer have to build. Then there is this line, from the same page, and it matters more because it is the vendor conceding a limit in its own documentation: “Processing consolidation eliminations is a manual process.”
You still have to find the transactions recorded more than once across companies, enter journal lines to eliminate them, and post the adjustments. The platform gives you a report to check your work before you post.
How far that automation goes varies by product, which is worth asking in a demo. Oracle's NetSuite documentation describes a NetSuite OneWorld feature that generates elimination journal entries from the intercompany lines you have marked for elimination, and says that without it you create and post those entries by hand.
What no product removes is the setup judgement. Someone has to decide which transactions represent group activity and which are internal recharges, and only a person who knows the business can make that call. The workarounds groups run before they have any of this, and where eliminations sit in the close, are covered in multi-entity accounting consolidation .
It does change the business case, though. If your close is slow because intercompany is messy, a platform moves that work to a different screen. The demo tends to imply it disappears.
Five signs you have outgrown your accounting system The layer has run out when the close stops being a finance task and becomes a data task. Five signals tend to be true by then: the close is stretching, spreadsheets have become infrastructure, intercompany volume is rising, somebody external is waiting on your numbers, and legacy systems have stopped integrating. Three of the five together usually mean the current shape has reached its limit, and the useful question becomes which layer.
The close is stretching Adding an entity should add hours to your close. In a 2025 survey of 100 finance professionals by Ledge, a close-automation vendor and so an interested party, drawn from companies of 51 employees upwards, only 18% of teams closed within one to three business days and 27% took more than seven. One vendor sample of 100 is a distribution to place yourself in rather than a benchmark to hit.
If each acquisition pushes you further down that distribution, the problem is architectural, and no amount of extra hours in close week will move it.
Spreadsheets have become infrastructure The same survey found 94% of teams use Excel somewhere in the close, and 50% named it as a key reason their close is slow. A spreadsheet that combines entity exports works for a quarter or two, then quietly becomes load bearing, which is the pattern we unpack in why spreadsheet consolidation breaks at scale .
Intercompany volume is rising Shared services, cross-entity recharges, and central purchasing all create transactions that have to be eliminated. Once they run to dozens a month, eliminations stop being something a finance lead squeezes into close week.
Somebody external is now waiting on your numbers A lender with covenant tests, a sponsor with a reporting pack, or an audit that now spans a group. External cadence removes your ability to be late, which is what turns a tolerated problem into a funded one. Internal frustration has no deadline attached to it.
Legacy systems have stopped integrating Ledge found 40% of teams named legacy systems that do not integrate as a top blocker. A desktop ledger nothing else can read is a permanent tax on every reporting cycle it survives.
What goes into the cost of changing your group accounting software? Four lines, and only one appears on the vendor quote: licences and subscriptions, implementation, internal finance time, and parallel running. Ask for all four in the same spreadsheet before the decision goes to a board.
We are not going to publish a total here, because it moves too far with entity count, data quality and how much you decide to change. The benchmarked numbers and the method for building a defensible figure are in how much post-merger integration costs . What follows is the shape of the budget.
Licences and subscriptions This is the visible number. Under per-entity pricing it also grows on its own every time you close a deal.
Implementation and configuration Configuration, chart of accounts design, data migration, and testing. On a single multi-entity platform this is a project with a partner, and the line that grows once scoping starts.
Historical data sits inside the implementation line and is the part most often waved through. How many years you bring across, and in what form, carries a real price. We cover that in data migration after an acquisition .
Internal finance time The people doing the migration are the same people doing the close. Ask your finance lead how many days a month they can give the project on top of the close, and their answer sets your delivery date, whatever the implementation plan says.
Parallel running Running old and new alongside each other doubles the work for as long as it lasts, which is why it gets cut short, and cutting it short is what makes the first close on the new system a scramble. Treat it as a transition with an end date.
The cost of not changing Against all four, set the cost of not changing: the recurring hours, the delayed board pack, and the risk premium a lender applies to numbers that arrive late.
The order to change a group finance system Chart of accounts first, then visibility, then standardisation. Run it in another order and the cost is mapping work that resurfaces the moment you try to consolidate.
Agree the group chart of accounts before anything moves. Skip it and you migrate twice: once onto the new ledger, and again when someone tries to line the accounts up. Chart of accounts mapping across acquired companies is the piece of work to do first, whichever architecture you land on.
Visibility comes next. A reporting layer takes weeks to stand up and can be switched off if the group changes shape. It also tells you where the migration money should go.
Six months of clean group numbers tells you which entities are worth the cost of standardising.
What that period gives you is specific. You learn which entities close late every month and why, where the intercompany volume sits, which is rarely where the org chart suggests, and which parts of the group chart of accounts turn out to be contested.
Those three findings change a migration scope, and usually they shrink it. A group that arrives convinced it has to move every company may find the problem sits in one or two of them, and that the rest can stay on their own ledgers for another year or two.
Standardisation comes last, and only for the entities the evidence points at. The trigger we would use is a quiet pipeline: no acquisition expected to close in the next two quarters, and a quiet you would put money on. Then a migration has somewhere to live.
If the pipeline is never quiet, that is an answer too. It means the hybrid is your architecture, so resource the reporting layer properly.
A group we scoped this summer runs Sage 50 across its main trading business and had already decided to replace it. That decision was made before we arrived, and it splits the order. Where a ledger is already committed to change, the group financial reporting has to wait for the replacement, because a consolidation built on a ledger about to be retired is a consolidation you build twice.
Anything that reads only from the systems staying put has nothing to wait for. Visibility first is still the rule here; what waits is the financial layer alone.
Can you get group reporting without replacing your accounting software? Yes, and it is usually the faster route. The reporting layer sits above the ledgers and reads from all of them, which is why it is the only one of the three layers you can change without a migration. It maps each entity's chart of accounts to one group standard, translates to a single reporting currency, and presents the result to whoever is waiting on it.
There are two ways to get that layer: buy a consolidation product, or have one built for your group. We compare those routes on cost and control in consolidation software versus bespoke dashboards , and the execution side is in the three-tier reporting consolidation framework , which sets that layer out for statutory, operational and portfolio readers.
This is the layer we build, and to be plain about it: PMI Stack does not sell or implement an accounting system, and we do not replace anybody's general ledger.
What we build is the layer above: data pulled from each entity's existing accounting system, commonly Xero, QuickBooks, Sage, DATEV or Exact, landed in a warehouse the client owns. It is mapped to one group chart of accounts and one reporting currency, defined with the client's finance team or a fractional CFO partner, then presented as a group dashboard with an assistant that answers from the same data the dashboard reads, with every figure traceable to a query rather than generated.
One caveat on coverage, since it decides whether we can help at all. A system with a modern documented API is in scope; a legacy desktop ledger with no usable API is a scoped connector build, and sometimes the honest answer is that the entity changes system before the reporting layer is worth building.
It is also built so a later ledger change stays contained: when an entity moves to a new system, the work is that entity's connector and its account mapping, not the group view above it. The full picture is in our guide to consolidated financial reporting for acquisitive companies .
If that is the problem you have today, our consolidated reporting service is where that work sits.
Frequently asked questions When is the best time to migrate an acquired company's accounting system? At a period boundary, and the useful question is whose. The entity's own year end fixes its comparatives before the move, which matters most where it still files its own statutory accounts, while the group's year end matters more once that entity reports into a group pack. Where the two differ, take the entity's, and keep the move outside its first ninety days after the deal.
Can you run multiple companies in one accounting system? Yes, though the mechanism differs by product. Multi-entity platforms hold each company as a subsidiary or business unit inside one system, with consolidation built in. Smaller cloud ledgers work one organisation per legal entity and hand the group view to a layer above them. Which of those fits depends on entity count, and the point at which a single cloud ledger stops coping is set out in where multi-entity Xero reaches its ceiling .
What should you ask a vendor about intercompany eliminations? Ask them to run one through in front of you. Have them show a transaction recorded in two companies, then watch who finds it, who writes the journal line, and who posts it, because that split differs by product: Business Central documents elimination processing as manual, while NetSuite OneWorld generates those entries once its Automated Intercompany Management feature is on.
No demo settles which transactions count as intercompany in the first place, so ask who does that setup and how long it took the last customer.
Who should own the group chart of accounts? One person at group level, with entity finance leads consulted. It is the artefact every future acquisition gets mapped into, so it needs an owner who can refuse a one-off account. A committee approves all of them.
Can a desktop ledger like Sage 50 feed a group reporting layer? Sometimes, but price it as bespoke work rather than a standard connection, because a desktop ledger usually has no documented API to read from. Where that work costs more than the entity is worth reporting on separately, change the entity's system first and connect afterwards.
What comes first, the chart of accounts or the system? The chart of accounts. Every migration you run afterwards maps into a structure that already exists. Agree it before a single entity moves.
The bottom line: name the layer, then set the date Deciding when to change your accounting system after an acquisition usually opens as a product comparison, and it gets settled by sequence: which layer is failing, and where the deal calendar leaves room. Name that layer, fix it, and let the deal pipeline set the date for anything deeper.
For most groups still actively buying, the sequence is visibility first. By the time you commit to a migration you are scoping it from six months of your own numbers, and your implementation partner is quoting against evidence.
If you want one thing to do this week, open your last board pack and mark every number that arrived by hand. Whichever layer those hands are working at is the layer to price first.
Sources 
