Somewhere in Monday’s meeting the question lands: why is R&D spend up forty percent in May? You know the answer exists. It’s on the shared drive, spread across a flash pack, a consultant’s invoice schedule, and a workbook someone named FINAL_v3. The hard part isn’t calculating the answer. It’s finding it.
Every AI assistant that answers questions about your numbers has that same job. The model doesn’t remember your files (it has never seen them before). When you ask, it searches first and answers second, and there are four ways it can search. They map, almost exactly, onto the four ways you’d do it yourself.
Search one: Ctrl+F with stamina
The real name is keyword search, sometimes lexical search. It’s the one you already use: match these exact characters, everywhere, instantly. Think of a temp on their first day. Fast, tireless, zero judgment. Ask for “headcount” and they will find every file containing the word headcount, including the 2023 policy doc you didn’t want. And they’ll walk straight past the file that matters because it says “FTE” instead.
Exact words in, exact matches out. That’s the whole tool. Powerful when you know the magic word, useless when you don’t.
Search two: by meaning
The real name is vector search, also sold as semantic search. Under the hood, every passage of text is converted into an embedding: a long list of numbers that works like coordinates on a map of meaning. Passages that mean similar things sit near each other on that map, even when they share no words. Searching means dropping your question onto the map and picking up whatever sits closest.
This is the colleague who’s been in the department fifteen years. Ask her about payroll and she hands you the staff costs file, the comp review, and the “people costs” tab, because she knows they’re the same thing. No exact words needed.
The catch: vector search returns what’s nearest in meaning, not what’s exactly right. For a policy question, nearest is usually fine. For numbers it’s quietly dangerous, because “close” is where finance goes wrong. In a poem, close enough is fine. In a trial balance it’s a misstatement.
Search three: walking the drive
File system search is the least glamorous and the most underrated: the agent browses your folders the way a new analyst would. Reads folder names, file names, dates. Opens the promising ones, looks inside, backtracks, tries the next.
Two things make this valuable. The file it opens is the live file, whole, in its natural shape, with nothing pre-processed or mangled in advance. And the trail is legible: you can see exactly which folders it walked and which file it opened, the same way you’d check a junior’s working. The dependency is your drive being navigable, which, be honest, is a coin flip.
Search four: following the lines
Graph search is the group structure chart, turned into something a machine can walk. A graph stores things and the connections between them: this cost centre rolls into that department, this invoice belongs to that contract, this entity owns that one, this person approved that payment.
It exists for questions that are really about connections. “Which contracts renew in Q3 inside the entities Germany owns?” is nearly impossible for the other three searches, because no single file contains the answer. A graph walks the ownership lines, then the contract links, and assembles it. The catch is that someone has to draw the map first. A graph only knows the lines someone drew.
The same question, four ways
Take “why did travel spend spike in May?” and run it through all four:
flowchart LR
Q[Why did travel spend spike in May?]
Q --> K[Keyword: 200 files containing the word travel]
Q --> V[Vector: the Lisbon offsite memo, found by meaning]
Q --> F[File system: the May flash pack, found by folder]
Q --> G[Graph: travel rolls into Sales opex, linked to the offsite approval]Keyword buries you in hits. Vector surfaces the memo about the “T&E exception for the Lisbon offsite” even though it never says travel spend. File system finds the actual May pack. Graph explains how the pieces connect.
None of them wins alone. A good agent combines them in sequence, the way you would: skim the folders first, Ctrl+F when you know the word, ask the veteran when you don’t, check the structure chart when the question is about how things relate. When a vendor says “our AI searches your documents,” the useful question is which of these it’s doing. Most do exactly one.
Where workbooks break it
Now the hard part. Most of what a finance team knows doesn’t live in prose. It lives in workbooks, and workbooks break the most popular search of the four.
Vector search needs text in chunks: cut the document into passages, place each on the map of meaning. Prose survives that surgery, because a paragraph carries its meaning with it. A spreadsheet doesn’t, because meaning in a grid is positional. Cell C47 is “May consultant spend for UK01” only because of the row label in column A, the header in row 3, the merged banner two rows above that, and the name of the tab. The cell itself just says 41,200.
Chop the grid into text chunks and the number detaches from its labels. The figure survives; what it means doesn’t. Which produces the specific, maddening failure you may have already seen: the right number quoted against the wrong month or the wrong entity, delivered fluently and with total confidence.
And that’s before the traps workbooks add on top. Cells that display a value but hold a formula. Hidden tabs. Sixteen versions of the same file (my favourite remains budget_FINAL_v3_ACTUAL-FINAL.xlsx), where searching by meaning happily picks the wrong one, because superseded numbers mean almost exactly the same thing as final ones.
The proper way to read a spreadsheet
The fix isn’t a cleverer shredder. It’s not shredding. A workbook should be read the way you read it:
- Find the right file first, by walking the drive and reading names and dates, not by similarity.
- Open it and take in the shape: which tabs exist, where the headers sit, where the table actually starts.
- Read values with their labels still attached, so a number never travels alone.
- Cite the source as file, tab, cell, so anyone can check in ten seconds.
- If two versions disagree, say so. Never silently pick one.
flowchart TB
subgraph S[The shredder]
direction TB
A1[Workbook cut into text chunks] --> A2[Numbers detach from their labels] --> A3[Right figure, wrong meaning]
end
subgraph P[The analyst's way]
direction TB
B1[Find the right file on the drive] --> B2[Read the tabs and headers] --> B3[Number cited by file, tab, cell]
endOne vendor question does most of the diligence for you: when your system quotes a number from a spreadsheet, can it show me the file, the tab, and the cell it came from? If the honest answer boils down to “we convert your documents into embeddings,” your workbooks are being shredded on the way in, and no amount of model quality downstream repairs shredded input.
What I’d tell your CFO
Every AI tool we evaluate will search our files before it answers, and the search method decides whether the answer can be checked. There are four methods and each fails differently, but the expensive failures come from feeding spreadsheets into a search built for prose. So make every demo answer one question: show me where that number came from, down to the file, the tab, and the cell. A system that can point at the cell can be audited. A system that can only gesture at similar documents can’t. Checkable beats fluent.
This is part of a series explaining AI and the systems around it for finance people, in their own language. I build AI systems for finance teams; the series is what I’ve learned doing it.