Tax

At the AA product level, tax can be defined either at Property Class Level or at Property Level. For example, a value INTEREST in the Property Class field means if a deposit product has one or more Properties of Interest Property Class (deposit interest, commission), tax is calculated for each of these Properties. The corresponding tax code has to be entered in the Tax Code field which should hold value from TAX table or a TAX.TYPE.CONDITION can be given.

If the user wants to restrict tax to any of the Properties of the product, this can be achieved by entering the Property in the Property field and corresponding values in Property Tax Code and Property Tax Cond fields.

Only Interest and Charge Property Classes or its associated Properties can be defined. It is mandatory to specify a value either in TAX or a TAX.TYPE.CONDITION for the Property Class or Property.

The Property Class field is an associated multi-valued field, which allows to define the products on which the tax can be collected.

The Tax Code field represents a reference on the TAX table, which indicates the rate used for computation of taxation for the associated Property Class. Either Tax Code or Tax Condition fields can be allowed.

The Tax Condition field accepts a valid TAX.TYPE.CONDITION value to calculate TAX for the associated Property class. Either Tax Code or Tax Condition fields can be allowed.

The Property field is an associated multi-valued field defines the Properties on which the Tax can be collected for the product.

If defined, the associated Property Tax Code and Property Tax Condition fields take precedence over Tax Code or Tax Condition fields for related Property Class.

The Property Tax Code field represents a reference on the TAX table, which indicates the rate to be used for computation of taxation for the associated Property. Either Property Tax Code or Property Tax Condition fields can be allowed.

The Property Tax Condition field accepts a valid TAX.TYPE.CONDITION to calculate TAX for the associated Property Class. Either Property Tax Code and Property Tax Condition fields can be allowed.

The Net Tax field enables tax netting. It is used in connection with the Property Net Tax field to control netting of tax calculation.

In the Tax Property, the Net Tax field enables the functionality and in the Property Net Tax field user can define the Interest Properties that are included for netting. A minimum of two interest Properties are needed but there is no limitation to the maximum. A combination of multiple credit or debit interest Properties is allowed as well as only two credit or two debit Properties.

The Property Net Tax field is a multi-value field, which is used to define the Properties that needs to be selected for tax netting. At least two Properties must be selected. Used in connection with the Net Tax field.

Bill amounts for the properties selected here is netted before tax calculation is applied. Netting only happens for bills having matching payment dates, payment methods (PAY or DUE or CAPITALISE) as well as matching defer dates.

Interest Properties with negative rates are not netted.

• At arrangement level, it is possible to remove the values of the TAX or TAX.TYPE.CONDITION defaulted from the product level allowing for zero or no tax calculation.
• On reaching the interest schedule AA.BILL.DETAILS holds the information related to interest paid to the customer and the tax, which is charged on the interest portion.
• AA.INTEREST.ACCRUALS holds the interest accruals for the period on which the tax gets calculated. The entry for the tax is debited from the customer’s account and then credited to the category given in AC.ALLOCATION.RULE.

For annuity payment calculation, tax can be both included and excluded during calculation. The calculation is based on the settings on the Tax Inclusive field in Payment Type. If set to Yes, then the annuity is calculated including the principal, interest and the tax.

• All other Temenos Transact Modules besides AA,
  • Although the solution is generic, scope of this functionality is confined to AA. Other modules may need to be enhanced to provide relevant information to the Tax Engine in order for the Tax Engine to calculate the split.
• Back dated Tax Rate Changes
  • These do not trigger any Reverse and Replay on the arrangements and therefore it does not impact the Tax, which is already calculated.
• Forward dated tax rate changes to be reflected in Schedule Projection
• Tax on Charges
• Tax Rate Changes as a result of,
  • Change of Ownership of the Arrangement
  • Change of Product of the Arrangement
  • Change of applicable Tax bucket of the Owner of the Customer
  • Effectively these may result in the Tax Code applicable for the Arrangement itself being changed during the Interest Period – but they will not have any impact. The system will only determine the Tax Code applicable as on the Interest Payment Date and will look for any Rate Changes only under that Tax Code.
• Proportional Calculation on Interest calculated based on Compounding Interest instead of Simple Interest.
  • This is supported only if the Tax Rate change happened mid-period. Then the base amount is calculated on a pro-rated basis based on the number of days. There will be minor differences because this Pro-rata is linear and not compounded.