A transaction is one row on a student's ledger. Every transaction moves through a predictable lifecycle, and the system records each stage as a timeline event. Refunds and prorations do not erase the original charge; they post new offsetting transactions that preserve a full audit trail.
Transactions carry an externalId that links them to your SIS, and cycle-level integration dates control when they export. Admin transaction actions are performed at Admin › Finance › Transactions and on the transaction detail page at Admin › Finance › Transactions › [id].
Transaction lifecycle events
The system records each stage as a timeline event. The event types you will see are:
Transaction created — a new transaction was recorded on the resident ledger
Transaction refunded — the transaction was refunded in full
Transaction prorated — a prorated portion of the transaction was refunded
Transaction deleted — the transaction was deleted from the resident ledger
Fee refund issued — a fee refund was issued
Transaction lineage
Refunds and prorations do not erase the original charge. Instead, the system posts a new offsetting transaction that points back to its source via originalTransactionId. This preserves a full audit trail: you can always trace a refund line back to the charge it reversed.
Coattail and child transactions use parentTransactionId to link to the primary transaction they were created from.
Refund vs. proration
A full refund reverses the entire original amount. This is the default refund path. The original transaction is marked isRefunded = true, and a new refund row with a negative amount is posted.
A prorated refund reverses only a portion and is used at move-out or cancellation. The system calculates the prorated amount based on the actual days occupied and records the prorated range as billingStartDate and billingEndDate. The original transaction is marked both isRefunded = true and hasBeenProrated = true. A proration fraction of 1 is treated identically to a full refund, so the code short-circuits to the full-amount path.
Non-refundable charge codes cannot be refunded. The system returns SKIPPED_NON_REFUNDABLE when a refund is attempted against a charge with isRefundable = false. A regular refund also rejects zero-amount attempts with the error: "Refund amount must be greater than zero."
Admin transaction actions
At Admin › Finance › Transactions you can:
Filter the list with Filters and Clear Filters
Export as CSV or Excel
Bulk Mark as No Transfer — skips rows that already have an externalId and disables rows with "Export in progress" or "Transactions have already been transferred"
On a transaction detail page you can:
Refund — issue a full refund
Prorate — issue a partial refund based on days occupied
Link to cycle — associate the transaction with a housing cycle
Mark as No Transfer — prevent the transaction from exporting to your SIS
How transactions flow to your SIS
Transactions carry an externalId that links them to the corresponding record in your SIS. Cycle-level integration dates control when the export occurs:
transactionsDateEffective — the date when housing charges are considered due in your billing system
transactionsDateEgress — the cutoff date that controls when charges begin exporting to your SIS
transactionDateInvoice — the invoice date applied on export (Ethos integration only)
Setting these dates correctly prevents charges from posting in the wrong billing period. For example, if you finalize assignments in May but set the egress start to July, no housing charges export before July even though the assignments exist.
Export logic selects transactions with externalId = null and isTestSimulation = false. Rows whose charge code is marked with a no-transfer external ID are collected into a noTransferList and written back with ETHOS_NO_TRANSFER_ID so they are permanently excluded from future export runs.
On export, the system uses the refundCode from the charge code if the transaction is a refund and has an originalTransactionId; otherwise it uses the normal code. CSV export rows include isRefund and isProration flags.
Preventing a transaction from exporting
A transaction can be flagged so it is not transferred to your SIS. The system uses an external ID value of NO_TRANSFER to mark this behavior. When a refund or prorated transaction is created, the system checks the original transaction's external ID and inherits the no-transfer status into the new transaction's refund or prorated external ID so that the offsetting entry also stays out of the SIS export.
Marking a transaction as No Transfer shows a confirmation that the transaction "will not be sent to an external system."
Where to verify results
After a transaction is created, refunded, or prorated, the timeline events appear on the student's ledger. You can also verify SIS export status by reviewing the transaction's external ID and comparing the cycle's integration dates against the current date.
Related articles
Charge Code Overview explains how charge codes define the billing template for every transaction.
Refund vs. Credit vs. Ad-hoc Transaction explains when to use each type of money-moving action on a student ledger.