Docs Menu

Docs

How To Carry Forward Fees

Move fee carry-forward balances from one academic session to another and review the resulting carry-forward logs.

Search docs

Search by workflow, module name, or operational keyword.

Documentation search is ready.

Last updated: March 22, 2026

This guide explains how to start and monitor the Fees Carry Forward workflow.

Short summary

Use Fees Carry Forward when outstanding fee obligations must move from a source academic session into a target academic session. The current UI supports session-level setup and a log-based follow-up workflow.

Best for

Finance administrators handling year-end or session-rollover balance continuity.

Requires

Source and target academic sessions, permission to carry balances forward, and a clear policy on which overdue balances should move.

Result

A carry-forward job is submitted and its result can be reviewed from the carry-forward logs.

Before you start

  • Confirm the source session truly contains the balances that should move forward.
  • Confirm the target session is the new academic destination.
  • Decide whether an overdue-days threshold should restrict what gets carried forward.
  • Prepare notes if your finance process requires an audit explanation for the rollover.

Fees Collection -> Fees Carry Forward

Step 1: Open Fees Carry Forward

In the sidebar, open Fees Collection and choose Fees Carry Forward.

Fees Carry Forward workspace showing source and target session controls plus carry-forward logs.
The current workflow combines session selection with a log table for submitted carry-forward jobs.

The current page exposes:

  • Source Session
  • Target Session
  • Overdue Days
  • Notes
  • Save
  • carry-forward logs with View and Retry

Step 2: Choose the source and target sessions

Set the two required session fields:

  1. Source Session
  2. Target Session

The source session should hold the balances being reviewed.

The target session should be the new session where the carried-forward balance needs to land.

Step 3: Add optional carry-forward constraints

Use the optional fields to narrow or explain the carry-forward run:

  • Overdue Days
  • Notes

Use Overdue Days when the policy only moves balances that have crossed a certain threshold.

Use Notes when the run needs a brief audit explanation.

Step 4: Submit the carry-forward run

After confirming the sessions:

  1. click Save
  2. wait for the submission result
  3. refresh the logs if necessary

This action starts the carry-forward job rather than instantly resolving every balance inside the same form.

Step 5: Review the carry-forward logs

Use the log table to monitor the result.

The current log area shows:

  • log ID
  • status
  • created date
  • View
  • Retry

Use View to inspect log entries when you need to understand what happened inside a specific run.

Use Retry only when the previous run did not complete cleanly and the underlying configuration is still valid.

Important notes

Current-UI note: the shipped page currently exposes session-level controls plus notes and overdue-days filtering. Even though deeper payload support exists in the implementation layer, the public guide follows the actual visible UI and does not assume hidden class or section controls.

Local dataset note: the current local environment already contains multiple carry-forward logs in processing and completed states, which makes the log-monitoring workflow directly inspectable.

Verification checklist

  • source and target sessions are correct
  • overdue-days filtering, if used, matches policy
  • notes are present when required for audit
  • the submitted run appears in the log table
  • the final log status is reviewed before assuming the carry-forward completed successfully

Troubleshooting

IssueLikely causeWhat to do
Save should not be used yetRequired sessions are missingSelect both source and target sessions first
The wrong balances may move forwardSource or target session was chosen incorrectlyRecheck both session fields before saving
A run stays in processing or failsThe carry-forward job did not complete cleanlyReview the log entry and retry only after checking the cause
Staff expect immediate row-level results in the formThe workflow is log-drivenUse the logs and entry view to validate the result

Related docs