Unifying multi-campus collections
An enterprise education network operates across 13 cities, 22 campuses and approximately 45,000 students. Tuition and ancillary services can involve different billing schedules, installment plans, bank transfers, cards, discounts, sibling rules and e-invoicing. The opportunity was to turn those fragmented payment moments into one parent-account and collection lifecycle that could scale across campuses without multiplying manual finance work.
Parent accounts, payment-plan policy, collection actions and financial posting were connected into one operating model so a large campus network could scale digital collections without scaling manual finance effort at the same rate.
self-service payment completion
A larger share of eligible parent payments moved through guided digital flows.
manual collection contacts
Routine reminders and payment-plan actions moved into the execution layer.
payment-to-posting time
Shared obligation identities reduced manual allocation before finance posting.
aged plan exceptions
Structured exception queues helped teams focus on unresolved account cases.
Campus scale turns payment complexity into an operating problem
A large education network does not have one collection journey. Tuition, meals, transportation and other services can follow different schedules, entities and policies. A parent may manage more than one student, more than one service and more than one due date at the same time.
At 22-campus scale, the challenge is not merely accepting cards. It is keeping account state, eligibility, discounts, payment plans and finance outcomes consistent enough that parents receive a clear experience while campus and central teams share the same financial truth.
The parent account became the financial context
Instead of treating each invoice or payment link as an isolated event, the model starts from a parent-and-student account. That context can hold tuition obligations, ancillary services, installment schedules, sibling relationships, discounts, credits, prior payments and outstanding balances.
This shared context lets the system decide which amount is payable now, which plan applies, what can be paid together and which items require separate handling. The result is a clearer self-service journey and fewer cases where finance teams must reconstruct the reason behind a payment manually.
Payment-plan logic moved into controlled rules
Education collections often combine full payment, installments, early-payment conditions, sibling discounts and service-specific rules. When those decisions are distributed across spreadsheets, emails and local processes, the same family context can produce inconsistent payment instructions.
A centralized rule layer makes plan eligibility, installment cadence, allowed methods, due-date behavior and exceptions explicit. Campuses can retain approved differences, but those variations remain observable and governed rather than becoming undocumented local knowledge.
Revenue Execution prioritized the next parent action
A payment calendar alone does not tell a finance team what to do next. Revenue Execution converts due dates, balances, previous behavior and exception status into actions: send a reminder, present a payment link, create a review task, surface an alternative method or pause automation while an enrollment or service issue is being resolved.
Each action can be tied to an observed outcome. This allows the organization to measure which interventions reduce overdue balances or support parent completion rather than simply counting messages and calls.
Cards and bank transfers converged on one obligation model
Parents may pay by card, installment card flow or bank transfer. Those rails behave differently, but they should close the same underlying obligation. A payment reference therefore needs to survive from the parent account through execution and into financial posting.
For bank transfers, stable student, account and obligation references reduce dependence on free-text descriptions alone. For card payments, the same identities allow successful transactions to be allocated directly to the intended fee or schedule instead of being reconstructed after settlement.
Cash application and e-invoicing were connected
A payment is operationally complete only when the organization can explain which obligation it settled and how that state was reflected in the school and finance systems. Financial Operations connects payment evidence to the expected account allocation and prepares structured posting toward ERP or school systems.
The same lifecycle can trigger or support the correct e-invoice context once the payable event is confirmed. Exceptions such as partial transfers, overpayments, duplicated payments, plan changes or cancellations can be separated from routine matches and routed to the appropriate team.
Central finance moved from broad follow-up to exception work
When routine reminders, standard payment-plan decisions, self-service collection and cash matching are handled consistently, central finance no longer needs to touch every account. Teams can work from exception queues containing cases that actually require judgment.
Campus staff also gain a clearer boundary: they can help the family relationship without becoming the system of record for payment status. That reduces context switching between campus operations, central finance, service providers and bank evidence.
One collection model scaled across campuses and services
The connected model joins registration context, parent accounts, fees and payment plans, Revenue Execution, card and bank rails, Financial Operations and school finance systems in one lifecycle. Each layer has a defined responsibility while the parent sees one coherent financial journey.
The practical result is scale without proportional administrative overhead: digital completion can increase, overdue work can be prioritized, payment-to-posting latency can fall and finance teams can focus on genuine exceptions rather than routine account reconstruction.
Education
Parent accounts, payment-plan policy, collection actions and financial posting were connected into one operating model so a large campus network could scale digital collections without scaling manual finance effort at the same rate.