One ledger.
Many front doors.
The ERP engine behind every system ikainepal builds — modules, verticals, localisation and how a build is delivered.
- Only the modules you run
- On-premise · cloud · hybrid
- Fully customised, always
- Multi-company · multi-branch · multi-currency
A fully customised ERP, on an engine that already works
What you buy is a fully customised ERP — your documents, your approvals, your chart of accounts — built on an engine that already works. One double-entry posting engine sits at the centre. Every way a business takes money — a salesperson raising an order, a cashier at a till, a waiter closing a table, a shopper checking out online — posts real accounting documents through that same engine. There is no nightly sync and no separate retail ledger, because there is only one set of books.
Three systems, four versions of the truth
Tier-one ERPs are priced for someone else
SAP Business One, Dynamics and their peers have the depth — costing methods, batch traceability, approval hierarchies, multi-currency. The licence, the partner and the annual maintenance put a real deployment out of reach for most companies here.
Affordable accounting packages stop at the ledger
They post an invoice and produce a VAT return. They will not run a production BOM through work-in-progress, hold a shopper's bag as a live quotation, or cost a project by phase. So the business buys a second and a third system.
The seams are where money leaks
When the till, the storefront and the ledger are separate systems, stock is wrong in at least one of them. Counter discounts never reach the margin report. Nobody is lying — the architecture cannot tell the truth.
Integration as a property, not a feature
Instead of building an ERP and bolting channels onto it through connectors, every channel is a thin client over one shared transactional engine. No document posts a one-sided entry, and the trial balance is asserted balanced after every scenario the test suites run.
Most-specific-first
The revenue, COGS or inventory account behind any movement resolves item override → item group → warehouse → company default. Give a warehouse its own inventory account and receipts, issues and transfers land in it.
Cost centre and project on every line
A dimension set on a document header flows onto every journal line that document posts. Project P&L and budget-versus-actual fall straight out of the ledger instead of being assembled in a spreadsheet.
Buy in cartons, sell in packs
Items carry a purchase and a sales unit with conversion factors. Every stock leg moves and values in base units while line totals stay in the entered unit and its price. The factor rides copy-forward.
What each document writes to the ledger
Every document type posts a known, balanced journal. Nothing is a special case.
| Document | Journal |
|---|---|
| Delivery | Dr COGS / Cr Inventory, at the item's valuation method |
| A/R Invoice | Dr A/R / Cr Revenue + Freight + VAT |
| Goods Receipt PO | Dr Inventory / Cr GR-IR Clearing, plus purchase-price variance on standard-cost items |
| A/P Invoice with TDS | Dr GR-IR + VAT Input / Cr A/P, with the withholding to TDS Payable — the payment settles net |
| Landed Cost | Dr Inventory + Price Difference / Cr Landed Cost Clearing |
| Production Issue | Dr WIP / Cr Inventory · receive Dr Inventory / Cr WIP · close variance to Production Variance |
| Fixed Assets | Capitalise · straight-line depreciate per period · retire at net book value |
The document chain
- SQQuotation
- SOSales Order
- DLVDelivery
- INVInvoice
- PAYPayment
- GLLedger
Approvals, multi-currency and audit trails follow the document at every step — and each step posts to the ledger the moment it happens.
In every build, whatever the business
Everything else depends on it, so it cannot be switched off.
Identity and access
Users and roles with a full authorisation matrix, per-account rate limiting, self-service password reset, and an audit trail.
Master data
Business partners, item master, chart of accounts with control-account guards, item and partner groups, warehouses.
Approvals
Multi-stage sequential routing. Each stage carries its own approvers and a minimum approval count; a rejection returns the whole document and resubmission restarts at stage one.
Rules and alerts
One saved-query engine backs three things: validations that block a posting when a rule fails, live alert rules per user, and reporting.
Reports
Trial balance, P&L, balance sheet, classified cash-flow statement tied to the ledger's cash balance, VAT return summary, A/R and A/P aging, gross profit per document, stock valuation and movements.
Setup masters, all dynamic
Tax and withholding codes, posting periods, currencies and rates, payment terms and methods, numbering series, price lists, house banks, approval procedures, account determination — every one is "define new", not a fixed list.
Built for how Nepal files
Not a translated product. The filing rules are in the engine, not in a plug-in.
- Fiscal calendar
- Bikram Sambat fiscal years own their posting periods, with non-overlap enforcement and period indicators tying a posting period to its document numbering series. Nepali dates throughout.
- VAT
- VAT codes on documents with a filing-ready return summary — output tax against input tax, bases net of discounts, net payable.
- Withholding tax (TDS)
- A working engine on both sides: A/P invoices withhold vendor TDS, A/R invoices book customer-withheld TDS, both applied at posting so payments settle net — with a filing-ready register.
- e-billing
- A fiscal register maintained over posted invoices for IRD e-billing submission.
- Currency
- NPR as the natural base currency, with full foreign-currency support for importers and exporters — documents post at their own rate, payments book realised gain and loss.
- Scope
- Multi-company, multi-branch and multi-currency, with consolidated reporting across companies.
What it already talks to
Anything not on this list is an integration project, quoted after the requirement study — not a "roadmap item".
Payments
- eSewa
- Khalti
- Fonepay
- Card payment gateways
- Bank integrations
Devices
- POS & receipt printers
- Barcode scanners
- Weighing scales
- e-attendance devices
Messaging & data
- SMS gateways
- SMTP outbox
- CSV import / export
How it is deployed and licensed
- Deployment
- On-premise, cloud or hybrid, as the business and its auditor require. The same codebase runs in all three.
- Your own database
- Your data sits in its own database, reached at your own domain — which matters when the auditor asks where the books physically live.
- Modules
- The Foundation is in every build; the ERP modules and verticals are chosen for your business. Adding one later is a switch, not a fresh project.
- Cutover
- Items and business partners by CSV, opening stock as posted goods receipts, opening balances as balanced journal entries. A cutover is a working day, not a quarter.
- Administration
- A data console lets your own admin browse and correct company data without a DBA — ledger tables readable but never writable, credentials masked, every write audited.
- Commercials
- Every engagement is a customised build on the n360 engine. Scope and price are quoted after the requirement study, so the number describes your system. Price on request.
Proven underneath, customised on top
Double-entry posting, account determination, three costing methods, batch and serial traceability, multi-currency with realised FX, multi-stage approvals and a dimensional ledger are the parts of an ERP that take years to get right and are unforgiving when they are wrong. In n360 they are already built, already exercised end to end, and already assert that debits equal credits through every scenario they run.
What that means for you: your engagement pays for the study, the customisation and the implementation of your system — not for someone to build an accounting engine on your books.