Most spending apps tell you "You spent $342 on groceries last month." That's it. They don't keep the milk-by-milk, store-by-store detail that you actually need six months later, when the real question is "which store has the better deal on this brand?" or "has travel spending crept up since last year?"
I built one that does. Snap a receipt, paste an online order confirmation, or just type "Lunch yesterday $12," and every line item gets pulled apart and saved with date, store, product, price, and category. The AI handles the extraction. Postgres stores it cleanly. SQL turns it into answers.
The Receipt-to-Database Pipeline
Four stages · one round-trip · under 5 seconds
All decision-making is AI-driven. Persistence and a duplicate safety net are deterministic code.
The receipt is just the entry point. The real value is being able to ask the data anything, six months later, in plain SQL.
Every line, not just the total
Most apps log "$24 at Whole Foods" and move on. Mine records every line on the receipt ($4 milk, $3 bread, $5 eggs), each as its own row, with the date, store, category, and subcategory attached. That's why I can ask, six months later, "has milk gotten more expensive at Whole Foods?" or "where do I get the best price on coffee?" The detail is the whole point.
The whole rulebook lives in the database, not the code
This is what makes it agentic. Traditional AI apps bake their prompts into the source code, so changing the AI's behavior means rewriting and redeploying. Here, both the standard rules and the time-limited overrides (like "for Jan 7–9, everything counts as Travel") live as rows in the database. The agent re-reads its rules on every call, so behavior changes the moment I edit a row.
A RAG pattern over my family's own purchase history
This is a textbook Retrieval-Augmented Generation (RAG) setup, but the "knowledge base" isn't Wikipedia or some scraped corpus. It's my family's own past spending. Before the AI sees a new receipt, the backend retrieves the last 300 transactions from Postgres, formats them as a compact log, and injects them into the system prompt as context. So when "Starbucks" shows up again, the AI sees that previous Starbucks entries were filed under Dining / Coffee Shop, and follows the pattern. Categories stay consistent across thousands of rows, which is exactly what makes period-over-period comparisons trustworthy.
Two-layer duplicate detection
Submit the same receipt twice and the system catches it. Twice. First, the AI looks at your last 300 transactions and flags anything that looks like a repeat. Then Python double-checks by date and amount over the last 30 days. If either layer spots a likely duplicate, you get a "did you mean to record this again?" prompt before it saves. Clean data going in is what makes the answers trustworthy coming out.
One household, many phones, one database
My partner records dinner from his phone. I scan a grocery receipt from mine. Both entries land in the same shared database, tagged with our family ID. Joining the household takes a 6-character code. One tap.