Consolidating when an entity is acquired, closed or migrated mid-year

An entity acquired mid-year is included in the group P&L only from the date control passed, while its balance sheet is included in full at the reporting date — and an entity closed or migrated mid-year has to keep contributing its history even after it stops trading. This is the part of consolidation that spreadsheets handle worst, because a workbook built around a fixed list of entities quietly breaks the moment that list changes.

When do you start including an acquired entity?

You include an acquired entity’s results from the date you obtained control, not from the start of the financial year. Under AASB 10 — converged with IFRS 10 — consolidation runs from the date control passes, so a company acquired on 1 March contributes four months of trading to a 30 June year end, not twelve.

The balance sheet is different. Because a balance sheet is a position at a point in time, the acquired entity’s assets and liabilities are included in full at the reporting date. There is no pro-rating on the balance sheet.

This asymmetry is where the first errors appear. Someone pulls a full-year P&L for the acquired entity from Xero, because that is what Xero gives you, and the group’s revenue is overstated by eight months of pre-acquisition trading. Xero has no concept of when you acquired the organisation; it will happily report from the beginning of its own financial year.

The practical control is to hold an inclusion-from date per entity in your reporting layer and enforce it, rather than relying on whoever runs the consolidation to remember which entities joined part-way through.

What happens to the comparatives?

Comparatives are not restated for an acquisition. Last year’s group figures show the group as it was, without the acquired entity, and this year’s show it from the acquisition date. That means the year-on-year movement contains both real trading performance and the arrival of a new business, mixed together.

This is correct under the standards and is also the single most misleading thing in most group reports. A group P&L showing revenue up forty percent, where twenty-five points of that came from an acquisition, tells a board almost nothing about how the existing business performed.

The fix is presentational rather than technical: show the movement split between the acquisition’s contribution and the like-for-like change in the entities present in both periods. If your reporting can expand a group movement to the entities that drove it, you can produce that split in minutes. If it cannot, you will be reconstructing it by hand every time someone asks.

What happens when an entity is closed or stops trading?

A closed entity must keep its history and stay selectable for reporting, while no longer syncing new data. Those are two separate behaviours and conflating them is what causes the damage.

The instinct when a company stops trading is to disconnect it. If disconnection also removes its history, every prior-period group figure that included it changes retrospectively — last year’s consolidated revenue drops, the board pack you circulated no longer reproduces, and nothing tells you why. You have silently restated the past by doing housekeeping.

What you want is a lifecycle state: the entity is marked closed or dormant, stops pulling new transactions, and remains fully available for any period in which it traded. Group reports for those periods continue to include it and continue to reproduce exactly.

The same applies to dormant entities that still exist but have no activity. They cost nothing to leave connected, and disconnecting them buys you a tidier list at the price of your comparatives.

What about migrating an entity to a new Xero organisation?

A mid-year migration splits one business across two Xero organisations, and the group has to treat them as one continuous entity or the year makes no sense. This happens more often than people expect — a change of Xero country edition, a restructure, a decision to start a clean file after years of accumulated mess.

The result is an entity whose first five months sit in one organisation and whose remaining seven sit in another. Consolidate naively and you get two entities, each with a partial year, and any year-on-year comparison compares half a business against a whole one.

Handle it by linking the two organisations as predecessor and successor, so the group treats them as one reporting entity across the boundary. The old organisation stops syncing at the migration date and keeps its history; the new one picks up from there. Reporting groups — named sets of entities you can report on together — are the practical mechanism, since the closed company and its successor can be grouped and reported as a single line.

Watch the boundary period itself. Migrations rarely happen cleanly on a month end, and transactions posted to the old organisation after cutover, or dated before it in the new one, will double-count or vanish depending on which way the error runs. Reconciling the migration month against both files before you rely on the group numbers is worth the hour it takes.

Why does a disposal need care even after the entity is gone?

Because a disposed foreign operation triggers a reclassification you will not see coming. Any accumulated foreign currency translation reserve relating to that operation is reclassified from equity into profit or loss on disposal — a balance that has sat quietly in equity for years suddenly appears in the income statement in the year you sell.

The group P&L also includes the disposed entity’s results up to the disposal date and nothing after, which is the mirror image of the acquisition treatment.

If you are disposing of an entity that traded in a different currency, check the translation reserve before you finalise the year. The mechanics are covered in the foreign currency guide, and the reclassification is one of the more commonly missed adjustments in owner-managed groups.

What can group reporting not fix?

Group reporting handles inclusion periods, comparatives and continuity. It does not perform acquisition accounting, and no consolidation tool built on top of Xero will.

Purchase price allocation, recognition of identifiable intangibles, goodwill and its subsequent impairment testing, non-controlling interests where you own less than all of a subsidiary — these are judgements made once, usually with your accountant or auditor, and posted as entries. A reporting layer consumes the result; it cannot derive it. If a tool claims to automate acquisition accounting from Xero data, be sceptical, because the inputs simply are not in the ledger.

It also cannot tell you the date control passed. That is a legal and commercial fact from the transaction documents, and it has to be entered by someone who knows it.

Why do these changes break spreadsheets specifically?

Spreadsheet consolidations assume a stable entity list, and every structural change violates that assumption. A workbook with a tab per entity and a summary sheet of hard-coded ranges works perfectly until an entity is added, at which point the summary silently omits it, or removed, at which point half the formulas return errors and someone repairs them under time pressure.

The failure is rarely dramatic. It is a total that stops including one company, in a workbook that has been reliable for two years, discovered a quarter later. This is the same class of problem as posting entries after a period was considered closed — the report you circulated was wrong and nothing told you.

If your group’s structure changes more than about once a year, the maintenance cost of keeping a spreadsheet correct across those changes is usually where the case for a reporting layer actually sits — not in the time saved each month, which is the argument every vendor leads with.