Balance Classification
Card account can be either in Credit balance or in Debit balance. Balance classification allows the balances to be classified according to certain attributes that the amounts should have. The balance in each balance class is further divided into different Buckets.
These balances in the Balance Classes as well as in the Buckets are held as Book Dated Balances as well as Value Dated Balances at all times.
Balance Classes and Balance update
User can define different balance classes and can map different Transaction codes (TCs) to each balance class. Balances that arise from transactions posted with these transaction codes get accumulated in the respective balance class.
Since balance classes are maintained by the users for each Product, the user can name these balance classes appropriately according to the balance that they hold, for e.g., 'Interest' to hold all interest balances in the account or 'Purchases' to hold all POS transaction balances.
One balance class is always defaulted to hold balances on the credit side and one on the debit side. These default balance classes can also be named by the user to suit different business needs. The default balance class will hold amounts of all transactions arising out of transaction codes that are not mapped to other balance classes. (For more information related to maintenance of balance class please refer to the Card Account Product_Balance Classification User Manual)
Below are some examples of maintenance of balance classes and the update of the balances when transactions are posted. All amounts in the examples are in EUR.
Balance updates Example (Debit)
- Data set up at the 'Balance Classification' tab
Debit
| Balance Class Description | Mapped Transaction Code | Transaction code for interest liquidation | Transaction code for balance movement |
|---|---|---|---|
| Cash | 700 | 752 | 852 |
| Purchase | 701 | 753 | 853 |
| Default | None; but, will take in transactions in all other transaction codes that are not mapped to other balance classes | Transaction code mapped for the Product as ‘Interest received within limit (DB / Client)’ | Transaction code mapped for the Product as ‘Movement of debit balances (DB / Client)’ |
- User has posted the following debit transactions into the account:
| Transaction Code | Amount (DB) |
|---|---|
| 700 | 800 |
| 701 | 112.5 |
| 103 | 150 |
- Following are the balance class updates for the above transactions assuming the opening balance in the account is 0.00
| Balance Class Description | Balance (DB) |
|---|---|
| Cash | 800 |
| Purchase | 112.5 |
| Default | 150 |
Balance updates Example (Credit)
- Data set up at the 'Balance Classification' tab
Credit
| Balance Class Description | Mapped Transaction Code | Transaction code for interest liquidation | Transaction code for balance movement |
|---|---|---|---|
| Payment | 750 | 754 | 854 |
| Default | None; but, will take in transactions in all other transaction codes that are not mapped to other balance classes | Transaction code mapped for the Product as ‘Interest paid (CR / Client)’ | Transaction code mapped for the Product as ‘Movement of credit balances (CR / Client)’ |
- User has posted the following credit transaction into the account:
| Transaction Code | Amount (CR) |
|---|---|
| 750 | 120 |
- Following are the balance class updates for the above transactions assuming the opening balance in the account is 0:
| Balance Class Description | Balance (CR) |
|---|---|
| Payments | 120 |
The impact of the debit balance class movement when the payment transaction comes in (assuming that the account is in debit balance) and vice-versa, please refer to the Additional topics_Replenishment User manual
Buckets
Every balance class on the debit side holds balances internally in different 'buckets'. Following are the buckets that Aura holds these balances in:
Current: This consists of the current cycle's balances
Past: This consists of the immediately preceding cycle's balances. The Current bucket balance moves into the Past bucket during Close-of-Business process on End of Cycle date.
Rolled over: This consists of the balances of all the cycles beyond the previous cycle. The Past bucket balance moves into the Rolled Over bucket during Close-of-Business process on Payment Due Date. This amount is arrived at after overdue balances are moved into the overdue bucket as described below.
Overdue: This consists of the overdue balances -- i.e. when the payment received is less than the Amount required, subject to Thresholds. The Past Bucket balance moves into the Overdue bucket, to the extent of the overdue amount, during Close-of-Business process on Payment Due Date.
Note:
Movement into Overdue bucket happens only if the Product has the Treat Overdue Balance flag marked as Yes. In case the flag is set to No, the balance from the Past bucket moves into the Rolled Over bucket, even though it may be overdue.
On End-of-Grace-Days, if there are any residual balances for Overdue and Rolled over (i.e., where there is an overdue or Rolled over amount, but, this is less than the threshold specified for the same), these will be moved into Rolled Over and Past Bucket.
The traversing of amounts between different buckets is explained below under various scenarios.
Note:
End of Cycle (EOC) Date = End of Month
Payment Due Date (PDD) = 10 days after EOC
Grace Days = 5 days
End of Grace Days (EOGD) = 5 days after PDD
Total Outstanding Amount on 31-Jan- is 750.00
Amount Required = 20% of Total Outstanding = 20% of 750.00 = 150.00
Full Payment
Account is opened. Transaction is posted. Invoice is generated. Payment is made for full outstanding balance of 750.00 and thus there is no balance for roll-over or overdue.
Partial payment > Amount required
Account is opened. Transaction is posted. Invoice is generated. Partial payment of 250.00 is made, which is greater than 'Amount required'. Since Payment is less than total outstanding, the balance amount will roll-over. Payment is greater than the 'Amount required' as per Invoice and hence, account will not be Overdue
Partial payment = Amount required
Account is opened. Transaction is posted. Invoice is generated. Partial payment of 150.00 is made, which is equal to 'Amount required'. Since Payment is less than total outstanding, the balance amount will roll-over. Payment is equal to 'Amount required' as per Invoice; so account has not gone into Overdue.
Partial payment < Amount required
Account is opened. Transaction is posted. Invoice is generated. Partial payment of 50.00 is made, which is less than 'Amount required'. Since Payment is less than total outstanding, the balance amount will roll-over. Payment is less than the 'Amount required' as per Invoice and hence, account becomes Overdue
Note: in this case, if Treat Overdue as Balance is marked as Yes in the Product, the Overdue bucket will show the overdue amount i.e., 100.00 as the balance and rolled over will be 600.00. If the flag is No, Rolled Over will be 700.00. The overdue amount is internally tracked as 100.00
No Payment
Account is opened. Transaction is posted. Invoice is generated but payment is not made. The entire outstanding balance will roll-over. Payment is less than the 'Amount required' as per Invoice and hence, account becomes Overdue.
Note: In this case, if Treat Overdue as Balance is marked as Yes in the Product, the Overdue bucket will show the overdue amount i.e., 150.00 as the balance and Rolled Over will be 600.00. If the flag is No, Rolled Over will be 750.00. The overdue amount is internally tracked as 150.00
