BOOTINGJRV//SYSTEMS/
A single outlet closes its own day accurately. The trouble starts at the second one, because the group figure is now somebody copying numbers out of three point-of-sale exports and two delivery dashboards into a spreadsheet at ten in the morning, and each of those five sources treats a discount, a void and a commission differently.
F&B software here means a daily-takings ledger across outlets: each outlet day closed once with its sales by channel, its voids and discounts, its supplier deliveries and its stock movements, so the group number is a query instead of a morning of copying.
Start with what the word sales means in a group with delivery. A platform reports the gross order value, keeps its commission, and pays you a net amount on its own cycle days or weeks later. The till reports the dine-in total before the discount was applied or after it, depending on how the outlet was set up. Cash declared and cash expected differ by the float and by whatever happened at the counter. Add three outlets and the group figure becomes an act of interpretation performed by one person every morning, which means it is late, it is not auditable, and it breaks entirely the week that person is on leave.
Then food cost, which is where the money actually goes. A menu is priced once, usually at opening, and then chicken moves eighteen per cent and nothing on the menu moves at all. A dish is a recipe: specific quantities of specific ingredients at what those ingredients cost this week. Without the recipe held anywhere, food cost is computed monthly at the total level, which tells you the kitchen has a problem and never tells you which dish it is. The dish that is quietly losing money is almost always a popular one, because popularity is what made anyone stop looking at it.
Supplier invoices are the third leak and the most ordinary. Deliveries arrive with a chit, get checked by whoever is at the back door, and are priced later or not at all. A supplier who raises a price by forty sen a kilo is invisible for months because nobody holds the previous price to compare it to. A short delivery is an argument at month end that you lose, because the only record of what actually arrived is a signature on a chit in a drawer.
Fourth is labour, and it belongs next to the takings rather than in a monthly payroll total. F&B margin is decided by two lines — food cost and labour cost — and in most operations both are recorded outside the accounting system entirely. Hours sit in a roster app or a book by the time clock, takings sit in the POS, and the two are never put side by side for the same shift. A Tuesday that was overstaffed looks exactly like a Tuesday that was quiet until somebody puts those two numbers on the same row.
Restaurant software is usually a point-of-sale with reports bolted on, and a POS is built for the counter rather than for the group. These are the objects that have to exist after the day closes.
One outlet, from the last cover to the cash-up, plus the next morning's consolidation. We are watching what gets keyed twice, which export is trusted and which is argued with, and where the group figure actually comes from today.
The closing record first, with every channel modelled separately and settlement dates on the platforms. This is the object everything else reports off, so it goes in before any dashboard exists.
However the numbers actually arrive — an API where the platform exposes one, a daily export where it does not, keyed entry where nothing else is available. We check what your specific POS and platforms allow before quoting rather than promising an integration that turns out to be a CSV.
The twenty items that make up most of your covers, costed properly, before anything else is touched. A full menu costed badly is worth less than twenty dishes costed accurately, and it takes three times as long to produce.
Supplier records, a receiving screen at the back door, and price history per ingredient. This is the module that pays for itself first, because it makes a supplier's price rise visible in the week it happens.
Outlet against outlet, day against day, food cost and labour cost beside takings for the same period. One screen the owner opens at ten in the morning instead of a spreadsheet somebody has to build.
Your Supabase project, your Vercel account, your GitHub. Outlet-level trading history is the asset here, and it should not sit anywhere you cannot reach without us.
A restaurant is the clean case for LHDN's consolidated route: hundreds of receipts a day to individuals who do not require a document, reported as a periodic summary rather than as hundreds of validated invoices. F&B is not among the activities excluded from consolidation, so the route is genuinely available to you. What has to work is the exception. The corporate lunch, the company dinner, the customer claiming back from an employer — any of them will ask for a proper e-invoice carrying their company's TIN, and that transaction then has to leave the batch. A system that cannot promote a single receipt out of the summary leaves the counter choosing between refusing the customer and reporting the same money twice.
The multi-outlet question is the one groups get wrong, and it is decided before any software is chosen. If every outlet trades under one company and one TIN, the consolidated submission is one batch and the outlet is an internal dimension. If the outlets are separate entities, they are separate submissions with separate thresholds. Either way the outlet code has to sit on the record from the first day, because the reconciliation you will eventually be asked for is between the group's reported revenue and what was actually submitted, and that never closes if the outlet dimension was added later.
Delivery platforms need an answer in writing rather than an assumption. The platform sits between you and the diner, and who issues the e-invoice to the end customer — and what document passes between the platform and you — follows the commercial arrangement in your contract. LHDN's self-billed mechanism names e-commerce transactions and payments to agents, dealers and distributors among its defined situations. Which of those describes your platform relationship is a question for your tax agent and for the platform's own finance team, and it is worth asking both before the first consolidated submission goes in.
On the buying side the market supplier is the common case: acquisition from an individual taxpayer who is not conducting a business is one of the named self-billed situations, so a restaurant buying direct from a smallholder may be the party that issues the document. Separately, prepared food carries service tax where the operator is registered, at a rate that did not move with the general one — F&B stayed at 6 per cent when the standard service tax rate went to 8. The registration threshold is set by Customs and is exactly the figure to confirm with your tax agent rather than read off a website. The last e-invoice mandate band came into force on 1 January 2026 for turnover up to RM5 million, with those under RM1 million exempt.
Published tiers, seen from a group with more than one kitchen. Fixed price from scope, on your own accounts, with no per-outlet licence when you open the fourth.
The outlet day with sales by channel, platform settlement, purchases with price history, the group view, roles and audit trail. The module that ends the morning spreadsheet.
Enterprise tier. The above plus recipe costing, ingredient stock and wastage, labour against the outlet day, central kitchen transfers, consolidated and individual e-invoicing, migration and per-role training.
Starter tier. Five pages with the menu as real content rather than a photographed PDF, WhatsApp routing for bookings, and the Google Business Profile work that decides whether you appear in the map pack for your town.
