Why Your Client's Books Shouldn't Live in a Spreadsheet

August 22, 2026

---

A new category of tool is being marketed to bookkeepers right now: the AI spreadsheet. Connect it to a client's QuickBooks, type a question into a cell, and an agent fills the grid with answers. The ads are aimed squarely at practitioners, and the pitch usually leans on the same word the profession actually cares about — audit. Automation you can audit. Numbers you can trust.

The pitch is right about what matters. The architecture underneath it cannot deliver what the pitch promises. It is worth being precise about why, because the reasoning affects any tool you let near a client's books — including ours.

What does a spreadsheet actually know about a number?

Almost nothing. A spreadsheet cell knows its value and, at best, a formula pointing at other cells. It does not know which bank transaction a number came from, who decided its category, whether it was a human or a model that put it there, or whether the source data changed after the cell was filled. The grid is the most flexible surface in finance precisely because it carries no history. Flexibility and provenance are a direct trade — every workpaper veteran knows the feeling of opening a spreadsheet from eight months ago and being unable to say where a figure came from.

That trade is acceptable when a person builds the sheet, because the person is the provenance. They remember, or their workpaper conventions record it. It becomes unacceptable when an agent fills the grid, because now nobody is the provenance. The number appeared. It is probably right. In client accounting, probably right is not a deliverable.

Why does putting an AI inside the spreadsheet make this worse?

Because it multiplies output while removing the one safeguard the spreadsheet had — the human who could vouch for each cell. An agent that writes fifty figures into a grid has produced fifty claims with no lineage. When one of them looks wrong, there is no thread to pull: no link from the cell back to the ledger row, from the ledger row back to the bank evidence. You verify it the old way, by redoing the work. A tool that requires you to redo the work to trust it has automated the part of the job that was never the bottleneck.

The bottleneck in client work has always been the opposite direction: explaining a number you already have. An info-poor bank line — a processor deposit, a payroll debit, a wire with a truncated memo — and the hour it takes to reconstruct what it was. Tools that generate more unexplained numbers add to that pile. Tools that explain existing numbers shrink it.

Should client data flow into a spreadsheet at all?

Yes — outbound, with its provenance attached. Practitioners commonly keep workpapers, schedules, and client-facing summaries in Excel or Google Sheets, and no software vendor should pretend that habit is going away. The question is the direction of authority. A spreadsheet is a fine place for accounting data to be presented. It is a poor place for accounting data to be born.

The honest architecture looks like this: the books live in a system where every figure keeps its chain — bank evidence, categorization decision, who made it, when — and the spreadsheet receives a copy of those figures with the chain summarized alongside them. Source, as-of date, review status. If the export can refresh, it refreshes one way only: the books push, the sheet receives. The moment a sheet can write back into the ledger, every cell edit becomes a potential second version of the truth, and reconciliation — the job all of this was supposed to reduce — now includes reconciling your own tools against each other.

How should a bookkeeper evaluate any AI tool's audit claim?

Ask one question: when this tool shows me a number, can I click through to what the number is made of — down to the bank transaction — without leaving the screen? Not a chat explanation generated after the fact. The actual records.

Then ask the follow-up: can this tool post, change, or create a transaction on its own? If the answer is yes, the audit claim is decorative. A system that can both generate numbers and commit them has no boundary a reviewer can stand behind. The boundary that matters is simple to state: software drafts, humans decide, and the bank feed is the only source that gets to say money moved.

A grid full of AI-generated figures fails the first question. A sync that writes spreadsheet edits into the ledger fails the second. It does not matter how good the model is; the architecture decides what can be audited, and the model cannot fix the architecture.

Where Nalo fits, stated plainly

Nalo is built on the opposite trade: the books live in a system where every number keeps its lineage — bank evidence, category decision, named reviewer, date — and AI only ever drafts, never books. Spreadsheets are treated as a destination, not a source: exports carry each figure's provenance with it, and comparison imports are compared against the books, never merged into them. If you want to see what a number is made of, you click it. That is the whole product. It is at nalo.app.