FDC: a WhatsApp bot that reads cheques and posts them into Busy

FDC (Fair Deal Corporation) is a distribution business. It was a team project, but the piece I built and owned independently is the WhatsApp cheque bot, so that’s what I’ll write about here.

The business problem first

The business wants every cheque, bill, and order to end up in their accounting software (they use Busy, a Tally-style accounting tool). The catch: they don’t want employees spending time learning accounting software. A trained person takes about 5 minutes to clear a single cheque in Busy. New employees — and staff rotates a lot — take 10 to 30 minutes, plus training time before that.

So the goal was simple to state and annoying to build: let an employee photograph a cheque, send it on WhatsApp, and have it settled correctly in Busy without anyone touching the accounting software.

What the bot does

An employee snaps a photo of a cheque and drops it in a WhatsApp group or chat. Behind the scenes the bot:

1. Extracts the cheque contents — amount (figures and words), date, cheque number, party, bank — using GPT-4o Vision.
2. Matches the party to the right account, including learned alternative names for the same party.
3. Fetches that party’s unpaid bills and settles the amount against them, oldest first.
4. Writes a receipt voucher straight into Busy.

Employees don’t wait for one image to finish before sending the next — they can fire off a whole stack at once, and the backend processes them in a queue.

The parts that were actually hard

OCR on real cheques is messy. Printed fields are fine; handwriting (date, amount, cheque number) is where accuracy drops. I tried more than ten different OCR approaches and providers — classical OpenCV pipelines, Tesseract, EasyOCR, and vision models — comparing extraction quality and cost. I even wrote it all up in the repo. The honest breakdown: catalog and party resolution land very high, and the accuracy we lose is almost entirely handwritten fields.

Measuring accuracy honestly. The accuracy numbers I quote aren’t from a lab. Every processed cheque is approved or disapproved by the operator in the dashboard, and the number is just approved / (approved + disapproved). Those same approvals feed a mapping table so party recognition keeps improving over time — a feedback loop grounded in real corrections, not a magic self-learning model.

Talking to Busy. Busy isn’t an API-first product, so I reach it over an RDP/SQL-Server bridge to read parties and unpaid bills and to write the receipt vouchers.

Stack

FastAPI backend, WhatsApp via the Evolution API, PostgreSQL with pgvector, Redis, and Nginx, deployed on GCP Compute Engine. The quotation side of the bot uses a small LangChain/LangGraph agent with pgvector + OpenAI embeddings to resolve catalog items from natural-language messages. Gemini is available as a second model through LiteLLM.

photo → Evolution API webhook → GPT-4o Vision extract
      → party match (+ alternative names) → fetch unpaid bills
      → settle oldest-first → write receipt voucher into Busy

What I took away

The interesting engineering here wasn’t the model — it was everything around it: making OCR reliable enough on handwriting to trust, matching fuzzy party names, and writing safely into an accounting system that was never meant to be automated. Getting a real business to stop doing 5–30 minutes of manual data entry per cheque was worth the unglamorous work.