Student accounts and statements

A student financial summary is an aggregate snapshot for one student, tenant, academic year and currency. It combines invoiced, paid, adjusted, scholarship, refunded, outstanding and ageing information. It supports receivables work, but it does not replace source invoices, payments, credit applications or the General Ledger.

Audience: bursars, credit controllers, accountants, school administrators, auditors, and support analysts
Learning time: 40–50 minutes
Primary route: /finance/student-summaries

Learning outcomes

You will be able to:

• read summary totals and ageing buckets;
• choose correct year, school and currency filters;
• distinguish source records from aggregate snapshots;
• recalculate one or many summaries safely;
• interpret credit, balanced, overdue and arrears classifications;
• export evidence without treating an export as the source ledger.

Prerequisites

Requirement	Verification
Correct student/school	identity matches
Academic year	selected or intentionally latest
Currency	all compared amounts share currency
Source transactions	invoices/payments/credits exist in expected scope
Access	list/read/statistics/recalculate/export abilities
Recalculation rationale	stale or corrected source evidence
Statement policy	date, recipients and confidentiality approved

Roles and exact permissions

• student_financial_summary:list
• student_financial_summary:read
• student_financial_summary:statistics
• student_financial_summary:recalculate
• student_financial_summary:bulk_recalculate
• student_financial_summary:export
• financial_invoice:list
• financial_invoice:read
• financial_payment:list
• financial_payment:read
• financial_credit_note:list
• financial_credit_note:read
• scholarship_award:list
• scholarship_award:read

Aggregate model

Total	Meaning
total_invoiced	invoices included in the aggregation window
total_paid	qualifying applied payments; failed/draft excluded
total_adjusted	controlled adjustments included by workflow
scholarship total	eligible awards in same year/tenant/currency
total_refunded	processed refunds
balance_due	resulting outstanding amount
recalculated_at	last aggregation refresh time

Balance classification

Ageing buckets

Bucket	Verified range
current	≤ 0 days overdue
30	1–30 days overdue
60	31–60 days overdue
90	61–90 days overdue
120+	> 90 days overdue

Always document the as-of date used operationally. Ageing changes with time even when no new transaction occurs.

Guided procedure

1. Select school and open Student Summaries.
2. Apply academic year and currency filters before comparing balances.
3. Search the student and open detail.
4. Record total invoiced, paid, adjusted, scholarship, refunded, outstanding, ageing, last invoice/payment and recalculation time.
5. Trace significant amounts to source invoices, payments and credits.
6. When a source correction occurred after recalculated_at, use authorised recalculation.
7. For bulk recalculation, choose explicit students or school, document year/options, remain under request limits, and review partial failures.
8. Use statistics for portfolio totals only after filter scope is recorded.
9. Export CSV/XLSX/JSON when authorised. Record job ID, status, filters, requester, format and completion/failure evidence.
10. Generate/send any guardian statement only under communication and privacy policy; the summary API’s last_statement_date is a marker, not proof of delivery by itself.

Recalculation controls

Single recalculation accepts student, optional year, currency and options. Bulk accepts 1–500 explicit students or a school and enforces a 2,000-summary hard limit after deduplication. Recalculation refreshes aggregates; it should not be used to conceal unresolved source discrepancies.

Worked scenario

Mupfure Learning Academy’s Form 3 learner has USD 1,000 invoiced, USD 600 paid and a USD 100 approved credit. The expected balance is USD 300. The summary still shows USD 400 because the credit was applied after the prior recalculation. The bursar verifies the invoice/credit response, recalculates the exact student/year/currency, and confirms USD 300 appears in the current bucket. No journal or payment is created by recalculation.

Statement boundaries

A statement should identify student, school, academic year, currency, as-of date, transactions/balance explanation, and contact details. Country-specific statutory statement requirements are not universal. Exports and PDFs are evidence packages; source transactions remain authoritative.

Controls and audit evidence

Retain filters, summary ID, recalculated timestamp, source IDs checked, recalculation request/response, bulk failures, export job ID/status/payload reference, requester and privacy approval.

Failure modes

Symptom	Likely cause	Evidence	Safe action	Escalate when
Balance differs from invoice list	wrong year/currency or stale summary	filters and recalculated_at	correct scope/recalculate	same scope remains inconsistent
Credit balance unexpected	overpayment or adjustment	source payments/credits	trace source	no supporting transaction exists
Ageing differs tomorrow	as-of date moved	due dates and current date	state as-of date	bucket calculation violates ranges
Bulk recalculation partial	missing/mismatched summaries	failure array	resolve listed students	unexplained widespread failures
Export remains pending/running	async job delay	job timestamps/status	poll same job	exceeds export SLA
Statement sent to wrong party	privacy/contact error	recipient evidence	stop distribution, incident process	confidential disclosure occurred

Verification checklist

• School, student, year and currency are explicit.
• Summary freshness is recorded.
• Material balances trace to source records.
• Recalculation was used for a documented reason.
• Ageing uses the documented as-of date.
• Bulk failures were reviewed.
• Export filters and job ID are retained.
• Statement privacy/recipient controls were followed.
• Aggregate/export is not treated as the General Ledger.
• Discrepancies remain visible until resolved.

Practice and knowledge check

Guided practice

Use a non-production test school and the Mupfure Learning Academy scenario. Record the selected school, academic year, term, currency, fee, operator, reviewer, and timestamps. Capture the before-state, action evidence, after-state, and any exception IDs. Do not mark the exercise complete from a success toast alone.

Knowledge check

1. What record proves the student obligation?
2. Which status dimension answers whether the invoice is authorised?
3. Which status dimension answers how much remains unpaid?
4. What evidence proves the selected student population was correct?
5. Which action requires a separate reviewer in your school policy?
6. What should be inspected before retrying a failed or partial operation?
7. Which later phase owns payment collection and receipt procedures?

Answer rubric: a complete answer names the exact Makronexus record, status, permission or evidence source. Role names alone are insufficient.

Next lesson

Continue to Ageing and collections worklists.