Automating your monthly reporting: what to solve first

There is a ritual that repeats in many companies during the first days of every month: someone exports data from several systems, pastes it into a spreadsheet, reconciles what doesn't add up, fixes the formatting and sends out the usual report. It costs one or several days of a person who knows how to do more valuable things, and everyone senses that "this should run itself". The instinct is sound and the decision deserves care: what has to be solved before you automate the monthly report, which parts are worth automating and which should stay human. Because there is a trap waiting: automating a bad report doesn't improve it; it just makes it arrive sooner.

The trap: speed is not quality

When a manual report has problems — figures that shift depending on who pulls them, definitions each department reads its own way, numbers nobody can defend when challenged — automation fixes none of that. It consolidates it. The report will land punctually on day one, with the same flaws as ever, but now carrying an authority it hasn't earned: what comes out of an automated process gets questioned less than what comes out of a spreadsheet, precisely because no one has touched it.

That is the specific risk of automating reporting: a manual error gets caught, because a person is watching while producing it. An automated error gets distributed. Which is why the order matters: first a report that tells the truth, then a report that produces itself. It is the same logic as not automating before you put things in order, applied to the concrete case of reporting.

What has to be solved first

Three things, and none of them is technical.

Settled definitions. Every metric in the report needs a definition that everyone involved accepts: what it includes, what it excludes, how it is calculated. As long as "sales" means one thing to the commercial team and another to finance, there is nothing to automate: there is a conversation pending. Automation forces you to pick one definition and freeze it, and that choice belongs to the business, not to programming.

Designated sources. For each figure, which system it comes from and what happens when two systems disagree. If today the reconciliation is solved by a person "knowing which one is right", that knowledge has to be made explicit before automating, because the machine won't improvise it. This is where the manual ritual, for all its flaws, hides something valuable: the person who reconciles the report every month knows exactly where the holes are. Writing down what that person fixes by hand is the best preliminary analysis there is.

An owner for the report. Automated or not, the report needs a named person responsible: someone who answers when a figure is challenged, decides when a definition must change and confirms the output is still correct. Automating without an owner orphans a process at exactly the moment it stops having someone look at it every month.

What to automate and what to keep with people

The word "report" bundles two very different jobs that are worth separating.

The first is production: extracting, consolidating, reconciling, calculating, formatting. It is mechanical, repetitive, rule-based, and it is where almost all the time goes. It is the perfect candidate for automation, and automating it takes nothing valuable away from anyone: nobody ever grew professionally by pasting cells.

The second is interpretation: explaining why the month came out the way it did, what deserves attention, what is being proposed. That doesn't get automated — not because of technical limits, but because it is exactly the part the report exists for. And here lies the real payoff of this automation, which is not just the time saved but where the time goes. The days currently spent producing the report are days not spent reading it. A report that produces itself and that nobody comments on is not an automation success; it is the same dead report, delivered on time.

One practical consequence: if, while preparing the automation, you discover sections nobody uses, don't automate them. Automating is a good moment to prune, because every block of the report acquires an explicit build cost that forces the question of whether it is worth it.

How to know it worked

Three honest checks, none of which is "the report arrives on day one":

• The figures no longer depend on who pulls them. The same number, requested through two routes, gives the same value. If there used to be versions and now there is one, the automation has done its most important job.
• Every figure can be traced. A well-built automated process leaves the path documented: which source each number comes from and what transformations it went through. That is an improvement the manual process almost never had.
• The process complains when it fails. An automated report that one month generates itself from incomplete data, without anyone noticing, is worse than the manual ritual it replaced. Silence is not confirmation: the automation must protest when something is missing, and someone must receive that protest.

And a final check, the most uncomfortable one: is anyone reading the report with the time that was freed? If the answer is no, production was never the problem.

Five questions before automating your monthly report

1. Are the definitions of every metric settled and accepted, or does each department calculate its own?
2. Do we know which source each figure comes from, and which one wins when two disagree?
3. What does the person who prepares it today fix by hand every month? Is it written down?
4. Does the report have an owner who answers for it once nobody touches it any more?
5. What will we do with the freed time: read and decide, or produce another report?

If the answers are green, automating monthly reporting is one of the most rewarding projects there is: mechanical work that disappears, figures that stop being argued over, and an improvement the whole organisation notices on day one of every month. If they are not, that is where the prior work lies — and it is usually the moment to frame it as a full data project, not as one more macro on top of the mess.