Rollout walkthrough
A school where fee collection is the presenting problem
How a rollout sequences when fees are the reason for the project, and what has to be true before fees can move.
What this is, and what it is not
This is a composite, not a customer story. It describes how a rollout typically goes for this kind of school, drawn from implementation experience across several. No school is named, no figures are attributed to a customer, and nothing here is presented as a measured outcome. Named case studies appear on this page only with written consent and stated measurement methods, and none are published yet.
The school described: Any size, where the immediate pain is collection: cash and cheques, manual receipts, and a debtor position nobody can state confidently.
Starting position
What brings a school like this to look for a platform
The presenting complaint and the underlying condition are usually different things, and the difference decides the sequence.
The board has asked a question nobody can answer precisely: what is outstanding, from whom, and for how long. The figures exist, in a spreadsheet maintained alongside a receipt book, and they disagree with the accounting system by an amount that gets explained rather than reconciled.
Collection itself is manual. Parents pay in person or by transfer, someone matches the transfer to a family, someone issues a receipt, and the matching is the bottleneck. Reminders go out when somebody has time, which means they go out unevenly, which means the families chased hardest are the ones who are easiest to reach rather than the ones who owe most.
The temptation is to move fees first and everything else later. That is close to right, and the part that makes it wrong is that a fee ledger attaches to a student and a payer, so the roster and the payer-of-record have to be correct before any of it means anything.
Sequence
What moves when, and why that order
Each phase states the reason it cannot sensibly come earlier or later. The reason matters more than the phase, because your school will need a different order for at least one of them.
- Before anythingStep 1
Opening balances and payer-of-record
Agree the outstanding balance per family in writing, with finance sign-off. Establish who the payer of record is for every child, including split families and families paying for siblings across year groups.
Why here: This is the most disputed data in any school migration. Establishing it after go-live means disputing it with a parent while the system asserts a figure, which is a much worse conversation than the internal one you are avoiding.
- Week one to fourStep 2
Minimum foundation
Academic year, terms, class structure, calendar, student import, guardian import with links verified. Stop there. Do not configure timetable or assessment yet.
Why here: Fees need a correct roster and correct guardian links, and nothing else from the foundation layer. Configuring more before the fee cutover adds work without reducing risk.
- Week two, parallelStep 3
Gateway onboarding
Start merchant onboarding immediately, with the gateway that settles in your billing currency. Assign it to a named person with a weekly check.
Why here: It is external, it has a lead time you do not control, and it is the item that most often decides whether the cutover happens in the term you planned.
- Week four to eightStep 4
Fee configuration and a full test cycle
Configure fee heads, instalments, discounts, and late rules. Then run a complete cycle in test: invoice, payment, receipt, reconciliation, refund. Reconcile the test against what finance expects, line by line.
Why here: The discount rules are where configuration meets policy, and policy that has never been written down surfaces here. Better to find the ambiguity in a test cycle than in an invoice run.
- The cutoverStep 5
One date, communicated
Set and announce the date the previous process stops. Issue the first live invoice run from the platform, with the office briefed and someone available for the questions.
Why here: A fee process running in parallel produces two debtor positions, and reconciling them costs more than the cutover it was meant to de-risk.
- AfterStep 6
Automate reminders, then extend
Once a full cycle has run cleanly, switch on scheduled collection and structured reminders. Then, and only then, sequence timetable, attendance, and reporting.
Why here: Automating reminders on a ledger you do not yet trust sends wrong reminders faster, at scale, to parents. Trust the ledger first.
Friction
What reliably goes wrong
Not risks in the abstract. These are the things that recur, so they can be planned for rather than discovered.
The discount rule nobody can state
Every school has one — a sibling discount interacting with a staff concession, or a hardship arrangement agreed verbally. It cannot be configured until it is written down, and writing it down is a governance conversation rather than a software task.
Receipts issued outside the system
Paper receipts continue for a while after cutover because they are faster in the moment. Each one is a reconciliation break. Count how many are issued in month one; the number tells you whether the counter workflow is actually usable.
Gateway settlement timing
Settlement is not instant, so the ledger and the bank balance differ by a predictable lag. Explain this to finance before the first month end rather than during it.
Reminders reaching the wrong parent
This is the payer-of-record problem arriving in a parent’s inbox. It is the most visible failure mode of a fee rollout and it is entirely preventable in the first stage.
Limits
What a platform does not fix for this school
Stated because the alternative is a school discovering it in term two.
- It does not collect the money. A structured reminder sequence reaches families reliably and evenly; whether they pay is a relationship question, not a software one.
- It does not replace accounting software. There is no connection to accounting packages, so the finance handoff is a file export rather than an integration.
- It does not automate reminders over SMS or WhatsApp. Sequences go out over email; other channels are sent manually by staff.
- It does not resolve a historical dispute about what a family owes. It records the figure you agreed; agreeing it is still your work.
A school where fee collection is the presenting problem: common questions
What schools in this position ask before committing to a sequence.
Can we move fees without moving anything else?+
Almost. You need the roster, guardian links, calendar, and class structure, because the ledger attaches to a student and a payer. You do not need timetable, attendance, or assessment. That is the smallest honest phase one for a fees-led project.
How long does gateway onboarding actually take?+
It varies by gateway and jurisdiction, it is the school’s own merchant account, and it is outside our control. Treat it as weeks rather than days, start it first, and give it a named owner. It is the most common reason a fee cutover slips.
Should we automate reminders straight away?+
No. Run one full cycle manually reviewed first. Automated reminders on an unverified ledger send incorrect demands to parents at scale, and the trust cost of that is much higher than a few weeks of manual review.
What if finance and the office disagree about the debtor position?+
Resolve it before migration, with a written sign-off. This disagreement predates the platform and importing it just means the platform now asserts one side of it with apparent authority.
Go deeper
Related planning material
Describe your own starting position
Tell us what your data looks like and which term you need to be live in. We will tell you what is realistic, including when the answer is not this year.
Already using Schoolyi? Sign in