Enquiries and admissions
Enquiries from the website, phone and walk-ins tracked through follow-up to enrolment, with the source recorded and nothing depending on a counsellor’s memory.
Schools and colleges run four cycles a year and usually run them in four places: admissions in spreadsheets, attendance in a register, fees in accounting software and academics in whatever the department prefers. The gaps between those four are where a student record goes wrong.
An Odoo school system puts the operational half on one database. The academic half — classes, timetable, exams — has no standard Odoo model, so it is built as a module on top, and this page is explicit about which is which.
Businesses running Odoo with OdooBots
An Odoo school management system holds admissions, the student and parent record, fee structures and collection, staff, purchasing and accounts on one database. Enquiries become admissions, the student links to the parent who pays, fee structures generate instalments with concessions and late fees, receivables report by programme and term, and library, lab and canteen purchasing runs through the same inventory and accounting as everything else.
Odoo has no standard model for a class, a timetable, an exam or a mark. Those are built as a module on top of it. We say so plainly, because a partner implying they ship with Odoo is a partner who will discover otherwise in week three of your project.
Six areas make up the operational side of an institution, and they share one database so a student is one record rather than six.
Enquiries from the website, phone and walk-ins tracked through follow-up to enrolment, with the source recorded and nothing depending on a counsellor’s memory.
The student as the academic record and the parent as the payer, linked, with documents, contact history and the whole family visible together.
Fee structures by programme and term generating instalments, with concessions, scholarships, late fees and part payments, and receivables ageing by programme.
Teaching and non-teaching records, attendance and leave with academic calendars that do not match a standard working week.
Lab consumables, library stock, uniforms and canteen supplies with reordering per location, so departments replenish against real consumption.
Fee revenue, grants, salaries and overheads in one ledger with analytic accounting per department, programme or campus, and multi-company for a group.
An enquiry becomes an admission, and the student record carries the parent who pays. The fee structure for that programme generates the term’s instalments, which are invoices like any other, so receivables ageing answers who owes what by programme without anyone building a sheet. Purchases for the chemistry lab tag to the chemistry analytic account, and the department’s real cost is a report.
The academic layer sits above this. Where an institution keeps a student information system, Odoo runs alongside it; where it does not, that layer is built as a module.
These are the configuration decisions that are cheap to make now and structural to change once transactions exist. We walk through each one before a single record is migrated.
Exactly which records live in Odoo and which stay in a student information system, written down first. Leaving this vague is the commonest reason an education project runs long.
Programme, term, instalment, concession, late fee — and whether these are products with pricelists or a custom fee master. Painful to change once a term is invoiced.
The student or the parent. This decides the contact structure, the ageing and who gets the reminder, and most institutions need both.
A scholarship as a discount behaves differently in your accounts from one as an expense, and the choice affects what your auditor sees.
Per department, programme or campus. Every purchase, salary and fee tags to it, so it is settled before the first transaction.
They rarely align, and how term revenue is recognised against a financial year is an accounting decision configuration then follows.
If classes, timetable and exams are in scope, that is a build. Its scope is agreed and quoted separately from the configuration work.
Odoo moves features between Community and Enterprise from one version to the next, so the list below is what holds today and is confirmed against your own version during the diagnosis rather than taken as permanent.
The operational side runs on standard applications, most of which are Community: CRM, Sales, Invoicing, Purchase, Inventory, Employees and Accounting.
What is not standard at all is the academic layer, and that is a build rather than a licence question.
We would rather say this before you buy licences than after. These are the areas where we scope real development, recommend a bolt-on, or tell you another tool is the better answer.
Building a clash-free timetable across rooms, staff and sections is a constraint-solving problem. A specialist tool does it properly; a custom module does it approximately.
Marks entry, weighting and report card generation belong in a student information system. Odoo can hold the outcome; it should not be the system of record.
Course content, assignments and online classes are an LMS function, not an ERP one.
Board, university and state submissions vary and almost always need either custom development or the SIS that already produces them.
Bus routes, stops and tracking need a custom module or a dedicated product.
Room allocation, mess accounts and attendance are a separate build if they are in scope.
Implementing An Odoo school management system needs more than installing the application. It should reflect how your business already works, and change only what is worth changing.
Understand your programmes and fee structures, who pays and who is taught, whether a student information system stays, and what your auditor needs on term revenue.
Settle the SIS boundary, the fee structure model, who the invoice addresses and the analytic structure before anything is configured.
Set An Odoo school management system up around how you work rather than installing it at its defaults, and build only what configuration genuinely cannot reach. See Odoo customization.
Masters, open items and opening balances prepared and loaded. Data cleaning is scoped explicitly, because it is usually the largest single task. See Odoo migration.
Your team runs real transactions in a test database before go-live, including the awkward cases that never appear in a demonstration.
Role-based training for the people who key transactions daily, then cutover, hypercare and ongoing support and AMC.
We do not publish one price, because the same application costs very differently depending on the factors below. We do publish what moves the number, and the price is fixed in writing before work starts.
We separate the fee engine from the academic layer on day one and quote them separately, because institutions are routinely sold "a school ERP" and then discover halfway through that the timetable was never in scope.
Product capabilities stated on this page are documented by Odoo. The configuration advice, edition notes and limitations come from our own implementations.
Tell us how many programmes and fee structures you run, and whether a student information system is staying. Those two answers decide the scope, and the diagnosis call is free.