Restaurant billing software: split bills, ++ and tax invoices
What restaurant billing software has to handle at a Thai checkout: splitting a bill without re-keying it, 10% service charge and 7% VAT, PromptPay next to card, and full tax invoices on request.
Restaurant billing software is judged on the last three minutes of a meal, not on how fast it rings up a pad thai. Four things decide whether it holds up on a Friday: splitting a bill by item without typing it twice, putting service charge and VAT on the bill correctly (10% then 7%, which is why ฿1,000 of food prints as ฿1,177), taking PromptPay, card and cash against the same bill, and issuing a full tax invoice when a guest asks after you already closed it. Test those four before you sign anything.
Every restaurant billing system gets judged on the same three minutes: from the moment a table catches your eye and asks for the bill to the moment the money is actually yours. That is where a Friday service either flows or jams, and it is the part almost nobody tests before signing. So this is a practical look at what restaurant billing software has to handle in Thailand: splitting a bill across four phones without typing it twice, service charge and VAT on the bill correctly, PromptPay sitting next to card and cash, and the full tax invoice a guest asks for ten minutes after you closed the table. Real numbers, in baht.
What restaurant billing software actually has to do
Strip the branding and the checkout has six jobs.
- Print a bill a guest can read. Items, service charge and VAT, in a layout that does not invite an argument.
- Take more than one tender against one order. Half on card, half on PromptPay, ฿200 in cash, one bill.
- Split the total. Evenly or by item, without re-keying anything.
- Issue the right document. A receipt for most guests, a full tax invoice for the ones expensing dinner.
- Record who touched the money. Voids, discounts, refunds, drawer opens, with a name and a timestamp against each.
- Reconcile to the bank. What you rang, what settled, and the gap between them.
Notice how little of that is "ring up an item". Ringing up is a solved problem and every POS on the market does it. The checkout is where systems actually differ, and it is the part your staff repeat two hundred times a week.
The Thai bill: why ฿1,000 of food prints as ฿1,177
If your menu is quoted "++", the arithmetic runs in a fixed order. Service charge, commonly 10%, goes on the food and drink subtotal. VAT of 7% is then calculated on the combined figure, because service charge is part of the taxable value. So ฿1,000 of food becomes ฿1,100, and the bill lands at ฿1,177. Quoting net instead is a perfectly good choice, and plenty of neighbourhood restaurants do it, but then the 7% is already inside the menu price and the bill has to show that clearly rather than leave the guest guessing.
Two numbers worth having straight. VAT is 7%, a reduced rate renewed by royal decree rather than a permanent one, most recently to 30 September 2026, so it deserves a glance each year instead of an assumption. And you only charge it if you are VAT registered, which becomes compulsory once turnover passes ฿1.8 million a year. Below that, a restaurant that adds 7% to a bill is collecting something it has no right to collect.
The part to configure once and then forget is the exceptions. Service charge on a dine-in table, none on takeaway, none on delivery, and none on a partner channel where the platform sets the price. In Papaya POS those channel rules are built in, so a takeaway order simply does not attract service charge, and individual items such as bottled water or a retail jar of chilli paste can be marked exempt. That matters because the alternative is a cashier remembering the rule at 8pm, and cashiers under pressure remember the rule about 90% of the time.
Splitting a bill without re-keying it
Splitting evenly is easy and every system can do it. The case that separates good billing software from bad is six people, one shared bottle of wine, two paying by card and four by PromptPay, one of whom only had the salad.
What you want is to split by item, drag the wine across the shares, and take a different tender for each. What you get in weaker systems is a second bill typed from scratch while the queue builds behind it. Put three minutes on that, twice a night, twenty five nights a month, and you have handed two and a half hours to a data-entry job that a checkout should have absorbed.
Papaya handles both modes at the till, evenly or by items, and when the table ordered through QR ordering the guests can split it themselves on their own phones, which removes the staff member from the transaction entirely. Two honest limits: a guest paying on their phone cannot hand over cash and cannot generate a full tax invoice without a person, so the guest app tells them to order with staff in both cases. And where a bill posts to a hotel room through a property system, split payments may not be supported at all, which is a constraint of the PMS rather than the POS.
PromptPay, card and cash against one bill
Thailand has already made this decision for you. PromptPay clears more than 74 million transactions a day, and in a restaurant it now sits alongside card and cash as a default rather than an alternative. A checkout that treats QR as a special case is a checkout designed for a different country.
Practically, the tender list a Thai restaurant needs is: card, PromptPay, cash, the wallets your guests actually use (TrueMoney, LINE Pay, ShopeePay, WeChat Pay and Alipay for tourist-heavy rooms), and a slot for the venue's own tenders such as staff meals, vouchers or a hotel room charge. Papaya Pay covers those methods, and on Thai plans the EDC terminal and a printer are included with a Starter or Pro subscription rather than sold separately, which changes the hardware maths more than most quotes admit. Check the current plans for what is bundled.
Delivery is where you should read any vendor's claims carefully, including ours. Grab is a two-way integration and orders arrive in the same queue. Deliverect fronts several aggregators through one connection, and Lalamove handles your own delivery dispatch. LINE MAN, foodpanda and ShopeeFood are not native order sync today: staff ring those orders up against their own tender so the day reconciles on one screen, which is useful and is not the same thing as an API.
The tax invoice request that lands after you closed the bill
Most guests want a receipt. The corporate table wants a full tax invoice, and they usually ask after the payment has gone through.
A full tax invoice carries particulars a receipt does not: the words "tax invoice", your name, address and tax ID, the buyer's name and address, a serial number, a description of what was sold, and the VAT shown separately from the value of the goods, as set out by the Revenue Department. Handwriting that at the till is how numbers go missing.
The system should issue it against the closed order, keep the serial, print a seller copy for your own file, and let you reissue when the guest gives you the wrong company name, with the previous number voided rather than quietly overwritten. Papaya does exactly that, and every reissue is written to the order's action log with the user who did it. Your accountant will ask about a gap in tax invoice numbers eventually. It is a much shorter conversation when the answer is on screen.
Who is allowed to void, discount or reopen a bill
This is not about assuming staff are dishonest. It is about being able to answer "what happened on table 12" without guessing.
Give voids, refunds and drawer opens their own permissions rather than bundling them into a manager login that everyone knows the PIN for. In Papaya those are separate role permissions, including opening the cash drawer and printing tax invoices, and the actions land in an order action log: payment voided, payment refunded, tax invoice reissued, cash drawer opened, each with a user and a time. Then set a discount ceiling a floor supervisor can approve without calling you, and require a reason on anything above it. The log is worth more than the restriction, because the pattern is what tells you something (or someone) needs attention.
What "it balanced" means at 11pm
Three numbers have to agree, and they never agree on the same day.
Takings by tender is what the POS says you sold. Cash in the drawer is what you can count. The payout is what the bank actually pays you, a day or two later, net of processing fees, often lumped across several days. So checking the bank against last night's sales will always look wrong. The check that works is takings by tender against the payout report, run weekly, plus a nightly count of the drawer against the cash line alone. Papaya's insights include a payouts view for exactly that comparison.
If tender and payout agree but the drawer is short, you have a floor problem, not a payments problem. That distinction saves a lot of wasted suspicion.
Six checks before you commit to a checkout flow
Run these on a trial, in this order, and you will know more than any feature grid can tell you.
- Ring a ฿1,000 bill with service charge on and confirm ฿1,177 prints with the VAT stated separately.
- Split it three ways by item, moving one shared dish between shares.
- Pay one share by card and two by PromptPay, against the same order.
- Ring a takeaway order and confirm service charge drops off by itself.
- Ask for a full tax invoice after the payment is complete, then reissue it with a corrected company name.
- Void a payment as a regular staff login, watch it get blocked, do it as a manager, then find it in the log.
Frequently asked questions
What is restaurant billing software?
It is the part of a POS that closes a sale rather than opens one: it prints the bill, applies service charge and VAT, splits the total across guests, takes several tenders against one order, issues the receipt or the full tax invoice, and records who voided or discounted what. Most systems ring up items competently. They differ almost entirely at the checkout, which is also the only part a guest ever sees on paper.
How do service charge and VAT work on a Thai restaurant bill?
Service charge (commonly 10%) is added to the food and drink subtotal, and VAT of 7% is calculated on that combined figure, because service charge is part of the taxable value. That is what the "++" on a menu means, and it turns ฿1,000 of food into ฿1,177. If your menu prices are quoted net, the same 7% is already inside the number on the page and the bill should say so. You only charge VAT at all if you are VAT registered, which is compulsory once turnover passes ฿1.8 million a year.
Can guests split the bill themselves?
They can when the table ordered by QR. Papaya's guest app has a split option, so four people at one table can each pay their share from their own phone without a staff member standing there with a terminal. At the till, staff can split evenly or by items and take a different tender for each share. The two cases the guest cannot self-serve are cash and a full tax invoice, both of which need a person.
A guest asked for a full tax invoice after paying. Now what?
A full tax invoice needs particulars a receipt does not carry: the buyer's name, address and tax ID, a serial number, and the VAT shown separately from the value of the goods. So it has to be issued against the closed order rather than rewritten by hand. In Papaya you issue, reprint or reissue it from the order, and a reissue voids the previous number and logs it, which is what your accountant will ask about at month end.
Why don't my POS takings match what the bank paid me?
Because they are measuring different moments. The POS records the sale on the night, while card and QR payments settle a day or two later, net of processing fees, and often in one lump that covers several days. The check that actually matters is takings by tender against the payout report, done weekly. If those two agree, a gap between cash counted and cash rung is a floor problem, not a payments problem.
Test the last three minutes, not the demo
Vendor demos always start at the menu screen, because ringing up a burger looks good and takes eight seconds. Nobody demos a table of six splitting by item at 9:40pm while two more tables wait to pay, one guest wants a full tax invoice for a company dinner, and the card terminal has just timed out. That is the test, and you can run it yourself in twenty minutes on a trial. Ring a ฿1,000 bill with service charge on, split it three ways by item, pay one share by card and two by PromptPay, then ask for a full tax invoice after the fact. If that sequence is clean, the rest of the system is probably fine. If it needs a workaround, you have just found the thing your staff will be doing every night for the next three years.
Restaurant benchmarks
See how your revenue, check and food cost rank against your segment.
More on Running the floor
Coursing, floor plans, staff and service — the day-to-day of a busy room.