Where spreadsheets really need help
Critical small-business processes often live in Excel: stock, price lists, requests, purchasing plans, and reconciliations. A workbook may combine manually entered fields, formulas, notes, and a sheet called “final_really_new”. Local AI helps when staff must interpret unstructured text: map product names to a catalog, classify requests, flag suspicious rows, or describe a discrepancy. Direct write access to a production workbook is risky, however. A plausible answer is not proof that a price or formula is correct.
The key principle is to make the model the author of proposals, not the owner of the spreadsheet. It returns a list of changes with stable row identifiers; conventional software checks the rules and applies only approved changes. This permits a local perimeter for confidential price lists while keeping responsibility clear: a spreadsheet engine performs calculations and an employee makes the decision.
Why reading a value may not reveal the current calculation
In an Excel file, a formula and its last calculated result are stored separately. Microsoft documentation describes the formula in the `f` element and a cached value in `v`, corresponding to the last recalculation. openpyxl documentation explains that `data_only` returns the stored value rather than recalculating the formula. If the workbook has not been recalculated recently, the result may be stale. Microsoft also documents automatic and manual calculation modes in Excel.
The practical implication is that a number returned by a file-reading library is not enough to validate an edit. Before comparing totals, establish which application recalculated the workbook and when. This is especially important for cost, discounts, and stock: a mistake in one source row can flow through dependent formulas and still produce a convincing-looking total.
A safer five-part architecture
1. **Source and snapshot.** Obtain the approved file version from a known location, keep a copy and checksum, and record the timestamp, owner, sheet, and range. If others edit the workbook concurrently, an old snapshot must never silently overwrite a newer version.
2. **Input preparation.** Extract only necessary rows and columns. Assign each row a stable ID and mark formula-driven and protected fields separately. Do not send personal information or irrelevant sheets to the model merely because it runs locally.
3. **Model proposals.** Request a structured list: row ID, field, old value, proposed value, reason, and confidence. A local inference server such as llama.cpp supports schema-constrained JSON responses. That makes output easier to parse; it does not establish that the contents are true.
4. **Validation and approval.** Deterministic code checks types, ranges, reference lists, required fields, allowed transitions, and formula integrity. A person reviews a “before → proposed” diff and accepts or rejects each change group. Prices and payment details may warrant their own threshold and a second approver.
5. **Application and audit.** Apply edits to a copy first. Open and recalculate it in the spreadsheet engine the company actually uses; compare control totals and formulas, then release a new version. The log records the source version ID, request, response, checks, employee decision, and output file. Test rollback before production use.
This does not require an elaborate agent platform. An initial pilot can use a local model, an export-and-validation script, a versioned folder, and an approval screen. The model needs no permission to delete files, change formulas, or update an ERP directly. If approved results must reach an ERP or CRM, pass them through the normal integration layer with its established access controls and audit trail.
What to test in a pilot
Pick one repeatable workflow, such as classifying 100–200 request rows or finding product-catalog mismatches. That is a convenient test-set size, not a performance claim. Include blank cells, duplicates, ambiguous names, negative amounts, formulas, manual calculation mode, and a stale file copy. Record an expert's reference decisions before running the model.
Do not measure only the share of correct proposals. More important metrics are incorrect edits that pass automated validation, approval time, version conflicts, and the ability to restore the original file. If even one critical formula changes without explicit authorization, the pilot is not ready for real data. The goal is less manual searching, not automatic acceptance of everything the bot suggests.
Economics without magic
Cost the entire process. An illustrative model: 1,000 rows per month at 40 seconds of manual review each amount to roughly 11 hours. If AI offers usable options for 70% of rows but saves only 20 seconds of review on each, the potential gain is about 3.9 hours per month before data preparation, validation, and maintenance. These figures are assumptions, not an observed implementation result. Substitute your own review time, acceptance rate, and cost of error.
Local inference also incurs compute, model-update, backup, and support costs. It can be justified when data cannot leave the organization, the workload is regular enough, or version and access control are important. For an occasional workbook, automation may cost more than it saves; a template, reference list, and ordinary rules may solve the problem without AI.
The manager's first step
Select one workbook and one manual operation, assign a data owner, and prohibit the model from writing to the original. In a week, build a small reference set, check formulas and versioning, then compare manual and assisted work for time and quality. Expand only if control totals are reproducible and errors are rejected before writing. Otherwise, fix the spreadsheet structure first. The robot intern may enthusiastically sort sticky notes by cell; the approval stamp stays with a person.