Generate Financial Statements

Financial Statement shows posted financial transactions within a selected period. It supports institution-level review for the campuses assigned to the Finance user, as well as student, campus, academic, and transaction filters.

The statement uses the student-account ledger perspective: charges increase the student balance as debits, while payments and other reductions decrease it as credits.

Review and export the statement

1. Choose the date range

   Select a required Date From and Date To range in DD-MM-YYYY format. The statement includes transactions posted within that period.

2. Apply optional filters

   Use Campus, Department, Programme, Class, Student, and Transaction Type filters when needed. A blank or All Records selection means that parameter is not restricted.

3. Apply the filters

   Select Apply Filters. The page displays the summary cards, transaction count, and transaction history for the selected scope.

4. Review the summary

   Review Opening Balance, Total Debits, Total Credits, and Closing Balance before exporting. The summary is calculated for the selected scope and date range.

5. Review transaction history

   Each row shows the date, student, campus, transaction type, reference, description, debit, credit, and running balance. Tax lines appear as separate rows beneath their related charge.

6. Request an export

   Select Download PDF or Download XLSX. The buttons become unavailable while that user already has an export being prepared.

7. Retrieve a completed export

   Open Queued Reports to see queued, processing, completed, and failed exports. Select Download when a completed file is available.

What the transaction types mean

• Charges: amounts added to a student account, such as tuition, admission, sports, accommodation, meal-plan, transfer, late, or individual charges.
• Payments: amounts received from a student and verified or posted by Finance.
• Amount Increases: adjustment entries that increase the amount owed.
• Amount Reductions: adjustment entries that reduce the amount owed without representing a payment.
• Waivers: approved reductions granted by Finance.
• Payment Reversals: entries that negate an incorrectly posted payment and restore the affected balance.
• Refunds: amounts returned or recorded as returned to a student; these reduce the institution-side received amount and are shown as debit-side account movements.
• All Records: includes every transaction type available to the Finance user.

Debit and credit formula

Running Balance = Opening Balance + Debits - Credits.

In this student-account statement, a debit normally increases the amount owed by the student. A credit normally reduces the amount owed. Therefore, a fee charge is a debit to the student account, while a verified payment is a credit to the student account.

This is why the statement colors debit and credit columns differently. The labels describe the ledger movement from the account perspective, not a claim that every debit is money physically leaving the institution or every credit is money physically entering it.

How taxes appear

Taxes are stored with the charge as a snapshot of the tax name, rate, taxable amount, tax amount, behavior, and exemption status at the time the charge is created. Later changes to a tax type do not recalculate historical charges.

In the statement, the base charge and each tax are separate debit rows. For example: Semester Fee, GST on Semester Fee (17%), Sports Charges, and GST on Sports Charges (17%). This keeps the ledger total and running balance transparent.

Export queue and retention

Exports are placed in a database-backed queue so large reports do not run inside the browser request. A background worker processes the queue and updates the report progress and status.

Completed files remain available for one hour after creation. After expiry, the file is deleted, the report is marked expired, and no Download button is shown. A new export must be requested if the file is needed again.

If an export fails, the Queued Reports entry displays the failure message and its support reference. Share that reference with support when reporting the problem.

PDF and XLSX behavior

• PDF: generated as an A4 portrait document with the institution logo and branding, summary at the top, repeated transaction-table headers on each page, tax rows, running balances, and a system-generated notice.
• XLSX: generated from the same filtered ledger data and includes the statement summary and transaction details.
• The statement uses the institution and campus scope of the Finance user. A Finance user cannot export records outside their assigned campus scope.

Production operation

The worker is intended to run continuously through the systemd service ocr-financial-statement-worker.service. The service starts the worker with the --continuous option and is configured to start automatically after a server restart.

The shared report storage directory is /home/otherdomains/private/ocr-for-education/reports. It is outside the public web root and is used by both the development and production deployments when they share the same server account.

The production worker user must have read and write access to that directory. Worker status can be checked with systemctl status ocr-financial-statement-worker.service, and worker output can be reviewed with journalctl -u ocr-financial-statement-worker.service.

Production database requirements

Before production use, the database schema must include financial_statement_report_jobs and its queue fields, including status, progress, file path, expiry, lock, and download timestamps.

The tax workflow requires tax_types, tax_type_versions, tax_applications, tax_exemptions, and tax_lines. The student_fee_charges table also requires the base amount, taxable amount, tax amount, and tax snapshot fields.

Apply schema changes after backing up production. These changes are additive and do not replace existing student charges, payments, balances, or historical tax snapshots.

Recommended next step

After reviewing the report, use Student Accounts and Payment Verifications to investigate individual transactions, payment evidence, receipts, adjustments, waivers, reversals, and refunds.