Unapplied payments and account credits

#Understand the numbers first

An unapplied payment is not a separate kind of money. It is the unused part of an existing local payment record.

The account can show both a positive Balance and positive Credit at the same time. For example, a family can have $100 in unpaid charges and a $40 unapplied payment. The current charge balance remains $100 until the $40 payment is allocated.

Important: The word Credit is calculated differently in a few current screens. The account header and report use an aggregate net amount. The charge-level allocation dialog builds a pool from individual positive payment remainders. Local refund or void offsets can make those two results disagree. Use the safe reconciliation procedure in this article before applying anything.

#Where credit appears

The report is a work queue, not a complete credit register. It intentionally omits an account that has credit but no unpaid charges, an account that owes money but has no credit, and some child-owned records that are outside the parent-account query.

#Before you begin

• Open the family account that owns the payment whenever possible. A child ledger can display a family payment already allocated to that child's charge, but available-credit actions use the exact account owner in the current implementation.
• Reload the full account page so the header, charges, payments, and credit breakdown come from the same point in time.
• Remove or record season, category, unpaid-only, and search filters that could hide related rows.
• Identify the original payment by date, amount, type, receipt or transaction reference, source, and notes.
• For a card or ACH payment, confirm the processor status and settlement independently without copying full credentials.
• Look for a related negative offset, refund wording, void wording, deletion wording, or refund relationship before treating a positive payment remainder as spendable.
• Record the current charge Paid and Balance, payment Applied Amount, account Credit, and relevant report values.
• Confirm the studio's policy and approval for allocation changes, write-offs, refunds, and corrections.
• Make the change in one browser tab, with one operator, and select the final action once.

Warning: Applying or returning credit changes ledger allocations immediately. The current allocation records do not provide a user-visible reason, actor, timestamp, or undo history. Preserve the before state outside the allocation dialog when the change requires an audit trail.

Warning: None of the allocation actions in this article charges a card, debits a bank account, settles money, or sends a refund. They change local payment-to-charge links only.

#Find accounts with both credit and unpaid charges

1. Open Reports > Unapplied Payments.
2. Wait for the report to load.
3. Review the summary count, total Credit, and total Unpaid amount.
4. Find the family by name or ID.
5. Compare Unapplied Credit with Unpaid Charges. The smaller of the two is the most that could be used without another payment or charge change.
6. Select the family name to open its Ledger.
7. Reload the account page before changing an allocation.

The current report has no date, season, location, payment-type, or source filter and no export action. A row can combine old and new records. Investigate the component payments and charges rather than assuming that the report total belongs to the current season.

#Why a family appears

The report calculates, for each parent family account:

• total local payments;
• total amounts assigned from those payments;
• total family-owned charges; and
• total amounts assigned to those charges.

It includes the family only when both of these results are positive:

unapplied credit = total payments - total payment allocations
unpaid charges   = total charges - total charge allocations

Negative local payment offsets reduce total payments. Negative charges reduce total charges. Neither becomes an independently selectable credit source.

#Reconcile one account before applying credit

1. Open Families or Students, select the account, then select Ledger.

2. In Account Totals, record Total Charged, Total Paid, Balance, and Credit.

3. Select the information control beside Credit to review the payment rows behind the available amount.

4. In Payments, find each source payment and compare Paid with Applied Amount.

5. In Charges, find the intended charge and compare Charged, Paid, and Balance.

6. Expand the ledger to all relevant seasons and categories. Search for matching notes, receipt references, or transaction references.

7. Look for negative payment rows and for refund, void, rejected, or deleted wording on the original payment.

8. For electronic money, compare the local rows with the processor's final amount and status.

9. Calculate the expected remainder for each usable payment:

   payment remainder = positive payment amount - allocations from that payment
   

10. Confirm that the account header, report, payment rows, and intended charge tell one consistent story before continuing.

Important: The account header's Total Paid and Balance are driven by charge allocations in the current ledger summary. An unapplied payment is shown separately as Credit and does not reduce a charge balance until it is assigned.

#Family and student ownership

Use the family ledger for a family-owned payment. The ledger can show a family payment on a child's record after that payment has been linked to the child's charge, but the available-credit pool for a new assignment is built from payments owned by the account currently open. Recording a new payment on a child account can therefore split the family's financial history.

If the report names the family but the child ledger does not show the expected credit, return to the parent family account. Do not recreate the payment on the child.

#Assign credit from the account header

Use Assign Credit when the full aggregate account credit is valid and you are comfortable with automatic oldest-first allocation.

1. Open the correct family account and reload the page.
2. Confirm the active season in Account Totals.
3. Select the positive amount beside Credit.
4. In Assign Credit, review Credit Available.
5. Review the unpaid charges shown for the selected season.
6. Select only the charges approved to receive credit.
7. Select Assign once.
8. Reload the full account page.
9. Confirm each charge's Paid and Balance, each payment's Applied Amount, and the header Credit.
10. Reopen Reports > Unapplied Payments in a fresh page and confirm the family changed or left the report as expected.

The current bulk action consumes the oldest available payment first, by payment date and then payment ID. It processes selected charges by oldest charge date and then charge ID. The order in which you select the checkboxes does not set the allocation order.

Important: Assign Credit lists up to 100 unpaid charges in the current request and does not show a payment-by-payment preview. For a large account, a cross-season exception, or a payment that must be matched to a particular charge, use the charge-level procedure instead.

Warning: If any source payment has been refunded, voided, deleted with an offset, or disputed, stop. The aggregate header can account for a negative offset while a lower-level allocation path can still treat the original positive payment as available. Have an authorized finance reviewer reconcile the records before assigning credit.

#Apply credit to one charge

Use the charge-level dialog when you need to see the proposed source payments or enter a custom amount.

1. Find the intended row under Ledger > Charges.
2. Confirm the charge's student, date, season, category, class, notes, Charged, Paid, and Balance.
3. Select Apply Credit to Charge in the row's Action column.
4. Review Available Account Credit, Suggested Amount, and Balance After.
5. Review each proposed payment's date, payment season, type, source, receipt reference, available amount, and amount to apply.
6. Investigate any warning that a suggested payment appears to belong to another season.
7. To control the sources or amounts, select Customize.
8. Enter an amount greater than zero for each approved source payment. The current save path caps an entry at that payment's available remainder and the charge's remaining balance.
9. Select Apply Credit once.
10. Reload the full account page and confirm both sides of the link.

Suggested allocations use the oldest positive payment remainder first. A payment date's matching season is used only to display a warning; it does not prevent a cross-season allocation. Category, class, tax, and charge session also do not restrict which payment can be selected.

Note: An allocation applies to the charge's stored total, including any tax already included in that charge. The allocation itself does not split principal and tax.

#Add more credit to a partially paid charge

When a charge already has any applied amount, the row action changes to Return Charge to Credit. The current dialog does not add one more payment while preserving the existing links.

To rebuild the allocation:

1. Record every applied payment shown in Return Applied Credit, including date, season, type, source, receipt, and amount.
2. Confirm that removing all of those links is approved.
3. Select Return to Credit once.
4. Reload the full account page.
5. Reopen the charge's Apply Credit to Charge dialog.
6. Select Customize and reconstruct the complete approved allocation, including any amount that should remain from the original assignment.
7. Apply once and reconcile every source payment and the charge.

Warning: Return to Credit removes all payment allocations from that charge. It does not return money, create a refund, restore a payment method, or preserve the old allocation as an auditable version. Reapplying the suggested allocation can choose different source payments because suggestions are recalculated oldest-first.

#Record an intentionally unapplied payment

Create a new unapplied payment only when value was actually received or an approved local opening balance must be represented. Do not create one merely to make a charge look paid.

1. Open the family account's Ledger.
2. Confirm that the same payment is not already present.
3. Select New Payment.
4. Enter Amount.
5. Select Payment Type and enter the approved receipt or check reference.
6. Confirm Payment Date and Location.
7. To keep the full amount as credit, leave every item under Apply to Charges unselected.
8. To apply part of the payment now, select the intended charges and confirm the displayed Unapplied remainder.
9. Enter non-sensitive Notes that explain the evidence and reason.
10. Select Save once.
11. Reload the full account page and reconcile the new payment, allocations, Credit, and charge balances.

Selecting a charge can change the form amount to the sum of selected balances. Review Amount again after changing the charge selection. The save path caps each allocation at the remaining payment and charge balance; any unused amount remains unapplied.

Warning: New Payment is a local ledger action. Selecting a card-related payment type does not charge a card. Confirm cash, check, bank, or processor evidence before saving the payment.

#Automatic credit application and future charges

Several screens refer to automatic credit, but they do not all use the same path. Treat every automatic option as a request that must be verified in the ledger.

#New Charge

The account ledger's New Charge form shows Apply Credit Automatically. In the reviewed build, the visible form and the current charge-save request do not use the same checked value, so the control is not reliable evidence that an allocation occurred.

For a finance-critical charge, use the explicit charge-level allocation after saving and verifying the charge. Never assume that the checkbox changed Paid or Balance.

#Tuition, late charges, and miscellaneous charges

The current bulk charge runs can store an AUTO_APPLY_CREDIT flag on created charge rows when that column exists. The inspected run services do not themselves create payment-to-charge allocations from that flag.

After any run that requested automatic credit:

1. review the charge session and account ledgers;
2. compare Paid and Balance on sample charges;
3. open Reports > Unapplied Payments; and
4. apply credit explicitly only after confirming that another job or workflow did not already do so.

#Staff Shopping Cart checkout

When the studio-wide automatic-credit setting is enabled and a staff checkout records a positive transaction amount, the current post-checkout path can sweep available account credit across unpaid charges. That sweep processes the oldest unpaid charges first and is not limited to the new order.

Reconcile the order's charges, the checkout payment, older account charges, and remaining credit. A checkout can be locally complete while the displayed credit was assigned to an older balance instead of the newest charge.

#Online Client checkout

The Online Client has a Use Account Credit presentation path, but the normal reviewed credit-discovery calculation does not currently surface ordinary unapplied payment remainders. The option may therefore be missing even when the account header shows credit.

Treat Online Client credit use as needing controlled acceptance testing for the studio before promising it to clients. If a checkout does use the deferred credit path, verify the resulting order and all account charges because the post-payment allocation can sweep the available pool oldest-first rather than limiting it to the amount displayed for that order.

#Negative charges, refunds, voids, and delete offsets

These records can change totals without creating usable credit in the same way.

#Negative charges

A negative charge reduces total charged in screens and reports that sum charge amounts. It is not a payment and does not enter the available-payment pool. It cannot be selected as a source in Apply Credit.

Use a negative charge only under an approved accounting policy. Confirm how the studio's income, tax, charge-session, and outstanding-balance reports treat it. Do not call it account credit unless the relevant screen actually shows a positive Credit amount.

#Local payment offsets

Refund, Void, and Delete (with offset) create a negative local payment row and link or annotate the original payment. They do not call the processor. The original payment's allocations are not automatically rebuilt by the offset action.

This can produce a valid audit pair while leaving a charge marked paid. It can also make the header's aggregate credit disagree with the per-charge allocation pool.

Warning: Do not use Return to Credit on a refunded or voided payment merely to make the charge look unpaid. The current per-charge pool can ignore the negative offset when deciding whether the original positive payment is available, allowing refunded value to be reassigned. Stop and obtain an approved reconciliation plan.

#Editing or deleting a charge or payment

• Reducing a charge amount does not automatically resize its existing allocations.
• Deleting a charge removes its allocation links in the current account-ledger path, which can make the source payment unapplied again.
• Editing a payment amount does not rebuild its allocations or move processor funds.
• A negative or over-sized correction can make report, header, and per-row calculations diverge.

After any edit or deletion, run the complete reconciliation below. Never add a second payment or an unexplained opposite charge to hide the mismatch.

#Safe reconciliation checklist

Use this checklist after applying, returning, creating, editing, refunding, voiding, or deleting a related record.

1. Reload the full account page, not only one table.
2. Confirm the original payment amount, source, type, date, receipt or transaction reference, and notes.
3. Sum that payment's Applied Amount and independently verify its remaining unapplied amount.
4. Confirm every affected charge's Charged, Paid, and Balance.
5. Confirm Account Totals > Credit and use its information control to review the component payment rows.
6. Compare the account's unpaid charges with its aggregate credit; remember that Balance is not automatically net of unapplied credit.
7. Refresh Reports > Unapplied Payments and record whether the family remains.
8. Check Finance > Payment History for the original payment and every negative offset.
9. For card or ACH activity, confirm the processor shows exactly the intended collection, refund, void, or unchanged transaction.
10. Check the relevant deposit, bank, accounting export, tuition session, checkout order, or charge session using the same date basis.
11. Record who approved the allocation, which payment and charge were involved, the before and after amounts, and why the change was made.

There is no exact allocation rollback button. Returning credit deletes the links, and reapplying can choose different oldest-first sources. A local negative offset also has no automatic reversal. If the result is wrong, preserve it and have an authorized finance reviewer approve the next auditable correction.

#Avoid stale or duplicate results

• Use one browser tab and one operator for an account while reallocating credit.
• Reload before previewing and immediately after saving.
• Do not double-select Assign, Apply Credit, Return to Credit, or Save.
• If a request times out, search the refreshed ledger before trying again.
• Do not leave an allocation dialog open while another staff member edits the payment or charge.

The per-charge operation uses a database transaction, but the current allocation paths do not lock payment or charge rows, and the legacy allocation table does not enforce one unique payment-and-charge pair. Simultaneous submissions can therefore produce stale previews or duplicate/over-sized links. Stop and escalate if Paid exceeds the intended payment or charge amount.

#Troubleshooting

#The report is empty but an account shows Credit

The report requires both positive credit and positive unpaid charges on a parent family account. It omits credit-only accounts and can omit child-owned records. Open the family ledger and reconcile the payment directly.

#The report shows credit, but the charge dialog shows none

Confirm that you opened the family that owns the payment, not only a child. Reload the full page and review negative offsets. The report and charge dialog do not use an identical per-payment formula.

#The header shows no credit, but the charge dialog offers a payment

Do not apply it. Look for a refund, void, delete offset, negative payment, or recently edited allocation. The lower-level pool can treat the original positive row as available even after an aggregate offset reduced the header credit.

#Credit went to a different selected charge

Bulk and automatic assignment process selected charges oldest-first. Checkbox order does not control priority. Return and rebuild the allocation only after preserving the current links and obtaining approval.

#A partially paid charge cannot accept more credit

Its action becomes Return Charge to Credit. The current interface requires removing all allocations from that charge and rebuilding the complete desired allocation. There is no add-only control for a partially paid charge.

#Credit or balance did not update after the action

Reload the full account page. Table refreshes do not consistently refresh every account-header total. Then compare the component payment and charge rows rather than trusting a stale summary.

#A deleted or reduced charge created unexpected credit

Deleting a charge removes its allocation links; reducing an amount can leave allocations larger than the new charge balance. Find the original payment, reconstruct the before state, and apply only the approved amount to a valid charge.

#Online Client does not offer Use Account Credit

The reviewed build does not reliably derive ordinary unapplied payment credit for the normal checkout display. Do not create another payment to force the option. Use an authorized staff allocation or escalate for tenant-level feature verification.

#A processor refund and the local ledger disagree

Stop all further allocation changes. Preserve the processor reference and the original/offset rows. Follow Payment history and corrections; do not issue another processor refund or local offset until the required net result is approved.

#Applied amounts appear duplicated or exceed a balance

Do not attempt repeated returns and reapplies. Capture the account, payment, charge, amounts, timestamps, and operator activity, then escalate. Concurrent or repeated allocation requests do not have a complete user-facing idempotency guarantee.

#Privacy and recording rules

• Use fictional family and student names in every screenshot or video.
• Use an address in the approved non-deliverable documentation domain if an email is necessary.
• Never show full card or bank details, processor credentials, saved tokens, routing numbers, account numbers, login data, or real transaction references.
• Mask receipt and transaction references to a short synthetic suffix.
• Crop unrelated accounts, browser tabs, notifications, and URL parameters.
• Use a disposable demo payment and charges; never submit a processor transaction for a documentation capture.
• For an offset example, create only an approved synthetic local record and preserve the before/after fixture IDs internally.

#Related articles

• Manage class charges and pricing overrides
• Account ledger
• Add a charge or record a payment
• Payment history and corrections
• Run tuition safely
• Shopping Cart checkout
• Online Client checkout
• Finance overview
• Reports overview