Start a conversation

Product decisions

What a school ERP needs before online payments

Jeet Sorathiya · 11 August 2026 · 3 min read


Online fee collection is the first thing every school asks about and close to the last thing worth building. Not because it is hard, but because a pay-now button on top of a fee ledger nobody trusts just moves the argument to a new place.

Every school software demo opens with online fee payment. It is the feature with the clearest story: parents pay from a phone, the school stops handling cash, everyone is happier.

A fee module can ship without a gateway, and usually should. This is why.

The ledger is the product, not the payment method

A school office’s actual problem is not that parents cannot pay online. It is that nobody can answer, quickly and with confidence, who owes what.

That question is harder than it sounds. A single student’s outstanding amount depends on the fee structure for their class, the instalment schedule, a sibling concession, a staff-ward waiver, a partial payment taken in cash in March, a cheque that bounced in April, and a fine that may or may not apply.

If that computation is not right, adding a payment gateway means parents can now pay the wrong number faster, and the reconciliation argument moves from the front desk to a bank statement.

What actually matters first

Receipt numbering that survives an audit. Sequential, gapless, per academic year, and never reused. If a receipt is cancelled, it stays in the sequence with a cancellation record. A gap in a receipt sequence is a question you do not want to be answering.

Concessions as first-class records. A concession is a decision someone made, with a reason and an approver. Modelled as a discount field on a transaction, it becomes untraceable within a term.

Partial payments and instalments. Real schools take partial payments, all the time, for entirely reasonable human reasons. A fee module that assumes payment in full is a fee module the office will keep a parallel spreadsheet alongside.

Reconciliation against what the bank actually received. Cash, cheque and bank transfer are how most fees are collected. The ERP’s job is to record that accurately and make it match.

The reports a principal actually asks for. Collection by class. Outstanding by instalment. Yesterday’s collection by mode. Defaulters, with a real contact number attached.

An audit trail on every financial action. Who changed what, when, and from what to what. Financial actions are where disputes happen, and a dispute without a trail resolves into whoever argues hardest.

What a gateway adds that nobody demos

Adding online payment is not adding a button. It adds:

  • Settlement timing. Money arrives in the school’s account a day or more after the parent sees “paid”. The ledger has to model paid-but-not-settled, or reconciliation breaks every single day.
  • Failed and pending states. A payment that fails after the parent’s bank has debited them is not rare, and it is the most emotionally expensive support call a school takes. Every one of those states needs a defined behaviour.
  • Refunds. Mechanically easy, operationally messy. Who authorises it, against which receipt, and what happens to the receipt sequence?
  • Idempotency. Gateway webhooks retry. If a retry creates a second payment record, a parent’s receipt is wrong. Every webhook handler needs to recognise a duplicate.
  • Reconciliation of gateway fees. The school receives less than the parent paid. That difference has to land somewhere in the books.
  • Compliance surface. Card data, refund policy, dispute handling.

Every item is tractable. Together they are a project, not a feature, and doing that project on top of a ledger that is not yet trusted is how you end up with two sources of truth that disagree about money.

What to do instead

The data model is provisioned for a gateway: the fields exist and the capability is switched off. When it is turned on, it is a new payment mode against a ledger that already handles partial payment, cancellation, reconciliation and audit, rather than a new system bolted to the side.

And in the meantime, the system records what schools actually do: cash, cheque and bank transfer, with proper receipts and a number the office can defend.

Why this is worth saying out loud

It would be easy to leave this off the website. Every competitor lists online payment, and being the one that does not looks like a gap.

But a school runs on this software for years. The thing you want to know about a vendor is what they will tell you before you sign, because that is a fair sample of what they will tell you afterwards.

Related

Tell us what you are trying to build.

A description of the problem is enough to start. You will get a reply from one of the people who would do the work.