Restaurant Billing & Payments in Nepal: Getting Tax and Invoices Right
How restaurant billing should work in Nepal: turning a completed order into an accurate bill with tax and service charge, and clean digital payments.
A restaurant bill looks simple from the customer's side: a list of items and a total. From the owner's side, it's the one document that has to satisfy three different audiences at once: the customer who wants an accurate total, your own sales reports, and (eventually) a tax auditor. Getting the calculation right, consistently, matters more than almost any other part of restaurant software.
The bill is a formula, not a number you type in
The cleanest way to think about a restaurant bill is as a formula applied consistently to every order:
Grand Total = Subtotal + Tax + Service Charge − Discount
- Subtotal comes directly from the order's line items: quantity times unit price, summed.
- Tax should be calculated by a fixed rule, not typed in per bill. In Nepal, the standard VAT rate is 13%; whatever rate applies to your business, it should be applied the same way every time, not left to whoever's working the register that night.
- Service charge, if you apply one, follows the same logic: a consistent rule, not a manual guess.
- Discount is applied last and should always be visible on the bill itself, not silently baked into a lower subtotal.
The reason this matters isn't just tidiness. A bill where every component is calculated by rule is one you can defend later, whether to a customer questioning a total, to your own reporting, or to a tax audit. A bill where a cashier manually adjusted the total to "make the math work" is one you can't.
Why the order needs to be locked before billing
A bill should only be generated from an order that's genuinely complete. Practically, that means the order lifecycle we cover in our order management guide needs to reach its final stage before billing calculates anything. Otherwise you risk billing a table for an item that got cancelled mid-service, or missing one that was added late.
Once a bill exists, the order behind it should be treated as historical record, not a live document. If a menu price changes tomorrow, last night's bills shouldn't change with it.
Cash, digital payments, and recording them correctly
Most restaurants in Nepal handle a mix of cash and digital payments at the till: bank transfers, QR-based wallet payments, and card payments where available. Whatever mix you accept, the billing system's job is narrow but important: record which payment method was used, how much was paid, and update the bill's payment status accurately. A bill sitting in "pending" when cash was clearly handed over is a reporting problem waiting to surface at month-end reconciliation, and a bill marked "paid" twice against the same order is worse.
If you're comparing systems, ask specifically how payment status is tracked and whether partial payments are handled explicitly (rather than forcing a bill to be marked fully paid or not paid at all). This is a common gap in simpler POS tools.
Financial reporting depends on clean billing data
Once bills are calculated consistently, they feed everything else: daily and monthly revenue reports, a breakdown of cash versus digital payments, tax summaries, and service charge summaries. This is where sloppy billing quietly costs owners the most, not in any single bill being wrong, but in a month of slightly-inconsistent tax calculations making your actual revenue and tax liability genuinely unclear. See our reporting-focused guide for what a useful sales report should actually include.
A short checklist before you trust your billing setup
- Tax and service charge are calculated by a fixed rule, applied identically to every bill.
- Discounts are visible on the bill, not folded invisibly into the subtotal.
- A bill can't be generated from an order that isn't actually complete.
- Every payment is recorded against a specific bill, with a clear paid/pending status.
- Historical bills don't change retroactively when your menu prices do.
Billing is the least forgiving part of restaurant software to get wrong, because the cost of a mistake compounds. A small inconsistency repeated across hundreds of bills a month becomes a real number by year-end. If you want to see how Culinary Velocity handles the order-to-bill flow end to end, check our pricing or talk to us directly.
Frequently asked questions
What is the standard VAT rate for restaurants in Nepal?
Nepal's standard VAT rate is 13%, applied broadly across goods and services including restaurant sales, though exact treatment can depend on your business registration and any applicable exemptions. Check with your accountant or the Inland Revenue Department for how it applies to your specific setup. This article explains the billing workflow, not tax law.
How should a restaurant bill be calculated?
A clear, auditable formula is: Grand Total = Subtotal + Tax + Service Charge − Discount. The subtotal comes from the order's line items, tax and service charge are applied consistently by rule (not typed in manually per bill), and any discount is applied last and visibly, so a customer or an auditor can follow exactly how the total was reached.
What payment methods should a restaurant billing system support?
At minimum, cash and digital/online payment. Many restaurants in Nepal also accept QR-based digital wallets and bank transfers at the counter. Whatever methods you accept, the important part is that every payment gets recorded against the right bill with a clear payment status, so nothing gets marked paid twice or missed entirely.
Can a bill be edited after it's generated?
It shouldn't be, at least not silently. Once a bill is generated from a completed order, the underlying order and its price are meant to be fixed. If a correction is genuinely needed, the safer pattern is a new, clearly linked adjustment rather than editing history, so your financial reports stay trustworthy.