The line: calculating versus interpreting
A management report consists of two kinds of work. The first is calculating: revenue per segment, margin per project, hours per employee. That is reproducible, verifiable and belongs in a BI tool, a data warehouse or, if need be, a well-built spreadsheet. A language model doing this adds a chance of error to work that can already be error-free.
The second is interpreting: why this month deviates, which three things the management team needs to know, how it differs from what we expected last month. That is language work, it currently takes the most time and it is exactly where AI adds something.
The practical rule: every number in the report comes from a source you can check; every sentence around it may be proposed.
Why that rule has to be so strict
A wrong sentence in a commentary gets noticed and corrected. A wrong number gets copied, calculated further and ends up in a decision. Moreover, a number that comes from a model is not reproducible: asking twice can give two answers, and then the report is no longer a report.
What AI does do in a report
- Describe deviations in plain language: which items deviate from the previous period and from the budget, and in what order of importance.
- Bring sources together: write a commentary that combines figures from the accounting software with context from the project system or the CRM.
- Write a draft of the commentary that a controller now types by hand — usually the biggest time sink in the whole cycle.
- Answer questions about the report, with a reference to the item the answer comes from.
What you never automate
The conclusion and the recommendation. A report that itself proposes to invest or to cut moves a management decision into a workflow. The model may state what deviates; what that means for the organization remains a conversation.
Also: forecasts based on free interpretation. A prediction should come from a model whose assumptions you can see, not from a text generator that merely sounds plausible.
When the figures are not right yet
Much reporting pain is not a reporting problem. If hours are not being logged, if projects are coded differently or if two systems use a different definition of revenue, automation makes those differences visible faster but not smaller. That can be useful — it forces a conversation — but it is not a time saving, and it is more honest to say so up front.
A workable setup
The setup that holds up in practice: the figures come entirely deterministically from the source systems and are carried over unchanged. A workflow only reads those figures, writes a draft of the commentary with references to the items, and puts it ready for the controller. The controller adjusts, approves and sends it. Every step is recorded in a log, so you can later see which commentary was changed and why.