Written by: Luke Sobieraj, Founder & COO, Digital Colliers
Every finance team I talk to has a version of this problem. The board meets monthly. They ask roughly the same six questions each time. And someone on your team, usually the sharpest analyst, spends three or four days rebuilding the answers from scratch.
That's the recurring-question tax. It's not glamorous, it doesn't show up on a risk register, and it quietly eats a full working week every month.
The same six questions, every month
If you sit in a mid-market finance seat, you already know the shape. The questions don't change much between boards. They usually look something like this:
- Where are we against budget, by business unit
- What's driving the variance versus last month and last year
- What's the cash position and the 13-week forecast
- Which customers or segments are growing or shrinking
- What's the state of AR, DSO, and any concentration risk
- What's changed in headcount, pipeline, or committed spend
None of these are hard questions. The data exists. What's hard is that the data lives in six different places, the definitions drift between systems, and last month's pack was built as a one-off rather than a repeatable process.
So someone rebuilds it. Every month. From scratch.
What the assembly actually costs
Month-end close at mid-market finance teams typically runs 8 to 10 days, and most of that work still happens in spreadsheets with numbers pulled by hand across systems. The board pack sits on top of that, adding another three to four days of assembly once the numbers are locked.
So the real math looks like this. You've got a senior analyst or an FP&A lead, fully loaded cost somewhere north of £100k a year, spending 40 to 50% of their month on assembly work that produces the same artifact it produced last month. The output is valuable. The assembly is not.
And there's a second cost that's harder to see. Because the pack takes four days to build, you can't ask a seventh question. You can't run a scenario the CFO thought of on Tuesday. The pack is frozen the moment it's finished, and any follow-up means another half-day of manual work. The best-in-class teams close in under 5 days, and they do it because they stopped treating each month as a fresh assembly job.
Why the pattern persists
The honest answer is that nobody gets fired for running it manually. The pack goes out, the board is happy, the analyst is tired but competent. The cost is distributed and invisible.
It also persists because most attempts to fix it fail. Around 95% of enterprise AI projects don't reach production or ROI, and finance automation projects are no exception. Teams buy a tool, the tool doesn't quite fit the way their GL is structured, integration stalls, and six months later the analyst is still opening the same spreadsheet.
The teams that actually get out of this trap tend to do three things differently:
- They pick the recurring questions first, not the tooling. Six questions, defined precisely, with agreed source systems.
- They build a thin pipeline from source systems to a single semantic layer. Not a data lake. Just enough plumbing to answer the six.
- They automate the pack generation itself, so the analyst reviews and annotates instead of assembling.
Done right, this cuts the board-prep window from four days to under one. That's roughly a week a month back in the hands of your best finance person.
The cost of leaving it alone
If you do nothing, the tax compounds. Your best analyst spends another year doing assembly work instead of analysis. You lose them, or you lose the questions they would have asked if they'd had time.
And the regulatory floor keeps rising underneath you. DORA has been in force since January 2025, which means operational resilience evidence is now part of the reporting cadence for in-scope firms. The EU AI Act's high-risk obligations land in December 2027, and if any part of your automated reporting touches credit or customer decisions, that clock is already running.
The teams shipping this well in 2026 aren't the ones with the biggest budgets. They're the ones who noticed the six questions were the same every month, and treated that as an engineering problem instead of a staffing problem.