A saved input and a stale report can coexist
We copied the synthetic expense workbook into a new task directory, opened it in native Excel and deliberately selected manual calculation. We also disabled calculation before saving for this test. The source budget table and the report were otherwise the same fixture used in the Power Query experiments.
The report began at $645,000. One October budget row contained $140,000. We increased that source value by $1 and read the report again: it still showed $645,000. Excel reported calculation state 2, pending. We saved a separate copy at that point so the stale state could be inspected.
This is a controlled demonstration of manual calculation, not evidence that Panes selects that setting by default. The script saves the previous settings and restores them in its cleanup. An agent should inspect the workbook and the Excel instance it actually received rather than assume a calculation policy.
Rebuild, then test the financial change
The script called CalculateFullRebuild. Microsoft documents that operation as calculating all open workbooks and rebuilding formula dependencies. The report then returned $645,001 and calculation state 0, done. The source change and the report change reconciled exactly.
CalculationState describes Excel calculation activity. It does not prove that a query downloaded current records or that an external workbook was available. Our separate missing-source experiment reached a done state while still retaining old query data. Treat source freshness, formula calculation and financial reconciliation as separate acceptance checks.
For a task that changes formulas or inputs, write down the expected effect before performing the edit. Here it was a $1 increase in the total budget. That independent expectation caught the problem immediately; reading the saved file back without an expected value would merely have repeated the stale answer.
$before = $report.Range('B9').Value2
# Apply the task's input change here.
$xl.CalculateFullRebuild()
$after = $report.Range('B9').Value2
if ([math]::Abs(($after - $before) - 1) -gt 0.005) {
throw 'Budget total did not reflect the expected USD 1 change'
}| Stage | Source budget row | Report budget | Calculation state |
|---|---|---|---|
| Before edit | $140,000 | $645,000 | Not recorded |
| After edit | $140,001 | $645,000 | 2: pending |
| After rebuild | $140,001 | $645,001 | 0: done |
Keep the calculation boundary visible
A successful Save is a persistence event. In this test it could preserve an unrecalculated result. Saving after the explicit rebuild gave us a different and correct output. That distinction matters when a later step reads cached cell values to build a presentation or a Word report.
Use an isolated Excel instance for this kind of test: a full rebuild affects every workbook open in that instance. Preserve and restore settings you intentionally change. For normal business work, select a calculation policy with the workbook owner rather than silently replacing a model’s existing manual mode.
The downloadable before-recalculation copy is deliberately stale. Reopening it under a different calculation policy may update it, so inspect its saved values before changing its state. Do not hand it to a customer as an accepted report.
Download both states and the exact procedure
Inspect the before-recalculation workbook, recalculated workbook, result log and PowerShell script. The script expects expense-original.xlsx in a new directory; use the synthetic expense workbook as that input.
Run the native step through Panes desktop execution. Pair this test with query freshness and pivot reconciliation when the workbook contains all three layers. The useful acceptance condition is a reconciled output from current inputs.