Monthly Report: Why It Takes a Week and What Actually Shortens It

The monthly report takes days because somebody has to assemble it. Numbers are exported from several systems, lined up in a spreadsheet, checked for anything odd, and only then written up. A manager is waiting for that last part: what changed and what to do about it. Everything before it is preparation nobody asked for. This article goes through each step and says which of them a system can take over today.

Earlier in this series we listed the six areas where a team loses time to repeated work (opens in new tab) and the cost your own reports cannot show you (opens in new tab). In both articles, reporting was named alongside other areas, with nobody explaining where the days go. Here it gets the whole article: where those days go and which steps can be handed to a system.

Where the days in a monthly report actually go

Ask a finance lead how long the close takes and you get a single number. Ask what those days consist of and the picture changes.

How many days there are has been measured. APQC, which collects benchmarking data on business processes, has a separate measure for it. The count starts at the initial trial balance, meaning the first statement in which the month's accounting entries are already in place. From there to the completion of the period-end management report (opens in new tab), the median across 3,287 organisations is ten days.

Ten days from that statement, and the month being described ended earlier still. By the time the report reaches the desk, a third of the following month has passed, and every decision taken in those days was taken without it.

The five steps in the reporting cycle, and which need a person

This is how we break the reporting cycle down before proposing anything. The split is ours, and the middle column comes from conversations with companies rather than a published norm.

The first two steps hold most of the week and contain no decisions at all. The fourth step, writing the commentary, looks like the one that cannot be handed to a system. But AI can now pull every record standing behind a number, compare it with the previous month, and produce a first draft of the explanation with a link to the data. The decision about what the number means for the business stays with a person, who now starts from a draft rather than a blank page.

The same customer, written three ways

Lining the records up takes more time than anyone plans for, and a rule never quite finishes it.

Your CRM holds a company as UAB Example. The accounting system holds Example UAB. The time tracker holds Example (new). A person looks at those three and knows the answer in a second. A rule has to be told, once for every pattern, and told again when a new one appears.

An AI layer works from context. It reads the name, the registration number if there is one, the address, and what that company has bought before, then returns a match along with how sure it is. When the system is not sure enough, the case goes to a person with the candidates already on screen. When it is sure enough, the record lines up on its own and nobody sees it. How sure it has to be is your decision.

That is what separates a report ready on the second working day from one that waits for somebody with a free afternoon.

Asking the report a question in plain language

A finished report produces questions immediately. Which client drove the margin down. Whether the overtime sits in one team or across three. Each of those means opening the source data again, which is why the answer usually arrives a day later.

AI already lets people ask in their own words, without writing database queries, and this is where the limit is worth stating openly. No system yet does it as accurately as a person. On the BIRD benchmark, which uses real company databases rather than teaching examples, data engineers answer 92.96% of questions correctly and the strongest system 82.39% (opens in new tab).

The gap is about ten percentage points, and it tells you how to build such a system. An answer in seconds is worth having. An answer nobody can check is worth nothing, so the only useful version is one that shows the query it ran and the rows it counted. A person then confirms the answer in a minute rather than rebuilding it in an hour.

What the analytics layer changed for us

We built the analytics layer for ourselves first, before offering anything like it to anyone else. In our own systems, access to business figures became three times faster and overtime costs fell by 30%.

The second number was the bigger surprise. The overtime built up at month end, when the data had to be gathered in a few days. Once that gathering moved to the system, the hours went back to ordinary work.

When a faster monthly report will not help

Sometimes the reporting cycle is the wrong thing to work on. Three signs point to that, and the first is the common one.

The month is not closed yet. If supplier invoices are still arriving on day eight, the report cannot be finished any earlier, however fast the numbers are gathered. The real constraint is the document queue, and that is a separate project with a separate payback.

Nobody acts on the report. A report produced because it has always been produced will get faster and stay unread. It is worth asking which decision changed because of it in the last six months.

Two departments disagree about the number. A system will show that disagreement on day two instead of day ten, which is useful. But the disagreement itself will not go away. Somebody still has to decide which definition of revenue the company uses, and no technology makes that call.

Where to start

Start with a half-hour conversation. We go through your reporting cycle, work out which of the five steps costs the most, and tell you what can realistically be handed to a system, how long it would take and what it would cost. We then build and deploy that system ourselves.

Get in touch (opens in new tab) and we will find a time.