Transactions Overview
Last updated: August 28, 2026
Transactions represent all financial activity recorded in the system, including charges, refunds, prorations, and manual adjustments. Each transaction is linked to a student profile and is typically associated with a residency, meal plan, or flex plan.
Every transaction in the system is powered by a charge code. Charge codes define the structure and intent of the transaction and serve as the foundation for all billing activity and reporting.
Charge Codes
Charge codes define the financial item or service being applied through a transaction. They include a label, description, and unit cost, and are connected to housing, dining, or miscellaneous charges and refunds.
Charge codes are managed in the Admin Portal. Admins can create new codes or update existing ones to reflect institutional billing practices. Every transaction, regardless of type, must be associated with a charge code. These codes also determine the description shown in the student’s transaction table.
Transactions: Charges
Charges are transactions that apply a cost to a student’s account. They are commonly created automatically when a student is assigned to a space, selects a meal plan, or completes an application that triggers a fee. Admins may also create charges manually to apply one-off or custom fees.
Charges can represent full-term housing or dining costs, cancellation fees, damages, or other service-based costs.
Identifying a Charge
Charges appear as net positive amounts. They are displayed in black text on the transaction table.
Transactions: Refunds
Refunds are transactions that return funds to a student’s account. They are typically generated in response to cancellations, removals, or changes to a student’s assignment or plan.
Admins can issue refunds manually by selecting the original transaction and choosing “Refund.” Some cancellation workflows, such as canceling a residency or meal plan, will automatically generate full refunds for the original transaction.
This ensures a clear 1:1 relationship between a charge and its corresponding refund. Admins must then decide if a new, reduced charge should be created based on policy.
Identifying a Refund
Refunds appear as negative amounts with a red minus sign. They are displayed in red text on the transaction table.
Prorated Transactions
Prorated transactions apply charges or refunds based on the actual usage dates of a student’s assignment or meal plan. The system calculates a daily rate using the total cost defined by the charge code and the applicable date range.
Proration is useful when a student cancels early or arrives late. Instead of issuing the full charge or refund, the system applies an adjusted amount.
Housing charges are prorated based on the start and end date of the student’s residency. Meal plans use the assigned meal plan dates. These dates default to the housing cycle configuration but can be overridden.
Locate Transaction History
All transactions for a student are listed in their profile under the Transactions tab. This table includes the transaction date, description, amount, and any linked assignment or plan. Use the color and sign indicators to quickly distinguish:
Black positive values = Charges
Red negative values = Refunds
Fees
Fees refer to specific transactions associated with third-party payment processors. These are commonly used for application fees, security deposits, or residential life engagement fees. Unlike other transaction types, fees are not automatically enabled in all production environments.
Fees must be explicitly configured and linked to your institution’s integrated payment processor. Admins should coordinate with their implementation or support team to ensure these fees are configured correctly before use. Once enabled, fees appear in the same Transactions tab and follow the same charge/refund visibility conventions as other transactions.
Reach out to your Housing.Cloud representative for more information.