"Bhai, payment?" — how a distributor put its receivables on WhatsApp

In distribution, selling the goods is the easy half. The hard half is the money: dozens of dealer accounts on credit, outstanding bills living in an accounting export nobody opens, and follow-up that depends on whoever remembers to call.

For one multi-brand distributor (whose name we keep private), we rebuilt that back office around the channel every dealer already answers: WhatsApp. Here is what actually runs, from the deployed system.

No re-typing. The outstanding-bills export from the distributor's existing accounting package uploads as-is; the system recognises three different export layouts, keys every bill on party + bill number so a re-import never creates duplicates, and marks bills that vanish from a newer export as settled. The accountant's Tuesday-morning export becomes the single source of truth.

A reminder is a Meta-approved WhatsApp template in Gujarati with the party's name, the total pending, and up to 15 bills itemised — bill number, amount, days overdue — with "+N more" beyond that. Every send tracks QUEUED → SENT → DELIVERED → READ, and the status can never move backwards. In one production day the system processed 704 of those delivery-status ticks.

That last tick changes the conversation: you know the dealer has seen the bill before you call. And if a send fails, the system opens a follow-up task for a person — silence is never silent failure.

Dealer replies come in three shapes and all become claims: a button flow that asks for the UTR number, a payment screenshot (recognised when the party was reminded recently; multiple screenshots within minutes merge into one claim), or plain text — a 12-digit UTR, or "paid" phrases understood in English, Gujarati, and Gujarati typed in English letters.

A reply router sorts every message into five intents — paid with proof, paid without proof, a promise, a dispute, unclear — and promises and disputes open follow-up tasks automatically. Reconciliation stays deliberately human: accounts staff pick which outstanding bills a claim covers before anything is marked settled. The code's own comment says it best: "No auto-matching — a human picks."

A salesman records a collection on the spot — amount, party, cash/cheque/UPI/transfer, with GPS where the phone allows — and the dealer instantly gets a WhatsApp acknowledgement that says "received by our representative", deliberately not "credited". The owner then confirms or rejects each receipt, or a whole day's challan per salesman, and can correct the amount at confirmation (the receipt shows the original figure in brackets — nothing is silently edited).

On confirmation, the official receipt goes out with a number in the form RCP-YYYYMMDD-NNN, issued by an atomic counter in the same database transaction — unique, gapless, and safe even when two confirmations land at once. Every rupee collected in the field is on record the moment it happens.

Receivables are half of eJodee. The other half: a catalogue that builds itself from each brand's own online store (adding a brand is a URL, not an integration — 8 national brands run through it today), a visual-similarity finder that fingerprints every product photo by shape and colour to surface the closest in-stock substitute with a match percentage, branded reels and WhatsApp card packs generated from live data, and trade-specific order entry — predefined size sets, or "whatever sizes you have", resolved at picking with QR-scan pick-and-pack where the packer can never approve their own packing.

Role-based access runs through it all: salesmen see only their own parties, money screens need explicit permission, and the owner gets a live dashboard of pending receivables, overdue accounts, claims to check, and the week's collections.