Charges

The Charge Property Class differs from other Currency Specific classes in that it includes the Currency attribute. This defaults to the currency of the record and specifies the currency in which the charge is defined and applied.

Specifying the currency in a separate attribute allows for the following capabilities:

• Charging in a currency different from that of the arrangement (that is, with charges defined in a currency which is different than the record’s currency) For example the product charges may be defined in USD, for arrangements in all currencies, but a different set of charge tariffs may be defined for contracts in different currencies but also in USD. So a GBP contract may attract a charge of 10 USD and a EUR contract may attract a charge of 20 USD.
• Default Currency charging – In this (optional currency) case a currency need not be specified in the ID of the record and the user has to set the currency attribute explicitly. Any arrangement which is in a currency for which a currency specific record has not been defined uses this default record and calculates or applies the charge in the currency specified in the currency attribute.
• The calculated charge should be converted to the arrangement currency at the prevailing mid-rate (stored on the CURRENCY table) when applied.

Charge Type can be further classified as follows:

Fixed Amount Charge

To define a fixed charge amount, user needs to set the value in the Charge Type attribute to FIXED and enter the amount of the charge in Amount. Fixed Amount attribute becomes mandatory when the value is designated as FIXED.

Calculated Charge

For a Calculated charge amount, user needs to set the value in the Charge Type attribute to CALCULATED and define the calculation in the following attributes:

Calculation Threshold

• User can specify that a charge can only be calculated if an amount threshold is surpassed. The threshold amount is of the same base type (that is, Activity Amount, Balance, Activity Count) as the base type for which the charge is being calculated and is defined in Calc Threshold
• Rounding Rule attribute - Allows the user to define the rounding rule for the calculated charge amount. The rule can be, round the charge amount either upwards or downwards or natural. Has to be a valid record in EB.ROUNDING.RULE.

Free Amount

• An amount which is deducted from the total calculated charge subject to any minimum and maximum which may be specified is defined in Free Amount.
• Handoff Charge attribute – Possible values are
  • YES - system hands over the charge amount to settlement account
  • NO or NULL continues the existing flow.

The Tier Groups attribute allows for either a single charge calculation (select NONE) or for the definition of multiple tiers of charge calculations (select BAND or LEVEL)

• Level - a product can be defined which can calculate a charge differently depending on the amount level. A single charge calculation can be selected and applied based upon the amount.
  • An example using the following tiers:

  Tier Level	Charge (in percentage)
  10,000	1
  20,000	0.75
  Above 20,000	0.50

  • A base value of 5,000 attracts a charge of 1 percentage of 5,000 = 50.00
  • A base value of 15,000 attracts a charge of .75 percentage of 15,000 = 112.50
  • A base value of 25,000 attracts a charge of .5 percentage of 25,000 = 125.00

• Band - It results in a blended charge calculation. This is similar to Level tiers, but allows for the charge calculation of each tier to be applied to the portion of the amount that falls within the tier.
  • An example using same tiers as above:

• A base value of 15,000 attracts a charge of 1 percentage of 10,000 = 100.00
• A base value of 5,000 attracts a charge of 1 percentage of 5,000 = 50.00
• Plus .75 percentage of 5,000 = 37.5 
• Total of = 137.5
• A base value of 25,000 attracts a charge of 1percentage of 10,000 = 100.00
  • Plus .75 percentage of 10,000 = 75.00
  • Plus .5 percentage of 5,000 = 25.00
  • Total of = 225.00
• Tier Groups (Bands and Levels) – it is possible to define complex tiers which are mixed groups of Bands and Levels.
• Any number of tier groups is possible. User can define these groups by using a combination of Tier Group and Calc Tier Type. Each Tier Group is treated as a high level tier, if the Tier Group is level, only the detail in Calc Tier Type from the tier group in which the base value falls can be used in the calculation. If the Tier Group is band, the detail from all tier groups that cover the base value is used in the calculation..
• The value of the tiers defined in Tier Amount within each tier group should increase, only the final tier in the final tier group should specify the remainder calculation detail.

Example

Tier Group 1

Tier Type	Tier Level	Charge (in percentage)
LEVEL	10,000	1
LEVEL	20,000	.75

Tier Group 2

Tier Type	Tier Level	Charge ( in percentage)
BAND	30,000	.25
BAND	40,000	.20
BAND	Above 40,000	.15

When the Tier Group structure is LEVEL:

• A base value of 15,000 results in a charge of .75 percentage of 15,000 = 112.50
• A base value of 25,000 results in a charge of .25 percentage of 25,000 = 62.50
• A base value of 50,000 results in a charge of .25 percentage of 30,000 = 75.00
  • Plus .20 percentage of 10,000 = 20.00
  • Plus .15 percentage of 10,000 = 15.00
  • Total = 110.00

When the Tier Group structure is BAND:

• A base value of 15,000 results in a charge of .75 percentage of 15,000 = 112.50
• A base value of 25,000 results in a charge of .75 percentage of 20,000 = 150.00
  • Plus .25 percentage of 5,000 = 12.50
  • Total = 162.50
• A base value of 50,000 results in a charge of .75 percentage of 20,000 = 150.00
  • Plus .25 percentage of 10,000 = 25.00
  • Plus .20 percentage of 10,000 = 20.00
  • Plus .15 percentage of 10,000 = 15.00
  • Total = 210.00

Temenos Transact supports the following three calculation types defined in Calc Type for each tier defined.

• Flat Charge – the user specifies an amount that is charged for the tier. This type of charge is only applicable for ‘Level’ tiers.
• Percentage Charge – a percentage of the base value can be calculated.
• Unit Charge – the base value is multiplied by the number of units.

The charge amount entered is expressed either as a flat amount, a percentage, or an amount per unit.

Related attributes are:

• Default Values (Calculation)>Tier Type>Calc Type
• Default Values (Calculation)>Tier Type>Charge>Rate
• Default Values (Calculation)>Tier Type>Charge>Amount

Charge minimums and maximums can be specified in two ways:

• Tier Level – the user can specify a minimum and/or maximum charge amount for each tier defined. These rates are defined in Tier Min Charge and Tier Max Charge.
• Overall – the user can specify overall minimum and/or maximum charges through the user of two Periodic Attributes. EB.ROUNDING.RULE to override the currency specified method.

Related Attributes are:

• Default Values (Calculation)>Tier Type>Tier>Min Charge
• Default Values (Calculation)>Tier Type>Tier>Max Charge

• Tier Amount attribute : allows the user to define the threshold amount for each tier. If more than one tier is defined then values in this attribute have to be in ascending order. This attribute is mandatory except for the last tier.
• Tier Count attribute: When charges are to be calculated based on activity count, this attribute acts as threshold for the number of times an activity is performed. Calculation based on Tier Count is linked to definition in AA.SOURCE.CALC.TYPE file. If the source balance for a charge is linked to a record in AA.SOURCE.CALC.TYPE which has the definition Source Type set to ACTIVITY and Calc Type set to COUNT, then those charges are eligible to be calculated based on activity count.
  • Validation Rules
    • It is possible to specify either Tier Amount or Tier Count. Both cannot be specified simultaneously.
    • Tier Count should be defined in ascending order.
    • Last multi value of Tier Count should be blank.
• Refer limit - When set as YES, the Tier Amount field should be left blank. The Tier Amount is taken as the limit amount and the charges are calculated as per the tier. For such a setup, only two tiers are allowed, one within the limit and one beyond the limit. This feature is applicable only for Accounts Product Line.
• Tier Exclusive attribute - When this is set to YES, Tier Amount or Count or Term is reduced to its next least number for calculation of Tier Amount.

  Examples

  • For Amount - Decimal places from the currency are fetched and used as power digit with 10. Smallest number = 1/10 Power(Decimal places), that is, if the decimal places is 2, 10 Power(2) = 100. Smallest Number = 1/100 = 0.01
    • Tier Amount Defined = 10
    • Least number = Tier Amount Defined - Smallest Number, that is, 10 - 0.01 = 9.99 is the new Tier Amount.
  • For Count - Decrease the existing value by one.
    • Tier Count Defined = 8
    • New Tier Count = Old Tier Count - 1, that is, 8-1 = 7
  • For Term - Term can be defined in Days, Weeks, Months and Years. Term value defined has to be converted to days and decrease the number of days by one.

Days

• Tier Term Defined = 10 D and No conversion to Days is required
  
• New Tier Term = Old Tier Term - 1, that is, 10 - 1 = 9

Weeks

• Tier Term Defined = 3W
• Convert week into Days: 3W = 7D * 3 = 21 D
• New Tier Term = Old Tier Term(in Days) - 1, that is , 21-1 = 20

Months

• Tier Term Defined = 5M
• Convert Month into Days: 5M = 31D * 5 = 155 D
• New Tier Term = Old Tier Term(in Days) - 1, that is, 155 -1 = 154

Years

• Tier Term Defined = 2Y
• Convert Year into Days: 2Y = 365D * 2 = 730D
• New Tier Term = Old Tier Term (in Days) - 1, that is ,730 - 1 = 729

• Refer limit - When set as YES, the Tier Amount field should be left blank. The Tier Amount is taken as the limit amount and the charges are calculated as per the tier. For such a setup, only two tiers are allowed, one within the limit and one beyond the limit.
• Tiers based on Term

  Tier Term and Tier Exclusive can be used to calculate the charges based on the term of the contract. Tier Term holds the value of Term in Days, Weeks, Months & Years and Tier Exclusive when is set to YES, Tier Amount or Count or Term is reduced to its next least number for calculation of Tier Amount.

  The source calculation type should be based on a Property Type with Attribute Prop Class Term Amount and Attribute Prop Field @AA.GET.TERM.PERIOD. This source type should be added in product designer with the Source Property as commitment (Term Amount Property).

  

• Refer Limit attribute - allows the user to designate a value as Day, Week, Month, or Year. The last value in the multi-value set must be null and values should be in ascending order in the multi-value set.
• Min Chg Amount attribute - allows the user to define the minimum charge amount that is compared to the system calculated charge amount. If the charge calculated is less than the minimum amount set, then based on the waive setup attribute, either the minimum charge amount is applied or waived.
• Min Chg Waive attribute - Minimum charge waive depends on the Min Chg Amount attribute value.
  • If minimum charge waive is set as YES, then if charge amount is less than minimum charge amount, charge is waived.
  • If minimum charge waive is not set then if charge amount is less than minimum charge amount then min charge amount is collected as charge.
• Cancel Period attribute - allows the user to define a period of days within which you can cancel the charge. Value in this attribute is considered as calendar days.
• Accrual Rule attribute - accepts only a valid record from EB.ACCRUAL.PARAM. Determines the amortization start and end dates while creating EB.ACCRUAL record. Input is allowed only when the charge is set to amortize.
• Internal Booking attribute – Income or expense is posted to internal account category specified in accounting condition instead of PL categories.

• Adjust Type attribute - allows the user to specify the type of adjustment being done on charge amount. Allowed values are:
  • Adjust – Adjusting the final charge amount.
  • Override – Overriding the final charge amount with a different amount.
  • Waive – Waiving the charge altogether.
• Adjust Amount attribute - allows the user to specify the discount or mark up amount that need to be applied to the calculated charge amount.
  • For example, for a debit charge, if the calculated charge amount is USD 100 and discount amount is specified as USD 25 then the final charge amount is USD 75, that is USD 100 - USD 25. For a credit charge, the final amount is USD 125.
  • Validation Rules
    • Allowed input only when Adjust Type is ADJUST.
    • Mutually exclusive with Adjust Percentage.
    • If the amount specified is greater than the calculated charge amount, then the entire charge is discounted.
• Adjust Percentage attribute - allows the user to specify the percentage by which the calculated charge amount is to be reduced or increased.
  • Validation Rules
    • Allowed input only when Adjust Type is ADJUST.
    • Mutually exclusive with Adjust Amount.
• Adjust Reason attribute- allows the user to specify the reason for adjustment. Must be a valid record from the AA.ADJUSTMENT.REASON virtual table.
• Adjust Expiry Date attribute - allows the user to specify a fixed date on which any discretionary user adjustment is no longer applied, and the arrangement resumes its standard charge processing.

The routines can be further classified as follows:

Charge Routine

• Certain types of charging are more complex than the options available. In such case, a user-defined routine can be specified to determine the charge amount.
• AA.LOCAL.CALC.CHARGE.AMOUNT routine is attached to the Charge Routine attribute to calculate the charge amount for early redemption activity. This attribute is optional and should be a valid record in EB.API.
• This API can be enhanced with different calculation methods as per the requirement of the customer. The sample calculation method to apply charge is calculated as below. Interest is calculated on the amount being withdrawn for the current period and the interest amount is levied as charge amount.
• Sample calculation method:
  • Principal Amount – 10000
  • Interest Period Start date - 1st June 2010
  • Interest Period End date - 15th June 2010
  • Current Date - 10th June 2010
  • Withdrawal Amount – 4000
  • Day basis – E
  • Interest Rate - 6%
  • Charge Amount = (4000 * 10 * 6%) / 365 = 5.47
• In this case tolerance is set in Activity Restriction then charge is calculated on base amount and not on withdrawal amount. Base amount in this case is the difference of the withdrawal amount and the tolerance percentage.
• Assuming a rule break charge with 15% tolerance for repayment is set, the base amount becomes the difference of (REPAYMENT.AMOUNT - TOLERANCE % AMOUNT) which is (4000-1500) = 2500. In our example, interest can be calculated on the base amount of 2500.
• Tolerance can be set in Activity Restriction.
• Related attribute Default Values (Calculation)>Adjustment Routine

Adjustment Routine

• This attribute enables the user to define a routine to apply adjustment logics on a calculated or fixed charge amount as required by the user. This is an optional attribute and must be a valid record in EB.API.
• New charge amount returned by this routine is considered as the final charge amount.
• The routine attached in this attribute is triggered for all charge calculation and thus if charge adjustment has to happen for specific activities, specific charge type, specific activity date then logic has to be written for those cases based on the incoming values.
• This API is invoked for New Arrangement, Issue Bill, Makedue, and Capitalise Activities for Accrual type of charge and hence the API needs to address it as such.
• If adjustment has to happen at the time of scheduled capitalisation then API should have logic to adjust the charge amount for Issuebill and Capitalise Activities.
• If it returns 0 in the NEW.CHARGE.AMOUNT when calculated during an issue bill, then it results in the bill not being raised at all.

Indicates a valid credit interest property. During a partial or full withdrawal of a term deposit, a break cost fee is calculated and adjusted against the accruals of this interest property. This field has to be configured in conjunction with the Adjust Rate attribute .

Attaches a local API routine. During a partial or full withdrawal of a term deposit, this routine returns the adjustment or penalty rate and the date to calculate the break cost fee. Adjustment rate refers to the rate by which deposit rate has to be reduced, while the penalty rate refers to the new rate using which interest has to be calculated.

The Extend Cycle feature in AA.PAYMENT.TYPE can be applied to scheduled charges as well, to extend and collect the charges beyond the loan maturity or payment end date.

• Where the account has been set as a Memo Account (BALANCE.TREATMENT in ACCOUNT property set to MEMO), any Charge Property in the account is treated as a Memo Charge.
• Accrual or Amortization is not be supported for these types of charges.
• It is still possible to specify capitalization or make due frequencies for such Interest.
• During Make Due processing, it triggers the settlement of such Memo charge between the settlement account and a counter booking account (please see Settlement Property class for more details)

It is possible to allow arrangement to be suspended even if interest is being capitalised. This can be achieved with the PROPERTY.TYPE>SUSPEND.

AA.CHARGE.DETAILS

• This is a central file used to maintain activity or rule based charge details for an arrangement. This file has two purposes.
  • Maintains history of charges applied for an arrangement.
  • Gives information needed for the system to raise charge bills.

• During Charge Capitalisation, if the account has insufficient funds to capitalise the charge, the pending amount is invoiced to the customer. System retries the invoiced charge automatically at regular intervals using Transaction Cycler facility
• Alt Payment Method attribute in AA Payment Type is set as CAP AND INV. This indicates that bill amount has to capitalised for the funds (based on settlement rules) and invoiced for the unrealised balance.
• For Activity Charge, Scheduled Charge, Rule Break Charge when charge is set to Capitalise and Payment Type indicates Alt Payment Method attribute as CAP AND INV, the pending amount for settlement after capitalisation is invoiced to the customer.
• Settlement Condition can be set as Full, Partial or None to indicate if account is fully debited irrespective of the balance available, partially debited for the available amount or not debited at all when full funds are not available respectively. The pending charge amount, which is invoiced, is moved to INV<CHARGE>
• Recycling conditions can be set to retry capitalising the invoiced charges using Rc Type and Rc Condition in Settlement Condition.

  CAP and INV can be used only for Interest and Charges Property Class in the schedule. Periodic Charges cannot use the CAP and INV option.

• Before we do the proof and publish for that product, user needs to ensure the allocation rule is configured for the below events
• Following is the list of events released from core.

• CAP.AND.INV is allowed for aging similar to other DUE Bills.
• When an Arrangement is suspended then balances are moved to INVSP.
• Balances are cleared as part of RESUME INVSP.

The AA application allows the user to calculate, apply and amortize charges which are settled by or to the customer. The Non Customer Facing Charge(NCFC) functionality allows the user to raise internal or non-customer facing charges at contract or arrangement level. NCFC can be realised immediately or amortised.

To define a fee or cost as a NCFC property, the charge Property Type should be set as NON CUSTOMER.

• As NCFC are internal to the bank,
  • They cannot be set to capitalise or deferred.
  • An internal account or internal PL accounting head needs to be specified in the Accounting condition of the product.
  • The type of bill raised is, Internal
• NCFC can be either made due or set as payable.
• The Internal Booking Account attribute allows the user to define the Internal Account/Account Class/PL category against which the due/pay type NCFC need to be settled. This step is mandatory if the product involves a NCFC property.

  

Example 1

A loan is created and fully disbursed. There are two customer facing and three non customer facing charges associated with the loan product and linked to the disbursement activity.

In the arrangement overview, the NCFC are showcased separately. The user can modify the composite screen to hide this overview if necessary.

• For NCFC, the bills generated are of the type Internal.
• Account balance is impacted only by the customer facing charges which are capitalised. There is no impact due on account balance due to NCFC.
• NCFC are settled from the internal booking account. The statement of the internal booking account is shown below.

  

Example 2

A loan is created and fully disbursed. There are two customer facing and one non customer facing charges associated with the loan product and linked to the disbursement activity.

Consider the NCFC is set without amort/ amort.defer configuration. For NCFC, the bills generated are of the Internal type.

The Accounting Product Condition of charge property without setting accrue/amort type is shown below:

Account balance is impacted only by the customer facing charges, which are capitalised. There is no impact due on account balance due to NCFC. NCFC are settled from the internal booking account.

The non customer facing charges of ADMIN FEE is shown below:

Entry corresponding to CHARGE-ACT.MAKE.DUE-DUE-INTERNAL is shown below:

It is possible to generate a charge for a non-financial arrangement and liquidate in a financial arrangement using the Generate Charges Activity Class. The charge is defined in a non-financial arrangement. These charges can be captialised the liquidation account given in Settlement Property Class.

For the Generate Charge Activity to trigger successfully at non-financial arrangement level, the respective CHARGE property does not necessarily have to be part of the liquidation account product. Although the liquidation account product doesn’t have the respective CHARGE property, the accounting condition of charge property class in the liquidation account is used for accounting. The only prerequisite is for the charge property to be available in the Transact system based on the charges setup in accounting condition of the liquidation account.

The CHARGE property should be added at the non-financial arrangement level and the product should be used to rebuild the activities and balance types.

For example, when NEWMCYFEE charge property is added to a MCY product group, the system releases the Balance Types and Activities for this Property (Rebuild Activity and Rebuild Balance Types set to yes). The system generates the activities for the MCY product line and the Accounts product line where the charge is liquidated.

If there is no accounting setup available for charges in the defined settlement account product, the system raises an error during the non-financial arrangement creation.

For example, whenever a charge on a MCY account is to be collected, then the system triggers the Generate Charge Activity as secondary activity at default settlement or liquidation account level.

It passes the charge property, charge amount, charge payment method (capitalise only allowed), payment type, bill type, mcy arrangement id, issue bill activity reference through the context names EVENT.PRICING.NAME, FINAL.FEE, FEE.APPLICATION.TYPE, CHG.PAYMENT.TYPE, CHG.BILL.TYPE, MCY.ARRANGEMENT and MCY.AAA.ID respectively along with their values.

The context names MCY.ARRANGEMENT and MCY.AAA.ID along with values are passed on through Issue Bill Activity at settlement level.

In bill details, the system updates the Master Arr Id field with MCY.ARRANGEMENT value and the Master Issue Bill Ref with MCY.AAA.ID value. The AA.CHARGE.DETAILS are updated at the non-financial arrangement level to have the charge details/info maintained at parent level whereas AA.BILL.DETAILS are maintained at liquidation account level.

Illustration

The following example displays GENERATE CHARGE processing when a MCYBONUS activity charge type is triggered against a multi-currency account. According to product setup, the system defaults the settlement account automatically with base currency sub-account 119188. The MCYBONUS charge gets capitalised to base currency account 119188.

It is evident that, when a charge is triggered at the MCY arrangement, the system uses Generate Charge Activity Class in the liquidation account and raises accounting at liquidation account level. The system uses the Context Name and Value set of fields to transfer the following to the liquidation account:

• Issue Bill Activity that triggered the charge at the initiation non-financial arrangement
• The CHARGE property
• The final charge amount

The fee charge should be set to get capitalised against the settlement or liquidation account.

Read Charges in MCY Arrangement for more details on Generate Charge activity.

Activity Charges defines the charges that needs to be applied when an activity is triggered on the arrangement. The event which has to trigger the rebate charge can be defined at the product level. On triggering this event, the rebate is credited to the customer.

Rebate could be paid to the customer by using Payout Rules definition. In the following screenshot, LENDING.PAYOUT Payout Rules record for lending is illustrated.

In this illustration, an arrangement is created with rebate facility. View the Arrangement created for USD 50000 with values set in Settlement Instructions for Payout Account

The illustration below displays the activity log and bill generated for Rebate(Pay Charges) in Bill Details.

Bill Details

Contract wise Balances of the arrangement showing the Pay balances (Rebates)

• During charge-make-due or capitalise, the payable charge details are passed to AA.ACCRUAL.DETAILS.HANDOFF routine such that it updates EB.ACCRUAL record with negative sign for pay charge.
• Accounting entry generated is as follows
  • During due activity
    • Dr ACC<CHARGE>
    • Cr PAY<CHARGE>
  • During capitalise activity
    • Dr ACC<CHARGE>
    • Cr CUR<CHARGE>

The ACC balance is amortized by the core accounting during COB.

To support rebate amortisation, the following AC.EVENT record is created and attached to the AC.ALLOCATION.RULE for charges.

• CHARGE-MAKE.DUE-PAY-AMORT
• CHARGE-ACT.MAKE.DUE-PAY-AMORT
• CHARGE-ACT.CAPITALISE-PAY-AMORT
• CHARGE-CAPITALISE-PAY-AMORT
• CHARGE-ACT.CAPITALISE -PAY
• CHARGE-CAPITALISE-PAY

  

Property Type field is set as CREDIT for NEWARRFEE charge property to support rebate processing.

View the AC Balance Type. PAYNEWARRFEE (Payable Charge) created for NEWARRFEE Charge Property

The Accounting Property Class defines the links between external transactions and the action(s) to be performed on an arrangement. The PAY action has been defined under the DEBIT.CHARGE Allocation Rule and the Amortization period is set. The Accrue field is set as AMORT and Amort Period as 1W for NEWARRFEE Charge Property.

The Reporting Property Class is used for reporting definition in IFRS. This primarily controls the IFRS cash flows applicable for the arrangement. This Property is added to the product in order to generate the EB.CASHFLOW record.

Once an arrangement has been created an EB.ACCRUAL record is created as per definition set for the amortisation process. Each record shows certain information like the daily accrual to date and the start and end date of accrual.

View the EB.ACCRUAL record after COB Process.

The AA application allows users to amortize charges over a period of the loan tenure. When a loan becomes non-performing, the charge amortisation is also suspended and booked to the Suspend bucket [ACC <CHARGE> SP]. When the loan is resumed, subsequently the charge amortisation is also resumed.

The Stop Suspend charge functionality allows user to stop the amortisation of the charges, and the posting to Suspend bucket is also stopped.

Subsequently, when the loan is resumed, the amortisation also resumes and the system arrives at the new straight line amount from EB.ACCRUAL based on the residual loan tenure. This results in the movement between ACC<CHG> and P/L for the new amortisation amount.

When a loan moves into the Non-Performing status, the associated credit charge accrual or amortisation is suspended, provided the underlying charge is enabled for the same. Transact allows the setup of the Suspend property type for a credit charge.

Other lifecycle events

Subsequently, when the loan is resumed, Transact resumes charge accrual or amortisation and books the suspended balance against the expense P/L account. If the customer pays off the entire loan, then the total suspended amount is accounted to the respective expense P/L. However, if the bank writes-off the unpaid amount, the accounting is done involving the associated write-off expense P/L.

The configuration for a ‘Credit’ type Charge property with ‘suspend’ functionality is shown in the below screenshot.