QuickRecon
Automated bank & GL reconciliation for finance teams
When we started building QuickRecon (reconciliation automation for finance teams), I assumed the AI would do the heavy lifting. Feed it the transactions, let the model match them, done.
That was wrong, and it took us months to fully admit it.
Here's what we actually learned building it:
Throwing everything at an LLM gives you garbage. Reconciliation has to be exact and auditable - the same input must produce the same output every time. LLMs aren't deterministic, so using one as the "engine" means hallucinated matches and no audit trail. For finance, that's a dealbreaker.
The problem is layered, not single. What actually worked was:
Rule-based matching for the obvious stuff (amount + date + reference) — no AI, handles the bulk
Fuzzy matching for near-misses (shortened names, slightly-off references)
AI only for the leftovers, one transaction at a time — never the whole batch
A human reviewing exceptions only
The AI is maybe 10% of the system. The boring deterministic layers do the real work. The LLM just mops up the edge cases a person would otherwise chase down by hand.
The counterintuitive lesson: for a category everyone's slapping "AI" onto right now, our hardest and most valuable work was figuring out where not to use it.
Still early, still learning , curious if other founders building in regulated/high-accuracy spaces (fintech, health, legal) hit the same wall. Where did you decide AI shouldn't be in the loop?
1 Comment
You've made an interesting tradeoff by treating AI as the exception instead of the engine.
In domains where correctness matters, trust usually comes from making the predictable parts deterministic and reserving AI for the ambiguity humans would otherwise handle manually. That feels like a much more durable architecture than trying to make AI responsible for everything.