IN THIS ARTICLE▾
Tuition, transport, activities, and trip fees can all run through one mandate at an SA school, instead of separate billing processes for each.
A parent's account at a fee-paying SA school rarely carries just one kind of charge. There's tuition, billed monthly or termly. There's transport, if the learner is bussed. There's activities, sport, culture, extramurals, some compulsory, some optional. There's the odd once-off: a textbook levy, a stationery pack, a school-photo charge, a sports-tour deposit. Each of these, at most schools, is tracked and billed a little differently.
Tuition usually runs through the school's core debit-order or invoicing process. Transport is sometimes billed by a separate transport provider, sometimes by the school on a different cycle. Activities get invoiced per term, often manually, sometimes only once a parent asks why an amount appeared on the statement. Once-off charges get added to the next statement if someone remembers to capture them, or chased separately if not.
None of these fee categories is individually complicated. What's complicated is running all of them, for every family, without four separate systems and four separate reconciliation exercises. This piece is about what changes when every fee category runs on one mandate instead.
Why fee categories end up scattered
The scattering isn't a design choice so much as a historical accident. Tuition billing came first, built around the fixed-amount debit-order mandate that's standard for recurring monthly charges. Transport, where the school runs it, often started as a separate, smaller system because it has its own logistics (routes, drivers, term-time-only billing) that didn't fit neatly into the tuition mandate. Activities billing frequently exists as a spreadsheet or a manual invoice process because activity fees vary term to term and learner to learner in a way the fixed tuition mandate wasn't built to handle. Once-off charges get bolted onto whatever process is closest at hand when the charge comes up.
Each piece, individually, made sense as a point solution. Together, they mean the finance office is running up to four parallel billing processes for a single family, each with its own cadence, its own capture step, and its own reconciliation.
What the parent sees
From a parent's side, the fragmentation shows up as multiple, disconnected touchpoints. A debit order for tuition. A separate invoice, sometimes via email, sometimes on paper, for the term's activities. A transport bill on its own schedule. An occasional ad-hoc charge that appears with little warning.
Parents querying a charge often can't get a single, clear answer quickly, because the person answering the phone may need to check three different places depending on which fee the query is about. That's not a reflection of the finance office's competence, it's a reflection of how many separate systems the query has to be checked against.
The variable-amount mandate as the unlock
The technical capability that allows every fee category to run on one system is the same one that unlocks multi-stream billing anywhere else: a variable-amount mandate, signed once, that authorises the school to debit any amount it raises, with appropriate notification to the parent, rather than a fixed amount on a fixed date.
With that kind of mandate in place, tuition, transport, activities, levies, and once-off charges can all run against the same authorisation. The amount varies fee to fee and term to term; the mandate covers all of it. There's no separate transport mandate, no separate activities invoice process, no second signature required when a new fee category is introduced mid-year.
What changes operationally
Three things shift in the finance office once fee categories consolidate onto one mandate.
Capture happens once, not four times. A new fee, a tour deposit, a textbook levy, a mid-year activity charge, gets raised against the parent's account and billed on the next cycle, rather than requiring its own separate invoicing workflow.
Recon has one source, not four. The end-of-cycle view shows what collected and what failed across every fee category on that family's account, in one place, rather than requiring the finance team to check the tuition system, the transport ledger, and the activities spreadsheet separately to understand a single family's position.
Parent queries resolve faster. Whoever takes the call can see the whole account, tuition, transport, activities, once-offs, in one view, rather than needing to check multiple systems to answer a single question.
What this means for reporting to the SGB or finance committee
A finance committee report that has to stitch together tuition collection, transport collection, and activities collection from separate sources takes longer to prepare and is harder to sanity-check. When every fee category runs on one system, the monthly or termly report to the SGB Finance Committee is a single pull, covering every revenue line the school bills to parents through the collection system.
This doesn't replace the school's core financial reporting or its accounting system, it feeds into it. What it removes is the manual stitching-together step between multiple parallel billing sources and the report the committee actually sees.
What this isn't
It isn't a claim that every fee a school charges must run through Recurv. Bar or canteen-style point-of-sale transactions, once-off cash payments at events, and other consumption-driven charges are out of scope, this is about recurring and scheduled parent-billed fees, not point-of-sale spend.
It isn't a mandate to standardise every school's fee structure. Fee categories, amounts, and billing cadence remain entirely the school's decision, set by the Bursar, Principal, and SGB Finance Committee as they always have been. What changes is the system those decisions run through, not the decisions themselves.
It also isn't a replacement for the school's transport logistics or activities-management software where those exist for scheduling and operational purposes. The consolidation is specifically about the billing and collection layer, what gets debited, when, and how it reconciles, not the operational systems that generate the underlying charges.
Related reading
See how Recurv handles recurring billing for schools & education.
View Schools & Education use case →