Reconciliation Investigator

nspiration Hackathons force you to ship something real in very little time. That pressure is what made this project exciting.

Finance teams still spend hours on small mismatches: the books say ₹10,000, the bank received ₹9,700, and someone has to hunt through three systems to find out why. Matching software can flag the gap. It rarely explains it.

We wanted a tool that investigates like a careful analyst: look at the facts, test a few likely causes, try to prove itself wrong, and say “I don’t know” when the evidence is thin.

What it does Reconciliation Investigator takes three files:

ERP — what the company booked Payment gateway — what the customer paid, including fees and refunds Bank — what actually landed in the account Ordinary Python code loads the files, cleans IDs and amounts, and matches related records. Clean matches stop there. Only the mismatches become investigations.

For each mismatch, the investigator works through a fixed list of causes (it cannot invent new ones):

Gateway fee Refund Timing difference (settlement not in yet) Manual adjustment Duplicate or missing transaction Unknown It pulls facts with lookup tools (fee, refund, bank settlement, related records). It also checks simple memory: a SQLite store of previously resolved cases with a similar pattern. Past cases can support a conclusion. They cannot override what the current records show.

Then it challenges the leading answer. Example: if it thinks “gateway fee,” it checks that the fee is recorded, that ₹10,000 × 3% = ₹300, that ₹10,000 − ₹300 = ₹9,700, that there is no refund, and that settlement is on time.

The output is an explanation first, then a recommendation:

Auto-resolve (only when confidence is high and the math holds) Wait for settlement Send to a person If no cause is strong enough, it returns unknown and asks for human review. It never auto-resolves just because one weak guess scored higher than another.

Hero example: ERP ₹10,000, gateway ₹10,000, bank ₹9,700 → gateway fee ₹300, high confidence, auto-resolve.

How we built it Two layers, on purpose:

Money and matching stay in Python. Loading CSVs, cleaning invoice IDs, comparing amounts, calculating fees, and fetching records are all deterministic. The model never does the arithmetic and never invents a transaction, fee, refund, or past case.
Investigation is a short, checkpointed workflow. Plan the allowed causes → collect evidence → score each cause → challenge the leader → recommend an action. If a person needs to review, the run pauses. After a final decision, the case is written to memory.

The UI is a Streamlit control room: explanation, evidence for and against, alternatives that were rejected, live investigation path, and a human-review step.

We used mock CSVs, not live bank or ERP connections. That kept the demo honest and finishable in hackathon time.

Challenges we ran into Keeping AI in its lane. It is easy for a model to “explain” a number it made up. We had to force every claim back to a source record or a Python calculation.

Bounded causes vs. open-ended guessing. A free-form “why” chain would look smart and be unsafe. Locking the six hypotheses was a design fight we had early.

Simple memory without overclaiming. Similar past cases help, but a past fee pattern must not hide a refund on this invoice. Memory is supporting evidence only.

The challenger. Agreeing with yourself is easy. We had to encode checks that can lower confidence or force review, including treating “record not found” as a real finding, not as proof that a cause is true.

Safe “I don’t know.” The hard demo case is competing or missing evidence. The product only works if it abstains instead of picking a winner anyway.

Time. Building matching, investigation, memory, challenge, and a demo UI in one weekend meant cutting live integrations and fancy search. SQLite plus clear rules was enough.

Accomplishments that we're proud of A full path from three CSVs to an auditable explanation, not just a match score. AI that ranks and writes, while Python owns money. A short hypothesis list that still covers the demo: fee, refund, wait, duplicate, unknown. Simple memory that remembers how similar cases were closed. A challenger that tries to break the leading answer. Human review when the evidence is not good enough. A UI that leads with why, not a percentage. What we learned Unexplained mismatches are an investigation problem, not a matching problem.

Trust in finance comes from traceable facts: source, record ID, calculation, and what was missing. Confidence is extra, not the product.

A small, fixed cause list plus a “try to disprove it” step is more useful than an agent that can wander forever.

“Not found” is evidence. Silence is not proof.

For a hackathon, the winning cut was: mock data, simple memory, strict rules for auto-resolve.

What's next for Reconciliation Investigator More real-world patterns (FX, chargebacks, partial settlements) without letting the cause list grow wild. Connect to live ERP, gateway, and bank feeds after the investigation rules are stable. Richer memory (still rule-based similarity, not a black-box search). Stronger audit export so a reviewer can replay every fact and check. Keep auto-resolve narrow: high evidence, small amounts, no contradictions.