How to match payment receipts that arrive over WhatsApp, automatically with AI

The customer pays and sends the screenshot. Not to the finance inbox: to the chat of the salesperson they always talk to, because that is where the conversation is. The salesperson sees it, says thanks, and forwards it to finance when they remember.

Then somebody opens the bank statement, looks for a movement with that amount, finds it among fifteen others that look alike, and allocates it by hand to the customer and the invoice.

How it is done today

Five steps, none of them difficult: receive the screenshot, read the amount and date, open the statement or the online banking, find the movement that matches, and post the allocation against that customer's open invoice.

The expensive one is the fourth. On any given day there are ten or twenty incoming transfers with similar amounts, some with a reference and some with nothing, and you have to decide which is which. That is not done in a hurry, so it gets done when there is a moment.

And meanwhile three things happen, all of them costly.

The payment sits unallocated for days, so the balance the salesperson sees when they go to sell again is wrong. They chase somebody who has already paid, or they sell to somebody more exposed than the system says.

The receipt lives in a conversation. When two months later you have to show when something was paid, you have to ask the salesperson for a screenshot.

And whatever does not match gets found at month end. A transfer for an amount different from the invoice is a conversation that needed to happen the day it landed, not thirty days later.

What the technology does, concretely

It reads the image. Amount, date, originating bank, destination account and reference number, from the screenshot or from the PDF receipt. The same if it arrives rotated, cropped or badly shot, which is how they arrive.

It finds the movement in the account. It cross-checks what it read against credited movements and against that customer's open invoices in your management system.

It proposes the allocation. It leaves which customer and which invoice it corresponds to set up, with the amount, the date and the identified movement in view, ready to approve with one click. Whatever does not reconcile, it flags.

It files the receipt where it belongs. Attached to the customer and the invoice in the system, not in a conversation. Two months later you find it by looking up the invoice.

It updates the balance. Once the allocation is approved, that customer's account is current, so the salesperson sees the real balance when they go to sell.

What changes

The payment is allocated the day it lands instead of next week, and the receipt stops living in a salesperson's phone. The finance person stops hunting for movements and starts approving proposals, which is a job that takes seconds.

The case that comes up most

The partial payment. The customer transfers less than the invoice says because they are deducting a credit note they have in their head and nobody issued. The agent flags the difference the day it lands, and that turns a month-end problem into a two-minute question.

Where it does not go alone

On the approval. The agent proposes and a person confirms, and that confirmation is recorded. It is not a formality: an allocation moves a customer's balance, and a balance moved wrongly generates a chase to somebody who owed nothing.

And on payments that cannot be identified. A transfer came in with no reference and there is no way to tell whose it is: that becomes a case with an owner, and the customer can be asked from the same conversation where they buy. What the agent does not do is guess who to allocate it to.

Where to start

With the channel receipts arrive through today, which is usually the salespeople's WhatsApp. Nothing has to change for the customer: what changes is where the photo lands and what happens to it in the next ten minutes.