Eight companies, one deadline
A group finance team is measured on something slightly unfair: the date the pack is ready. Not the quality of the judgements inside it, not how much was learned along the way — the date. And the date is determined less by the difficulty of the accounting than by how long it takes to get everyone's numbers into a state where the accounting can start.
This page describes a group of eight: a holding company, four trading subsidiaries, two property SPVs and a dormant entity that still has a bank account. Between them, fourteen accounts across five banks, one in euros. It is a shape that recurs constantly — not a large group, but comfortably past the point where a spreadsheet per company still works.
The interesting question is not how to close it. It is where the hours go, and why two groups of identical size routinely take four days and three weeks respectively.
The shape of the problem
Work in a group close divides into two kinds with very different economics. There is work that scales with the number of entities — downloading statements, getting them into data, checking each one, chasing what is missing. And there is work that scales with the number of relationships and judgements — intercompany, allocations, currency, review.
The second kind is the actual job and it is what finance people are for. The first kind is preparation, and in most groups it consumes the majority of the calendar, which is why the close feels rushed at exactly the point where thinking would be most valuable.
Everything that follows is organised around one idea: move the first kind out of the close window entirely, so the close window contains only the second kind. That is a scheduling change more than a technology change, though it needs the data work to be fast enough to happen continuously.
Who does what
Three roles, and the split matters more than the headcount. The failure mode in most groups is not too few people — it is unclear ownership, where a statement that never arrived is technically everyone's problem and therefore nobody's.
| Role | Owns | Does not own |
|---|---|---|
| Entity owner | Statements arrive; balance check passes; local queries | Intercompany decisions, consolidation |
| Group accountant | Intercompany, allocations, currency, group view | Chasing individual banks |
| Finance lead | Review, judgement calls, sign-off, the pack | Data preparation of any kind |
The row that gets violated most is the last one. A finance lead who spends the close fixing spreadsheets is not reviewing, and the review is the only step that catches judgement errors. Protecting that boundary is worth more than most process improvements.
The monthly cycle
Written as it actually runs, with the preparation deliberately outside the close window.
Throughout the month — convert as statements arrive
Each entity owner converts and proves their own statements the week they land. Gaps get chased while the bank is easy to reach.
Day 1 — confirm completeness
Every entity, every account, present and proved. The list of exceptions is short and already assigned.
Day 2 — intercompany
Candidate pairs surfaced by amount and date; each classified as transfer or genuine charge, and the decision recorded.
Day 3 — allocations, currency, group view
Central costs allocated, the euro entity translated at stated policy, the consolidated view built from the same dataset.
Day 4 — review and sign-off
The finance lead reviews judgements rather than arithmetic, and the pack goes out with its assumptions documented.
The first line is the whole design. Everything below it assumes clean, proved, tagged data already exists — and if it does not, each subsequent day absorbs that work as well as its own, which is precisely how a four-day plan becomes three weeks.
Where the hours actually go
Measured across a month for this eight-entity group, with fourteen accounts and roughly 1,200 transactions in total. The point of the table is not the absolute numbers, which vary — it is the ratio between the two columns.
| Activity | Typed and pasted | Converted and tagged |
|---|---|---|
| Getting statements into data | 24–30 hrs | 2–3 hrs |
| Checking each entity balances | 6–8 hrs | Automatic, reviewed in 1 hr |
| Finding intercompany pairs | 4–6 hrs | 0.5 hr, then decisions |
| Spotting duplicated rows | Usually missed | Flagged automatically |
| Building the group view | 3–4 hrs each month | Re-run, under 1 hr |
| Answering follow-up questions | 2–5 hrs, unpredictable | Filters, minutes |
Two things stand out. The first line dominates everything else, which is why it is the only one worth attacking first. And the fourth line — duplicates — has no left-hand number, because in a manual process they are not usually found at all. That is not a time saving; it is a correctness difference, and it is the one that shows up in a group total.
The ROI calculation, honestly
Roughly 30 to 40 hours a month of preparation for this group. At a loaded internal cost of £30 to £40 an hour, that is £1,000 to £1,600 a month — before any software cost, and the software cost is a rounding error against it.
But the honest version of this calculation includes two things vendors usually leave out. First, the saving is not the full amount: review, exception handling and judgement remain, and they are perhaps a quarter of the total. Second, and larger, is the cost of errors found late. A misstated group figure that reaches a board pack, a lender or a set of statutory accounts costs far more than the hours, and it is the cost nobody budgets for because it is irregular.
The most defensible way to present the case internally is cycle time rather than money. Four days instead of fifteen changes what finance can do with the rest of the month, and that argument survives scrutiny in a way an hourly-rate calculation sometimes does not.
Continuous beats batch, for a specific reason
The instinct is to do the data work at period end, when everything is available. It is the wrong instinct, and not mainly because of workload smoothing.
The real reason is that data problems need time to solve and period end has none. A statement with a missing page, an account nobody mentioned, a bank login that expired — each of those needs someone to contact a bank and wait. Discovered on day one of the close, they threaten the deadline. Discovered on the eleventh of the previous month, they are a minor errand.
Converting as statements arrive also keeps the review honest. Twelve statements reviewed one at a time across a month get real attention; twelve reviewed in one sitting on a deadline get a glance. The quality difference is significant and completely invisible in any process document.
Working the exception list
With per-statement balance checks, the close does not begin with a general instruction to review everything. It begins with a list: these eleven statements proved, these three did not, and here are the rows involved.
That changes the management of the close more than it changes the work. An exception list is assignable, estimable and finishable. "Check the numbers" is none of those things, which is why it expands to fill whatever time exists.
The exceptions themselves are predictable and worth knowing by shape: a missing page, a movement split across a page break, a balance read from the wrong line, the wrong period downloaded, or an account that genuinely had no activity. Our validation page covers reading each of them.
What the board actually needs
Rarely more detail. Almost always the same few things: the group position, the movement since last month, which entity drove it, and what is different from what was expected.
All four are pivots on a tagged dataset. Entity by month answers the third; category by entity usually answers the fourth. The value is not that the pack looks better — it is that the follow-up question asked in the meeting can be answered in the meeting, which changes how much the board trusts the numbers generally.
One discipline is worth insisting on: state whether a figure is before or after intercompany elimination. Quoting one when the audience assumed the other is the most common way a group reports a number that is simultaneously correct and misleading.
What the auditor needs from the same data
Different questions, same dataset. Which entity a figure came from; which statement page it was read from; which items were eliminated and on what basis; whether each entity's cash agrees to the bank.
When those are columns in the data rather than knowledge in someone's head, audit requests become filters. When they are not, each request is a small reconstruction project, and the cumulative cost of an audit season is measured in weeks rather than days.
The thing reviewers respond to most is not accuracy — they expect that — but the ability to answer quickly and consistently. A group that can trace any figure to a document in under a minute gets treated very differently from one that has to go and look.
Adding the ninth entity
The test of any close process is what happens when a company is added, and for most groups the honest answer is that the process gets a little worse each time and nobody notices until it is obviously broken.
With a tab per company, adding an entity means restructuring the workbook, extending every formula and remembering the new tab in every summary. With an entity column it means uploading statements. The fixed work stays fixed; only the per-entity work grows, and that is the part that has been made small.
For an acquisition, do the opening-balance work before the entity joins the cycle rather than during its first close — see opening balances from bank statements. One difficult entity inside a close that otherwise runs will consume the whole close.
What changes for the team
Worth being direct, because this is usually the unspoken question. Removing data preparation does not remove people; it changes what they spend the month doing. In practice the same team covers a group that has grown, which is how most finance functions actually experience it.
The work that remains is more interesting and more demanding. Intercompany classification, allocation bases, currency policy, explaining a variance to an operations director — these need judgement and context. They are also the parts where a finance function is visibly useful, which matters for a team that has spent years being seen as the people who produce the pack late.
One genuine risk is worth naming: when preparation becomes automatic, familiarity with the underlying detail can fade. The entity owner who typed every transaction knew things that a reviewer of a clean file does not. That is a real trade, and the mitigation is the exception list — it forces attention onto precisely the rows that would have been noticed manually.
The objections you will hear internally
Changing how a close runs is a political exercise as much as a technical one, and the objections are consistent enough to prepare for. None of them are unreasonable; all of them have an answer that is better than an argument.
"Our statements are unusual." Sometimes true, and easy to settle rather than debate. Convert the most awkward statement in the group — the scanned one, the card account, the foreign bank — and look at the output. This takes ten minutes and replaces a discussion nobody can win with evidence everyone can see.
"We would need to standardise first." This is the objection that costs the most time, because it sounds responsible and postpones everything indefinitely. Working at transaction level means each entity keeps its own system and chart of accounts; only the bank data is common, and bank data is already common by construction.
"The team already knows the numbers." Usually accurate and genuinely valuable — and also the reason a departure is so disruptive. The answer is not to dismiss the knowledge but to note that an exception list surfaces the same anomalies to someone who does not have it, which is what makes the process survive a resignation.
"Is it secure?" A fair question about financial documents and worth answering precisely rather than reassuringly: uploads over TLS, EU-hosted processing, the original file deleted immediately after extraction, no archive retained, and documents never used to train models. The security page states each of those explicitly, which is more useful to a sceptical colleague than a summary.
"We tried something like this before." Often the most informative objection. Ask what broke. Template-based tools that needed configuring per bank, or products that produced a file nobody could reconcile, left a fair impression — and the useful response is to run the comparison on their statements rather than to claim things are different now.
Starting without making it a project
The version of this that fails is the one that begins with a group-wide rollout, a standardised chart of accounts and a steering meeting. The version that works starts with one entity next month.
Pick the entity with the most transactions, convert its statements as they arrive, and run its balance proof before the close begins. Compare the result with what the old process produced. If it agrees, extend to two more entities the following month; if it does not, you have learned something valuable about the old process at negligible cost.
By the third month the pattern is usually settled and the remaining entities are a formality. Total elapsed effort is a few hours a month, and at no point is there a version of the close that depends on something untested. Groups that try to change everything at once tend to revert at the first difficult period end.
Choose the first entity for difficulty rather than convenience. The instinct is to start with the simplest company, which proves nothing — the simple one was never the problem. Starting with the messiest gives a real answer to the only question that matters, and if it fails you have learned that in month one at the cost of an afternoon rather than in month six with the process already half adopted.
Keep the old process running alongside for those first months. Parallel running feels wasteful and is the cheapest insurance available: it gives a comparison on every number, it means a bad period is recoverable, and it removes the pressure to defend the new approach before there is evidence for it. Stop the parallel run when the comparison has been identical twice, not when someone decides it is time.
Finally, decide in advance what would make you stop. A specific, written condition — entities that will not prove, output that has to be corrected by hand, a close that is slower rather than faster — turns the decision into an observation instead of an argument. Changes without a stopping condition tend to continue on momentum long after the evidence has stopped supporting them, and finance is not a good place to learn that lesson slowly.
Where this stops
It gets bank data in, clean, tagged and proved. It is not consolidation software: eliminations at ledger level, equity accounting, minority interests and statutory consolidation stay in your accounting or consolidation system.
It covers cash. Receivables, payables, stock, accruals and provisions all need their own evidence, and a group whose bank position is proved still has a balance sheet to substantiate.
And it is not an archive. The original PDF is deleted immediately after extraction — processing runs on EU-hosted infrastructure and documents are never used to train AI models, with detail on the security page. Retention of the statements themselves stays where you keep it today.
Start with one entity next month
Convert a single real statement free — no registration — and compare it with what your current process produces.