ERPNext for schools and universities with Frappe Education

Frappe Education runs student administration on ERPNext, so admissions, fees, exams, finance and HR share one system. This page covers the requirements, build choices, compliance duties and rollout.

Book a callTalk to us
On this page

Why ERPNext for schools and universities fits one back office

Many schools and universities run admissions in one tool, fee collection in a spreadsheet or payment portal, timetables in a scheduling package and payroll in a separate HR system, with student data copied between them by hand. ERPNext with Frappe Education puts these functions on one Frappe site, so an applicant record, a student record, a fee invoice, a timetable slot and a staff contract refer to the same underlying data. For registrars, that means an admitted applicant becomes a student record and an enrollment without re-keying. For bursars, fee structures, invoices and payments post to the accounting ledger that the finance team already closes each period. For teachers, course schedules and assessment entries appear where they already work. For IT, the number of systems to back up, patch, secure and grant access to drops, though the education apps and their roles still need deliberate configuration.

The fit depends on three questions to answer before any build starts. First, which records the institution must keep and for how long, because student data falls under rules such as FERPA and the institution's own retention schedule, and those rules shape which roles see which fields. Second, which payment methods and gateways the bursar's office accepts, since online fee payment depends on a configured gateway and the institution's merchant arrangements, and the team should confirm these with its provider. Third, how people sign in. ERPNext supports LDAP login through LDAP Settings and Social Login Keys for external providers, so the registrar should confirm whether staff identities already live in Active Directory, OpenLDAP or a single sign-on service before deciding where accounts are created. If the answers point to many separate student-facing systems or a heavily regulated research environment, a single back office may need extra integration work or may not be the right first step.

Which education records rules shape the ERPNext build

This table maps the US education records, financial aid, children's privacy and accessibility rules to the parts of an ERPNext build they affect, with the source for each. Read it as a starting list for your compliance and legal review, not as a finished control set, since which rules apply depends on your funding, student population and services. The main takeaway is that the rules touch roles, logging, retention, login and portal design, so they should be settled before data migration begins.

RequirementSourceWhat it means for the ERPNext build
Access limited to legitimate educational interestFERPA, 34 CFR 99.31(a)(1)(ii)Design role permissions so staff see only the student records their duties need, using role and user permissions and field-level restrictions.
Outside contractor acts under direct controlFERPA, 34 CFR 99.31(a)(1)(i)(B)Your contract and access grants must keep the institution in control of records held in the system, including implementer accounts.
Inspection request within 45 daysFERPA, 34 CFR 99.10(b)Confirm you can locate all records for one student across admissions, fees, exams and HR-linked data within the 45-day window.
Log of each access and disclosureFERPA, 34 CFR 99.32Plan audit logging and retention of access records for as long as the student records are kept, and test that logs can be exported.
Multi-factor authentication for system accessGLBA Safeguards Rule, 16 CFR 314.4(c)(5)Apply two-factor authentication and login policies to staff accounts that reach fee and financial aid data, and confirm the login method you use.
Written information security program and breach noticeGLBA Safeguards Rule, 16 CFR 314.4 and 314.4(j)Document access, encryption and incident procedures, and build the ability to identify affected consumers quickly enough for a 30-day FTC notice.
Children under 13 personal informationCOPPA Rule, 16 CFR Part 312Applies only if the school collects personal information from children under 13 through the portal or forms. Confirm whether that applies before designing parental consent and deletion.
Retention and deletion timeframesCOPPA, 16 CFR 312.10 (where applicable)Where COPPA applies, keep a written retention policy with deletion timeframes and configure automated cleanup or anonymization.
Accessible student and applicant portalADA Title II web rule, 28 CFR Part 35 Subpart HTest the student portal, admissions forms and payment pages against the accessibility standard the rule references, and fix theme and form issues before launch.
Penalties for non-complianceFERPA, 34 CFR 99.67Funding and eligibility are at stake, so compliance evidence should be kept with the system documentation from the start.

How student records, fee invoices and accounts share one dataset

The main reason to run registrar, fee and accounting work on one ERPNext site is that a tuition payment, a fee invoice and a student record point at the same underlying data. An applicant or student record links to a guardian or contact, a fee structure defines the components and amounts charged for a program and term, and a fee invoice is generated from that structure against the student. When a parent pays through an online payment gateway, the payment is recorded against the invoice and posts to the receivable and bank accounts in the ledger. For a bursar, the practical benefit is that a question such as "why does this student still owe tuition" can be traced from the ledger entry back to the invoice, the fee structure and the enrollment that produced it. Before go-live, confirm the exact Frappe Education DocTypes, their field names and how they relate (for example, which record holds the program enrollment and which holds the fee invoice) against the release your institution plans to run, since these relationships have changed between versions.

The main trade-off is between one site for registrar, finance and HR and separate sites connected by integration. A single site keeps the student, invoice and ledger chain intact, lets one set of roles and permissions govern who sees fee data, and avoids copying records between systems that can drift apart. The cost is that every team shares one permission model, so role design, user permissions and field-level access must be settled before users are created, and a change to finance configuration affects the registrar's screens. Separate sites with an integration give each department its own release schedule and access boundary, but every shared field, such as student ID, guardian contact or payment status, becomes a synchronization job that someone must monitor and reconcile. Ask the implementation partner to write down which party is the system of record for each shared object before you choose.

Whichever layout you choose, plan the reconciliation routine before the first term is billed. Decide who matches gateway settlements to invoices, how partial and refunded payments are handled, and which reports the bursar uses at period close. Confirm in your own environment how your payment gateway app posts to ERPNext, because the exact entries created depend on the configured accounts and the integration version. Test a full cycle with sample students in a non-production site: enrollment, invoice, online payment, refund and month-end report, and check that every ledger entry can be traced back to its source document.

Which modules and settings matter most for a school or university

A school or university build on ERPNext and Frappe Education turns on a handful of decisions: how applicants become students, how fees are structured and collected, how schedules and exams are published, and how people sign in. Each card below names the decision that drives the build and the data the institution must supply before configuration starts.

Admissions and applicant records

Decide whether applicants are created through a web form, imported from an admissions office spreadsheet, or both, and map each application stage to a status your admissions team already uses. Confirm which fields are required before an applicant can be converted into a student record, since that conversion creates the record everything else depends on. Collect the program list, intake calendar and document checklist first. Use Data Import for historical applicant lists from CSV, Excel or public Google Sheets, and remember that the documentation advises importing only a few thousand records at a time.

Student and teacher master data

Settle the student and instructor identifiers, guardian relationships and program enrollment rules before any records are loaded, because later modules reference them. Decide which personal fields are visible to which roles, since student records hold education records covered by FERPA. Ask the registrar for a clean extract with one row per student and separate tables for guardians and enrollments, so child rows import in the right order. Confirm who owns record corrections and how changes are logged.

Fee structures and online payment

Fee structures are the core finance decision: define fee components per program and term, decide how scholarships and discounts are applied, and choose which payment gateway settles student payments into the institution's bank account. The bursar must confirm the accounts, tax treatment and refund rules, since these flow into the general ledger. Expect the gateway account and reconciliation process to need a separate scope. Ask for the current fee schedule, discount approval rules and the receivables aging the finance office reports on.

Course schedules, assessments and exams

Decide how courses, sections, rooms and instructors are scheduled, and whether timetable changes are made by the registrar or by department staff. Exam definitions, grading scales and result publication rules determine who can see marks and when. Confirm the term calendar, room inventory and grading policy with academic leadership before building schedules, because changing them after results are entered requires careful correction. Ask for last year's timetable and the assessment policy document.

Student portal and role access

The student portal exposes selected records to enrolled learners and guardians, so the decision is which pages, documents and fee balances each portal role may see. Set portal user creation as a deliberate step tied to enrollment, not a bulk export of every applicant. Confirm which documents students may download, such as transcripts or fee receipts, and which must be requested through the office. Review role permissions with the data protection officer before launch, and test them with a student account and a guardian account.

Sign-in through LDAP or social login

Choose one identity source for staff and students before accounts are created. ERPNext supports LDAP login against Active Directory or OpenLDAP, with SSL/TLS options and automatic mapping of LDAP groups to ERPNext roles at each login. Frappe's Social Login Key can use providers such as Google or Microsoft, or a custom OAuth or OpenID Connect endpoint. Confirm with the identity team which directory holds staff accounts, how student accounts are provisioned, and whether multi-factor authentication is enforced, since the GLBA Safeguards Rule requires it for anyone accessing an information system.

Choosing where the ERPNext site runs

Frappe Cloud shared hosting places your ERPNext site on a shared bench managed by Frappe. According to the ERPNext pricing page, shared site hosting starts at 5 US dollars per month, and the price is the lowest entry point of the managed options. Frappe runs the infrastructure, so your team carries less day-to-day operations work, but you share the platform with other tenants and accept its limits.

  • Server Scripts are not available: Frappe Cloud public shared benches do not allow Server Scripts, so any logic that needs them (for example, custom fee validation on document save) must move to a Client Script, a custom app on a dedicated plan, or a manual process.
  • Data residency is set by Frappe's hosting regions: Confirm with Frappe where the data is stored and processed before loading any student records, since FERPA and GDPR questions depend on it.
  • Operations are largely managed: Backups, updates and platform maintenance are handled by the provider, but your institution still owns configuration, user access and data quality.
  • Customization is constrained: Custom apps and scheduled jobs may not be available on shared plans, which can affect integrations with a student information system.
  • Cost is one-time setup plus recurring subscription: Implementation work is quoted separately, and the hosting fee recurs.

Before choosing this tab, confirm in writing which features your fee structures and portal need are supported on a shared bench.

Compliance duties that change the ERPNext design

A school or university running student records on ERPNext and Frappe Education inherits several overlapping privacy and security duties, and each one lands on a specific configuration or hosting choice. The cards below set out what the institution must be able to prove, what the ERPNext design should provide, and what to confirm with your counsel and auditors. DeployOpen prepares systems, controls and evidence for these reviews, but does not issue audit reports or certifications.

FERPA record access and disclosure logging

Under 34 CFR Part 99, the institution must show that only school officials with a legitimate educational interest see student records, and must log each disclosure of personally identifiable information with the parties and their interests. In ERPNext, this means role and user permissions on Student, Program Enrollment and Fees, a tested process for the 45-day inspection deadline, and an access log retention decision agreed before go-live. Confirm with counsel which disclosures your institution must record.

Contractor access as school official

An implementation partner or hosting provider may see education records only if it performs a service the institution would otherwise use employees for, works under the institution's direct control, and observes redisclosure limits. Written scope, named access accounts, and removal of partner logins at handover all support this position. Ask your partner how it will be granted and revoked on your site, and whether support staff can view student data on your production instance.

GLBA Safeguards duties for Title IV institutions

Institutions in the Title IV programs agreed to follow the GLBA Safeguards Rule, which requires a written information security program and multi-factor authentication for anyone accessing an information system. On ERPNext, enforce two-factor authentication for all staff and finance users, restrict admin roles, and keep login policies under review. The rule also requires FTC notification within 30 days of discovering an event affecting at least 500 consumers, so your incident runbook must name who makes that call.

COPPA for under-13 personal data

If the school collects personal information from children under 13, for example through admissions forms, learning accounts or the portal, COPPA requires a written security program, at least annual risk assessments, and a written retention policy with a deletion timeframe. In ERPNext, this translates into a documented retention rule for applicant and child records, scheduled anonymization or deletion jobs, and limits on which custom fields collect data from minors. Confirm which age groups your institution serves before the data model is built.

GDPR and NIS2 for EU institutions

An institution established in the EU or processing EU residents' data falls under GDPR for lawful basis, data subject requests and retention, and may fall under NIS2 for cybersecurity risk management and incident reporting, depending on its sector and national transposition. ERPNext design choices include where the database and backups are hosted, how data subject access requests are fulfilled from the Student and Guardian records, and how logs feed incident detection. Confirm your status under each regulation with your data protection officer before hosting decisions are made.

Web accessibility for public entities

Public institutions covered by Title II of the ADA must meet the web and mobile accessibility requirements in 28 CFR Part 35 Subpart H. The student portal, admissions forms and fee payment pages built with ERPNext web forms and portal templates are in scope. Test custom templates and print-free portal pages with assistive technology, and record the test results as evidence. Ask your partner whether custom Jinja templates and third-party payment widgets were included in the test plan.

How to load legacy student and fee records without overloading imports

Load legacy student, guardian and fee data in batches, and reconcile every opening balance before any student sees a fee statement. ERPNext's Data Import tool reads CSV or Excel files or public Google Sheets, and it works from downloadable templates for each doctype. Student, guardian and fee records usually span several doctypes, and guardians and fee lines are linked to students, so the import order matters. Load the student records first, then guardians and program enrollments, then fee structures and outstanding fee balances. Child table rows, such as guardian rows on a student or line items on a fee, go into the same file as their parent record. The documentation advises importing only a few thousand records at a time, so split large exports into batches by program or academic year and log the result of each batch. Confirm the template version for your ERPNext release before you map columns, since template fields can change between versions.

Opening fee balances are the highest-risk part of the cutover. Agree with the finance office which balances move across, whether as opening invoices, outstanding amounts or payment history, and reconcile the totals against the legacy ledger batch by batch. Confirm how Frappe Education and the accounting modules will post these balances, and test one academic year end to end on a separate test site before the production load. The test site also shows which student and guardian records fail validation, such as duplicate identifiers or missing mandatory fields, so those can be fixed in the source file rather than by hand after go-live. Plan a cutover window in which legacy systems are frozen for fee changes, because any payment taken during the load will not appear in the reconciliation.

Migrated student and guardian data is personal data, so the access and retention duties that apply to live records apply to the migration files, staging sites and logs as well. Limit who can run imports and who can read the source spreadsheets, store them under the institution's control, and delete working copies once reconciliation is signed off. FERPA's recordkeeping and access rules in 34 CFR Part 99 cover education records wherever they sit, and any contractor handling the data must be under the institution's direct control. Ask your DeployOpen team and your compliance lead to document where each migration file lives, who holds it, and when it is destroyed. Review 34 CFR Part 99 on eCFR with counsel before the data leaves the legacy system.

How a school or university rollout runs in phases

The sequence moves an institution from compliance scoping and hosting decisions to a tested Frappe Education system, with each phase closing on a written decision or piece of evidence. Timing for each phase should be confirmed in a written scope before work starts.

  1. Map requirements and compliance obligations first

    The institution's registrar, finance office, IT lead and compliance or legal contact list the processes the system must support, such as admissions, fee collection, exams and the student portal, and identify which privacy and security obligations apply to each record type. DeployOpen maps those obligations to configuration choices, access roles and retention rules, and notes where an auditor or counsel must make the final call. The phase closes with a signed requirements register that names the data categories, the data owner for each and the controls that will be evidenced later.

  2. Decide hosting and identity before building

    The institution decides where the system runs, such as its own cloud account, a data center or a managed hosting arrangement, and which identity source signs staff and students in. The team checks whether the institution's directory is Active Directory or OpenLDAP, which ERPNext supports through LDAP settings with TLS options, or whether a social login or external OIDC provider is required. Hosting and identity choices also determine who holds administrator access and where backups are kept. The phase closes with a written architecture decision record and an approved list of administrator accounts.

  3. Configure the system on a test site

    DeployOpen builds a non-production site and configures the academic structure, such as programs, courses, academic years, fee structures, grading and the course schedule, following the requirements register. Custom fields, print formats and any server-side logic are reviewed against the institution's change policy, and Server Scripts are enabled only where the hosting setup allows them. The registrar and finance staff test each configuration with sample cases they supply. The phase closes when the institution signs off the test site as matching the requirements register, with open defects logged.

  4. Migrate legacy records in controlled batches

    The team extracts student, guardian, staff and fee records from the legacy systems and maps them to the Frappe Education DocTypes. Imports use the Data Import tool with its downloadable templates, and the documentation advises importing only a few thousand records at a time, so the team loads each batch, reconciles counts and balances against source reports, and keeps a log of rejected rows. Personal records are loaded only into environments with the access controls the institution approved. The phase closes when each batch reconciles and the registrar signs the reconciliation report.

  5. Test the student portal and online fee payment

    Test users from each role, including a student, a guardian, a teacher and a finance clerk, walk through enrollment, timetable viewing, fee statements and payment on the test site. The team checks that each role sees only the records it is entitled to, that payment gateway callbacks update the fee records correctly, and that receipts and notifications are sent. Accessibility of the portal is checked against the institution's obligations, and results are recorded as test cases. The phase closes when every critical test case passes or has a documented, accepted exception.

  6. Train staff on their own workflows

    Training is organized by role, covering admissions officers, registrars, teachers, bursars and HR staff, using the institution's own forms and scenarios rather than generic demonstrations. Each group practices the tasks it performs weekly, such as creating an admission, posting a fee invoice, recording attendance or running an exam schedule. The team also trains administrators on access reviews and on how to handle a data access request. The phase closes when each role group completes a practical task sheet and the institution names an owner for user administration.

  7. Go live and run a hypercare period

    The team freezes configuration, runs a final migration of the remaining records and verifies counts, switches users and the payment gateway to production, and confirms backups and scheduled jobs are running. During the hypercare period agreed in the written scope, DeployOpen and the institution's IT staff review tickets daily, check error logs and payment reconciliations, and tune permissions where users report access problems. The phase closes with a hypercare exit report listing open issues, the operations runbook and a handover to the institution's support model. Confirm the length of hypercare and the support terms in the written scope.

What schools and universities ask before hiring an implementation partner

How much does an ERPNext with Frappe Education implementation cost?

No fixed figure applies, because the quote follows from the written scope. Cost has three main parts: the software, which is free to self-host under the GPL-3.0 license, the infrastructure you pay for, and the implementation work. Implementation covers configuring fee structures, admissions and course schedules, migrating student and finance records, building the portal and connecting finance and HR. The recurring costs are hosting, backups, upgrades and support. According to the ERPNext pricing page, Frappe Cloud shared site hosting starts at 5 US dollars per month, while self-hosting ERPNext is free. Ask each bidder for the scope, the deliverables, the number of programs and integrations, and which recurring costs are included.

How long does a school ERP implementation take?

The timeline depends on how many programs, fee rules and integrations are in scope, and on how clean your existing student data is. Admissions, fees and the student portal usually depend on decisions your registrar and bursar have not yet made, so those decisions often set the pace. Data migration takes longer than most teams expect, because records must be cleaned and tested before import. Confirm the timeline in writing against a fixed scope, and ask the partner which milestones depend on your staff, such as sign-off on grading rules or fee schedules.

What does our institution need to provide before implementation starts?

Before work starts, you need to provide written registrar rules, including enrollment, grading, transcript and course-repeat policies. You also need your fee policies, refund rules, scholarship and payment plan terms, and a sample set of student and finance records. For access, the team needs an identity provider contact and administrative access to your directory, such as Active Directory or OpenLDAP, if you plan to use LDAP login, or the details of your OAuth or OpenID Connect provider for Social Login Key sign-in. Ask the partner for a complete list of inputs in the written scope.

Can our own IT staff implement ERPNext using the documentation?

Yes, for a small deployment with a team that has Linux, database and Python experience, the public documentation and the frappe_docker repository provide a workable starting point. The harder parts are fee logic, student and finance data migration, role permissions for records that carry student data, and integration with your identity provider. Mistakes in these areas are costly to reverse after students and staff start using the system. Compare the cost of your staff's time and the risk of a rework against a fixed-scope partner engagement, and confirm which parts you want to keep in-house.

Which ERPNext version should we run given the support policy?

Run a version that is still in support for the full life of your deployment. According to Frappe's supported versions page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. Frappe's policy also says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Ask your partner to confirm the version, the upgrade path and which support plan applies to your setup.

What does ongoing support and maintenance look like after go-live?

Ongoing work includes applying minor releases, which both supported major versions receive frequently, testing upgrades in a staging copy, monitoring backups and the background scheduler, and handling fee cycle changes or new programs. Support can be provided through a retainer agreed in writing, and it should state response expectations, the systems covered and how upgrades are scheduled around enrollment and fee deadlines. Ask for a written list of recurring tasks, who performs each one and how restores are tested.

Does the implementation cover FERPA and other student data rules?

Implementation can prepare the system for compliance review, but it does not make your institution compliant, and DeployOpen does not issue audit reports or certifications. Access control, audit logging of disclosures, data retention and vendor contracts are shaped by rules such as FERPA in 34 CFR Part 99. Ask your partner which controls are configured in ERPNext, which are handled by your policies, and what evidence the system produces for an assessor. Confirm the requirements with your legal and compliance team before scoping.

How DeployOpen works on this

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports ERPNext inside the infrastructure you control, including the admissions, fee, exam and finance flows a school or university runs on Frappe Education. Work starts from a written scope that names the modules, apps, integrations and records-handling duties in play, so the quote follows from what is actually agreed.

How we scope

  • Map admissions, student records, fee structures, exams and finance flows against the modules and apps you plan to use.
  • Identify which student and staff data falls under FERPA or other rules that apply to your institution, and confirm them with counsel.
  • Agree deliverables, timelines and acceptance criteria in writing before any build work begins, as engagements are fixed-scope.

How we build

  • Configure Frappe Education and ERPNext on your chosen hosting, with server scripts only where the hosting plan allows them.
  • Connect identity through LDAP or social login to your directory, and test role mapping with real staff and student accounts.
  • Plan and rehearse data imports for students, courses and fee history in batches, checking each batch against source records.

How we hand over

  • Deliver configuration documentation, customization records, access matrices and runbooks your administrators can follow.
  • Walk your registrar, finance and IT staff through admissions, fee posting and exam workflows before go-live.
  • Provide evidence of access controls, backups and change history that your own auditors can review and assess.

How we support

  • Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
  • Plan ERPNext and Frappe version upgrades with the support lifecycle dates confirmed against Frappe's published policy.
  • Confirm with your team who owns patching, backups, monitoring and access reviews after handover, and write that split into the scope.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com