F&B POS and Ordering Systems in Singapore: Custom vs SaaS

Whichever route you choose, test these four points in a demo with your own menu and a real bill.

GST on service charge. IRAS states that service charge is part of the total price and is subject to GST. Its guidance for the hotel and F&B sector works through an example: S$100 of food, a 10% service charge of S$10, and 9% GST on S$110, giving S$9.90 of GST and a total of S$119.90. Your system must calculate in that order and keep it right through discounts, split bills, voids and refunds.

Price display. GST-registered businesses must generally show GST-inclusive prices. The same IRAS page sets out the exception for hotels and F&B outlets that impose a service charge: they may display GST-exclusive prices, provided they show a prominent statement that prices are subject to GST and service charge. The concession does not apply to outlets that charge no service charge, and takeaway-only items without service charge must be shown GST-inclusive. Your QR menu, delivery menu and printed menu all need to follow the rule that applies to you.

InvoiceNow. IRAS is phasing in a requirement for GST-registered businesses to submit invoice data through InvoiceNow. According to the IRAS GST InvoiceNow page, as of October 2026 it applies to new voluntary registrants, and existing GST-registered businesses join in stages from 1 April 2028 (annual supplies up to S$200,000) to 1 April 2031 (above S$4 million). IRAS also notes that businesses may aggregate supplies data from point-of-sale systems before submitting. Ask any vendor how its system will produce that data and through which Access Point provider.

Marketing consent. QR ordering makes it easy to collect phone numbers. Sending promotional SMS or WhatsApp messages to Singapore numbers brings in the PDPA's Do Not Call rules: you must check the DNC Register unless you hold clear and unambiguous consent in evidential form, as the PDPC's advisory guidelines on the Do Not Call provisions explain. Put a separate, unticked consent box in checkout and store the evidence with a timestamp.

Where SaaS fits well

• One outlet or a handful, with a standard menu.
• Counter service, table QR ordering and takeaway, with common modifiers such as size, sugar level and add-ons.
• Card and QR payments through the vendor's integrated terminals.
• Standard reports: daily sales, item mix, shifts and cash-up.
• No appetite for owning servers, updates or support.

You pay a subscription per outlet or terminal plus payment fees, and you trade control for speed. Before you sign, ask for a full export of orders, items and customer records in CSV or through an API, and read the minimum contract term.

Where SaaS starts to pinch

• Multi-brand kitchens. One central kitchen producing for several brands, each with its own menu, prices and delivery listings, often fights a product designed around one brand per outlet.
• Ordering as part of the product. A loyalty app, meal subscriptions, a corporate catering portal with credit terms or pre-order windows go beyond what most counter POS products are built for.
• Data you can join. You want order-level data in your own database, alongside inventory, staffing and marketing spend. Vendor reports stop at what the vendor chose to build.
• Fees that grow with outlets. Per-terminal and per-outlet pricing compounds as you add kiosks and locations.
• Integrations. Connecting your accounting, inventory or ERP depends entirely on what the vendor's API exposes.

A custom F&B system has more moving parts than the ordering screen suggests:

• A menu and modifier engine covering combos, time-based pricing and outlet-specific availability.
• Ordering channels: QR web ordering, kiosks, staff tablets, and a customer app if loyalty matters, which is where mobile app development comes in.
• A kitchen display with routing by station, so drinks and mains reach the right screen.
• Payments through a licensed payment provider's terminals and hosted checkout. Your own code should never handle raw card numbers.
• An offline mode, so orders keep flowing when the internet drops and sync when it returns. We built that pattern into SchoolBill, a Windows fee app for a multi-branch private school in India that keeps taking student entries offline and uploads them once the connection is back. Different industry, same engineering problem.
• Tax and receipts: service charge before GST, rounding, refunds and an InvoiceNow-ready data export.
• Reporting and an accounting integration.

Plan for roughly 12–20 weeks for a first release covering ordering, kitchen display, payments and reporting for one brand. A customer loyalty app adds to that. Our AccVora billing product, built for Indian businesses, has modules that switch on by business type, restaurants among them. Singapore's GST rules differ from India's, so tax logic would be written to IRAS rules, but the order-to-receipt flow is familiar ground for us.

The hybrid many groups choose

Keep a SaaS POS at the counter for payments and day-to-day reliability, and build the parts that differentiate you around it: your own ordering app, loyalty, a catering portal and a reporting database that reads orders through the POS vendor's API. This works only if the API is good, so ask for API documentation, rate limits and webhook support before you commit to either piece. Our custom software development work often starts here, because it lowers risk while you test demand.

If you were planning around the Productivity Solutions Grant, note the change. Enterprise Singapore's EDGE Grant page states that EDG, MRA and PSG ceased on 29 September 2026 and that applications from 30 September go under EDGE. The page also sets an overall cap of S$100,000 in grant support per company per year across all activities, refreshed each 1 April, paid on a reimbursement basis. Enterprise Singapore's FAQ adds that within that cap, up to S$30,000 can go to single-function digital solutions, integrated enterprise systems and pre-scoped equipment, that some activities require a pre-approved vendor, and that applications made after work starts or a deposit is paid are not supported. Check the activity that fits your project before you sign anything.

• How many outlets and brands do you expect to run in three years?
• Is the ordering experience something customers choose you for?
• Do you need to own customer data and loyalty, or is the vendor's version enough?
• What will the SaaS cost at your planned scale over five years, including payment fees?
• Can the SaaS export all your data and expose an API you can build on?
• Who will own a custom system after launch, in-house or under a support contract?

If most answers point to a standard setup, buy SaaS. If two or more point the other way, scope the hybrid first and build custom pieces only where the SaaS cannot reach.

Can our QR menu show prices before GST?

Only if you impose a service charge and display a prominent statement that prices are subject to GST and service charge. Otherwise, IRAS requires GST-inclusive prices on menus, websites and other price displays.

Do we need InvoiceNow for POS sales?

It depends on your GST registration date and size. Existing GST-registered businesses are phased in from 1 April 2028 to 1 April 2031, and point-of-sale supplies data may be aggregated before submission. Confirm your date with IRAS and your accountant.

Should a custom system process card payments itself?

No. Use a licensed payment provider's terminals and hosted checkout pages, so card data never touches your servers and your compliance scope stays small.

How long does a custom ordering system take to build?

Plan for 12–20 weeks for a first single-brand release. A hybrid built on an existing POS vendor's API is often quicker, because payments and counter hardware are already solved.

If you are weighing SaaS against custom for your outlets, talk to us about your setup. Send your menu structure, outlet count and current tools, and after a short discovery call we will send a written scope and a fixed quote for the parts worth building.