Creating automated reports: key figures, sources and AI summary

On the Monday before the monthly meeting, there are three answers on the table to the question of last month’s revenue. Accounting gives one figure based on invoices issued. The CRM gives another, because it counts orders marked as won. A spreadsheet from the sales manager contains a third, which still includes a credit note from the previous month. None of the three is made up, and yet they do not add up.

In this scenario, we assume a company with ten to fifty employees that has so far compiled its figures by hand. Someone in the office exports data, pastes it into a spreadsheet, formats it, adds a few sentences and sends out the result. This takes time, it depends on that one person, and it is prone to copy errors that only come to light when someone recalculates.

What gets lost along the way is also typical. The person who builds the report knows the quirks of the data: that a major customer was entered twice in March, that a certain account has to be read differently, that visitor numbers are no longer comparable with previous years after a website relaunch. This knowledge lives in people’s heads and in margin notes, not in a document, and it disappears as soon as the person goes on vacation or leaves the company.

The wish for automated reports usually arises from time pressure. But the real work lies not in sending but before it: what counts as revenue, which source applies, and who decides in case of doubt? Anyone who builds automation on unclear figures produces the same confusion, only faster and in a prettier form.

Technically, pulling data from accounting, the CRM and website statistics is usually unspectacular. Most systems offer interfaces or at least regular exports. It gets difficult at the seams: customer numbers differ between systems, date fields mean different things, and currencies, taxes or cancellations are booked differently.

Then there is data quality. A CRM in which orders are only set to “won” weeks later delivers a delayed truth. Accounting with open receipts at month end delivers provisional values. Website statistics, in turn, are sampled or incomplete because of consent prompts, so absolute visitor numbers should be read with caution.

A third problem is responsibility. When a report is generated automatically, nobody asks while creating it whether a figure looks odd. The human who used to pause while retyping is missing as a control. The checks must therefore move into the process itself, otherwise management decides on the basis of figures nobody has looked at.

Finally, the question of AI. A summary in running text is pleasant to read, but a language model writes fluently even when the interpretation is not supported. “Revenue rose because of the new campaign” is a sentence that sounds plausible and does not have to be in the data.

Reporting consists of three layers that are often mixed up. At the bottom are the raw data in the source systems, in the middle the key figures with their definitions, at the top the presentation for people. Errors usually arise where one layer takes over the job of another, for example when the calculation logic sits in a spreadsheet formula that nobody remembers anymore.

The middle layer is the most important. It states in writing how each key figure is calculated, which source it comes from, which period it covers and who is responsible for it. This directory is unspectacular; it can be a document or a small configuration file. But it is the one truth to which email, dashboard and summary all refer equally.

An example shows how the directory works. The entry “revenue” names accounting as the source, calculates by invoice date excluding VAT, includes credit notes and applies to the closed calendar month. The entry “order intake,” by contrast, comes from the CRM and counts orders by date of commitment. The two figures may differ, as long as nobody confuses them. That is exactly what the definition is for.

For a small company this is not a corporate project. Ten to fifteen key figures are often enough, and more would overwhelm management rather than inform it. The discipline lies in leaving things out: any key figure that does not prepare a decision does not belong in the monthly report, but at most in a detail view that can be called up.

The sequence is the actual solution strategy. We would first work with management to determine which decisions the report is meant to support: planning liquidity, managing capacity utilization, evaluating customer acquisition. The key figures are derived from these decisions, not the other way around. Only then do we check which source can supply them and in what quality.

One alternative would be to connect a ready-made dashboard tool and adopt the software’s defaults. This is quick and suitable if the tool’s standard key figures match your own definition. The price is that calculation paths are often hard-wired. Anyone with their own logic, such as revenue by service period instead of invoice date, quickly runs into limits.

The second alternative is a spreadsheet-based report with scripts. It is flexible and sensible for small volumes of data, but becomes fragile as soon as several people work on it or sources change. We prefer a lean, dedicated intermediate store in which raw data is kept and key figures are calculated reproducibly, with the dashboard and email drawing on it.

The trade-off with the intermediate store matters. It means additional technology that has to be maintained, and for very small volumes of data it can be overkill. It pays off as soon as several sources come together, figures need to be recalculated retroactively or checks need to be traceable. We decide this case by case and not out of habit.

AI comes last. It receives only the fully calculated and validated values, including the previous period, and may put them into words. It should not calculate, and it may only name causes if they exist as a data field. This keeps the text a reading aid for numbers, not a second, uncontrolled reporting system.

For the presentation, the rule is: concise and reliable rather than complete. The monthly email starts with three to five key statements that are understandable without an attachment. Below that come the key figures as a simple table with value, previous period and deviation. Anyone who wants to know more follows a link to the dashboard, where periods and details can be opened.

The design follows a simple rule: a value without comparison says little. A placeholder value X is a lot if the previous period was clearly below it, and little if it was clearly above. That is why the previous period is shown next to every key figure, and for seasonal businesses also the same period of the previous year. We use color signals sparingly and only where a threshold has been agreed beforehand.

The email suits everyone who wants the overview, and it has an advantage that is often underestimated: it archives itself. The March report can be opened in autumn exactly as it was sent back then. A dashboard, by contrast, shows the current state of the data, and retroactive corrections change the past unnoticed. Both have their place, but the basis for decisions should be frozen.

The schedule follows the rhythm of the data, not the calendar. A report on the first working day sounds sensible but is pointless if accounting keeps posting receipts until the fifth. Better is a fixed date after the close, supplemented by a short weekly overview for ongoing figures such as inquiries or visitors that do not need a close.

Every figure in the report carries its origin. A small footer names the source, retrieval time and version of the definition. This looks sober but builds trust: anyone who doubts a figure sees immediately where it comes from and does not have to ask the person who entered it back then.

Technically, the report runs as a scheduled chain. At the set time, a service retrieves the data from the sources, either via interfaces or via scheduled exports. The raw data is written unchanged to an intermediate store and given a timestamp. The key figures are calculated from this store so that every report can later be reproduced exactly.

The checks kick in before delivery. They test completeness (are all expected sources and periods present?), formal validity (no empty required fields, no amounts stored as text) and plausibility (is the value within an expected range compared with the previous period?). If a check fails, the report does not automatically go to management; instead, a warning goes to the responsible person.

Only then is the text created. The summary receives the calculated key figures as structured data and a fixed instruction: every statement must refer to a data field, causes may only be named if they are there, and uncertainty must be stated explicitly. A downstream comparison checks whether every number mentioned in the text appears exactly in the values supplied, and discards the draft if not.

Access rights and data protection are part of it from the start. Retrieval gets read-only access, credentials are stored encrypted, and personal data is used only if the report really needs it. Aggregated values are usually enough. Where names are needed, for example for receivables, it should be clarified beforehand which service processes the data and where, without this being understood as legal advice.

The most common special case is the incomplete month. If receipts are missing or orders have not yet been booked, the report looks worse than reality. We would not calculate such values silently but mark them as provisional and compare them with the status in the following report. A small marker with a date is more honest than a smooth-looking value that has to be corrected later.

A second case is changes to definitions. If the calculation of the contribution margin is adjusted, comparability with earlier periods breaks down. The solution is to version every definition and, when it changes, recalculate the previous periods using the new method, provided the raw data is still available. Otherwise a clear note appears that the comparison is not reliable.

Third, outliers. A large invoice, a one-off refund or a test record in the CRM can distort a key figure. The plausibility check detects anomalies but cannot decide whether they are real. That is why we report instead of correcting: the value stays but carries a note, and a person confirms or cleans it before the report reaches management.

Fourth, the failure of a source. If an interface does not respond or a data format changes, the report should not silently appear with old data. It is halted, the responsible person is informed, and the gap is explicitly named in the next report. Error handling and monitoring are not an add-on here but part of report quality.

The obvious benefit is time. The hours previously spent exporting, pasting and formatting largely disappear. How many there were is something only each company knows, and that is exactly why it is worth noting today’s effort once before starting. Without this baseline, the gain remains a claim.

At least as important is reliability. A report that always appears at the same time and uses the same definitions changes the meeting culture. There is less arguing about which figure is right and more about what follows from it. This cannot be expressed in percentages, but it can be observed: how often does someone in the meeting ask where a figure comes from?

Some indicators can be measured. These include the time between period end and dispatch, the number of corrections after dispatch, the number of runs halted because of failed checks, and follow-up questions per report. Over two to three reporting cycles, it becomes clear whether the process has settled in. A before-and-after comparison is only meaningful after that.

Another gauge is operational calm. If the report runs for several months without manual intervention, apart from the occasional warning, the setup has proven itself. If corrections pile up instead, the cause is rarely the dispatch but unclear definitions or inconsistent data maintenance in the source systems. Then the report becomes a measuring instrument for data quality, and that is not a side effect but often its first tangible benefit.

What cannot be promised is that better reports automatically lead to better decisions. They provide a more solid basis, nothing more. The AI summary does not replace analysis either: it summarizes the values supplied and can point out anomalies, but the assessment remains with people who know the business.

The most important insight is unspectacular: the bottleneck is almost never the technology but agreement on terms. Half a day in which management, accounting and sales go through every key figure together saves many times that in discussion later. The result fits on one page and is the most valuable part of the entire project.

Second: start small and let it grow. A first report with five key figures from two sources quickly shows where the data falls short. Further sources and key figures are added only once the first run has worked stably for a few cycles. Anyone who wants everything at once usually gets a report nobody trusts.

Third, the human should stay in the right places. They confirm outliers, release dispatch when there are warnings and read the text critically once before it goes to third parties. Over time, this oversight can shrink once the validation rules have proven themselves. Dropping it entirely at the beginning would be reckless.

Fourth: the AI summary is an add-on, not the core. It is worthwhile when reports contain many key figures and readers need orientation. It is less worthwhile when five figures can be grasped at a glance anyway. That, too, is part of an honest assessment: not every report needs running text.

Anyone who wants to create automated reports should start with the definition and not with the tool. Once key figures, sources and validation rules are clarified, dispatch is a matter of craftsmanship. If none of that is clarified, every automation becomes a faster route to the same disputes. AI helps with wording, but only if it stays tied to the data.

The next step is small. Write down the five figures your management really needs, and note for each where it comes from and how it is calculated. Wherever two people answer differently, you have found your first task. We are happy to look at your sources together with you and will tell you clearly whether an automated report is worthwhile for a company of your size.

What remains once the report is running? A document that explains key figures, a chain that can be adapted to changes, and a routine that makes deviations visible early. This framework is more valuable than any single report because it can absorb new questions from management without everything starting over.

It is also fair to say that not every company benefits immediately. With very few figures and a single source, a clean template can be enough. As soon as several systems come together and figures are needed regularly, an automated process pays off. We state the effort after a look at your systems, not before.