Fees priced from the academic record, not from a spreadsheet.
Criteria-based plans that read the programme, the study mode and the credits registered, then bill, collect and settle on one ledger. One balance the student, the dean and the auditor are all looking at.
The problem
The academic record decides the charge. Billing is told about it afterwards.
A fee follows from facts the institution already holds: the programme joined, the mode studied, the credits registered, the aid awarded, the day a course was dropped. Yet the fee structure lives in a spreadsheet per programme, the invoice is raised in a package that has never heard of a credit hour, and the waiver was approved in an email.
Three things go wrong every term. Pricing is maintained by hand, so two students on the same plan get different amounts. Reductions are granted outside the system, so nobody can say who approved what. And the ledger is reconciled after the fact, so the student portal and the finance report disagree about the same balance.
The operating model
Price by rule, bill from records, keep the trail.
Four design choices turn billing from a monthly reconciliation into an operating layer: plans are governed rules, the charge is computed from the academic record, every reduction is an approved exception, and the ledger is the single balance everyone reads.
A plan is a rule, not a price list
Fee components, categories, eligibility criteria, credit ranges, tax and currency live as governed, versioned objects. The rule engine matches a student on their own attributes, so pricing is consistent across programmes, campuses and intakes by construction.
The charge is computed from the record
Registered credits, study mode and enrolment status drive the amount. A course added in week two and a course dropped in week four both change the invoice, because billing reads the same record registration writes to.
Every reduction is an approved exception
Scholarships, discounts, waivers and refunds carry caps, criteria and an approval chain. Where a threshold is crossed, the request escalates. Nothing is granted quietly, and every grant names its approver.
One ledger, one balance
Invoices, debit and credit notes, receipts, wallet credits, aid and penalties post to the same account the student sees in the portal, and a sponsor billed as a third party settles against that same ledger, so the finance report, the dean's dashboard and the audit trail are views of one number rather than three exports.
What it does
Five things a finance office needs. One ledger.
Fee structure and plans, invoicing and instalments, aid and waivers, payments and penalties, and the reporting a board and an auditor ask for. Pick one to see what sits inside it.
Click any block to explore
One rule that prices every student the same way.
- Fee components with code, currency and tax treatment
- Fee categories grouping tuition, lab, hostel, services and exams
- Criteria-based payment plans on programme, batch, mode, nationality, category and campus
- Fixed, credit-based and programme-specific plan types
- Credit ranges, thresholds and per-credit pricing
- Enrolment caps per plan and multi-currency per campus, USD, MYR, AED and more
- Billing parties for sponsors, employers and government schemes
- Versioned plans with effective dates and simulation before publish
Itemised at generation, never edited in place.
- Billing schedules for automated invoice generation
- Itemised invoices from fee components, with tax inclusive or exclusive
- Draft, finalised, sent and paid lifecycle with versions instead of edits
- Debit notes for additional charges raised after an invoice is issued
- Bulk invoicing across cohorts, programmes and campuses
- Instalment schedules: count, interval, upfront amount and percentage split
- System-calculated due dates, balance splits and over or under payment handling
- Instalment compliance tracked in real time
Nothing granted quietly, everything capped.
- Scholarship plans with eligibility rules and academic conditions such as minimum GPA
- Award duration, disbursement schedule by semester and renewal criteria
- Merit, referral, programme-specific and administrative discounts
- Flat or percentage reductions with caps per student and per plan
- Auto-apply on criteria or route through multi-level approval
- Threshold escalation for large waivers
- Full trail of who assigned and who approved each reduction
Collect, reverse and charge late fees by rule.
- Online, wallet and advance payments with gateway integration
- Student wallet with top-up, applied and unapplied credit balances
- Receipting straight to the ledger, with partial and scheduled payments
- Time-based drop charges by date of withdrawal
- Refunds to student wallet, bank transfer or original source, with approval routing
- Credit notes where a reversal rather than a payout is correct
- Late fees with grace period, frequency, maximum invoice limit and stop-penalty count
- Reminders before and after a penalty, and reversal with an audit trail
Every figure opens onto the ledger lines behind it.
- Collection by programme, campus, cohort and plan
- Ageing buckets with instalment compliance and default trends
- Discount effectiveness and waiver analytics
- Refund turnaround time and penalty recovery
- Student account statement across invoices, payments, notes and refunds
- Revenue recognition and billing-party settlement reporting
- Dashboard, PDF and Excel output for compliance and board review
- Read-only auditor access with an immutable trail on every adjustment
Inside the product
The whole billing cycle, in one place.
This is the application, not a diagram. Move through the surfaces your finance office works in: the payment plan, the invoice run, instalments, aid and waivers, payments and penalties, the collection report, and the student account every one of them posts to.
| Instalment | Due | Amount and rule | Status |
|---|---|---|---|
| Upfront | 01 Aug | 25% of payable after aidplan v3.2 | Paid |
| 1 of 3 | 15 Aug | USD 2,250gateway, receipted | Paid |
| 2 of 3 | 15 Sep | USD 2,250grace 7 days | Due |
| 3 of 3 | 15 Oct | USD 2,250reminder scheduled | Open |
| Reference | Term | Fees category | Amount | Status |
|---|---|---|---|---|
| INV658 | Fall 2025/26 | Tuition fees, admissioncreated 09 Jul · no penalty | USD 1,080 | Due |
| INV656 | Fall 2025/26 | Application feecreated 09 Jul · receipted | USD 500 | Paid |
Lifecycle or product
The lifecycle is the operating model. This is the product that runs it.
Two pages, two jobs. Read the lifecycle to understand how money connects to enrolment, registration, records and clearance; read this page to see the application your finance office opens on Monday.
One of the institutional lifecycles: the governed model for fee plans, invoicing, aid, collection, refunds and settlement.
The application that runs billing: plans, invoices, instalments, aid, payments, penalties and reporting.
How does money connect to enrolment, registration, records and clearance?
What do finance officers, fee admins and finance managers actually see and do in each screen?
The full finance model, including holds, clearance, board reporting and audit.
Plan to settlement: pricing, invoicing, instalments, aid, collection, refunds, penalties and reporting.
You are designing the operating model or comparing architectures.
See the lifecycle →
You are replacing fee spreadsheets or a billing bolt-on.
See inside the product →
Displacement
A billing bolt-on raises an invoice. It does not know what a credit hour is.
General accounting packages and campus billing add-ons start from an upload. Someone exports a student list, prices it in a second place, then keys the result back. The invoice is only as right as the last export, a dropped course never reaches it, and proving how an amount was reached means rebuilding the chain by hand.
Maintained by hand, per programme.
A rule matched on student attributes, versioned.
Never reaches the invoice.
Repricing and a credit note, by the drop rule.
A reconstruction project every close.
A view of live ledger lines, generated on request.
Good at accounting. Disconnected from enrolment, registration and the record that decides the charge.
Also part of the operating system
Student Finance & Billing is also part of Student Financials.
Connect it and enrolment, registration, aid and holds run on the same records, so a balance is a calculation rather than a monthly reconciliation.
Built for every role
One ledger. Five views of the same balance.
Sees the schedule, the balance and every receipt, and pays online without queueing to ask what is owed.
Posts payments and updates ledgers on records that already know the plan, not on a spreadsheet.
Configures plans, discounts and caps once, so pricing is consistent by construction.
Refunds and large waivers arrive with the rule and the history attached, ready to approve.
Read-only access to every charge, reduction and approval, with the trail intact.
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.
Creatrix Campus has helped us centralise all student information in one reliable and intuitive system, improving efficiency and reducing errors.
Go deeper
From the Creatrix library.
Blogs, whitepapers and case studies for the people who own the money: bursars, finance officers, fee admins and auditors.
Frequently asked
Plain answers about student finance and billing.
How does a student get the right fee plan?
By rule. A plan carries eligibility criteria 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 currency set per campus.
Does it bill by credit hour?
Yes. A credit-based plan prices registered credit hours against configured credit ranges and thresholds, so a student who registers fourteen credits is billed for fourteen credits.
Because registration and the plan sit on the same record, adding or dropping a course adjusts the charge without a finance re-entry.
How do instalments and upfront payments work?
An instalment schedule defines the number of instalments, the interval, an optional upfront amount and the percentage split. 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 approved?
Every reduction is a rule with an owner. Discounts are flat or percentage, capped per student or per plan, auto-applied on criteria or routed through a multi-level approval workflow, with larger waivers escalated.
Scholarship plans carry eligibility, academic conditions such as a minimum GPA, duration, a disbursement schedule and renewal criteria, and the full assignment and approval trail stays on the record.
What happens on a course drop or withdrawal?
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 and are paid to the student wallet, a bank transfer or the original source. Where a reversal rather than a payout is correct, a credit note is generated instead.
How are late fees 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 runs through an approved workflow with an audit trail.
Can we run it standalone?
Yes. It runs on its own against a student list imported from your existing student system, and it connects into the Academic Operating System when you are ready, so plans, invoices, aid and holds run on the same records as enrolment, registration and student records.
SEE IT ON YOUR OWN FEES
Bring one programme and one fee structure. We will price it live.
A tailored proof session uses your fee components, your plan criteria and your refund and penalty rules, not a canned demo. Leave with a named, dated next step.