School ERP Nepal: Features, Vendors, and What to Actually Pay For

The Nepali School ERP market is crowded with vendors who all promise the same thing: a unified student management system. What they actually ship varies wildly in quality, lock-in risk, and total cost over 3–5 years. This is the honest guide we share with school principals, administrators, and trust boards who ask us how to evaluate.

What a modern School ERP actually has to include

Before any vendor conversation, write down what you actually need. The non-negotiable modules for a Nepali school:

Student Information System (SIS). Admissions, records, family info, document storage, lifecycle from inquiry to alumni.
Attendance. Daily and period-wise, biometric or QR-based, with parent SMS for absences.
Academic and exam management. Class timetables, exam scheduling, results, transcripts, grade computation that matches your curriculum (CBSE, NEB, IB, etc.).
Fee management. Fee structure, invoicing, payment gateway integration (eSewa, Khalti, IME Pay), scholarship handling, late-fee automation.
Communication. SMS and mobile-first notifications. WhatsApp where applicable. Email where parents check it.
Parent and teacher portals. Web and mobile, with simple flows — not full clones of the admin dashboard.
Library, transport, hostel. As applicable.
Reports. Class performance, attendance trends, fee-default risk, dropout signals, board-level dashboards if multi-campus.

If a vendor’s base package omits any of the first six, the rest of the pricing conversation is a fiction.

The pricing models you’ll see (and what each one actually costs)

Per-student-per-month (most common)

Vendors quote NPR 20–80 per student per month. Sounds small. For a 1,500-student school, that’s NPR 360,000–1.44M per year — just for licensing. Add customization fees, integration fees, and the math gets uncomfortable over 3 years.

Watch for: per-module surcharges (separate fee for parent portal, separate for transport, etc.) and per-user fees for admin staff on top of per-student.

Annual flat licensing

Less common but cleaner. A flat NPR 500K–2M per year regardless of student count. Often offered by international vendors trying to enter Nepal.

Watch for: caps on number of users, modules locked behind tier upgrades.

One-time purchase + AMC

The Tally-Education model: pay once, then 15–20% annual maintenance. Tempting for budget-fixed schools but usually the support quality reflects the pricing.

Watch for: end-of-life dates on the version you bought, customization fees that creep up.

Custom build (what we typically do)

A senior team builds a system to your spec, deploys it (SaaS or self-hosted), then either supports it on a monthly retainer or hands it over completely.

Total over 3–5 years is usually lower than per-student-per-month vendor licensing for any school over ~800 students. The school owns the system, the data, and the source code in escrow.

We describe our School ERP build approach for Nepal in detail, including what’s included and typical timelines.

Vendor patterns to avoid

”Modular pricing” that punishes growth

If every module is a separate line item, every time you add a feature you reopen the commercial conversation. The good vendors include everything you need in one fee.

”Cloud-only” with no data export

If the system is SaaS and the vendor controls the database, ask for the export contract before you sign. Schedule a data export every 90 days regardless — to prove it works and to keep your leverage.

Demo data only, never your data

A demo against synthetic data tells you nothing. Ask for a one-week pilot with a slice of your real data. Vendors who refuse usually have data-shape problems they don’t want you to discover.

”AI features” as the headline

Most “AI-powered” School ERPs are search-with-better-marketing. Ask: “show me an eval set for your AI predictions.” If they can’t, the AI is decoration.

Lock-in via the parent portal

Vendors sometimes offer the parent portal free or cheap to lock the school in via parent inertia. When you try to leave, parents complain because the app changes. Look for systems where the parent portal is a thin layer over the core data — easy to replace.

What schools should actually demand in any RFP

Schema and data export documentation delivered with the proposal.
API documentation showing how external systems can integrate.
Performance benchmark: time to load grade reports for the full school across all subjects.
Multi-campus support with a clear answer on data isolation between campuses.
Localisation for Nepali language (where the parent portal needs it) and for NPR formatting / Nepali calendar / SST tax rules.
Source-code escrow on any custom build.
A clear cutover plan from your existing system, with parity testing.

When a custom build makes more sense than a vendor

A custom build typically wins over vendor licensing in three scenarios:

Multi-campus trusts where vendor per-student fees scale unfavourably.
Schools with unusual curriculum (international curriculum mix, hybrid programs, vocational + academic) where vendor templates don’t fit and customization fees stack up.
Schools that want to own the data and integrate it with operational systems beyond the ERP (alumni CRM, admissions marketing automation, finance systems).

For schools under 300 students with a standard curriculum, off-the-shelf vendor software is usually fine.

What we’d charge for a custom build

Indicative pricing for a custom School ERP build (single school, full module set):

Build phase: 6–12 weeks, fixed fee in the range a mid-sized school can typically justify against 3-year vendor licensing.
Optional ongoing support: monthly retainer for issue resolution, minor enhancements, security patches.
Self-hosted: you pay your own AWS / data-center bill (typically lower than vendor SaaS hosting markup).

We’ve shipped these for schools and colleges in Nepal at significantly lower total 3-year cost than the major regional School ERP vendors, with better integration and full data ownership.

Where to start

If you’re evaluating now, the highest-value next step is to write down what you actually need (use the module list above as a checklist), then ask any vendor or potential build partner to map each module to a line item and timeline. The mismatch between what’s promised and what’s delivered will become obvious within two conversations.

If you’d like a counter-proposal that treats the school as a data platform with the right operator UI on top, tell us about your school — we’ll scope a custom build or recommend you stay with a vendor if that fits better. Either answer is honest.