Overview
When a payer makes a payment before they have a charge due, the ledger will adjust to the prepayment differently, depending on:
- If the payment is made before any current or future charges exist on the ledger
- The payment goes into the Prepaid billing category
- If the payment is made early and there is a future charge on the ledger that is not yet due
- The payment is reassigned into the categories matching the upcoming charges
This article will cover those two scenarios in more detail and how the system will automatically adjust to them.
Prepayments Without Any Future Charges (Prepaid Billing Category)
When a payer does not have a current or future balance and they make a payment, the payment first goes into a Billing Category called 'Prepaid'.
You can think of prepaid as a temporary holder for the payment while the system is calculating which categories to distribute the money into. The system automatically then makes that calculation and moves the money out from the Prepaid category and into whichever categories have a future balance on the account.
For example, (as in the image below) if there is a ledger with no upcoming charges but a payment is made on that ledger, the payment will be held in the 'Prepaid' category until there is a charge applied to this ledger.
Additional Notes:
- Schools can exclude certain categories from prepayments.
- For example: If a school wants all payments made before upcoming charges to only apply to Tuition, they can do so by going to Settings > Financial > Billing Categories. Next, enable the option 'Exclude for Automatic Overpayment Logic' for every category except Tuition.
Important Note: Please do not deactivate the prepaid category on the Billing Categories page (Settings > Financial > Billing Categories). This will stop any prepayments from functioning properly.
- The prepaid billing category redistributes credits or payments to billing categories with positive charges every day.
- If a charge is added after the prepayment has been made on the same day, the redistribution will occur the very next day.
- Payments that exceed future charges, will also be applied to the prepaid category. For example:
- There is a ledger with the following outstanding charges:
- a $50 late fee charge
- and a $25 charge for tuition
- The parent currently owes a total of $75 but makes a payment of $100.
- The system distributes the payment to billing categories as follows:
- $50 is assigned to the Late Fee category
- $25 is assigned to the Tuition category
- $25 is assigned to the Prepaid category
- Next, the Admin adds an upcoming charge of $25 for a Library fee.
- The system sees the new charge and re-assigns the $25 Prepaid balance into the Library Fee billing category.
- There is a ledger with the following outstanding charges:
Prepayments with Future Charges
When a payer doesn't have a charge due right now but has charges due in the future and they make a payment early, the system will automatically redistribute the payment into the billing categories assigned to the upcoming charge.
For Example:
- In March, the parent signs their contract, and their ledger populates with the tuition charges for the year. The parent's charges do not start until June 1st.
- The parent makes an early payment of $500 even though they do not owe a payment until June.
- The system sees a future charge due in June and the $500 prepayment is automatically applied toward the balance for June and is assigned to the category or categories assigned to that charge.
Additional Notes:
- If there is more than one billing category associated with an upcoming charge, the system will distribute the payment amongst the categories based on the term they are owed in and then the order they are listed on the Billing Categories page (Settings > Financial > Billing Categories). You can read more about this, within the How Payments are Applied section of this article.
- If the prepayment is larger than the next charge due, the system will look past it and distribute the payment within the next owed balance amounts in the ledger.
Comments
0 comments
Article is closed for comments.