Occupancy reports and revenue reports disagree
When the property system keeps its own figures and accounting keeps others, the monthly reconciliation never quite closes and neither number is fully trusted.
Reservations through night audit to posted revenue, with restaurant charge-to-room and city-ledger billing included.
Hotels usually choose between a foreign property system that does not understand Nepali tax, and a local system with no real folio or night audit. Penahak gives you the hotel operation and posts it into the same ledger your restaurant and shop use.
When the property system keeps its own figures and accounting keeps others, the monthly reconciliation never quite closes and neither number is fully trusted.
A checkout that fails halfway — a gateway timeout, a dropped connection — and a retry creates a second invoice for the same stay.
City ledger kept on a spreadsheet ages quietly until a corporate account is well past its credit limit.
Outlet bills written on paper and carried to reception get lost, mistyped, or applied to the wrong room.
Each step below creates or references a real document. Nothing is retyped between them, and every figure at the end traces back to the action that caused it.
A starting point, not a fixed bundle. Add or drop modules once we have seen how you operate.
A hotel and homestay operating module wired directly into Penahak accounting. Hospitality owns operational state; the ERP owns financial truth — so occupancy reports and revenue reports finally agree.
Table service built around a floor map, station-routed kitchen tickets and durable print jobs that survive a printer going offline mid-service.
Not a separate contact database bolted on beside your books. Penahak CRM reads live ERP signals — balances, disputes, deliveries, returns — so every screen tells someone what to do next.
A double-entry core with a real chart of accounts, cost centres, fiscal-year control and immutable posting. Every sale, folio, payroll run and stock movement in Penahak resolves to a source document here.
Not features — outcomes. If these are not true six months after go-live, something has been configured wrongly and we want to hear about it.
Every total drills down to the source document behind it.
IRD-approved, with fiscal invoice behaviour in the central SalesBill and POS paths, IRD sync, VAT customer and vendor summaries, and an audit trail built for inspection rather than reconstructed after the fact.
Bikram Sambat fiscal-year control, business-date close and dual-date handling throughout documents and reports.
eSewa, Khalti, Fonepay, card, bank, QR and wallet adapters, with verification evidence required before a provider goes live. Cash stays simple: no merchant ID, no callback URL.
Interface translations and a localisation layer in both the web application and the reporting engine.
Every posting command carries an idempotency key. Corrections go through approved reversal or credit paths; posted truth is never edited in place.
Granular roles and permissions, IP address whitelisting, two-factor authentication, user activity logging, time-based account expiry, and stage-based setup gates that block posting until configuration is safe.
We map your outlets, books, stock locations and statutory obligations, and agree what go-live means.
Chart of accounts, tax and bill terms, document numbering, godowns, roles and payment providers, all checked against the setup gates before anything posts.
Masters, opening balances and opening trial imported and reconciled against your closing figures.
Role-based sessions for owners, cashiers, front desk, kitchen, storekeepers and accounts, using your own data.
One full test cycle end to end, then supervised go-live with a support engineer on hand.
Ongoing support, statutory updates, new-release rollout and periodic health checks.
Book a walkthrough and we will demo the modules that match how you actually trade — not a generic slide deck.
No obligation. Typically 30–45 minutes.