Monthly Management Report With AI: Data, Draft and Review

Monthly Management Report With AI: Data, Draft and Review

To build a monthly management report with AI, split the work into three parts. The numbers come straight from the source (ERP, CRM, spreadsheet or database), the AI only writes the narrative about those numbers, and a manager checks every claim before the report goes out. The AI should not calculate, look up or estimate data on its own. It writes about what you hand it, and responsibility for the content stays with the person who signs the report.

Key takeaways

• Numbers come from the source, calculated by a query or formula, never by the language model.
• The AI receives a closed table and clear instructions, and returns text in which every sentence can be traced back to a row of that table.
• The manager checks claim by claim, using a checklist, and only then does the report go out.
• Comparisons, causes and recommendations are the weakest point: the AI should flag them as hypotheses, and someone who knows the business decides whether they stay.
• A pilot of a few monthly cycles, with a record of what was corrected each time, shows whether the process deserves to continue.

Why monthly reports often go wrong with AI

The most common mistake is pasting an entire spreadsheet into a chat and asking for a summary. The model returns fluent, professional-sounding text, and that fluency is exactly what hides the problems. A wrong sum, a month compared against the wrong period or an invented cause for a drop all look as trustworthy as the rest of the paragraph.

There are three recurring failures. The first is asking the AI to do the math: language models write well, but arithmetic over many rows is a risk point. The second is handing over data without context, such as columns with no definitions, and letting the model guess what margin, average order value or cancellation means in your company. The third is treating the text as finished, with no explicit review step.

OWASP lists overreliance on model output and the generation of incorrect information among the risks of applications built on language models. The monthly report is a typical case: the text goes to partners, banks or teams, and becomes the basis for decisions. That is why the design of the process matters more than the choice of tool.

How should work be divided between data, AI and manager?

Think in three layers, each with a different responsibility.

• Data layer: queries, formulas or deterministic routines that produce the month's table. The result is the same every time you run it on the same data. If someone asks where a number came from, the answer is a query, not a model.
• Writing layer: the AI receives the table, the indicator definitions, last month's report as a format reference and writing rules. It produces the draft narrative: what went up, what went down, what deserves attention.
• Review layer: the manager compares the draft with the table, corrects it, removes what does not hold up and adds what only they know, such as a supplier change or a campaign that shifted the month.

This separation follows the logic of predictable workflows combined with AI where judgment is needed, described in Anthropic's documentation on building effective agents. The part that can be deterministic stays deterministic. The AI comes in where the text needs reading and synthesis. If you want to go deeper on validating model output before it moves downstream, read about guardrails for AI agents.

How to prepare the numbers before calling the AI

The quality of the report is decided before the first prompt. A good input package has these elements:

• One table per subject (revenue, costs, support, production), with the period stated explicitly on each row and the comparison already calculated at the source: current month, previous month and the same month last year, where it makes sense.
• A short indicator dictionary, with each definition in one sentence. For example: what counts and what does not count as a cancellation, and which date counts as the sale date.
• A list of facts about the month that are not in the data: holidays, process changes, outages, campaigns. This keeps the AI from inventing explanations.
• The limits of what the AI must not claim: forecasts, causes without evidence, comparisons with the market.

If part of your numbers arrives as PDFs, such as statements, invoices or third-party reports, extract the fields with rules and review before feeding the table. The article on extracting data from PDFs with AI covers that step. The principle is the same: data only enters the narrative after it has been validated.

One privacy precaution: before sending data to any model, decide what is allowed to leave the company. Management reports often contain sensitive commercial information and sometimes personal data about customers or employees. Aggregate what you can and remove identifiers the text does not need. If the provider processes data outside Brazil, see what LGPD requires in international data transfer when using AI and consult the ANPD guidance.

How to instruct the AI to write without inventing

The prompt for the monthly report is a working document, not a loose sentence. Keep it versioned and adjust it every cycle. A good set of instructions includes:

• Role and audience: you are drafting the monthly report for the leadership team, in a direct and calm tone.
• Source rule: use only the numbers in the table provided. Do not calculate new values. If you need a number that is not in the table, state that the data was not provided.
• Cause rule: never assert the cause of a variation. When the facts of the month contain an explanation, cite it. Otherwise, write that the cause needs to be verified.
• Format: a summary of a few lines, then sections by area, each with what changed, what deserves attention and open questions.
• Traceability: next to every numeric claim, indicate in square brackets the table row or indicator it came from.

The last rule is the most useful for review. When every sentence points to an origin, the manager does not have to hunt for where a number came from, only confirm it. Anthropic's documentation on context engineering reinforces that a model works better with relevant, organized and lean information than with everything dumped at once. The same applies to the size of the context window: huge, uncurated tables make the result worse.

A note on instructions hidden in data: if any free-text column comes from customers or third parties (comments, notes), treat it as untrusted content. OWASP describes how external text can try to change the model's behavior. For this report, the simple habit of not sending free-text fields the narrative does not need already reduces the risk.

How does the manager check each claim?

Review is the step that makes the process safe, so it needs a script. Use this checklist every cycle:

• Every number in the text appears in the month's table, with the same value, the same unit and the same period.
• Every comparison (higher, lower, stable) matches the real direction of the difference in the table.
• No cause was asserted without support in the facts of the month that you provided.
• No forecast, target or recommendation went in without your approval.
• Names of people, customers and suppliers are correct and actually needed in the report.
• Indicator terms match the dictionary (the AI did not swap cancellation for non-payment, for example).
• What was left out is intentional: nothing relevant in the table was dropped because the model overlooked it.
• The tone suits the audience and promises nothing the company cannot deliver.

The manager also has to decide what to do on finding an error. Two rules help. First: if the error is in a number, fix it at the source or in the table and generate the text again, instead of just patching the paragraph. Second: if the error is one of interpretation (an invented cause, for example), log it and adjust the instruction for next month. That way review feeds the improvement of the process.

It is worth remembering that some passages should not be delegated. Assessments of individual people, termination decisions and legal positions stay with whoever answers for them. The article on what not to delegate to AI in your business helps draw that line.

Illustrative scenario: a monthly report for a services operation

Imagine, as an illustrative scenario, a services company with WhatsApp support and a schedule of technical visits. Every month the operations manager consolidates tickets opened, tickets resolved, visits completed, reschedules and ratings received. Today she spends a good part of an afternoon copying numbers from three systems and writing the text.

In the new process, a saved query in each system produces the month's table, already including the comparison with the previous month. The manager writes a few lines on the facts the data does not show, such as a change of field team. The AI receives all of this plus the indicator dictionary and produces the draft, with the origin of each number noted in brackets.

During review, the manager notices two things. The draft attributes the increase in reschedules to a shortage of parts, but that cause is not in the facts she provided: she removes the sentence and writes that the cause will be investigated. And the text calls closed tickets resolved, while the dictionary defines resolved as closed without reopening. She corrects the term and notes the adjustment for next month's prompt. The report goes out with the numbers from the source, the AI's narrative and the accountability of the person who checked it.

No numeric values appear here on purpose: the point of the scenario is the design of the process, not a result to expect.

How to apply the method in a pilot

The method we use for AI projects in companies follows four moves: map, limit, pilot and hand over. Applied to the monthly report, it looks like this.

• Map: describe how the report is made today. Who gathers the data, from which systems, how long it takes, where errors tend to appear and who reads the result. This is the baseline for knowing whether anything improved.
• Limit: define which data the AI may receive, which stays out and which claims it is forbidden to make. Also decide who reviews and who approves the send.
• Pilot: run the process for a few monthly cycles, in parallel with the old method in the first one. Record what the manager corrected each time, the time spent and whether the report prompted fewer follow-up questions. Agree beforehand on which metric defines success. To structure this evaluation, see how to measure an AI automation pilot.
• Hand over: document the query, prompt, checklist and owners, so the process works without depending on whoever built it. Then decide whether to expand to other reports, adjust or stop.

NIST, in its AI risk management framework, addresses exactly this idea of mapping, measuring and managing risks with defined owners. For an internal report the rigor can be proportional, but the reasoning is the same.

If the plan is to track team performance from these reports, make sure the indicators do not turn into individual surveillance. The piece on measuring AI productivity without surveillance covers that balance.

Frequently asked questions

Can the AI calculate the report's indicators? The safest answer is no. Calculate by query, formula or deterministic routine and hand the finished result to the model. That way any number can be audited back to the source, and the AI is only responsible for writing about it.

Do I need to review the text every month, even after the process stabilizes? Yes. The data changes every cycle, and the model can introduce a new error even with a prompt that worked before. Review can get faster with the checklist and traceable origins, but it should not be removed as long as the report is a basis for decisions.

Can I use a model that runs inside my company to protect the data? It is an option when the data is very sensitive, with the caveat that text quality and maintenance effort change. Evaluate it with a real test of your report, and read the article on running Ollama and local models in a company to understand what it requires.

What if the AI states something that is not in the data? Remove the claim, log the type of error and reinforce the matching rule in the prompt, for example by forbidding explanations of causes without evidence. If the problem keeps recurring, reduce what the model has to write and hand that section to the manager to draft.

Sources

• NIST: AI Risk Management Framework
• OWASP: Top 10 for LLM Applications
• Anthropic: Building effective agents
• Anthropic: Effective context engineering for AI agents