Refund vs. Credit vs. Ad-hoc Transaction

Refund, credit, and ad-hoc transaction are three different actions that move money on a student's ledger, and they target different parts of the system. A refund reverses an existing charge; a credit reduces what a student owes on a scheduled plan; an ad-hoc transaction creates a standalone charge or credit with no existing transaction or plan involved.

Refund — reverses an existing charge

A refund targets a transaction that has already been posted. The system marks the original transaction as refunded and posts an offsetting credit linked back via originalTransactionId. This preserves the audit trail: the original charge remains visible, and the refund line points directly to it.

Non-refundable charge codes cannot be refunded. The system returns SKIPPED_NON_REFUNDABLE when a refund is attempted against a charge with isRefundable = false. Use a refund when a real charge needs to be undone.

In the payments UI, the Issue refund action is only available when isFeeRefundEnabled is true. It is disabled with "No amount to refund." or "Only successful or refund-failed payments can be refunded." Eligibility is limited to payments with an amount and status SUCCESS or REFUND_FAILED.

Credit — a new adjustment on a scheduled billing assignment

A credit does not reverse anything. It posts a new Credit (Refund/Payment) transaction on a ScheduledPlanAssignment and reduces what the student owes. It draws down the remainingBalance and adjusts upcoming occurrences on that one student's assignment, not the whole schedule.

The admin detail page for a scheduled assignment shows Credit available, Applied to schedule, and Remaining credit. The balance projection computes projectedBalance = remainingBalance - creditAmount. The UI shows Current balance and subtracts the Credit from it.

Use a credit for waivers or service-interruption compensation that applies to a specific student's payment plan.

Ad-hoc transaction — a brand-new charge or credit

An ad-hoc transaction is a standalone charge or credit created when there is no existing transaction to reverse and no scheduled assignment involved. Every ad-hoc transaction still references a charge code, which supplies its accounting code and default amount. Use this when you need to enter a one-off amount yourself.

Ad-hoc transactions are created through the Create Transaction modal (or Edit Transaction for existing items). The modal steps are:

• Type & recipients — select the transaction type and recipients; a billing cycle is required and at least one recipient is required

• Charge & amounts — select a charge code; split modes are same, even, and custom; a custom split shows "Allocations sum to ... but the target total is ... — adjust to continue." if the totals do not match

• Date & description — set an effective date and a description; the effective date cannot be in the past and defaults to today if left blank; the description is visible to recipients on their statement

• Review & post — review the summary; refunds resolve to Applied as → Credits; non-refunds resolve to Posted against → the selected charge code

Validation messages you may see:

• "Charge code is required"

• "Effective date cannot be in the past"

• "Transaction amount is invalid. Please enter a valid dollar value."

The transaction types available in the modal are:

• Debit (Charge) — a standard charge

• Credit (Refund/Payment) — a credit or refund

Quick guide

Related articles

Charge Code Overview explains how charge codes define the billing template for every transaction, including the isRefundable flag that controls whether a charge can be refunded at all.

How Transactions Flow explains the lifecycle events and lineage model, including how refunds and prorations are recorded as new offsetting transactions.