← The Catalogue desktop app
No. 13

A payment-run validator that clears the approver's anomaly check in minutes, not hours

A local, deterministic desktop app that reconciles a payment run against history and produces a tamper-evident audit report — without ever exposing bank data to an LLM.

PythonDesktop GUIpandasSHA-256 hashingReportLab PDFdeterministic rule engine
How it works — the logic, animateddesktop app

Context

Every payment run, each approver has to satisfy themselves that nothing in the file is wrong before they release money — a changed bank account, a step-up against the vendor's historical payments, a duplicate, an amount that doesn't fit the pattern. Done properly, that anomaly check is eyeballing a payment file against history line by line. It takes 30–40 minutes per approver, every run, and it's exactly the kind of slow manual control that either becomes a bottleneck or gets rubber-stamped.

Challenge

Speed it up without weakening it — and do it on data you cannot hand to a model. Bank statements and account numbers can't be pasted into an LLM; the validation also has to be *deterministic and explainable* (an approver releasing money needs the same answer every time, not a probabilistic one). And whatever clears the run has to stand up later: an auditor will ask which exact file was approved, by whom, and when.

What I built

A local Python desktop app with a GUI an analyst can run without training. The workflow is two clicks: select the payment-run file, select the history to check it against — and the full reconciliation runs on the machine, nothing leaving it.

  • Deterministic rule engine — flags bank-account changes against history, step-ups versus a vendor's historical payment pattern, duplicates, and amount anomalies. Same input, same result, every time — and every flag is explainable, not a black-box score.
  • Local and private by design — runs entirely on the desktop. Sensitive bank data is never sent to any model or external service. This was a deliberate choice: the job called for determinism and confidentiality, so it gets a tool, not an AI.
  • Tamper-evident audit trail — the app records the files used, the username, and the timestamp, and stamps the SHA-256 hash of each input file, so there's no ambiguity later about exactly which version was validated.
  • Beautiful PDF audit report — a clean report generated alongside each payment run, carrying the full audit trail and the anomaly findings, ready to attach to the approval.

Outcome

The per-approval anomaly check dropped from 30–40 minutes a run to about 5 minutes — and the control got *stronger*, not weaker: every release now carries a hash-verified, timestamped audit report instead of a tired analyst's word that they looked. The bottleneck in the payment run is gone, and the audit question — "which file did we approve, and who approved it?" — answers itself.

Why it's here

Judgement about the right tool for the job: sensitive money data doesn't go near a model, it gets a deterministic local app with a real audit trail. I build controls that are faster *and* harder to fudge — and that an auditor can verify, file by file.

© Deepak Sharma — Finance Transformation ca.deepaksharma1@gmail.com Back to the catalogue →