One close, many companies
A single-company reconciliation has one question to answer: does the ledger agree with the bank? A group close has to answer that question once per entity, and then answer a second one on top — does the consolidated picture hold together once the companies inside it have been trading with each other. Those two questions pull in opposite directions. The first wants everything kept separate and provable. The second wants everything in one place.
Most groups resolve that tension with a spreadsheet and a lot of copying. Each entity's statements get converted or typed up on their own, then pasted into a consolidation tab, and by the time anyone notices a problem the trail back to the original page is gone. The fix is not a better spreadsheet. It is producing the data once, with the entity recorded on every row, so separating and combining are both just filters.
This page covers what changes when you reconcile several companies instead of one: how the entity column earns its keep, how intercompany transfers and duplicate rows are surfaced rather than silently absorbed, why the balance check has to stay per statement, and where the honest limits of a conversion tool sit in a statutory close.
Why a group is harder than the sum of its companies
The difficulty is not volume. Ten entities are not ten times one entity — they are one entity plus a set of relationships, and it is the relationships that cost the time. Money moves between the companies. Costs are paid centrally and recharged. One entity banks in a different currency. Two were acquired mid-year and arrived with balances someone else prepared.
Each of those creates the same failure mode: a number that is correct in one place and wrong in another, with nothing in the data to explain the difference. A management charge from the parent is revenue in one company and cost in another. A cash sweep looks like a large unexplained withdrawal on a subsidiary's statement and a large unexplained receipt at the top. Neither is an error. Both look exactly like an error until you can see both sides at once.
That is the case for putting every entity's transactions into one dataset before doing any reconciling. Not to merge the companies — they must stay separable — but so that the second side of every two-sided movement is present when you go looking for it. A pair that spans two spreadsheets is invisible. A pair inside one table is a sort away.
The entity column does most of the work
One extra column changes what the dataset can do. Every extracted row carries the file and the account it came from, which in practice means the entity: this statement is Holdings Ltd's current account, that one is the trading subsidiary's euro account. Nothing is merged away, so the group table can always be filtered back to a single company without re-running anything.
It sounds trivial and it removes a whole class of month-end argument. When a figure in the group pack is questioned, the answer is a filter, not a reconstruction. When local management wants their own numbers, they get a file that contains only their rows and nothing else. And when the auditor asks where a consolidated total came from, every component traces to a statement page rather than to a cell someone typed.
| Column | Where it comes from | What it lets you do |
|---|---|---|
| Entity / source file | The statement the row was read from | Filter the group table down to one company |
| Account | Statement header | Separate current, deposit and currency accounts |
| Date | Transaction line, normalised | Sort and cut by period across all entities |
| Description | Joined from multiple lines | Search a payment reference months later |
| Amount | Single signed value | Sum anything without merging debit and credit |
| Balance | Running balance | Prove each statement on its own terms |
| Currency | Statement or line, where stated | Stop accidental addition across currencies |
The same principle applies to the two columns the bank never gives you — a category and a counterparty reference. Added once and reused on recurring descriptions, they turn a list of movements into something that answers questions. Our transaction categorisation page covers that side in depth.
How it works, end to end
The flow is the same whether you are closing one company or twelve. The difference is that the upload step takes every entity at once instead of one at a time, and the review step is organised by entity.
1 — Upload every entity's statements
Drag in the PDFs for all companies and accounts, digital or scanned, from any bank. Nothing needs sorting first.
2 — AI reads each statement
Fields are recognised by meaning, so different banks and layouts produce the same columns — with the source file recorded per row.
3 — Check per statement, then across
Each statement is proved against its own closing balance; intercompany candidates and duplicate rows are flagged across the set.
4 — Export both views
One combined file for the group pack, or filter by entity for local books — from the same extraction, so they cannot drift.
Intercompany transfers, made visible
An intercompany movement is the defining feature of a group close and the single biggest source of a total that is quietly wrong. Money leaves one company and arrives at another. Both statements record it honestly. Add the two entities together without doing anything about it and the group has apparently both spent and received money that never left the group at all.
Because every entity's rows sit in one dataset with the entity tagged, the two sides of that movement are findable: the same amount, with opposite signs, on two different entities, within a day or two of each other. Those pairs are surfaced as candidates. What they are not is automatically removed — and that restraint is deliberate. A £50,000 transfer between two subsidiaries and a genuine £50,000 payment from one to the other for services look identical in the bank data. Only you know which is which.
Practically, the useful output is a flag rather than a deletion. Keep the flag as a column and you can produce both numbers whenever you need them: the raw sum of all entities, and the sum after elimination. If the two are ever quoted without saying which is which, someone will eventually make a decision on the wrong one.
| Pattern | How it looks in the data | What to check |
|---|---|---|
| Cash sweep to parent | Large round amount out, same amount in next day | Whether it is funding or a real charge |
| Management recharge | Regular monthly amount, both sides | That an invoice exists behind it |
| Loan drawdown | One-off large amount, no matching invoice | That it is on the intercompany loan account |
| Cost paid centrally | One entity pays a third party for another | Which entity the cost belongs to |
| Netting settlement | One payment settling several balances | That it is split back to the right entities |
The deeper problem — pairs that should match and never quite do — is worth its own treatment. We wrote one: intercompany transactions that never match.
Duplicate rows in a group close
Duplicates arrive in two ways when several people prepare files. The familiar one is the overlapping period: the closing days of one statement repeat at the start of the next, so a year assembled from twelve statements contains a handful of movements twice. The one specific to groups is the same PDF filed under two entities, which happens whenever a shared drive has a folder per company and someone is unsure which one a statement belongs to.
Both inflate totals, and both are hard to spot by eye precisely because a duplicated row looks completely normal. Detection compares date, amount and description across the whole set rather than within a single file, which is what catches the second kind — a row duplicated across two entities would be invisible to any check that only looks inside one statement at a time.
What you do about a flagged duplicate is a judgement call, and there is one case that regularly trips people up: two genuinely identical payments on the same day. A company paying the same supplier the same amount twice is unusual but real, and deleting the second one because a tool flagged it turns a correct record into a wrong one. The flag is a prompt to look, not an instruction.
Every statement proved on its own terms
This is the part that must not be consolidated away. Each statement carries its own arithmetic: opening balance, plus the movements it lists, equals the closing balance it declares. That check runs per statement, and it is the only thing that tells you extraction was complete rather than merely plausible — a missing page, a movement split across a page break, or a balance read from the wrong line all show up here and nowhere else.
A group-level total cannot do this job. If ten entities are added together and the sum looks reasonable, that says nothing about any one of them: two offsetting errors in different companies produce a perfectly reasonable group figure. The value of the per-statement check is that it points at an entity, so the review that follows is bounded instead of open-ended.
Operationally this changes what a close feels like. Instead of a single moment at the end where the consolidated numbers either work or do not, you get a list at the start: these eight entities are clean, these two need looking at, and here are the rows involved. Everything after that is bounded work. Our statement validation page covers the checks themselves in more detail.
When entities bank in different currencies
A group with a foreign subsidiary has at least two currencies in the same close, and the dangerous moment is the one where they get added together without anyone deciding to. A column of numbers does not know that some are euros and some are pounds, and a spreadsheet will happily total them.
The defence is to carry currency as data. It is captured per statement, and per row where the document states it, so a mixed dataset stays honestly mixed. A group total in one currency then becomes something you build deliberately — at a rate you have chosen and can name — rather than something that appeared because a formula reached across a filter.
The translation itself stays outside this step, and that is the right place for it. Which rate applies to which balance is an accounting policy question with real consequences: closing rate for balance sheet items, average for the period on the income statement, historical for equity. A conversion tool that quietly picked one for you would be making a policy decision it has no business making.
Opening balances you can defend
Every entity that joins a group mid-year, and every set of books inherited from a previous accountant, arrives with the same question: is the starting position right? It is asked less often than it should be, because checking it feels like re-doing someone else's work. It is also the number every subsequent figure sits on top of.
The statement itself gives you the cheapest possible anchor. A bank's stated opening balance on a given date is a third-party assertion, not a handover spreadsheet, and reconciling to it establishes a defensible starting point in an afternoon. From there the movements are arithmetic. Our dedicated page on opening balances from bank statements works through the method, including what to do when the first statement you can get starts later than the date you need.
For an acquisition, it is worth converting a few months either side of completion rather than only the period afterwards. The pre-completion movements are what explain the balances you inherited, and they are far easier to obtain while the relationship with the previous owner is still cooperative than a year later when a question finally surfaces.
Different charts of accounts, one dataset
Groups rarely have a single chart of accounts, especially after acquisitions. A common instinct is to solve that before anything else, and it is usually the wrong order — harmonising a chart is a project, and the close is next week.
Working at transaction level sidesteps the problem. The conversion produces movements, not journal entries: a date, a description, an amount, an entity. Mapping those to each entity's own account codes happens afterwards, in each accounting system, exactly as it does today. No shared chart is required for the extraction to be useful.
What does help is a consistent category column applied across the group — a small, stable vocabulary like payroll, rent, utilities, bank charges, intercompany. It is not a chart of accounts and should not try to be. It exists so that a group-level question can be answered before the mapping work is done, which in practice is when it gets asked.
The consolidation sheet, without the copying
Most groups already have a consolidation workbook, and it usually works. What makes it fragile is not its logic but its inputs: a tab per entity, filled by hand, refilled every month, with the link back to the source living only in whoever built it.
A single tagged export changes the shape of that workbook. One table holds every entity's movements; a pivot gives you entity by month, or category by entity, without a tab per company. Adding a thirteenth entity means uploading its statements, not restructuring the file. And because the entity column is data rather than the name of a worksheet, a mistake cannot hide by being pasted into the wrong tab.
One habit is worth keeping from the old way: put totals somewhere other than the bottom of the data table. A total row inside the table gets caught by filters, imported as if it were a transaction, and eventually double-counted by someone who did not build the file. Use SUBTOTAL, or keep summaries on a separate sheet.
What the auditor will ask for
Audit requests in a group are predictable in shape even when they are unpredictable in detail. Show us how this consolidated figure was built. Show us the intercompany eliminations. Show us that this entity's bank balance agrees to the bank. Show us the movements on this account between these dates.
Each of those is a filter on a tagged dataset and a slow reconstruction on a folder of PDFs. The difference is not whether you can answer — you can either way — but whether answering costs an hour or a week, and whether the answer arrives with its provenance attached. A figure that traces to a specific statement page carries its own evidence.
Keep two things and most requests become routine: the source column, so any number can be walked back to a document, and the intercompany flag, so the elimination question has an answer that does not depend on someone's memory of what happened in March. Neither costs anything to maintain if they are produced by the extraction rather than added afterwards.
A realistic close timeline
It is worth being concrete about where the time actually goes, because the saving is not evenly distributed. Converting statements is fast either way once you have a tool; what changes is everything downstream of it.
| Stage | Spreadsheet-and-typing | Tagged dataset |
|---|---|---|
| Getting statements into data | Hours per entity | Minutes for the whole group |
| Knowing which entity is clean | Only at the end | Before review starts |
| Finding intercompany pairs | Manual, across files | A sort on flagged candidates |
| Spotting duplicated rows | Usually missed | Flagged across the whole set |
| Rebuilding the group table | Re-paste every month | Re-run the same export |
| Answering an audit query | Reconstruct from PDFs | Filter the source column |
The pattern is that the fixed costs stay fixed while the per-entity costs stop scaling. That is why the case gets stronger with every company added, and why groups that grew by acquisition feel the difference most sharply.
Five mistakes that make a group close painful
Consolidating before proving each entity. A plausible group total hides offsetting errors. Prove every statement individually first; the group number is then a consequence rather than a hope.
Eliminating intercompany automatically. A transfer and a genuine charge between group companies look identical in bank data. Flag them, decide deliberately, and keep the flag so both totals stay available.
A tab per entity instead of a column. Worksheets cannot be filtered, sorted or pivoted across. The moment a question spans two companies, a tab-per-entity workbook forces manual work that a column would have made trivial.
Adding currencies without meaning to. Keep currency as a column, and build any cross-currency total deliberately at a stated rate. A total that quietly spans two currencies is wrong in a way nobody notices until it is quoted.
Losing the source. Once a number cannot be traced to a statement page, it can only be defended by assertion. Keeping the source column costs nothing and is the difference between answering an audit query and re-performing the work.
Automating a recurring group close
A group close is the same work every month on different documents, which makes it a good candidate for automation once the manual version is stable. The API returns the same structured data as JSON, so statements that arrive on a schedule can be converted and tagged without anyone opening a preview.
The sensible sequence is to automate the boring half first. Extraction, entity tagging, balance checking and duplicate detection are mechanical and benefit immediately. Intercompany decisions and anything touching policy should stay manual for longer than feels necessary, because those are the steps where a wrong automated answer is expensive and hard to notice.
A useful discipline for automated runs is to treat a failed balance check as a stop rather than a warning. In an automated pipeline nobody is looking at the screen, so a statement that does not prove should raise something a person will see rather than flow onward into a group pack.
Who this is for
Group finance teams closing several companies to the same deadline, accountancy practices with clients that own more than one entity, property and investment structures with an SPV per asset, and any business that grew by acquisition and now runs more bank accounts than it has people to reconcile them.
Group finance teams
One close across every subsidiary, with each balance provable on its own.
Accountancy practices
Clients with several companies, handled in one pass rather than one at a time.
Property and SPV structures
An entity per asset, dozens of accounts, the same routine every month.
Post-acquisition finance
Inherited books and opening balances anchored to what the bank says.
If your group is one company with several accounts rather than several legal entities, the same tagging applies at account level and most of this page still holds — the intercompany section is the part you can skip. Our group finance use case works through a full monthly cycle.
What this is not
Worth stating plainly, because the boundary matters more in a statutory group close than almost anywhere else. FlowParse converts statements into verified data. It is not consolidation software: eliminations, equity accounting, minority interests and statutory consolidation stay in your accounting or consolidation system, where they belong.
It is not an archive and not a compliant document-retention system. The original PDF is deleted immediately after extraction, so the statements themselves — and whatever retention obligations attach to them — stay wherever you keep them today. The export you get is a working document, not a substitute for the original.
And it does not decide accounting treatment. Whether a movement is a loan or a charge, which rate translates a balance, whether an entity consolidates at all — none of that is visible in bank data, and a tool that guessed would be guessing about the numbers that matter most.
Try it on one entity first
Convert a single real statement — no registration — and check the balance and the columns before committing a whole close.