For bursars and student finance teams
The student account, on the student record.
Whether your office is called the bursar, student accounts or student finance, the job is the same: charge correctly, collect fairly, and answer for every balance. On Salesforce as the SIS, student financials run natively on the same record as registration — so the account always agrees with the enrollment it bills.
Native student financials
The account, function by function.
In our deployments these run natively — configured on the platform, tied to the record they bill.
- Fee assessment
- Charges assessed from actual enrollment — per term, per program, per credit, or per whatever your model is.
- Accounts receivable
- Balances, aging and statements on the student record itself.
- Payments and refunds
- Processed against the same account the student sees.
- 1098-T
- Generated through Cashnet or Regent — the one student-finance function that runs through a third party, and we say so.
Payment that fits the student
Plans that follow the student, not the term.
Rolling starts, self-paced programs, continuing education, one course sold four ways — the operating models growing fastest are the ones a term-based billing engine handles worst. When payment plans and schedules are configuration, the account fits the student’s actual arrangement: not hard-wired to a term, a model, or a single payer.
One record
Billing that agrees with the registrar.
The account bills the enrollment the registrar recorded, reflects the aid the aid office awarded, and shows the student one coherent picture of all three. The reconciliation your office runs between systems today is not automated here — it is unnecessary.
Start here
Bring your hardest billing model.
The cohort that pays monthly, the employer who pays per course, the program with no terms at all. A demo built around your accounts beats one built around ours.