Fees and Payment Reconciliation System
A private school of several hundred students collecting termly fees, mostly by bank transfer to one or two accounts, with some cash and POS at the bursary. Matching payments to students consumes the bursar's first two weeks of every term.
The problem
Parents transfer from personal accounts with no reference, pay for two children in one transaction, and pay amounts that match no invoice. The money arrives; identifying whose it is, is manual.
In scope
- Fee structures
- Invoicing
- Payment recording
- Bank statement import and matching
- Part payments and plans
- Receipts
- Debtors and ageing
- Sibling and family billing
- Concession rules
Out of scope
- Attendance
- Results
- Admissions
- Parent portal beyond a fee balance view
- Timetabling
- Also out, and worth stating plainly: a live banking API. Most institutions here will not expose one, so this is statement import, and any vendor promising live bank integration should be asked to name the bank.
What this would cover
Grouped by module — open the ones you want to read.
Fee structure
- Components by level and term (tuition, development levy, books, uniform, examination), effective dates, versioned so a mid-year change does not rewrite issued invoices
Concessions
- Sibling discount, scholarship, staff-child, as named rules applied automatically rather than as manual adjustments a bursar has to remember
Invoicing
- Per student per term, itemised, issued ahead of the term, regenerable if the structure changes before issue
Family billing
- Siblings grouped, one balance, one statement, because parents think in families and schools bill in students
Payment recording
- Cash, POS, card, transfer, with the transfer reference captured as typed
Statement import
- Upload the bank statement, automatic matching on exact reference, then on amount against outstanding invoices, then on sender name against guardian names; everything unmatched drops into a holding queue
Holding queue
- Unidentified payments held as money received but unallocated, never discarded, cleared manually with a search across students and families
Part payment and plans
- Agreed instalments with dates, arrears flagged against the plan rather than the invoice
Receipts
- Issued automatically on allocation, delivered by message
Debtors
- Outstanding by class, family and ageing band; list for the head before a term begins
Data model
- FeeStructure → FeeComponent
- Student → Family
- Invoice → InvoiceLine
- Payment → Allocation
- PaymentPlan → Instalment
- Concession
- BankImport → ImportLine
Invariants
- A payment is recorded before it is allocated, and an unallocated payment is never deleted — the money exists whether or not the system can identify it.
- Allocation is a separate record from payment, so one payment can settle several invoices across siblings.
- A closed term's invoices and allocations are immutable.
- Import lines are retained with their source file, so a disputed match can be traced.
Offline behavior
Not required. Bursary work happens at a desk with connectivity. Cash receipting should degrade to a queued local record rather than blocking, since a parent standing at the counter cannot be asked to wait for the network.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Transfer matching cannot be fully automated, and selling it as though it can is how this project fails.
A parent transferring from a personal account with no reference is not identifiable by any algorithm. What the system does is narrow the work — exact-reference matches clear themselves, amount and name matching produce ranked suggestions, and the bursar is left with a short queue instead of a full statement. The honest claim is that it turns a fortnight into an afternoon. It does not eliminate the task, and a school expecting elimination will be disappointed by a system that is working correctly.
End state
What would be true about their day once this is running.
- A parent's payment is matched, allocated and receipted without the bursar reading a statement line by line.
- Money that cannot be identified sits visibly in a queue rather than being lost or guessed at.
- Siblings bill as one family.
- The head has a debtors list by class before the term starts rather than after it ends.
This is a deliberate first step toward School Operations & Parent Portal Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review