Overview
Closing one company is a sequence. Closing a group is a sequence with a dependency graph laid over it, because the companies transact with each other and some of them cannot be finished until others are. That is the whole difficulty, and almost every problem in a group close is a version of it.
The approach in this guide is deliberately ordered: prove things that stand alone before touching anything that depends on two entities at once. Bank data is the natural starting point because a bank statement is a third-party record — it is the one place where a number is not something the group asserted about itself.
The guide assumes you have PDF statements rather than a feed, which is the usual situation for at least some accounts in most groups. If your statements come in as data already, skip step two and the rest still applies.
What actually changes when there is more than one company
Four things, and it is worth naming them because each one has its own step later.
Money moves inside the group. Transfers, recharges, loans and central payments all create two records of one event, in two sets of books, that must agree and often do not.
Totals mean two different things. The sum of the entities and the consolidated figure differ by the eliminations, and quoting one when the audience assumed the other is a real and common error.
Errors hide behind each other. Two mistakes in different companies can offset, so a group total that looks sensible proves nothing about any individual entity.
The work is not evenly distributed. One entity is usually where the complexity lives — the one with the foreign currency, the acquisition, or the central payments — and planning as if all entities are equal makes the close look on track until it suddenly is not.
Before you start
Five things make the difference between a close that runs and one that stalls, and all five are cheap to arrange in advance.
| Have ready | Why it matters |
|---|---|
| A list of every entity and account | The most common group error is a forgotten account, not a wrong number |
| Agreed period end for all entities | Different cut-offs make intercompany pairs impossible to match |
| Access to every bank, or the statements | Chasing access during the close is what turns days into weeks |
| A named owner per entity | Review only happens when someone specific is responsible for it |
| Last period's closing balances | They are this period's opening balances and the anchor for everything |
The entity and account list deserves more attention than it usually gets. Groups accumulate accounts — a dormant one from an old acquisition, a currency account opened for a single supplier, a card account nobody thinks of as a bank account. Every one of them can hold a movement that matters, and none of them will announce themselves.
The seven steps
In order. The ordering is the method: each step depends only on things already proved, which is what stops a late discovery from invalidating work already done.
1 · Collect every entity's statements
Gather statements covering the same period for every company and every account. Download them as PDFs from each bank rather than screenshots or partial exports — a statement downloaded a page at a time is the single most common cause of a close that will not prove, and it looks complete until the arithmetic disagrees.
Record what is outstanding as you go. A group view that is explicitly missing one company is useful information; one that silently omits it is a report that will be acted on and is wrong.
2 · Convert and tag in one pass
Convert everything together rather than company by company. The reason is not speed — it is that the second side of every intercompany movement needs to be in the same dataset for step four to be possible at all. A pair that spans two files is invisible.
Each transaction should come out carrying the file and account it was read from, which in practice identifies the entity. That provenance is what lets the same dataset serve both the group view and each company's local books; entity tagging covers the mechanics.
3 · Prove each entity before looking at the group
For every statement: opening balance, plus the sum of its movements, must equal the closing balance the statement declares. This is arithmetic, it takes seconds per statement automatically, and it is the only check that tells you extraction was complete rather than merely plausible.
Resist the temptation to look at group totals first. A consolidated figure cannot fail this test in a useful way, because offsetting errors in two companies produce a perfectly reasonable group number. Per-statement proof points at an entity, which makes the review that follows bounded work instead of an open-ended hunt.
When a statement does not prove, the causes are predictable: a missing page, a movement split across a page break, a balance read from the wrong line, or the wrong period downloaded. Our validation page covers reading the difference.
4 · Find the intercompany movements
Now that everything is in one dataset with entity tags, look for equal amounts with opposite signs on two different entities within a few days of each other. Sort by absolute amount and the pairs line up next to each other; the ones that matter are usually round numbers, which makes them easier still.
Expect a small number of near-misses that are genuine pairs — a transfer that arrived the next working day, or one where a payment charge was deducted so the amounts differ by a few units. Widen the date window before widening the amount tolerance, because dates drift far more often than amounts do.
5 · Eliminate deliberately, and record why
Each flagged pair is one of two things: an internal transfer, which should be eliminated on consolidation, or a genuine charge between group companies, which should not. Bank data cannot tell them apart — both are money leaving one company and arriving at another — so this step is a decision, not a calculation.
Record the decision as a column rather than by deleting rows. Keeping the flag means you can produce both figures at any time: the sum of all entities, and the consolidated total after elimination. Deleting rows means the group file can no longer be reconciled back to the entities that fed it, which is exactly the reconciliation an auditor will ask for.
6 · Translate currencies as an explicit step
If any entity banks in another currency, keep the currency as a column throughout so nothing gets added across currencies by accident, then translate as a deliberate, documented step. Which rate applies where is policy — typically closing rate for balance sheet items, average for the period on the income statement, historical for equity — and it should be written down rather than remembered.
The failure to avoid here is subtle: a formula that reaches across a filter and totals two currencies produces a number that is wrong by an amount nobody can estimate, and it looks entirely normal. Keeping currency visible is the cheapest protection against it.
7 · Build the group view from the same data
The consolidated view should be a pivot on the tagged dataset, not a new file assembled by copying. Entity by month, category by entity, with and without eliminations — all views of one table.
This is what makes the group pack defensible. Every figure in it is a sum of rows, every row names its source file, and every source file is a statement. When someone asks where a number came from three months later, the answer is a filter rather than a reconstruction.
Worked example: a group of three
A holding company, a trading subsidiary and a property SPV. The holding company pays central costs and recharges them; the SPV receives rent and sweeps surplus cash upward. One month, simplified to the movements that matter.
| Entity | Movement | Amount | Treatment |
|---|---|---|---|
| Trading Ltd | Customer receipts | +180,000 | Group revenue — keep |
| Trading Ltd | Management charge to Holdings | −12,000 | Intercompany — eliminate |
| Holdings Ltd | Management charge from Trading | +12,000 | Intercompany — eliminate |
| Holdings Ltd | Group insurance paid centrally | −9,000 | Real cost — keep, allocate |
| Property SPV | Rent received | +26,000 | Group revenue — keep |
| Property SPV | Cash sweep to Holdings | −20,000 | Intercompany — eliminate |
| Holdings Ltd | Cash sweep from SPV | +20,000 | Intercompany — eliminate |
Added naively, the group appears to have received 238,000. After eliminating the two intercompany pairs — the 12,000 recharge and the 20,000 sweep — actual external income is 206,000. The 32,000 difference never left the group, and a report quoting the larger figure would be overstating turnover by more than 15%.
Note the insurance line, which is the one that catches people. It is paid by Holdings but benefits all three companies. It is a real external cost so it is not eliminated — but leaving it entirely in Holdings makes that company look loss-making and the others more profitable than they are. Allocation is a separate decision from elimination, and conflating the two is a recurring source of confusion in group reporting.
A close calendar that holds
The single biggest determinant of how long a group close takes is not headcount or entity count — it is whether data is converted as it arrives or assembled at the end. A calendar built around continuous conversion turns the close into a review.
| When | What happens | Who |
|---|---|---|
| As statements arrive | Convert, tag, prove — one entity at a time | Entity owner |
| Day 1 | Confirm every account is present; chase gaps | Group accountant |
| Day 1–2 | Review failed balance checks by entity | Entity owner |
| Day 2 | Identify and classify intercompany pairs | Group accountant |
| Day 3 | Currency translation; allocation of central costs | Group accountant |
| Day 3 | Build group view; reconcile back to entity totals | Group accountant |
| Day 4 | Review pack; document eliminations and judgements | Finance lead |
The row that does the most work is the first one. Everything below it assumes the data already exists; if it does not, every subsequent day absorbs the conversion work as well as its own, which is how a four-day plan becomes three weeks.
Two scheduling details are worth copying. Put the completeness check on day one rather than day two: discovering on the final day that an account was never included is the single most expensive thing that happens in a close, and it is entirely preventable by asking the question first. And keep day four genuinely free of preparation work. A review day that is quietly absorbed by fixing things is not a review day, and the errors it was meant to catch are precisely the ones that survive into the pack.
The calendar also needs an explicit answer for the entity that is late, agreed before it happens rather than negotiated while it does. Deciding in advance that the group publishes on day four with any missing entity flagged removes the recurring argument about whether to wait, and it puts the cost of lateness where it belongs — visible, with the name of the company attached, in front of the people who can change it.
For groups reporting quarterly rather than monthly, run this cycle monthly anyway and publish quarterly. The work is far cheaper in monthly pieces, and a quarterly close built on three already-proved months is a summary rather than a project. Groups that only touch the numbers quarterly spend most of each close rediscovering what happened in the first of the three months.
What to do when an entity will not prove
Every close has one. A statement whose arithmetic does not agree, and a deadline that does not care. The instinct is to keep looking at the numbers until they resolve, and that is usually the slowest available route — the causes are a short, finite list, and working through them in order is faster than staring.
First, check completeness. Count the pages of the PDF and check the page numbering printed on the statement itself. A document downloaded a page at a time, or printed from a screen view, is missing rows that nothing in the file will tell you about. This is the most common cause by a wide margin and takes thirty seconds to rule out.
Second, check the boundaries.Compare the opening balance against the previous statement's closing balance. If they differ, the problem is not in this period at all — a statement is missing between them, or the wrong period was downloaded. Chasing rows inside a statement whose opening balance is already wrong is wasted effort.
Third, look at the page breaks. A transaction that spans a page boundary, or a running balance that restarts on a new page, is where extraction most often loses a row. The difference will usually equal a single visible transaction, which makes it identifiable by amount.
Fourth, consider the account type. Card accounts, merchant accounts and some payment institutions do not publish a running balance at all, so an arithmetic proof against a closing balance is not available in the same form. That is not a failure to fix; it is a different check — total credits less total debits against the stated movement for the period.
If none of those explain it, stop and escalate rather than adjusting. A difference forced to zero with a balancing entry is worse than an unresolved one, because it removes the evidence that a question exists. Publish the group view with that entity flagged and its difference quantified; a named, sized problem is something a reviewer can accept, and a silent plug is not.
Documenting the judgements, not just the numbers
A group close produces two outputs. The obvious one is the pack. The one that determines how much the next close costs is the record of what was decided and why — and it is almost always the one that gets skipped, because at the moment of deciding the reasoning feels self-evident.
It is not self-evident three months later, and it is certainly not self-evident to whoever inherits the process. The questions that come back are always the same shape: why was this treated as a transfer rather than a charge, which rate was used to translate this balance, on what basis were the central costs split, why does this entity's difference remain open. Each of those took a minute to decide and takes an afternoon to reconstruct.
Four things are worth writing down every period, and none of them need more than a line. Which intercompany pairs were eliminated and on what basis. Which rate was applied to which balance. How central costs were allocated and why that basis. Any difference left open, with its size and the reason it is acceptable.
| Decision | Record | Question it prevents |
|---|---|---|
| Intercompany elimination | Pair, amount, transfer or charge | Why does group revenue differ from the sum of entities |
| Currency translation | Rate, source, which balances | Why does this subsidiary move when it did not trade |
| Cost allocation | Basis, entities, amount | Why is this company suddenly loss-making |
| Open difference | Entity, size, reason accepted | Was this known, or was it missed |
| Excluded entity | Which, why, expected date | Does this pack cover the whole group |
The compounding effect is what makes this worth insisting on. A group that documents decisions has a close that gets cheaper each period, because settled questions stay settled. A group that does not re-litigates the same five judgements every quarter, and loses them entirely whenever someone leaves.
Keep it with the data, not in a separate system. A one-page note stored alongside the converted statements is found by whoever needs it; the same note in an email thread is not.
A short note on who signs off what. In groups small enough that one person does most of the close, sign-off tends to be implicit — the pack went out, therefore it was approved. That works until something is wrong, at which point nobody can say what was reviewed and what was merely produced. Recording the reviewer alongside the decisions costs a line and makes the distinction real.
The same applies to the entities that were not fully closed. Every group has periods where an entity is estimated rather than proved, usually for a good reason — statements not yet available, an account being migrated, a dormant company nobody chased. Estimated is a legitimate status; the problem is only ever that it looked like proved. Marking it explicitly in the pack costs nothing and is the difference between a limitation and a misstatement.
Common mistakes
Consolidating before proving. A plausible group total conceals offsetting errors. Prove every statement individually first and the group figure becomes a consequence rather than a hope.
Eliminating automatically. Transfers and genuine intercompany charges are indistinguishable in bank data. Flag, classify, record — and keep both totals available.
Deleting eliminated rows. The group file then cannot be reconciled back to the entities, which is the first reconciliation any reviewer will ask for.
Confusing elimination with allocation. A cost paid centrally is not intercompany; it is a real cost sitting in the wrong company. Different problem, different fix.
Different cut-offs per entity. If one company closes on the 30th and another on the 31st, intercompany pairs will not match and the difference will be hunted rather than explained.
Holding the whole group for one late entity. Close what you can and state clearly what is excluded. Silence about an omission is far more dangerous than the omission.
Best practices worth adopting once
Convert continuously. Statements converted the week they arrive spread the work and surface problems while there is still time to solve them.
Write the policies down. Translation rates, allocation bases and elimination rules should be a short document, not institutional memory. Groups lose more time to re-deciding settled questions than to deciding new ones.
Keep the source column forever. It costs nothing and converts most future audit requests from projects into filters.
Give every entity a named owner. Review that belongs to everyone belongs to no one, and the per-statement check is only valuable if someone acts on the failures.
Agree intercompany conventions with the other side. Most unmatched pairs come from two companies describing the same event differently — a reference format agreed once removes the problem permanently. That is the subject of this article.
Start with step two
Convert one entity's statement free — no registration — and see the tagged, balance-checked output the rest of this process depends on.