Accounting Software in Nepal: VAT Billing That Reconciles

Most small and mid-sized businesses in Nepal run accounting as a separate activity from operations. Sales happen at the counter or in the field, and then, sometime later, someone enters them into accounting software so the returns can be filed.

That gap is where nearly every accounting problem originates. The books are a reconstruction of what happened rather than a record of it, and reconstructions have gaps.

The registers and the ledger must be the same data

A VAT return draws on a sales register and a purchase register. The financial statements draw on the ledger. In a lot of businesses these are separately maintained, and the reason they disagree is that they were separately typed.

They should be one thing. A sale posts to the sales register and the ledger simultaneously, because it is one transaction being viewed two ways. A purchase does the same. When that holds, the return and the trial balance cannot disagree — there is nothing to reconcile because there is only one set of records.

This sounds obvious and is genuinely the main structural decision. Everything else is detail.

Invoice requirements

Tax invoices in Nepal have required content and formatting expectations, and abbreviated invoices apply below a threshold for retail sales. The details are set by the Inland Revenue Department and change from time to time — your auditor is the authority on the current requirements, not a blog post — but the software implications are stable:

• Invoice format is configurable, not hard-coded. Requirements change. A change to a required field should not be a software release.
• Numbering is sequential and gapless per series. Cancelled invoices are recorded as cancelled, not deleted, so the sequence stays complete.
• Records are immutable once issued. A correction is a credit note or a debit note, not an edit. Software that lets a user quietly change a posted invoice will fail an audit and, more importantly, will let staff quietly change a posted invoice.
• Every edit is logged. Who, when, what changed, previous value.

That last point is not paranoia. It is what makes the books defensible, and it is what lets you distinguish an honest correction from something else.

The audit trail is the product

A business with a good audit trail has a much easier audit, and a much easier time answering its own questions.

At minimum, for every transaction: who created it, when, from which terminal, what it originally said, every subsequent change with the same detail, and whether it has been reversed or superseded.

For a system serving both a business and its auditor, this matters twice over. An auditor arriving to find that any entry could have been changed at any time by anyone has to widen the scope of their testing considerably, which costs the client money.

Sales and purchase reconciliation

The two checks that catch most problems, and which the system should be able to run on demand:

Sales register versus ledger. Total taxable sales and VAT in the register for a period should equal the corresponding ledger movements. A difference means something was posted to the ledger without going through sales, or a sale was recorded without posting.

Purchase register versus supplier ledger. Same principle. Purchases claimed for input credit should tie back to what suppliers were credited.

If either check requires exporting two reports and comparing in a spreadsheet, it will not get run monthly and problems will accumulate until year end.

Where operations meets accounting

The best version of this is where the accounting is a by-product of running the business rather than a separate data entry job.

A sale at the counter posts revenue, VAT, cost of goods and stock movement. A purchase entry posts the payable, the input VAT and the stock receipt. A payment posts against specific invoices and moves the bank or cash balance. A stock write-off posts the loss.

At that point the trial balance is available continuously, not at month end, and the person who used to spend a week entering the month’s transactions is doing something more useful.

This is the same logic that makes an ERP system for businesses in Nepal worth having — accounting is not a module bolted on the side, it is what the operational transactions add up to.

Multi-currency, if you need it

Businesses importing or exporting need foreign currency handled properly: the transaction in its original currency, the rate and its date recorded, and the NPR equivalent derived rather than typed. Realised and unrealised exchange differences then compute rather than being plugged in.

If you only ever transact in NPR, skip it. If you do not, a system that stores only the converted amount will make bank reconciliation extremely painful later.

What to check before choosing

• Can I produce the sales register, purchase register and trial balance for a period, and do they tie without manual adjustment?
• Can a posted invoice be edited? If yes, walk away or at least understand exactly who can and what is logged.
• Is the invoice format configurable without a code change?
• Can my auditor be given read-only access with their own login?
• Does an operational transaction — a counter sale, a stock transfer — post to the ledger automatically, or does someone re-enter it?

The last question is the one that determines whether your accounting is a record or a reconstruction.

We build accounting, inventory and HR software for businesses in Nepal where billing, stock and the ledger are one system rather than three. If your VAT filing starts with a week of data entry, talk to us.