TallyMatch

Inspiration

Manually checking receipts against a bank or card statement is tedious and error-prone, which is exactly where mistakes like missing receipts, duplicate charges, or double-renewed subscriptions hide. TallyMatch was inspired by the need to help freelancers and small business owners who do their own bookkeeping. My goal was to build a secure solution that runs entirely in memory, with no login, no database, and no saved history—allowing users to simply upload, check, and be done.

What it does

TallyMatch is an application that accepts two CSV uploads: a bank/card statement and a list of receipts. It first matches bank transactions to unused receipts using exact-match code, checking if absolute amounts agree within one cent and dates are within three days. It then sends the remaining unmatched items, along with a list of already-matched pairs as background context, in a single OpenAI request using gpt-5.6-luna. The AI uses this context to compare the group and identify likely tips, fees, partial refunds, duplicate charges, and genuinely unexplained items, providing one plain-English reason per item. Finally, it displays all matched pairs and AI review items in one combined table.

How we built it

I started my development process by using Claude for my initial project planning and architectural design. I built the project over four days using Codex. I started by building and verifying a simple exact-match version with no AI at all. I then added the gpt-5.6-luna model specifically to handle the ambiguous, leftover cases. Instead of building everything at once and checking it at the end, Codex explained each change as it was made, and we verified each step against real test data before moving to the next one.

Challenges we ran into

I encountered challenges with Indian card restrictions blocking OpenAI's direct billing. To work around this, i routed our requests through AICredits, an OpenAI-compatible billing gateway. I controlled this using an optional OPENAI_BASE_URL variable, ensuring the app still successfully requests the gpt-5.6-luna model while bypassing the payment restrictions.

Accomplishments that we're proud of

I am proud of designing a system where transparent, repeatable exact-match logic runs first, reserving the AI's judgment strictly for ambiguity rather than having it redo the entire matching job from scratch. I have successfully implemented a privacy-focused, in-memory architecture where API keys entered on the page are never written to disk and are discarded as soon as the request ends. I have created a robust fallback mechanism so that if no API key is available, the exact matching still works and the app simply notifies the user that the AI review was skipped.

What we learned

I learned the value of incremental development, heavily relying on verifying individual steps against real test data (like our included fake bank statement and receipt files) before moving forward. I learned how to effectively blend hardcoded rules with an LLM to handle nuanced comparisons, such as teaching the system that a $25 bank charge matched to a $20 receipt is likely a tip, or successfully identifying a duplicate charge.

What's next for TallyMatch

Currently, receipts must be entered as CSV rows, which is a known limitation since real-world receipts are typically individual photos or PDF pages. The natural next step for TallyMatch is to build direct image or PDF upload capabilities with automatic data extraction.

Built With

• api
• claude
• codex
• css
• gpt-5.6-luna
• html
• javascript
• nano-banana
• openai
• python