A customer pays by PromptPay, screenshots the confirmation and sends it to your LINE. Someone on your team then scrolls through unpaid invoices, finds the one that looks right, ticks it and replies "received, thank you". Multiply that by every day of the month and it becomes a full-time job that nobody planned. This guide explains how PromptPay reconciliation can be automated in a way that stays safe, and where a person should always confirm.
The problem in plain terms
PromptPay made paying easy. For the shop, it moved the work to the other end. Money arrives in one place (your bank account), the proof arrives in another (a chat), and the thing it should be matched to lives in a third (your invoices or order list).
The usual process:
- The customer transfers money and sends a slip image on LINE.
- A staff member opens the image and reads the amount and time.
- They search invoices for a match, often by name or amount.
- They mark the invoice as paid and tell the customer.
- At month end, someone checks the bank statement against all of it.
Every step is manual, and the weak point is step 3. Two customers pay ฿1,500 on the same day. One types a different name. One sends a screenshot cropped so the time is missing. The matching is judgement work done in a hurry.
What a slip actually is
It helps to be exact. A payment slip is an image generated by the customer's banking app. It usually shows the amount, the date and time, a transaction reference, and the names or account details of the sender and receiver, sometimes partly hidden. Many slips also carry a small QR code intended for verification.
What a slip is not: confirmation that the money is in your account. It is a picture. Pictures can be cropped, reused or edited. So a safe process treats the slip as a strong clue and the bank record as the fact. This distinction shapes the rest of the design.
What can be automated
Four parts of the job are well suited to software.
Reading the slip
An automated reader takes the image from the LINE chat and pulls out the amount, date, time and reference number. Slips follow fairly consistent layouts, so this works well when the image is clear. It should also record how confident it was.
Finding the likely invoice
The system compares the extracted amount, date and any reference with your open invoices. If exactly one open invoice for that customer matches the amount, that is a strong candidate. If three match, it lists all three and asks a person.
Replying and recording
The system can reply to the customer immediately ("We have received your slip and will confirm shortly") so they are not left wondering, and attach the slip to the invoice record for your files.
Preparing the confirmation
The system puts the slip, the proposed invoice and the amounts side by side, so a person can confirm in seconds. This is the screen that replaces the scrolling.
What it should not do on its own is the last step: declaring an invoice paid. We come to that below.
The failure modes you should plan for
Anyone who has handled slips by hand has met these. A good system names each one and defines what happens next.
| Failure mode | What happens in practice | Safe handling |
|---|---|---|
| Unreadable slip | Cropped, blurred, glare, or a photo of a screen | Ask the customer politely for a clearer image; leave the invoice open |
| Partial payment | Customer pays half, or rounds down | Flag as mismatch; a person decides on balance or acceptance |
| Wrong or missing reference | Customer pays the right amount but cannot be identified | Show candidate invoices; a person picks one or asks the customer |
| Same amount, several invoices | Two ฿1,500 invoices outstanding | Never auto-pick; list all candidates for a person |
| Duplicate slip | The same slip sent twice, or reused for another invoice | Match on reference and amount; flag any slip already used |
| Overpayment | Customer pays more than the invoice | Flag; a person decides on credit or refund |
| Edited or fake slip | Image altered to show a payment that never happened | Confirm the money in your own bank record before releasing goods or marking paid |
| Late or out-of-order | Slip arrives hours after the transfer, or before the invoice exists | Hold as unmatched until a person or the invoice catches up |
Notice what these have in common: every one ends in "a person decides" or "ask the customer". The goal of automation here is not to eliminate judgement but to put the judgement in front of the right person with the right information.
The human-in-the-loop "mark as paid" step
The safest design is simple. The software proposes. A person confirms.
The mark-as-paid step works like this:
- The system presents the slip image and the proposed invoice side by side, with the amounts and times highlighted.
- The person checks your own bank app or statement for the credit.
- They press "mark as paid". The invoice closes, the customer is notified and the job or order can proceed.
- If the money is not there, they press "not received". The invoice stays open and the system drafts a polite message.
It takes seconds per slip instead of minutes, and the risky decision stays with someone accountable. The reason is simple: a screenshot is not a bank credit.
If your bank or payment provider offers a way for businesses to receive payment notifications or verify slips, that can sit alongside this step and reduce how often a person has to check by hand. What is available varies by bank and by your account type, and we do not assume it. We find out what yours supports during the scoping call, and design for the version that works with or without it.
Make matching easier before you automate
Many matching problems are avoided before the slip exists.
- Generate a payment QR per invoice with the exact amount. The customer scans, the amount is fixed and typing mistakes disappear.
- Put the invoice number in the message you send with the QR, so the customer sees it, even if it does not appear on the slip.
- Avoid several invoices of identical amounts to one customer at the same time, or accept that a person will resolve them.
- Ask customers to send the full screenshot, not a crop.
- Send one clear confirmation message, so customers stop sending the slip twice.
None of these requires new software. All of them make the software more accurate.
A worked example: a cleaning booking paid in advance
Here is a typical sequence for a service business that takes payment before the visit.
- A customer books a deep clean for ฿2,400 and receives an invoice and a PromptPay QR for that amount.
- They pay and send the slip on LINE.
- The system reads ฿2,400, today's date and a reference, and finds exactly one open invoice for that amount and customer.
- It replies: "We have your slip, thank you. We will confirm shortly."
- In the admin view, a coordinator sees the slip beside the invoice, checks the bank app, and presses mark as paid.
- The booking moves to confirmed, the customer gets a confirmation, and the slip is saved with the record.
If at step 3 the amount had read ฿1,200, the invoice stays open and a person is asked to decide. If the same slip appears again tomorrow, the system flags it as already used. Our work on this lives in the integrations service, and chat intake can come from a LINE OA automation set-up.
What about privacy and accounting?
Slips contain personal and financial details. Decide who may view them, how long they are kept, and keep them out of group chats where possible; our guide to PDPA basics for a Thai website covers the general principles, and your lawyer should confirm what applies to you.
On the accounting side, matching a payment to an invoice is bookkeeping support, not tax advice. How you record income, issue receipts and file is a question for your accountant. A good integration hands clean, matched records to whatever accounting package you use, such as Xero or QuickBooks, and leaves the rules to them.
What it costs and how long it takes
This is usually an integration project: a reader, a matching rule set, an approval screen and a link to your invoicing tool. DigitalRova publishes integrations and automation work from ฿39,000, typically in 2 to 3 weeks, with the final price fixed in writing after a free scoping call. The volume of slips, the number of channels and the tools you invoice from change the scope. Third-party costs are listed separately at cost. See the pricing page for the full picture.
If you want to see where your slips go missing today, tell us how your payments flow and we will say honestly what can be automated and what should stay with a person.