The desk everything lands on

Admissions, fees, records and the report somebody needs by Friday. One portal, one set of records, no re-entering.

Book a demo

The week this fixes

Monday starts with three parents at the counter, a transfer certificate that has to be issued today, and a principal asking why last month's collection figure does not match the bank. None of that is difficult work. It is slow because the answer lives in four places and none of them agree.

By Wednesday somebody has rebuilt the outstanding-fees list in a spreadsheet because the printed one was out of date by the time it was printed. By Friday that spreadsheet has been emailed to two people who will each edit their own copy.

The administrator portal is built on the assumption that this is the actual job. Not reporting on the institution once a term, but answering the same twenty questions every day without going looking for the answer.

What the administrator portal handles

Grouped by the job it belongs to, rather than by the menu it sits in.

Admissions and enrolment

Enquiry through to enrolled, with the record created once and carried forward rather than retyped at each stage.

Transfers and withdrawals

A leaver keeps their history. The certificate is issued from the record, so it cannot disagree with it.

Student and staff records

One record per person, visible to the people who need it and nobody else.

Fee collection and receipts

Collection against the correct head, with the receipt produced at the counter rather than written up afterwards.

Concessions and adjustments

A discount is recorded against the family with a reason attached, so next term nobody has to remember why.

Outstanding balances

Who owes what, as a live view rather than a report that is stale the moment it is run.

Documents and ID cards

Certificates and cards generated from the record, so a reprint is never a retype.

Bulk import and export

Getting a year group in at the start of a session, and getting data back out whenever you want it.

Reporting

The numbers leadership asks for, available without a request going into a queue.

The cases most systems get wrong

Any system handles a student who joins in April, pays on time and leaves in March. The office is not slow because of those.

The mid-term joiner. A child starts in week six. Fees are pro-rated, but not evenly, because the transport charge is monthly and the admission fee is one-off. Most systems make this a manual override, which means it is invisible to whoever handles the account next term.

The family with three children on different structures. One on a sibling concession, one on a scholarship, one paying full. A single payment arrives covering all three. Splitting that correctly, and having it still be correct when one child leaves, is where spreadsheets quietly break.

The verbal concession. A principal agreed something in August. It was never written down. In January the family says one thing and the office remembers another, and there is no record to settle it.

The correction after the receipt. A payment was posted against the wrong head. Deleting it loses the audit trail; leaving it makes the ledger wrong. The right answer is a reversal that stays visible, which is what we do.

What an administrator can and cannot see

Being explicit about the limits matters as much as the access.

Scoped to their campus

An administrator at one campus does not see another campus, unless you deliberately give them a group-level role.

Sensitive fields stay hidden

Not everyone who can open a record can see every field on it. Payroll and personal contact details are separable from the rest.

Changes are attributable

Every change carries who made it and when, so a query about last month is answered from record rather than memory.

Deletions are reversible

Removing a record hides it rather than destroying it. A mistake on a Friday afternoon is recoverable on Monday.

What it shares records with

The point of a single portal is that the work done here does not have to be repeated elsewhere. An enrolment creates the student record that attendance marks against, that examinations reports on, and that the family portal reads. A fee structure set here is what the family sees on their own screen, at the same moment, without anybody publishing anything.

That is also why corrections matter. A record fixed here is fixed everywhere it appears, which is the opposite of the spreadsheet problem where fixing one copy leaves three wrong.

Questions we get asked

How long before the office is actually using this?
Most institutions run the first term in parallel on fees only, then move the rest once a full collection cycle has been through it. Trying to move everything in one week is how implementations fail, and we will say so rather than agree to it.
Can we bring our existing student data in?
Yes, by bulk import. The realistic constraint is not the import itself but how consistent the existing data is, which is worth looking at before a migration date is agreed.
What happens when an administrator leaves?
Their access ends and their record of what they did remains. Those are deliberately separate: losing the history when somebody leaves is how a query becomes unanswerable.
Can two people work on the same thing at once?
Yes. That is the main practical difference from a shared spreadsheet, where the second person either waits or creates a second version.
Do we have to use every module?
No. What is switched on is set per institution, and a module nobody uses is better switched off than left in the menu confusing people.
Can we restrict who sees fee information?
Yes. Access is set per role, and financial information is one of the things most commonly restricted to a smaller group than general student records.

Bring us your messiest fee case

Not the straightforward one. The family with three children on different structures, or the concession nobody wrote down. That is the useful demo.

Book a demo