A spreadsheet can look finished while its logic is still untested. The headings align, the totals update and the chart looks convincing. A formula may nevertheless exclude the last row, apply a rule to the wrong category or treat missing information as zero.
When AI helps build or modify a workbook, the person using it still needs to establish what the calculations mean. Asking the assistant to explain its formula is useful, but an explanation alone does not prove that the workbook implements the intended rule.
My AI for Business material treats clear tasks, context and examples as foundations for useful AI work. VORTA also connects readiness with ownership and test plans. For an AI-generated spreadsheet, I would apply those ideas through a concrete review: define the rule, test cases with known answers and inspect the calculations that affect the decision.
Write the business rule before checking the formula
Start with a sentence that someone familiar with the work can approve without reading spreadsheet syntax. Specify the inputs, the rule, the output and the exceptions.
Consider this fictional example: an online store charges a delivery fee of 5 units when an order subtotal is below 100 units, and no delivery fee when it is 100 or more. A missing subtotal must be flagged for review. Negative subtotals are outside the permitted input range.
That statement answers questions a short request such as “calculate delivery fees” leaves open. It defines the threshold, what happens at the threshold and how incomplete or invalid data should be handled. Real organisations would also need to specify the currency, applicable discounts and other relevant conditions. This example is deliberately narrower.
Before generating formulas, ask the responsible person to confirm the rule. An AI assistant should not quietly decide whether a discount applies before or after the delivery threshold, or whether a blank cell means a free order.
The same discipline belongs in the task brief: define what a correct result means before choosing the wording of the prompt.
Use a small set of cases with known answers
Test the workbook on a separate copy with synthetic or otherwise approved data. Write the expected result independently before comparing it with the calculated result. If the same assistant generates both the formula and every expected answer, an incorrect assumption can appear in both.
For the fictional delivery rule, a useful starter set is:
- Ordinary case: a subtotal of 80 should produce a fee of 5.
- Just below the boundary: 99.99 should produce 5.
- Exactly at the boundary: 100 should produce 0.
- Just above the boundary: 100.01 should produce 0.
- Missing input: a blank subtotal should be flagged, not silently treated as a valid zero-value order.
- Invalid input: a negative subtotal should be rejected or flagged under the agreed rule.
These cases are chosen to expose different mistakes. Testing several ordinary orders alone would not distinguish “greater than” from “greater than or equal to” at the threshold. Nor would it show whether a missing value is handled properly.
Add cases for the workbook’s actual complexity: dates at a reporting boundary, duplicate identifiers, unmatched lookup values or categories with different rules. A handful of cases is a starting point, not proof that every possible combination works. More consequential or complex workbooks need deeper review by someone qualified to check the underlying business logic.
Follow the calculation from input to output
A correct answer on one test row does not establish that every row uses the same logic. Inspect the formulas behind the outputs that matter.
Look for three things:
- References: does the calculation use the intended input cells, lookup table and period? Check whether references shift correctly when copied.
- Coverage: do totals include every intended row without counting subtotals twice? Does a newly added row enter the calculation?
- Consistency: are similar rows using the same rule, or has a formula been replaced by a fixed number or a different expression?
Microsoft’s formula error guidance describes checks for issues such as inconsistent formulas and numbers stored as text. It also makes clear that error checking does not guarantee an error-free worksheet. A valid formula can still encode the wrong business rule.
Excel’s Trace Precedents and Trace Dependents can help reveal which cells feed a calculation and which outputs depend on it. These tools have limits, including some reference types they cannot trace. Use them to support inspection, not as a certificate that the entire workbook is correct.
Ask AI to describe the calculation in plain language and identify its assumptions. Then compare that description with the actual formula and the approved rule. When they disagree, resolve the discrepancy before using the result.
Test what happens when the workbook changes
A workbook may pass its first test and fail during ordinary use. Users add rows, paste data, rename categories or copy formulas into a new period.
On the test copy, try the operations the team will actually perform. Add one valid record and check that both the detailed result and the total change as expected. Change a value across a rule boundary. Remove a required input and confirm that the missing-data signal remains visible. Repeat the known-answer cases after any AI-assisted revision.
Check input types as well as displayed formatting. A cell that looks like a number or date may not behave as intended in a calculation. Also confirm that the results have recalculated in the spreadsheet application the team will use; a displayed value alone is not evidence that the latest inputs were evaluated.
Keep the original workbook and a clear version history. Do not overwrite the only working copy while experimenting. If an AI-generated solution introduces macros, scripts or external connections, treat those as a separate change requiring the organisation’s normal security and approval process. They should not be enabled merely to make a demonstration work.
Make the review useful to the next person
The handover does not need a large assurance document. It does need enough information for another person to understand what was checked and what remains uncertain.
Record the workbook version, its intended use, the rule owner, the test inputs, the expected and observed results, and any unresolved exceptions. Identify who reviewed the material calculations and when the tests should be repeated, such as after a rule change or a new data source.
Keep working files within approved systems. Before sharing a workbook with an AI service, apply the business-data boundary checks. Hidden sheets, comments and linked data may contain information that is not apparent in the visible table.
Finally, keep calculation assurance separate from the meaning of the source data. A perfectly implemented formula can still answer the wrong question if the inputs mix different populations or periods. The companion article on checking what business-report numbers count addresses that upstream issue.
Accept the workbook for a defined use
The useful acceptance question is: “Can we explain this rule, reproduce its expected results and see when it stops applying?” That is more informative than whether the file opens without errors or the AI says it has checked its work.
AI can accelerate spreadsheet construction and help a reviewer examine logic. The responsible owner still decides whether the evidence is sufficient for the workbook’s intended use. For a consequential decision, unresolved discrepancies are a reason to pause that use, not to hide the warning behind a polished chart.
If your team needs a practical review approach for AI-assisted business workflows, schedule a consultation.