VAT billing for restaurants in Nepal: what actually has to be on the bill
12 min read ยท
Most restaurant owners in Nepal find out what their bill is supposed to look like the hard way, a customer asks for a proper tax invoice, or an inspection turns up a receipt that's missing something it was legally required to have. The rules themselves aren't complicated once you see them laid out. What trips people up is that the requirements change the moment a business crosses the VAT registration threshold, and most billing setups don't handle both states cleanly.
PAN-only vs. VAT-registered: two different bills
A restaurant that hasn't registered for VAT issues a PAN bill: the total is the total, no tax line, no 13% added anywhere. The moment a business is VAT-registered, that changes completely. Every bill now needs the 13% VAT computed on the taxable amount, applied after any discount, and shown as its own line, not folded into the total silently.
This is where a lot of manual or half-digital setups get it wrong. If your system doesn't know your registration status, or worse, has it hardcoded, you either overcharge VAT on a PAN-only bill or undercharge it once you register, and Nepal's Electronic Billing Procedure 2082 treats both as the same class of problem: an incorrect invoice.
What changes the day you register for VAT
The transition is the moment most restaurants discover their billing system wasn't ready. The day IRD processes your VAT registration, every bill you issue must carry the 13% line. There's no grace period and no partial-month exception. Bills issued before registration are PAN bills; bills issued from the effective date are VAT bills. The system needs to know which is which automatically.
Practically, this means your billing software needs to know your VAT registration number and your registration effective date, not just a toggle you set manually. A system that requires someone to remember to flip a switch on exactly the right day will get it wrong at least once. For VAT-registered businesses, that mistake is a non-compliant invoice, which creates problems on your VAT return that are tedious to unwind.
The VAT registration threshold for most businesses in Nepal is an annual turnover of Rs 50 lakhs. Once you cross it, registration is compulsory within a set window. A restaurant that's growing should track its running turnover and not wait until IRD sends a notice โ the billing system switch needs to happen proactively, not reactively.
What the printed bill is required to show
Under the current procedure, a compliant tax invoice needs, at minimum:
- The seller's name, address, and PAN or VAT number, printed prominently, not buried in fine print.
-
A sequential invoice number tied to the Nepali fiscal year (e.g.
INV-81/82-00001), with no gaps and no manual overrides. - Taxable and non-taxable amounts shown separately, followed by the 13% VAT line, followed by the grand total.
- For VAT-registered businesses issuing a B2B bill, the buyer's PAN as well.
- If the bill is a reprint of an already-finalized invoice, a clear "Copy of Original" watermark or label โ the original and the reprint are never allowed to look identical.
None of this is exotic, it's the same shape as a tax invoice anywhere else. The friction is entirely operational: getting a cashier-facing system to compute it correctly, every time, without anyone having to remember the rule.
The invoice number sequence in practice
Nepal's fiscal year runs from Shrawan 1 to Ashad 31 in the Bikram Sambat calendar, and invoice numbers reset at the start of each year. A compliant sequence runs from 00001 on the first day of Shrawan with no skips, no duplicates, and no numbers that reset mid-year because someone changed systems or printed a test bill.
During an IRD audit, the inspector can request every invoice in sequence for any given period. A missing number, a duplicate, or a manual override that created an out-of-order entry is a flag that will be asked about. IRD's published guidelines require that the sequence be system-generated and tamper-evident, meaning it cannot be overridden by the person operating the till.
This is why switching billing software mid-year requires care. The new system needs to continue from wherever the old sequence left off, not restart from 00001. A restart in the middle of a fiscal year creates a gap in the number sequence that is very difficult to explain in an audit without supporting documentation.
Why this usually breaks at the point of sale, not the ledger
A restaurant's accountant can get VAT right at month-end reconciliation. The harder problem is getting it right at 10pm on a Friday, on the twentieth bill of the night, printed by a waiter who has never read the Electronic Billing Procedure and shouldn't need to. That's a point-of-sale problem, not a bookkeeping one โ the calculation has to be correct automatically, before the bill ever prints.
This is the specific thing Srota RMS is built around: VAT is computed from your actual registration status the moment a bill is finalized, applied after discounts, and printed with a proper fiscal-year invoice number in Bikram Sambat, the same date format your customers already expect on a Nepali receipt. If your business isn't VAT-registered, the tax line simply doesn't appear; nothing to misconfigure. When your registration status changes, you update it once in settings and every bill from that point forward is correct.
What to do if a bill is already wrong
The first thing to understand is that finalized invoices cannot be edited. This isn't a software limitation, it's a requirement of the Electronic Billing Procedure: a bill that has been issued is a document of record. Editing it retroactively would break the audit trail IRD relies on.
The correct mechanism is a credit note. If a bill was issued with the wrong amount, wrong VAT calculation, or wrong buyer details, you issue a credit note against it. The credit note is its own document with its own sequential number, referencing the original invoice. The original bill is never touched. If a corrected bill needs to be issued, it's a new invoice with a new number. This is the same process used by every VAT-registered business in Nepal and it needs to be built into the billing system, not handled with a pen and a new piece of paper.
A credit note also needs to be submitted to IRD's CBMS system, the same way the original invoice was. An unsubmitted credit note means IRD's records still show the incorrect invoice as valid.
What to check today
If you're not sure whether your current billing setup handles this correctly, print a real bill and check three things: does the invoice number follow a fiscal-year sequence with no gaps, is VAT shown as its own line rather than folded into the total, and does a reprinted copy look visibly different from the original. If any of those is "no," that's worth fixing before it becomes a bigger problem than a wrong receipt.
If your restaurant also runs credit tabs for regular customers, the way khata orders interact with issued invoices is worth thinking through carefully. Our guide on managing khata digitally covers how order history, balances, and settlement records stay connected without creating gaps in your billing trail.
See VAT billing done right
Srota RMS computes VAT automatically once you're registered, no spreadsheet, no manual math at the till.
Explore Srota RMS