I've watched a 50-person manufacturing company pay the same vendor twice in three months. Not because their finance team was careless. Because the person who remembered the first payment had left, and nothing in their AP software remembered it for her.
Accounts payable automation exists. Ramp, Tipalti, SAP — there are tools for this. But the tools that exist are built for companies with procurement teams, ERP integrations, and dedicated finance staff. A 50-person manufacturing company in Pune processing invoices from 30 vendors in a shared Gmail account is not their target customer.
For that company, the invoice processing problem isn't paperwork volume. It's institutional knowledge loss. The person who knows that CloudHost India submitted duplicate invoices twice last year, or that Prakash Office Supplies always invoices on Net-30 when the contract says Net-45 — that person is the only line of defense against vendor billing mistakes and fraud. When they leave, the company pays for every pattern they knew that no one else did. I built Finley because I wanted to see if that knowledge could live somewhere more durable than one person's memory.
What "Institutional Knowledge" Actually Means in Practice
Every senior accountant carries a mental model of each vendor they work with. Prakash has a history of small billing discrepancies. That one supplier always rounds up on partial deliveries. This vendor tried to get paid twice for the same job last quarter.
None of this is in any system. It lives in the accountant's head, maybe in sticky notes, maybe buried in email search. It's not structured, not searchable, and not transferable. When I started mapping out what Finley needed to do, I realised that building another invoice checker wasn't the point. The point was making this knowledge structural — capturing it every time a human makes a decision, and feeding it back into every future decision about the same vendor.
I used Hindsight for the memory layer. Every invoice interaction gets written to Hindsight's memory API under a vendor-scoped namespace:
const memoryEntry = {
invoiceId,
vendorName,
date: new Date().toISOString(),
amount: extracted?.totalAmount,
paymentTerms: extracted?.paymentTerms,
agentDecision: decision?.verdict,
userAction, // "approved" | "rejected" | "overridden"
correctionNote, // "confirmed duplicate" / "wrong terms per contract"
flags: decision?.flags || [],
};
await storeMemory(vendorName, memoryEntry);
After 10 invoices, the vendor memory contains a structured history of every interaction: what the agent decided, what the human did, and why. That history feeds directly back into analysis of the next invoice from the same vendor. The system doesn't get smarter in general — it gets smarter about this vendor, specifically, based on what it has learned from every prior interaction.
The Before and After That Makes It Concrete
I structured the demo as two acts deliberately, because the contrast is where the value becomes undeniable.
Act 1: Process invoice #1 from a new vendor. The agent has no memory. It runs generic checks, finds no issues, approves. Zero memory recalls. Perfectly reasonable behaviour — it simply has nothing to go on yet.
Act 2: Process invoice #10 from Prakash Office Supplies after nine prior interactions have been stored. The agent retrieves all nine, detects the duplicate invoice pattern — same amount submitted three weeks ago under a different ID — flags the payment terms mismatch (Net-30 invoiced against Net-45 contracted, a correction that had been made twice previously), and holds the invoice for review. Nine memory recalls. Completely different outcome.
Same vendor. Same code. Same pipeline. The difference is accumulated knowledge. When I've shown this to anyone who has worked in finance at a small company, the reaction is immediate: "We've paid for this exact problem." Duplicate invoices from vendors counting on the fact that no one's tracking. Payment terms that drift because the vendor knows accounts payable is too busy to check the contract.
Why Not Just Use a Database?
The obvious question I kept getting: why use Hindsight agent memory instead of writing vendor history to a Postgres table?
Because the retrieval problem is semantic, not exact. When the analyser asks whether this vendor has had payment terms issues before, it's not running a WHERE clause. It's asking a question about a pattern that might be expressed differently across entries: "corrected payment terms", "wrong terms per contract", "terms mismatch flagged by reviewer". Those are the same signal written three different ways by three different people at three different times.
Hindsight does semantic retrieval — it returns the most contextually relevant memories for a query, not just exact field matches. That's what makes the LLM analyser able to surface patterns that weren't explicitly indexed when they were stored. You could build this with a raw vector database and your own embedding pipeline. Hindsight is that, packaged as an agent-optimised API. The difference in implementation time is significant and the retrieval quality is better than what I would have shipped on my own.
The Market Gap This Fits Into
There are roughly 5.5 million small businesses in India with 10–250 employees. Most of them process invoices manually. The tools built for enterprise finance don't fit their workflow, their price point, or their technical capacity. They don't have an ERP to integrate with. They don't have an IT team to run a deployment.
What they do have is a finance person — often one person — who is the living memory of every vendor relationship the business has. Finley is not trying to replace that person. It's trying to make sure that when they go on leave, or leave the company, or just have a bad week, the knowledge they carry doesn't disappear with them.
A system that takes 30 minutes to set up, works with existing invoice formats — PDF, image, email attachment — and gets measurably better at catching vendor-specific billing issues over time, with no ERP integration required, serves a market that existing tools have actively ignored.
What I'd Do Differently
Start with memory architecture, not the pipeline. I built the 8-step pipeline first and bolted memory onto steps 3 and 8. In hindsight — no pun intended — the memory layer should have been designed first. The pipeline exists to serve the memory loop, not the other way around.
Structure correction notes at write time. Early versions stored correction notes as free text. Retrieving "Net-45 per contract" when the query is about payment terms works. Retrieving "reviewer fixed the terms again" does not. Structured fields for correction type and corrected value made retrieval dramatically more reliable.
Vendor-scoped retrieval beats global retrieval. I tried global semantic search early — retrieve the most relevant memories across all vendors and rank by similarity. It surfaced patterns from unrelated vendors that confused the analyser more than they helped. Filtering by vendor at retrieval time, then ranking by semantic similarity within that filtered set, was the right architecture.
The feedback loop compounds fast. I expected months of data to be needed before memory made a meaningful difference. In practice, five to seven interactions per vendor was enough to see the pattern detection improve noticeably. The system earns trust faster than I expected.
The memory is the moat. Any business can run the same LLM. Any business can build the same pipeline. What they cannot quickly replicate is two years of vendor-specific corrections, dispute resolutions, and payment term overrides stored in a system that actually uses them at decision time. That accumulated history is the durable part of the product.
The full agent is running at finley-rho.vercel.app. The Hindsight memory documentation covers the retrieval architecture in detail if you want to understand how vendor memory actually works under the hood.
Top comments (0)