An Excel ledger into a monthly report, with formulas you can recompute and check
Measured on 2026-11-14 — numbers from one real run
The run log here comes from an actual run, not an estimate. Where token usage was not captured it says so rather than guessing.
When to use
One ledger sheet per month; you need a monthly report someone else can review, with numbers that aren't hard-coded.
Preparation
- Host version
- 0.1.2-alpha.5
- Model
- To fill
- Mode / permissions
- --profile headless / workspace-write / Windows 11 / node 22.22.2
- Plugins required
- None (add name & version after testing if used)
- Input materials
- A synthetic ledger.xlsx: 120 rows plus a header, five categories, amount always equals quantity times unit price
Full instruction
Read [ledger.xlsx] and generate monthly-report.xlsx.
Aggregate income and expenses by [DEPARTMENT] and [MONTH], and compute the balance.
The summary must use formulas; do not paste pre-computed numbers as static values.
Requirements:
1. First list the original sheet's column names, row count, empty values, and duplicate rows; wait for me to confirm the definitions before computing.
2. After generating, recompute once with formulas and compare the recomputed result with the numbers you wrote in the summary; report any mismatch rather than changing the numbers yourself.
3. Also save a verification-notes.md: state which columns were used, what was filtered out, how the formulas are written, and which rows were excluded and why.
4. Do not modify ledger.xlsx.Run log
| Item | Value | Note |
|---|---|---|
| Time spent | 3 minutes 20 seconds | 2026-11-14 |
| Result | All five categories totalled correctly (268 units, 62,805 in value); produced monthly.md plus monthly.xlsx with SUMIF/COUNTIF formulas rather than hardcoded numbers; the source file's SHA256 was identical before and after | |
| In / out tokens | Not captured | |
| Leftovers | Five _*.py analysis scripts were left behind. It claimed the sandbox forbade deleting them; we have not verified that claim, but the residue is real — the 'check leftovers after every run' rule is not redundant. |
What the run showed
- The source really was untouched: it computed the SHA256 itself, matching the 0a6322f5… I computed externally, and additionally reported that size and modification time were unchanged.
- The requirement that subtotals reconcile to source rows produced something better than expected: because rows of one category are non-contiguous (every fifth row), it did not hand-wave 'rows 2 to 121' but listed all 24 row numbers per category with the arithmetic (1+2+2+3+5+…=62) so each term can be checked.
- A real limitation: no Excel and no LibreOffice on this machine, so formulas cannot be actually recalculated. It did not pretend to verify: it implemented its own SUMIF/COUNTIF evaluator, checked all 24 formula cells, and said plainly to press F9 in Excel to confirm.
- On cross-workbook references it laid out the trade-off: monthly.xlsx is a self-contained copy with the ledger sheet inside, so editing that copy recalculates; linking to the original would need cross-workbook references, which it could not verify without an engine, so it declined.
To reproduce the value here, keep the clause about subtotals reconciling to source rows. Remove it and the output still looks fine while being unverifiable.
Output
After a successful run, list files and screenshots here, and note whether originals changed.
Acceptance checklist
Tap to tick each item off as you verify.
- The summary cells in monthly-report.xlsx are formulas, not static numbers
- The recomputed formula result matches the summary
- verification-notes.md states the excluded rows and the reasons
- The original ledger was not modified
Failures & boundaries
- When column names in the source are inconsistent, confirm the definitions first; do not guess
- Merged cells and hidden rows are easy to miss in the calculation; flag them in the verification notes first
- This page is a recipe template and has not yet been tested on this site