Business Reports with AI: Keeping Verified Numbers Separate from Generated Commentary

Artificial intelligence can make a report readable that nobody reads. What it can't do is decide how much you billed: if you ask it for the calculation and the commentary together, it hands back smooth text in which the wrong numbers are indistinguishable from the right ones. This guide is about building reports where the verified part and the generated part stay separate and recognizable even six months from now.

There's one rule that holds up everything else: the numbers are calculated by the system that owns the data; the model receives the finished result and works only on the wording.

The model doesn't calculate the numbers

A language model that receives raw data and is asked to produce sums, averages, or comparisons generates results that are plausible and unverifiable. The problem isn't its ability to calculate: it's that the result isn't reproducible, and no one will be able to say, looking back later, which method was used.

• Sums, averages, changes, and percentages are calculated where the data lives: in the business management system, in the spreadsheet, in an already-defined view. They're verifiable and repeatable.
• The model receives a closed table, with the values already calculated, and uses them as they are. It should have no reason to recalculate anything.
• In the final document, the numbers must be traceable back to their source. One line at the bottom stating which system they come from and which period they cover is worth more than ten lines of commentary.
• If a number isn't there, it shouldn't be estimated: it should be flagged as missing. This is where generated reports go wrong most often, because a gap gets filled in with something that sounds reasonable.

What to feed in: a closed table and context

The quality of the commentary depends almost entirely on what's put in front of it. A model that receives only numbers produces descriptions: "the value went up." A model that also receives context produces useful observations.

1. The table of values for the period, with the comparison period already set alongside it and the change already calculated.
2. The definition of each indicator in one line: what it measures, what it excludes, what unit it's in. Without this, the commentary will use the terms in their common sense, not yours.
3. The thresholds or targets, where they exist. "Below this value we step in" turns a description into a flag.
4. The known facts of the period: a closure for vacation, a campaign, a lost customer, a vendor at a standstill. Without context, every deviation becomes a mystery, and a model that doesn't know why a number moved tends to invent a reasonable-sounding explanation.
5. What's excluded or incomplete: data that will arrive late, locations not yet integrated, periods that aren't comparable.

A sample report

Here is what a report built this way looks like. The values are illustrative and are only meant to show the structure: the top part is calculated and verifiable, the bottom part is generated and needs approval.

Below the table comes the commentary, and every sentence needs to belong to one of the three categories in the next section. A comment where you can't tell which category a sentence belongs to needs to be rewritten, not corrected.

Observation, hypothesis, missing information

This is the distinction that makes a generated report usable in a meeting. Three categories, explicitly labeled in the text.

• Observation: states only what the table shows. "Quotes issued are lower than the comparison period, on a figure that doesn't include two locations." It adds nothing and can't be wrong.
• Hypothesis: offers a possible explanation, labeled as such, with a way to check it. "One possible cause is the August closure at one location; this can be checked by comparing actual working days." It's useful precisely because it comes with its own verification.
• Missing information: states what would be needed to answer. "It isn't possible to say whether the lost requests concern a specific sector: the sector data isn't in the table." This is the part that most often improves the next report.

A practical consequence: the model is asked never to formulate an operational conclusion. "Sales efforts need to increase" is neither an observation nor a verifiable hypothesis — it's a decision, and decisions stay with whoever is accountable for them.

Who approves it, and what stays on record

A recurring report needs a stable process, otherwise the review happens the first time and then stops.

1. The calculation is run and the table is frozen, with the date and time of extraction.
2. The commentary is generated from that table, and isn't regenerated after data changes without redoing the calculation too.
3. A person reviews it, corrects it, or rejects it. Frequent corrections should be logged: they're the most useful signal for improving the instructions given to the system.
4. The document that's distributed carries with it the extraction date, the period, the sources, and a note of which parts were generated. Anyone who finds it again in a year's time should be able to understand it without having to ask.

What this guide doesn't cover

This guide covers assisted interpretation: how to prepare a report so the commentary is useful and checkable. Defining the indicators — formulas, sources, frequencies, and who's responsible for the data — comes first and is covered in a dedicated guide: without that work, a generated comment will elegantly describe numbers the company doesn't actually agree with. The tests to run on an assistant before putting it online have a guide of their own.