Flow: payment & reconciliation

The family pays one balance by mobile money; the payment reconciles itself to the invoice and updates the statement — and anything outstanding drives the aging report and reminders.

Payment & reconciliation — the rail confirms, ep.fee.payment reconciles, the portal reflects it.

The finance models

Model	Role
`ep.fee.assignment` / `.line`	What a student owes this year, line by line (incl. bridge lines).
`ep.fee.invoice`	The billable document the family pays.
`ep.fee.payment`	A received payment, matched to an invoice; reconciliation lives here.
`ep.fee.installment`	A payment plan / schedule for families paying over time.
`ep.fee.payment.audit`	Tamper-evident audit trail of every payment event.
`ep.fee.invoice.token`	A secure token so a parent can pay a specific invoice from a link.

How reconciliation works

The parent pays from their phone; the rail (mobile money) confirms the transaction.
An ep.fee.payment is created and matched to the ep.fee.invoice by reference.
If the family is on a plan, the ep.fee.installment schedule is updated.
The family gets an SMS receipt; the statement reflects the new balance immediately.
Whatever remains rolls into the 30/60/90-day aging report, which fires dunning reminders.

Edge cases

Duplicate / double payment: caught at matching; the overpayment becomes a credit on the family ledger.
Unmatched payment: held for manual allocation at the bursary rather than silently lost.
Scholarship / bursary: award rules reduce the invoice before the family pays, with an approval trail.