Student Financials
A fee is an academic event. Most institutions bill it like a separate business.
The charge depends on the programme, the study mode, the credits registered, the scholarship awarded and the date a course was dropped. All of that lives in the academic record, yet the fee structure usually lives in a spreadsheet, the invoice in an accounting package and the waiver in an approval email. The Student Financials lifecycle runs fee components, criteria-based plans, invoicing, instalments, aid, payments, refunds, penalties and reporting on one governed model, so every ledger line traces to the rule and the person that created it.
The problem
The academic record decides the charge. Finance is told about it afterwards.
Nothing about a student fee is arbitrary. It follows from the programme they joined, the mode they study in, the credits they registered, the aid they were awarded and the day they dropped a course. Every one of those facts already exists in the institution. Yet the fee structure is maintained in a spreadsheet, the invoice is raised in an accounting package that does not know what a credit hour is, the waiver was approved in an email thread, and the ledger is reconciled by hand at the end of the month. The result is not fraud. It is a set of numbers that disagree, and a finance office spending its time proving which one is right.
HOW STUDENT FINANCE WORKS
How to think about student finance.
Here is one student, one semester, run two ways. Nothing about the academics changes: the same programme, the same fourteen credits, the same scholarship, the same dropped course in week four. What changes is whether the plan, the invoice, the aid and the penalty land in three systems or on one model, and whether the balance on the last day of the month is a calculation or a negotiation.
Every step happens on time, in the right tool. None of them share a rule, so the closing balance depends on who last touched the spreadsheet.
The same fees, priced by a rule that reads the academic record, so a dropped course, an awarded scholarship and a missed due date all reach the ledger without a finance re-entry.
Run student finance as a lifecycle on one model, and the institution can answer what a bursar and an auditor actually ask: what was charged, under which rule, who approved the reduction, when was it received, and will the same balance still be there next month.
The lifecycle
One finance model, from fee plan to settlement.
Four phases. Nine stages. One shared model, so a click on any stage shows what it feeds downstream.
Capabilities in this lifecycle
Four products. One finance model.
Each is a real product with its own page. Each was built to run as part of one lifecycle, not as a standalone tool you would later try to reconcile.
Fee components and categories, criteria-based plans for fixed, credit-based and programme-specific structures, billing parties for sponsors and employers, billing schedules, itemised invoices and debit notes with tax and currency rules, and a draft to paid lifecycle with versions instead of edits.
Instalment schedules with upfront amounts and configurable splits, online payments and a student wallet with applied and unapplied credits, sponsor settlement, receipting straight to the ledger, reminders before penalties and compliance tracked in real time.
Scholarship plans with eligibility rules, GPA conditions, duration, disbursement schedules and renewal criteria, plus discounts and waivers that are capped, criteria-applied or approved through a workflow with a full trail.
Time-based drop charges, refunds to wallet, bank or original source, credit notes, configurable late fees with grace periods and stop-penalty limits, a full student statement, and collection, ageing, revenue and audit reporting from live records.
Intelligence in this lifecycle
Intelligence that's earned, not promised.
Data before models. Governance before automation. Assistance before autonomy.
A balance a model produced but nobody can explain is a dispute waiting to happen. Pricing here is deterministic: same plan, same credits, same rules, same amount, every time. AI predicts which accounts will slip, flags invoices and reductions that look wrong, and drafts a recovery approach. A person approves every reduction, every refund and every reversal. The structure is the lifecycle itself; the model rides on top.
Plan v3.2 · credit-based
Payment risk, before the due date
Payment history, instalment behaviour, aid dependency and prior-term patterns are used to rank which accounts are likely to slip, so the finance office contacts thirty students in week two rather than three hundred in week ten.
Anomalies on invoices and reductions
A charge that does not match the plan, a discount above its cap, duplicate invoices for one registration, a refund larger than the amount received: each is surfaced with the rule it breaks and the person who raised it.
Reconciliation checks before the close
Gateway settlements that do not match receipts, registrations with no invoice, aid awarded but not disbursed and penalties applied past the stop limit are all caught while the period is still open.
Recovery approaches that worked before
Where an account is overdue, the suggestion draws on what actually recovered money from a comparable cohort last time: an earlier reminder, a restructured instalment, a short deferral. Finance decides; the action is tracked to closure.
Built for every role
One lifecycle. Six views of the same ledger.
My fees, my schedule, my receipts, and I can pay online without queueing to ask what I owe.
Post payments and update ledgers on records that already know the plan, not on a spreadsheet.
Plans, discounts and waivers are rules I configure once, so pricing is consistent by construction.
Refunds and large waivers reach me with the rule and the history attached, ready to approve.
Collection and outstanding balances for my department only, on the same numbers finance uses.
Read-only access to every charge, reduction and approval, with the trail intact.
How it fits the Operating System
Finance sits downstream of enrolment and upstream of clearance.
Enrolment creates the account and triggers the plan. Registration decides what is billable. Finance prices, bills, collects and settles, then hands holds and clearance to the student record and its numbers to the board. None of it is an import.
What finance teams say about running student money on Creatrix.
Creatrix makes it simple for us to follow up on our students: who paid, who didn’t, and how much is owed for every student. It has become the best way to keep critical student information updated on time.
What I like best is its user-friendly and intuitive design. It makes managing tasks, attendance and academics seamless and efficient.
Go deeper
From the Creatrix library.
Blogs, whitepapers and case studies for the people who carry the money: bursars, finance officers, fee admins and auditors.
Frequently asked
Plain answers about student finance.
What is the Student Financials lifecycle?
It governs money owed by and to students: fee components and categories, criteria-based payment plans, billing schedules and invoicing, instalments, scholarships and discounts, payments and receipts, refunds and credit notes, late-fee penalties and finance reporting.
In Creatrix Campus this is one of eight institutional lifecycles in the Academic Operating System, driven by academic events rather than by a second round of finance data entry.
How are students matched to a payment plan?
By criteria, not by hand. A plan carries eligibility rules built on student attributes: programme, batch, study mode, nationality, category, campus and region. The rule engine assigns the matching plan at enrolment.
Plans support fixed fees, credit-based calculation and programme-specific structures, with enrolment caps per plan and campus-specific logic such as multi-currency pricing.
Does it support credit-based billing?
Yes. A credit-based plan prices registered credit hours against credit ranges and thresholds, so a student who registers fourteen credits is billed for fourteen credits.
Because registration and the fee plan sit on the same model, adding or dropping a course adjusts the charge without a finance re-entry.
How do instalments work?
An instalment schedule defines the number of instalments, the interval, an optional upfront amount and the percentage split across instalments. Due dates, balance splits and adjustments for over or under payment are calculated by the system.
Students see the schedule and pay from the portal, and instalment compliance is tracked in real time rather than assembled at month end.
How are discounts, waivers and scholarships controlled?
Every reduction is a rule with an owner. Discounts can be flat or percentage, capped per student or per plan, auto-applied on criteria or approved through a multi-level workflow, and larger waivers can be routed for additional sign-off.
Scholarship plans carry eligibility rules, academic conditions, duration, a disbursement schedule and renewal criteria, and the trail of who assigned and who approved each reduction stays on the record.
What happens when a student drops a course or withdraws?
Drop charges apply your time-based refund rule, so the refundable percentage depends on the date of the drop rather than on a negotiation.
Refunds route through the configured approval chain, are paid to the student wallet, a bank transfer or the original source, and appear in the refund dashboard with reason, status and payout timeline. Where a reversal rather than a payout is correct, a credit note is generated instead.
How are late fees applied?
Late fees are configured against payment terms: penalty amount or percentage, grace period, frequency in days, weeks or months, a maximum invoice limit and a stop-penalty count so charging ends after a set number of penalties.
The scheduler applies them on invoice ageing, students are alerted before and after, and reversal is available through an approved workflow with a full audit trail.
Who can see and do what?
Access is profile-based and scoped by attribute. A student sees and pays only their own fees. A finance officer posts payments and updates ledgers. A fee admin manages plans and waivers. A finance manager approves refunds.
A dean sees their department only, an auditor has read-only access to logs and compliance reports, and gateway, currency and global permission configuration is limited to the system administrator.
How does this connect to the other lifecycles?
Enrolment creates the account, so a plan is matched at matriculation. Registration drives credit-based charges, and drops drive credit notes and refunds.
Financial holds and clearance flow to Student Success & Records, so a block stops a registration or a transcript at the right moment, and finance reporting feeds institutional dashboards and audit.
GET STARTED
Make the balance one number, on one model.
Tell us how fees are priced, billed and reconciled today, and where the ledger stops agreeing with the student portal.