Skip to content
Penahak now runs hotels, restaurants and retail on one ledger.
Penahak
Enterprise & multi-branch

ERP for multi-branch organisations in Nepal

Several companies, a dozen outlets, a hotel with a restaurant inside it, a factory feeding its own retail chain. When an organisation gets to this size the problem is no longer bookkeeping — it is whether the consolidated numbers can be trusted, and whether anyone can tell you who changed what.

Everything on this page is something we can show you in a working system. Where we do not yet publish a figure, we say so rather than estimate it.

The real problem

At this size, the failure is never one wrong invoice

It is that four systems each hold part of the truth, and the month-end pack is assembled by hand from all four. Every organisation we take on at this scale describes some version of the same five problems.

Every branch is its own island

Each outlet runs a separate copy of something. Consolidating them is a monthly spreadsheet exercise, and by the time it is finished the numbers are three weeks old.

Nobody agrees on the stock figure

The store, the counter and the books each report a different quantity, so the valuation in the accounts is a negotiated number rather than a measured one.

No one can answer "who changed this?"

A figure moved between two reports and there is no trail explaining it. This is the question an auditor asks first, and the one that is hardest to answer after the fact.

Everyone can do everything

Access was granted by whoever needed it that week. The person raising a purchase order can also approve it and pay it, which is a control failure waiting to be found.

Close takes weeks, not days

Because reconciliation is manual, the period cannot close until several people have finished chasing differences that a connected system would never have created.

Branch performance is guesswork

Revenue by outlet is known. True contribution by outlet — after landed cost, wastage, staff cost and overhead — usually is not.

Structure

Companies and branches are built in, not bolted on

Your organisation holds as many companies and branches as you actually trade through. Each carries its own books; consolidation sits above them rather than being assembled from exports.

Every module posts into one ledgerEight Penahak modules arranged around a central accounting ledger. Each module sends source documents inward to the ledger, and the ledger feeds a single reporting layer. One ledger immutable Retail POS Restaurant POS Hospitality CRM Inventory HR & Payroll Production Sales & Purchase

What each branch keeps for itself

  • Its own books, opening balances and fiscal-period control
  • Its own document numbering series, so references never collide
  • Its own stock locations, terminals, outlets and price lists
  • Its own report layouts and branding where it needs them
  • Its own staff, roles, shifts and approval thresholds

What the group sees across all of them

  • Consolidated trial balance, balance sheet and profit and loss
  • Branch-by-branch comparison on the same definitions
  • Group stock valuation across every location
  • Receivables and payables ageing by branch and in total
  • One activity trail spanning every company and branch
Controls

Segregation of duties, approvals and a trail that cannot be rewritten

The controls an auditor asks about are the ones that have to be in the system rather than in a policy document nobody reads.

Roles carry only what the job needs

Permissions are granular and assigned by role, so the person who raises a document is not automatically the person who approves or pays it. Menus and screens follow the role, so people are not shown work they cannot do.

Approvals sit on the risky actions

Discounts above a threshold, price overrides, voids and corrections can each require an approver, and every one is recorded with the approving user and a stated reason.

Posted figures are immutable

A posted invoice, receipt, payment or stock voucher cannot be edited in place. Corrections go through a credit note, debit note or reversing journal that references the original — so last month’s reported profit cannot quietly change.

Setup gates stop bad configuration posting

Stage-based configuration checks block posting until ledgers, tax terms, numbering and mappings are in place. Wrong configuration is caught before it produces a thousand wrong entries.

Access is restricted, logged and time-bound

Two-factor authentication, restriction by IP address, user activity logging, and account start and expiry dates for staff who should only have access for a defined period.

Every figure drills back to a document

Any total in any report opens the documents behind it. "Where did this number come from" is a click, not an investigation.

Rollout

How a multi-branch rollout actually runs

One branch is proven end to end before the rest follow it. A simultaneous group-wide cutover sounds faster and is how implementations fail.

  1. Pilot one representative branch. Usually the most complex one, because the simple branches are then a subset of a configuration that already works.
  2. Run it in parallel for one full period. Trade on both systems, then reconcile. Differences at this stage are configuration findings, not problems.
  3. Freeze the configuration as the group template. Chart of accounts, tax terms, numbering, roles and report layouts become the pattern every later branch inherits.
  4. Roll out branch by branch. Each one gets its own opening balances, its own reconciliation against closing figures, and its own supervised go-live.
  5. Turn on consolidation last. Group reporting is only meaningful once every branch underneath it has been reconciled individually.
01

Discovery

We map your outlets, books, stock locations and statutory obligations, and agree what go-live means.

02

Configuration

Chart of accounts, tax and bill terms, document numbering, godowns, roles and payment providers, all checked against the setup gates before anything posts.

03

Migration

Masters, opening balances and opening trial imported and reconciled against your closing figures.

04

Training

Role-based sessions for owners, cashiers, front desk, kitchen, storekeepers and accounts, using your own data.

05

Go-live

One full test cycle end to end, then supervised go-live with a support engineer on hand.

06

Aftercare

Ongoing support, statutory updates, new-release rollout and periodic health checks.

Before you choose anything

Enterprise readiness checklist

Work through this against us and against anyone else you are considering. If a vendor cannot demonstrate an item in a live system, treat it as absent.

Ask the vendor to demonstrate

  • A consolidated trial balance across at least two companies, on screen
  • The same report filtered to one branch, reconciling to the group total
  • An attempt to edit a posted invoice — and what the system does instead
  • A correction, from reversal through to the audit trail entry
  • Two users with different roles, showing what each cannot reach
  • An approval being triggered, refused, and logged
  • A total drilled all the way down to a source document
  • A full data export in a format you can read without their software

Prepare on your side

  • A current, agreed chart of accounts — not four versions of one
  • A closing trial balance per company that your accountant stands behind
  • Clean master lists: customers, suppliers, items, employees
  • A physical stock count close to your intended cutover date
  • A named owner per branch who can make decisions, not just relay them
  • Written agreement on who may approve what, before roles are built
  • The reports your board and your auditor actually require
  • A realistic view of who needs training, and when they are free
Being straight with you

What we will not claim on a web page

Enterprise buyers are asked to accept a lot of unsupported numbers. These are the questions we answer in writing, against your requirements, rather than with a figure on a marketing page.

Read how we handle security and your data

  • Transaction volume and concurrent-user limits — we will discuss them against your actual numbers, under a mutual understanding of what we are measuring.
  • Uptime and support response commitments — these belong in your service agreement, where they are enforceable, not in a headline.
  • Reference customers — introductions are arranged with the customer’s consent, per evaluation. We do not publish names or logos without written permission.
  • Full MRP with multi-stage production scheduling — our Production module is light manufacturing. If that is your core requirement, say so early.
  • A dedicated mobile app — the web application works in a mobile browser today; our Android app is still in development.

Bring your hardest requirement to the first call

Multi-branch evaluations go faster when they start with the thing you are worried about. Tell us the structure, the branches and the reporting you are accountable for, and we will show you it working or tell you plainly that it does not.

Typically 45–60 minutes for a multi-branch scoping call.