Management reports with AI: numbers from systems, words from the model.

Every Monday, an operations manager spends the morning on the weekly report: exporting figures, pasting them into the template, and writing three paragraphs about why one plant fell behind plan. The figures take an hour. The paragraphs take the rest of the morning, because the reasons live in shift logs, sales notes and other people’s inboxes.

AI can take most of that morning back, on one condition: it never touches the arithmetic. Compute the figures in the ERP or BI layer, let the model draft commentary from those figures and from the notes people already write, and cite every statement to the number it explains. The steps below show how, with what “done” looks like at each one.

Why shouldn’t the model do the arithmetic?

A language model produces text by prediction, not by calculation. It will add up a column correctly most of the time and occasionally get a total or a percentage wrong, and the wrong number looks exactly like a right one. It also doesn’t know that your “net sales” excludes returns, or how your on-time delivery is defined, unless someone tells it.

The model writes about the numbers. It never writes the numbers.

Done when no figure appears in the draft that isn’t in the input table. A simple automatic check compares every number in the text with the table and blocks the draft if one doesn’t match. Goes wrong when the model “helpfully” works out a total or a change nobody gave it.

Where should the numbers come from?

From the same ERP queries or BI layer that already produce the figures finance stands behind, computed and checked upstream: totals tie back to the ledger, and differences against the prior period and the plan are calculated there too.

The model receives a table, not raw data. Each row holds the metric, the period, the value, the comparison figures, the difference, a materiality flag and, crucially, the metric’s definition, so the commentary uses the right words. Rounding and units are settled upstream as well: the table says whether a figure is in thousands or millions, and the draft quotes it exactly as given. Ad hoc questions against the same data are a different design; our note on text-to-SQL covers when that works.

Done when every figure in the report comes from a named, tested query. Goes wrong when someone pastes an export into a chat window and asks for a summary.

What can the model add?

Words, structure and evidence for the “why”. The reasons for a variance usually already exist in notes people write anyway: sales notes in the CRM, shift and operations logs, maintenance tickets, complaint records. The model reads those notes for the report period and connects each variance to the entries that explain it.

Just as important is what it must not add. When a flagged variance has no recorded reason, the draft says “no recorded reason” and asks the owner, rather than offering a plausible cause. Deciding which variances matter stays upstream too: the materiality flag in the table, not the model’s impression, decides what gets a paragraph.

Keep the structure fixed so readers know where to look: a two-line headline, then the flagged variances in order of materiality, each with its reason or the words “no recorded reason”, then the open questions for owners.

How do you cite a sentence to a figure?

Give every figure and every note an identifier, and require each sentence to carry the identifiers it relies on:

• A sentence that states a number cites the table row that holds it, with the number written exactly as it appears there.
• A sentence that gives a reason cites the note it came from, dated inside the report period.
• A sentence with neither is opinion, and is either removed or marked for the owner.

Both checks are automatic, and the review screen shows the cited row or note on click. Our note on why AI makes things up explains why grounded, checkable drafts fail less.

Who reviews the draft before it goes out?

The person who used to write the report. They see the draft next to the figures and sources, with flagged items at the top; they answer the “no recorded reason” questions, add context no note contains, and edit the tone. The report goes out under their name, because they are accountable for it. Their edits are worth keeping: when the owner makes the same correction every week, such as a preferred term or a recurring caveat, it belongs in the instructions or the table rather than in another round of edits. Done when every flagged item carries an owner comment or is deliberately left open.

How do you judge whether the report improved?

Here is an illustrative example: the weekly operations report of a manufacturer with two plants.

• Before: “Output was lower due to several issues. Deliveries were mostly on time.”
• After: “Plant B output fell short of plan [output, Plant B]; the shift log records a stoppage on line 3 [shift log, line 3]. On-time delivery held steady [on-time delivery, all plants]. Scrap rose at Plant A, with no recorded reason; owner to comment [scrap, Plant A].”

The second version takes a few more lines, but every statement in it can be checked, and it says openly what nobody knows yet. Judge the change against the baseline: time to produce the report, edits the owner makes, the share of material variances with a recorded reason, numeric errors found after distribution, which should be none, and how many follow-up questions readers send.

Start where the figures are stable

Pick one recurring report with a stable set of figures and an owner who writes the commentary. Weekly management report drafts are a typical use in ERP and enterprise workflows, and the tested queries and definitions underneath are data and AI foundations work.