# OpenEduCat: a modular ERP for schools and colleges

> OpenEduCat Community Edition is a set of Odoo addons covering admissions, exams, fees, attendance, library, transport, hostel and payroll for educational institutions, distributed under the LGPL v3. It suits schools and colleges that want an ERP they can extend rather than one they configure.

**openeducat/openeducat_erp** — Comprehensive Open Source ERP for Educational Institutes

- Repository: https://github.com/openeducat/openeducat_erp
- Website: https://www.openeducat.org
- Stars: 895 · Forks: 781
- Language: HTML
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/openeducat-openeducat-erp

## One repository per functional area, not one monolith

The repository layout is the first thing to read, because it explains how the product is built. The top level is a list of addons, one per functional area, and there are fourteen of them: openeducat_core, openeducat_admission, openeducat_assignment, openeducat_attendance, openeducat_classroom, openeducat_exam, openeducat_facility, openeducat_fees, openeducat_library, openeducat_parent, openeducat_timetable, openeducat_activity, openeducat_erp and theme_web_openeducat. The naming follows the Odoo addons convention, with a theme addon at the end, and the presence of an openeducat_erp entry suggests the umbrella application that pulls the others in. This is the practical difference between an ERP you configure and an ERP you extend. Because the code is split by domain, a school that needs a fee structure no template covers can modify or replace one addon and leave the rest alone, and a school that does not need transport or hostel can avoid installing those. The primary language of the repository is listed as HTML, which is a consequence of the Odoo view definition files being XML and templates being HTML, while the business logic is Python.

## Admissions, students and the course and batch model

The feature list runs from the beginning of a student's life to the administration around it. Admissions and registration covers enrollment and registration processes, and student information management covers profiles, academic history and personal details. Course and batch management organises courses, batches and scheduling, and that module is the structural centre of the whole system, because batches are how an institution distinguishes one intake of a course from another, and exams, attendance, fees and results all hang off them rather than off the student directly. Examination management covers exam scheduling, evaluation and result processing. Attendance and timetable covers keeping track of attendance and class schedules, and library management handles book lending, cataloging and member management. Two modules cover the physical side of a campus, transport and hostel management, overseeing transportation logistics and hostel accommodations. Parent-facing communication has its own addon in openeducat_parent, and the separate activity addon suggests a general activity or event mechanism on top of it.

## Money and staff, the two areas that decide whether an ERP is used

The two modules that decide whether an institution actually keeps using the system are fees and HR, and both are listed with detail. Fee and finance management automates fee collection, invoicing and financial reporting, which is the part of an ERP that replaces a spreadsheet and a receipt book. HR and payroll management covers staff records, payroll and performance reviews. These two are also the parts that vary the most between institutions, because fee structures differ by programme and by student category, and payroll has to reflect local employment rules. That is where the modular design pays off and where the cost of a self-hosted ERP appears. A school whose fee model is idiosyncratic will spend its time in the fees module rather than in the exam module, and the readme is upfront about the platform being customizable and modular, with modules to adapt or extend to meet an institution's unique needs. Reporting and analytics, with the framing of generating insightful reports for data-driven decision-making, is the module that turns all of the above into something a principal can act on, and communication tools with integrated messaging and notifications covers the announcements that keep a large institution aligned.

## Installation is delegated to a guide, not to a script

The installation section is one line, and it points at a hosted document rather than describing the steps. It says to follow the steps to set up OpenEduCat Community Edition, with the link pointing at the administration install page in the documentation site. That is a reasonable arrangement for a system of this size, since a real deployment involves a database, a Python environment, an application server and the initial configuration of your institution's academic structure, and none of that fits in a readme. The repository does carry the configuration files for the code quality tooling, with a flake8 config and a pylint config, and there is a coverage configuration file, a pre-commit configuration and a GitHub directory, which together indicate a project where the code style and the test coverage are enforced. The documentation portal is the reference for both administrators and users, with separate user guides, and the features page is the canonical full list rather than the readme summary. There is also a live demo, so an evaluation can be done in a browser before anything is installed.

## The branch and release state deserves attention

The version information in the repository is the part most likely to surprise an adopter. The default branch is 19.0, which tells you the development line, and the only release listed is 18.0-beta, tagged 18.0, dated 2024-11-26, which is a beta of the previous line rather than a stable release of the current one. The last push was on 2026-10-13, so the 19.0 branch is being worked on actively, but there is no 19.0 tag in the release list. That combination tells you what kind of project this is: an actively developed open source ERP where the version you run is a branch you choose, not a release you install. For a school considering it, the sensible approach is to run the stable line it can find, or to pin a commit of the development branch and take responsibility for the upgrade, because a branch that moves will not stay where you left it. The roadmap section reinforces that the project is in motion, with an enhanced mobile experience, new modules based on community feedback, performance optimisation, extended integrations with third-party services and user experience enhancements listed as the near-term direction.

## LGPL in the documentation, a custom file in the repository

The licensing is stated in the documentation but the repository's own field disagrees, and that is worth resolving before a deployment. The readme carries a badge reading LGPL v3 and its licence section says the project is distributed under the LGPL-3.0 License with a link to the LICENSE file for details, while the licence field for the repository says Other, with a note that it is a custom licence GitHub cannot classify and that the LICENSE file is the place to look. The two statements are not necessarily contradictory, since a repository can be classified oddly while still shipping a recognised licence in its files, but they are not the same statement and a school that is redistributing modified addons needs to read the actual LICENSE file rather than take either label on trust. LGPL is a reasonable choice for an ERP, since it lets a school modify modules and share the modifications while not requiring the whole system to be published, but the module boundaries then matter, because the boundary between a modified addon and the rest of the system is exactly what LGPL asks about. Support comes through a support email address, the community forum, a community chat space, an issue tracker on GitHub, and regular community meetings and webinars.

## Conclusion

OpenEduCat is a good fit for an educational institution that has outgrown spreadsheets, that wants its admissions, fees, attendance and exam data in one place, and that has somebody on staff who can extend a module when the workflow does not match. It is the wrong choice for a school with no technical capacity, since almost every real deployment needs local configuration of fees, grading and timetable, and it is the wrong choice if you need a guarantee of a supported release, since the only tagged release in the list is 18.0-beta from 2024-11-26 while the development branch is 19.0. Before committing, read the installation guide for the community edition, plan the data model for courses and batches early because almost every other module depends on them, and check the licence terms in the LICENSE file, since the documentation describes the project as LGPL-3.0 while the repository's own licence field points to a custom file. The last push was on 2026-10-13.

## FAQ

### What is OpenEduCat and what does it cover?

It is an open source educational ERP for academic and administrative processes, covering admissions and registration, student information, course and batch management, examinations, fees and finance, attendance and timetable, library, transport and hostel, communication, reporting and analytics, and HR and payroll. The feature list is in an addon per area so modules can be adapted or extended.

### How do I install OpenEduCat?

The installation section points to the setup steps for the Community Edition in the project documentation, at the administration install page on the documentation site. There is also an online demo you can try in a browser before installing anything, and the documentation portal carries both administration guides and user guides.

### Which version of OpenEduCat should I run?

The default branch is 19.0 and the only listed release is 18.0-beta from 2024-11-26, with the last push on 2026-10-13. In practice that means you choose a branch and take responsibility for the upgrade, so pinning a commit of the line you test is safer than tracking a moving branch.

### What licence does OpenEduCat use?

The documentation states LGPL-3.0 and points to the LICENSE file, while the licence field on the repository says it is a custom licence GitHub cannot classify. Read the LICENSE file directly if you plan to redistribute modified modules, since the addon boundaries are what LGPL questions turn on.

### Can I extend or replace individual OpenEduCat modules?

Yes. The project describes itself as customizable and modular, and the repository is laid out as one addon per functional area, including a theme addon, so a school can adapt or extend the modules it needs without touching the rest. The roadmap also lists new modules based on community feedback as ongoing work.

## Sources

- [Issues](https://github.com/openeducat/openeducat_erp/issues)
- [openeducat/openeducat_erp on GitHub](https://github.com/openeducat/openeducat_erp)
- [Project website](https://www.openeducat.org)
- [README](https://github.com/openeducat/openeducat_erp/blob/19.0/README.md)
- [Releases](https://github.com/openeducat/openeducat_erp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openeducat-openeducat-erp