Choosing a system

How to choose accounting or ERP software in Nepal

This is the page we would want to read if we were buying. It is a framework for evaluating any system, including ours — because a customer who chose us for the wrong reason becomes an unhappy customer about four months later.

No competitor names, no scoreboard. Take these criteria to every vendor on your list and make them demonstrate each one.

Method

Run the evaluation, do not sit through the demos

The single biggest predictor of a bad software decision is letting each vendor choose what to show you. Five polished demos of five different things cannot be compared.

Write down your ten hardest requirements first. Before you speak to anyone. The awkward ones — the way you handle consignment stock, the report your auditor insists on, charging a restaurant bill to a room.
Send the same list to every vendor. Ask each to demonstrate those ten things, in that order, in a live system. This alone will separate the shortlist quickly.
Insist on your own data, or something like it. Demo data is arranged so that everything works. Ask for one of your genuinely messy cases to be entered live.
Put the daily users in the room. The cashier, the storekeeper and the accounts assistant will spot in ten minutes what a director will not notice for six months.
Ask what happens when things go wrong. A wrong posting, a failed print during service, a connection drop mid-shift, a member of staff who leaves suddenly. Every system looks good on the happy path.
Cost the whole thing, over three years. Licences, implementation, migration, training, hardware, support, and the cost of the staff time the rollout will consume.
Check the exit before you sign the entry. Ask to see a full export of your own data in a format you can read without their software. A vendor who cannot show you the door is a vendor to be careful with.

The criteria

What actually determines whether it will work

Grouped by the question each one answers. Score every vendor on the same scale, and treat anything that cannot be demonstrated as absent rather than as promised.

Accounting foundations

Genuine double-entry accounting, not a sales ledger with a report on top
Bikram Sambat fiscal year and dual-date handling throughout, not converted at the edges
The exact IRD position, and precisely what it covers — ask for the wording, not the adjective
VAT workflows, and TDS deduction and reporting as you actually operate them
Fiscal period control: what closing a period prevents, and who can reopen it
Whether a posted document can be edited, and what the correction path is instead

Structure and scale

Multiple companies, and whether each keeps genuinely separate books
Multiple branches, with branch-level books and separate numbering
Consolidated reporting across companies and branches, produced by the system
Whether adding a branch later is configuration or a second implementation
How access is scoped, so a branch manager sees their branch and not the group

Inventory, if you hold stock

Multiple stock locations, and transfers between them that post correctly
Batch, serial and expiry tracking, if your goods need it
Landed cost: whether freight and duty reach the item cost or land in an expense
Stock counts and adjustments, and the approval around a write-off
Which valuation method is used, and whether it matches what your accountant reports

Selling, if you have a counter

Whether POS posts into the same books, or exports a daily total to be reconciled
Cashier shifts, cash handover and how variance is recorded
Restaurant needs: kitchen and bar ticket routing, table service, split bills
Hotel needs: folios, night audit, city ledger, charge-to-room from an outlet
What precisely happens offline — printing continuing is not the same as the system working
Which printers and devices are supported, and who supports them when they fail

People and process

Attendance, leave, overtime and staff advances as you run them
Whether payroll posts a salary journal, or ends in a spreadsheet someone types up
Production and bill-of-materials costing, if you make anything
CRM connected to real balances and history, rather than a separate contact list
Role-based permissions granular enough to separate raising, approving and paying

Trust and evidence

Whether every total drills down to the source document
The audit trail: what it records, and whether it can be altered
Reports your board and your auditor require, out of the box
Data ownership, export formats, and what happens to your records if you leave
Security: two-factor authentication, access restriction, activity logging, backups and a tested restore

The parts nobody demos

Who does the implementation — the vendor, a partner, or you
How opening balances are migrated, and reconciled to your closing trial balance
Training: by role, using your data, or one session for everyone
Support: hours, channels, language, and whether they can see your configuration
What a service agreement actually commits them to, in writing
Language: English and Nepali, and whether that covers reports as well as screens

Where we fit

When Penahak is the right answer — and when it is not

Scored against the criteria above, here is where we are strong and where you should look elsewhere. We would rather lose a deal early than lose a customer at month four.

Choose us when

You want accounting, stock, POS, hospitality and payroll sharing one ledger, rather than four systems reconciled monthly
You operate more than one outlet, branch or company and need consolidation you did not assemble by hand
Nepali fiscal years, VAT, TDS and fiscal invoicing need to be in the engine rather than worked around
You run hospitality — a hotel with a restaurant in it is where separate systems hurt most
Auditability matters to you: you want posted figures that cannot change without a trail
You want implementation and support from people in the same country and time zone

Look elsewhere when

You need full MRP with multi-stage production scheduling — our Production module is light manufacturing
A dedicated mobile app is a requirement today; the web application works in a mobile browser, but our Android app is still in development
You want to reopen and edit posted vouchers. We will not do that, and it is deliberate
You need to be live next week with no configuration — the setup gates exist to prevent exactly that
You are a single freelancer needing simple invoicing; this is more system than you need
Your requirement is a deep, industry-specific niche outside the modules we publish

Not locked to one computer

How it usually works

Accounting sits on a single desktop in the back office. The owner cannot see today’s numbers from anywhere else, a second branch means a second disconnected copy, and the backup is whatever someone remembered to take.

With Penahak

One cloud account with branch-level books and consolidated reporting. The same application runs in a browser, or as a desktop app where thermal printing is needed. Backups and updates are handled for you.

Posted figures cannot be quietly edited

How it usually works

Many systems let a user reopen and change a posted voucher. It is convenient, and it means last month’s reported profit can change without anyone knowing — which is exactly what an auditor is looking for.

With Penahak

Posted documents are immutable. Corrections go through credit notes, debit notes or reversing journals, each recorded with the approving user, the reason and the original document. The trail is complete by construction.

The till and the books are one system

How it usually works

POS is a separate product that exports a daily total into accounting. Someone reconciles the two, the numbers rarely agree exactly, and the difference gets written off as a rounding or shortage entry.

With Penahak

The counter posts source documents straight into the ledger with their tax and settlement treatment. There is nothing to reconcile between them because there is only one set of records.

Hotels and restaurants are not an afterthought

How it usually works

Hospitality means either a foreign property system priced for a chain and unaware of Nepali tax, or a local system with no real folio, night audit or city ledger. Restaurant and hotel usually do not talk to each other at all.

With Penahak

Full folio, night audit, housekeeping and city-ledger handling, with restaurant charge-to-room built in — and checkout posting one invoice into the same ledger your retail counter uses.

Printing that survives a real service

How it usually works

Kitchen tickets print from the browser. If the printer is offline, out of paper or the tab was closed, the ticket is simply gone and the table waits.

With Penahak

The backend creates durable print jobs and routes them by product group to the right station. A local bridge delivers them and retries until acknowledged, so a printer fault delays a ticket instead of losing it.

Nepali compliance in the engine, not bolted on

How it usually works

Fiscal year handling, VAT treatment and the audit trail are added around the edges of a system designed for another market, and the statutory return is assembled by hand each period.

With Penahak

Bikram Sambat fiscal control, IRD-ready fiscal invoicing, VAT and TDS treatment and the audit trail all live in the central posting paths, so every module inherits them. eSewa, Khalti and Fonepay are first-class tenders.

Configuration is checked before it can hurt you

How it usually works

You are handed a login and left to it. Six weeks later somebody notices a year of revenue posted to a default or suspense ledger, and unpicking it costs more than the software did.

With Penahak

Stage-based setup gates block reservations, check-in, charge posting, checkout and stock posting until the ledgers, tax terms and numbering behind them are mapped. Being blocked on day one is much cheaper than being wrong for a year.

Support that can see your setup

How it usually works

Support is a phone number and a screen-share, and every call starts by explaining your own configuration from scratch.

With Penahak

We are in the same market and on the same platform. Support can see your ledger mapping, document numbering and activity log, and tickets are raised from inside the application against the document causing the problem.

Our methodology

Why there is no comparison table here

You have probably seen vendor comparison tables where one column has ticks all the way down. They are written by the vendor who wins them, usually from a competitor’s marketing site, and they go stale within a release or two.

If we publish one, it will follow the rules on the right — and it will still say "Unknown" wherever we have not checked. Until we can meet that standard, a framework you can apply yourself is more useful to you than a scoreboard that flatters us.

The standard any table here must meet

Every value carries a source: a URL, a quote or a screenshot
Every value carries the date it was checked, and by whom
Only Yes, No, Partial, Add-on, Unknown or Contact provider — never an inference
Unknown stays Unknown. We do not guess on a competitor’s behalf
The methodology and the last-reviewed date are published with it
It must remain useful to a buyer who ends up choosing someone else

Bring your requirement list

Send us the ten hardest things on it. We will show you each one working, or tell you plainly which ones we cannot do — before you have spent any money finding out.

Request a demo Talk to sales

You are welcome to run the same session with every vendor on your list. We would rather be compared properly.